Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Model-based integrated total project management systems, with an emphasis on materials management Ghanbari, Abdolhamid 2006

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata


831-ubc_2006-199817.pdf [ 31.03MB ]
JSON: 831-1.0063231.json
JSON-LD: 831-1.0063231-ld.json
RDF/XML (Pretty): 831-1.0063231-rdf.xml
RDF/JSON: 831-1.0063231-rdf.json
Turtle: 831-1.0063231-turtle.txt
N-Triples: 831-1.0063231-rdf-ntriples.txt
Original Record: 831-1.0063231-source.json
Full Text

Full Text

Model-Based Integrated Total Project Management Systems, with an Emphasis on Materials Management  A B D O L H A M I D GHANBARI B.Arch.Eng., Architectural Engineering and Urban Planning and Design, Shahid Beheshti University, Tehran, Iran, 1985 M.Eng., Building Engineering, Concordia University, Montreal, Canada, 1995  A THESIS SUBMITTED IN PARTIAL F U L F I L M E N T OF T H E REQUIREMENTS FOR T H E D E G R E E OF DOCTOR OF PHILOSOPHY  in  T H E F A C U L T Y OF G R A D U A T E STUDIES  (Civil Engineering)  T H E UNIVERSITY O F BRITISH C O L U M B I A May 2006 © Abdolhamid Ghanbari, 2006  Abstract This dissertation addresses the field  of computer integrated construction (CIC), which  encompasses interoperability among architecture, engineering, construction, and facility management (AEC/FM) computer systems for the purpose of improving the efficiency and effectiveness in the A E C / F M industry. It focuses on model-based integrated total project management (PM) systems: a class of computer systems that include a suite of applications that support a wide range of P M functions and can flexibly and openly contribute to and draw from a shared pool of project information (referred to as a unified project object model) irrespective of the type of environment. Over the past two decades, many CIC projects have worked towards developing the basic building blocks of CIC; i.e., the formalization and standardization of A E C / F M project information. While the results are encouraging, they have not yet reached the level of richness and comprehensiveness required by CIC. Among the major problems identified by this research are: lack of coverage of the full range of P M functions, lack of standardization of the processes through which information flows, and lack of integration of business process and information models. The overall objective of the research was to investigate (within the context of CIC) how A E C / F M product and process information could be integrated into a unified A E C / F M project model that could support a wide range of construction P M functions, with an emphasis on materials management (MM). This was done through a coupling of topdown analytical activities (from high-level conceptual analyses to detailed modeling) and bottom-up activities (from data collection activities to analysis and design). The bottom-up investigations, which were critical in informing, providing the research criteria, and validating the models produced in the topdown activities, include a review of current project and construction management software applications, software prototyping, field data-and- process analyses, and a Process Modeling Practice Workshop. This dissertation includes a comprehensive, critical literature review and a description of the research activities and deliverables. The primary research deliverables presented are: 1) a conceptual A E C / F M Project Core Model (APCM), 2) a Conceptual P M Functions Framework (CPMF) for classifying P M functions, 3) a classification of P M / M M functions, 4) a model for the integration of A E C / F M business and software system models, called the Integrated Total Project Management Systems (ITPMS) model, 5) an implementation of the ITPMS model in a C A S E (Computer-Aided Software Engineering) tool, and 6) a set of M M domain object models and process models. A special emphasis is placed on the "modeling process" and derivation of information through business process modeling (i.e., explicit linkage of the two types of models) for a better model management. The proposed solutions collectively represent both a proof-of-concept and the means of realization of model-based integrated total P M systems. It is envisioned that they will be informing and will contribute to the CIC initiatives.  ii  TABLE OF CONTENTS ABSTRACT  ii  TABLE OF CONTENTS LIST O F T A B L E S LIST O F FIGURES  i" •.  .  •  ix  .  •  x  LIST O F ABBREVIATIONS  xv  ACKNOWLEDGEMENT CHAPTER 1  ............xvii 1  INTRODUCTION T O T H E RESEARCH  1.1 INTRODUCTION 1.2 A GENERAL BACKGROUND ; : ; 1.2.1 Definitions of Basic Terms : 1.2.2 The Key Research Ideas Interoperability and The Unified Project Object Model Integration of Business Modeling with the Software Development Process 1.2.3 Project Management Functions and the CIC Projects 1.2.4 The Materials Management Function 1.2.5 The State-of-the Art in CIC Developments 1.3 PROBLEM STATEMENT : 1.4 THE RESEARCH PLAN .: 1.4.1 The Objective and Research Questions 1.4.2 The Scope.... 1.4.3 The Methodology Research Activities and Workflows Modeling Techniques and Tools Research Deliverables The Evaluation and Validation of The Research ..: 1.5 THE ORGANIZATION OF THE DISSERTATION 1.6  CHAPTER CONCLUSIONS  CHAPTER 2  l 4 •  ...5 7  :.: ,  8 9 10  • 12 :.. 13  13  ••••  :  • ,  2.1 MODELING AND SOFTWARE DEVELOPMENT (TERMS AND CONCEPTS) 2.1.1 Some Basic Definitions : , Data, Information, and Knowledge : Process Object-Oriented Modeling Software Engineering, Software Reengineering, and Information Engineering 2.1.2 Evolution of Software Development Methods and Techniques 2.1.3 Software Development Process 2.1.4 From Requirements Model to the Design Model Domain Object Model Use Case Model... •'• 2.1.5 Summary of Modeling and Software Development 2.2 BUSINESS PROCESS MODELING (CONCEPTS AND VIEWS) 2.2.1 From Functional Orientation to Process Orientation 2.2.2 Business System versus Software System 2.2.3 Business Process versus Software Process 2.2.4 Business Object Model versus Software Object/Class Model 2.2.5 Process Reuse, along with Object Reuse  14 1.6 16 18 ...19 19 20 21 22  POINTS O F D E P A R T U R E A N D R E S E A R C H VIEWS  iii  4 5  •  , : ....  22 22 23 .23 24 ....25 25 27 30 30 31 31 32 32 33 33 34 35  2.2.6 Advantages of Basing Information Systems on Process Models 2.2.7 Summary of Business Process Modeling 2.3 MODELING TECHNIQUES AND TOOLS 2.3.1 Modeling Techniques Information Modeling Techniques Activity/Process Modeling Techniques 2.3.2 Advantages of Object-Oriented Concepts and Technology.... 2.3.3 The Unified Modeling Language: A Technology for Integration of Models 2.3.4 CASE Tools 2.3.5 XML (extensible Markup Language) Technology.. 2.3.6 Summary of Modeling Techniques and Tools 2.4 A E C / F M INFORMATION MODELING 2.4.1 Types of Information/Data Models Meta-Models Conceptual Models Core (or Reference) Models versus Application Models Type Models versus Instance Models 2.4.2 Product and Product Model 2.4.3 Product (data) Model versus Process (data) Model 2.4.4 An Overview of Some of the Existing AEC/FM Information Models G A R M [Gielingh 1988] STEP (ISO 10303) [ISO 1995a] B C C M (ISO 10303-106) [ISO 1995b and 1997] AP225 (ISO 10303-225) [ISO 1995a] : C O M B I N E [1995] C O N D O R (ESPRIT 23 105) [Rezgui and Cooper 1998] : IAI[2005] A Brief Background IFC Model Architecture IFC Specification Development Process The IFC Object Model 2.4.5 Summary of AEC/FM Information and Process Modeling 2.5 A E C / F M PROCESS MODELING ( P M FUNCTIONS)... 2.5.1 A Review of Selected AEC/FM Process Models Project and Project Management The I B P M Approach [Sanvido 1990] The ICON Approach [1994].. The MoPo Project [Karstila and Bjork 1999] '. The G D C P P Approach [2001] The P M B O K Approach [PMI 1996] '. The U B C Approach 2.5.2 Issues and Resolutions in Modeling PM Functions Complexity and Integration Issues Subjectivity Issue •. Context Issue (Specific versus Generic) The Base of Classification : 2.5J The Research Methodology for AEC/FM Process Modeling 2.5.4 Summary of AEC/FM Process Modeling 2.6 MATERIALS MANAGEMENT SYSTEMS 2.6.1 Importance of Materials Management 2.6.2 Categories of Materials Management Literature 2.6.3 Materials and Materials Management: Definitions and Technologies Construction Materials Materials Management and its scope Evolution of M M Systems and Use of IT 2.6.4 Materials Management and other PM Functions 2.6.5 A Review of Selected MM Modeling Research Cheng and O'Connor [1996] Cheng and Chen [2002]  iv  :  — •  ;  •  :  •  • •• :  :  — :  •  35 36 37 37 37 38 39 40 42 43 45 46 46 46 46 47 47 48 48 50 • ,50 52 52 53 54 57 57 58 58 '—60 60 65 65 66 • 66 66 71 77 77 81 83 83 84 84 85 86 87 90 90 '-90 92 94 94 96 97 98 100 100 100  Echeverry and Beltran [1997] Kong, Li, and Love [2001] Pheng and Chuan [2001]  Riley and Sanvido [ 1995 and 1997]  Sullivan [1989]  : =  :  101 101 102  103 •  •  105 From Tommelein and Zouein [1993] To Riley and Tommelein [1996] Summary of M M Literature Review 2.6.6 The Approach to Modeling MM Processes and Information Requirements  2.6.7 2.7  '•  •  108 109  :  Summary of Materials Management Systems  :  CHAPTER CONCLUSIONS  CHAPTER 3 3.1  The Scope The Methodology  106 107 108  A  •  112  BOTTOM-UP INVESTIGATIONS AND R E S E A R C H CRITERIA  REVIEW OF CURRENT  PM/CM  113  SOFTWARE APPLICATION SYSTEMS..  3.2 SOFTWARE PROTOTYPING 3.3 FIELD INVESTIGATIONS 3.3.1 The Goal and Objectives 3.3.2 The Methodology and Results , 3.3.3 The UBC Faculty and Staff Housing (Thunderbird) Project 3.3.4 CM/MM in the Thunderbird-1 Project : 3.3.5 An Overall Assessment of the Thunderbird Project.... 3.3.6 The Use of Information Technology •• 3.3.7 Major Outcomes and Lessons Learned 3.3.8 Summary of Field Investigations 3.4 T H E PROCESS MODELING PRACTICE WORKSHOP 3.4.1 The Goal and Objectives 3.4.2 The Methodology and Participants ': '.. 3.4.3 Results and Lessons Learned : 3.4.4 Summary of the PMPW : 3.5 SETTING RESEARCH CRITERIA 3.5.1 General Modeling Criteria : 3.5.2 Flexibility as a Basic Requirement 3.5.3 Summary of Research Criteria 3.6 CHAPTER CONCLUSIONS , CHAPTER 4  112  :  113  -114 115 115 116 117 117 121 • 124 125 • 126 128 • 128 •• 128 129 130 133 133 133 134 135  :  • :.-  :  • , •  A E C / F M PROJECT INFORMATION MODELING REQUIREMENTS  A E C / F M PRODUCT INFORMATION MODELING 4.1.1 Product-Related Concepts: Target Product, Space, and Material 4.1.2 Form, Function, and Behavior/Performance 4.1.3 Products and their Environment: The Concept of Agent..:... 4.1.4 Views 4.1.5 Product Models and PM Functions: Examining Existing Product Models Target-Product and Space Concepts in Models Form Information , Functional Information..... Behavior/Performance Information Change and Versioning : 4.1.6 Material Information Modeling Material: Evolution and Changing Roles Material Information In AEC/FM Information Models.. : Material Information in the IFC Model Summary of Material Information Modeling : 4.1.7 Summary of AEC/FM Product Information Modeling 4.2 BEYOND PRODUCT INFORMATION: MODELING PROJECT INFORMATION 4.2.1 Properties and Relationships of Objects Some Modeling Issues on Properties and Relationships Properties and Relationships in the IFC Model  136  4.1  136  ;  v  —•  • •  •  136 137 138 139 139 140 142 143 145 147 150 150 152 154 158 158 159 159 159 160  4.2.2  4.2.3  4.2.4  4.2.5 4.2.6 4.3  :  Role Players and Roles Roles in the IFC Model Beyond Organizational Roles Some Guidelines for Modeling Roles Summary of Roles of Objects  ,  ;  Process-Centered Construction The Need for Standardization of Transactions Transaction Information in the IFC Model Some Guidelines for Modeling Transactions Summary of Processes and Transactions  168 -168 171 172 173  •  Transactions in Construction Projects  •  • 174 •  •••• 174 174 176 •••• 178 • 179  : : '.  An Examination of the IFC Object Model Using Coad's DNC Model Summary of Modeling Beyond Product Information  180 181 •  181  A CONCEPTUAL A E C / F M PROJECT C O R E M O D E L (APCM)  183  '.  Subtypes of Occurrence Object Subtypes of Type Object.... Subtypes of Property Definition Subtypes of Relationship  183 183  • '.  ..•  184 184 185 185 186  :  Subtypes of Thing Subtypes of Physical Thing Subtypes of Role Subtypes of Event Subtypes of Process Subtypes of Transaction Subtypes of Aspect  186 187 .....188 • 189 190 190 • • • 192  :  195  PROJECT M A N A G E M E N T FUNCTIONS CLASSIFICATION  196  '.  196  Project Objectives Basic PM Functions Project Elements  196 .....797 198 200 202  A Tabular Listing of PM Functions A Hierarchical Classification of PM Functions T H E INTEGRATED 212  • 163 164 166 166 167  -168  •  202 208  CHAPTER CONCLUSIONS.....  CHAPTER 7 MODEL 7.1 7.2 7.3 7.4  Roles of Objects  A CONCEPTUAL P M FUNCTIONS FRAMEWORK (CPMF) FURTHER EXPLORATION OF P M FUNCTIONS  6.3.1 6.3.2 6.4  :  DIMENSIONS OF PROJECT MANAGEMENT  6.7.7 6.1.2 6.1.3 6.2 6.3  163  CHAPTER CONCLUSIONS  CHAPTER 6 6.1  162 •  LOWER-LEVEL OBJECTS OF THE MODEL  5.3.1 5.3.2 5.3.3 5.3.4 5.3.5 5.3.6 5.3.7 5.4  Type and Occurrence Information Type and Occurrence Information in Models Type and Occurrence Information in the IFC Model How Type and Occurrence Information are Used and Related Summary of Type and Occurrence Information  T H E SCOPE OF THE MODEL T H E BASIC STRUCTURE OF THE MODEL  5.2.1 5.2.2 5.2.3 5.2.4 5.3  ;  CHAPTER CONCLUSIONS  CHAPTER 5 5.1 5.2  Summary of Properties and Relationships  Levels of Specificity of Objects: Type and Occurrence Information.....  ••  TOTAL  T H E I T P M S MODEL ARCHITECTURE T H E META-MODEL OF THE ITPMS MODEL.... A N APPLICATION OF THE ITPMS MODEL CHAPTER CONCLUSIONS  PROJECT  MANAGEMENT  SYSTEMS  '. : '.  vi  211  (ITPMS)  :  212 214 217 218  CHAPTER 8  T H E MATERIALS M A N A G E M E N T PROCESS AND INFORMATION MODELING... 219  CLASSIFICATION OF M M FUNCTIONS : 219 8.1.1 Managerial Processes versus Operational-Technical Processes 219 8.1.2 Functional Bodies Involved in MM processes 220 8.1.3 Major Categories of MM Processes 227 8.1.4 A Hierarchical Classification of MM Processes 222 8.2 M M BUSINESS PROCESS MODELING IN THE ITPMS MODEL STRUCTURE 230 8.2.1 An Overview of the Model and MM Processes..: 230 The High-Level Components of the Model 230 The M M Package at a Glance : ...231 The Assignment of Stereotypes to Model Elements • 233 8.2.2 MM Initiation... 233 8.2.3 MM Planning. ...... 234 Materials Requirements Planning • 234 M M System Planning 237 8.2.4 MM Organizing. • • — 239 8.2.5 MM Execution • 239 8.2.6 MM Controlling ; 242 Materials Controlling 242 M M System Controlling , 242 8.2.7 MMCloseout '. • ......243 8.2.8 MM Follow-up & Redirection ". : 243 8.3 BUSINESS USE CASE MODELING IN THE ITPMS MODEL STRUCTURE 243 8.3.1 An Overview of the Business Use Case Models •••• 243 8.3.2 An Example: Materials Request Processing 244 Use Case: "Request Materials" —• 245 The Scope .' • 245 Preconditions 246 Postconditions 246 Main Flow of Events (MFE) '. 246 Exceptional Flows of Events (EFE) '. 246 Activity Diagrams • 246 Use Case: "Process Materials Request" 248 . The Scope : '. ...... •• 248 Preconditions .• .. 248 Postconditions .' .' • -248 Main Flow of Events (MFE) —•• 248 Exceptional Flows of Events (EFE) 248 Activity Diagrams : 249 8.4 M M BUSINESS OBJECT MODELING IN THE ITPMS MODEL STRUCTURE 251 8.4.1 An Overview and the Approach to Business Object Modeling 252 8.4.2 Business Objects and Domain Packages 252 8.4.3 Types of Information Attached to Business Objects ; 253 8.5 CHAPTER CONCLUSIONS • • -254 8.1  CHAPTER 9  EVALUATION AND VALIDATION OF T H E RESEARCH  9.1 THE OVERALL RESEARCH EVALUATION AND VALIDATION 9.2 AN EVALUATION OF THE A P C M . . 9.2.7 Advantages and Limitations of the Model 9.2.2 Linkage between the APCM and the IFC Model. 9.3 AN EVALUATION OF THE C P M F MODEL. 9.4 AN EVALUATION OF THE ITPMS MODEL 9.5 A N EVALUATION OF THE M M SYSTEMS MODELS 9.5.7 Advantages and Limitations of the Results The Conceptual Classification of M M Processes ITPMS-Based M M Models 9.5.2 The CASE Tool Evaluation 9.5.3 Other Observations and the Next Steps  vii  256 256 261 -—  •  : — •  '. •  267 264 — 267 267 270 270 270 -271 272 273  9.6  CHAPTER CONCLUSIONS  C H A P T E R 10 10.1  274  CONCLUSIONS AND RECOMMENDATIONS  .  275  SUMMARY  275  10.1.1 Problems 10.1.2 The Overall Objective and Premise 10.1.3 Actions, Results, and Values 10.2 CONTRIBUTIONS AND BENEFITS 10.3 RECOMMENDATIONS. 10.4 FURTHER RESEARCH  ,  :  ;  REFERENCES  •  275 276 276 278 .....279 280 •••• 283  APPENDIX A:  SELECTED MODELING TECHNIQUES AND TOOLS  297  APPENDIX B:  S E L E C T E D C O M M E R C I A L P M / C M S O F T W A R E STUDIED  324  APPENDIX C:  A PROTOTYPE M M APPLICATION SYSTEM  330  APPENDIX D:  M M BUSINESS O B J E C T S  356  viii  List of Tables Table 2-1: Activity Zones and their Responsibilities in GDCPP  79  Table 3-1: The General Characteristics of the Buildings of Thunderbird-1  117  Table 3-2: The Quantitative Characteristics of the Models  131  Table 3-3: Process Breakdowns in the Produced Models  132  Table 6-1: Project Elements versus Basic P M Functions  204  Table 6-2: Project Elements versus Project Elements  ;  207  Table 9-1: The Primary Research Deliverables Responding to the Research Criteria....  258  Table 9-2: A Mapping Between the A P C M Objects and the I F C s  265  Table A - l : Possiblity of Inclusion and Composition Relationship Between Model Elements in the Streams  :  320  Table B - l : Attributes of Selected Commercial P M / C M Software Applications Studied  324  Table D - l : M M Business Objects in the ITPMS Model Implementation  356  ix  List of Figures Figure 1-1: The Basic Idea: A Unified Project Object Model for Communication of Project Information 6 Figure 1-2: The Research's Modeling Approach Compared with Software Development Methodologies 8 Figure 1-3: The Knowledge Areas Within the Scope of the Research  .  15  Figure 1-4: The Modeling Domains of the Research  15  Figure 1-5: The Research Activities and their Workflows...  :  Figure 2-1: The Unified Software Development Process: Phases and Core Workflows  17 28  Figure 2-2: A Schematic Activity Diagram of the Core Workflows within each Phase of a Software Development Process  29  Figure 2-3: Business Process and Software Process in a Business System  35  Figure 2-4: Product Data Model versus Process Data Model  49  Figure 2-5: High-Level Entities in the G A R M Model  ...51  Figure 2-6: A Partial Classification Hierarchy of High-Level Objects in B C C M  53  Figure 2-7: A Partial, Simplified Model of Product View in AP225  54  Figure 2-8: A Partial, Simplified Model of Product View in C O M B I N E  56  Figure 2-9: IFC Model Layers and Modules/Schemas  59  Figure 2-10: A Partial Model of the Kernel Module of the IFC Object Model  64  Figure 2-11: The IBPM's Process Breakdown Streucture (p. 1/4)  68  Figure 2-12: The ICON'S Process Breakdown Structure (p. 1/4)  73  Figure 2-13: A n Example of Hierarchy of Sub-Processes for the Phase 0 in GDCPP Model  80  Figure 2-14: The Process Groups within a Project Phase  82  Figure 2-15: Some of the Major Process Areas in Construction Materials Management....  85  Figure 2-16: The Activities Involved in the P M Process Modeling of the Research  89  Figure 2-17: Communication Links among Organizational Functions  99  Figure 2-18: Construction-Space Decomposition  ,  103  Figure 2-19: The High-Level Process (Create Construction Sequence) in the Space Planning Process Model  104  Figure 2-20: A Hierarchical Representation of Space Planning Processes........  105  Figure 2-21: The Workflow Involved in M M Process Modeling  110  Figure 2-22: The Workflow Involved in M M Information Modeling  Ill  Figure 3-1: The Thunderbird Project, North East View of Phase 1, Building A (top left) and Building B (right); August 14, 2000  118  Figure 3-2: The Thunderbird Project, North East View of Phase 1 (Building B , right) and Phase 2 (Building C, left), February 1, 2005  .118  Figure 3-3: Concrete Supplier Selection and Contracting Processs in Thunderbird-1  120  Figure 3-4: Reinforcement Delivery Ticket Strapped and Left in the Open Laydown Area  122  Figure 3-5: A n Example of a Label Stuck on Window's Glass (in the 3 Floor, Unit B312)  122  Figure 3-6: Unloading Labeled Lumbers....  123  Figure 3-7: Cutting the Foundation Wall to Run Electrical and Communication Cables  123  rd  Figure 3-8: Concrete Tester Transferring Information from a Delivery Ticket to his Concrete Test Report 125 Figure 3-9: Concrete Delivery Ticket Covered with Patches of Concrete  125  Figure 4-1: A Conceptual Representation of Product-Related Concepts  137  Figure 4-2: The Product, its Aspects, and its Environment  139  Figure 4-3: Product-related Objects in the IfcProductExtension Schema of IFC R2x  141  Figure 4-4: The IfcProxy Object in the IfcKernel Schema of IFC R2x  142  Figure 4-5: A Partial, Simplified Model of Functional View in C O M B I N E . . .  145  Figure 4-6: Versioning and Change in AP225  147  Figure 4-7: Change Order in the IfcSharedMgmtElements Schema of IFC R2x  148  Figure 4-8: Approval in the IfcApproval Resource Schema of IFC R2x  149  Figure 4-9: A Simplified Model of Material View, with Selected Attributes, in C O M B I N E  153  Figure 4-10: A Model of Material (Property) View in AP225.  153  Figure 4-11: A Model of Material View and its Related Entities in B C C M . . . .  154  Figure 4-12: The Resource Objects in the IfcConstructionMgmtDomain Schema of IFC R2x  155  Figure 4-13: Material-related Objects in the IfcMaterialResource Schema of IFC R2x  156  Figure 4-14: Association of Building Elements and Material Definitions  157  Figure 4-15: Material Properties in the IfcMaterialPropertyResource Schema of IFC R2x  157  Figure 4-16: Properties in the IFC Object Model  161  Figure 4-17: Levels of Abstractions (Generic, Type, and Occurence Information)  164  Figure 4-18: Type and Instance (i.e., Occurrence) Objects in TOPS  165  Figure 4-19: Actor-Related Objects in Various Schemas of IFC R2x (Base Schema: IfcActorResource) ......170 Figure 4-20: Contextual and Non-Contextual Actors and Roles in IFC R2x  172  Figure 4-21: The Specialization Hierarchy of IfcControl in IFC R2x  177  Figure 4-22: A Partial View of the High-Level Objects in the IFC Model  181  Figure 5-1: The Basic Entities of the Proposed A E C / F M Project Core Model (APCM)  193  xi  Figure 5-2: The Specialization Hierarchy of the Physical Thing.  194  Figure 5-3: Subtypes of the Process  194  Figure 5-4: Subtypes of the Transaction  194  Figure 6-1: A Typical Project Process and Its Elements  :  199  Figure 6-2: Dimensions of Project Management  201  Figure 6-3: P M Functions relating to Cost and Material  202  Figure 6-A: A Simplified Portion of the Hierarchy of P M Functions  209  Figure 7-1: The Views and their Dependency Relationships and Artifacts in the ITPMS Model.  214  Figure 7-2: The Meta-Model of the Incorporated Views of the ITPMS Model..  215  Figure 7-3: The Meta-Model of the ITPMS Model  216  Figure 8-1: Major Functional Bodies Involved in M M Processes  221  Figure 8-2: The Major Groups of Materials Management Processes  222  Figure 8-3: Overall Process Breakdown of Managerial Processes ("Manage M M System")  224  Figure 8-4: Overall Process Breakdown of Operational Processes ("Manage Materials") (p. 1/2)  225  Figure 8-5: A Partial Process Breakdown of "Plan Materials"  226  Figure 8-6: A Partial Process Breakdown of "Procure Materials" (p. 1/2)  227  Figure 8-7: A Partial Process Breakdown of "Handle Materials"  229  Figure 8-8: The Top-Level Model Eelements of the ITPMS Implementation Model  230  Figure 8-9: The Basic P M Topic Areas Defined in the ITPMS Implementation Model  231  Figure 8-10: The First-Level of M M Business Processes in the ITPMS Model  232  Figure 8-11: The Overall Structure for M M Process Modeling in the ITPMS Model  232  Figure 8-12: A n Example of the Assignment of Stereotypes to Packages  233  Figure 8-13: The "Materials Requirements Planning" Package in the ITPMS Model  235  Figure 8-14: The " M M System Planning" Package in the ITPMS Model  237  Figure 8-15: A Partial View of the " M M Execution" Package in the ITPMS Model.  240  Figure 8-16: "Materials Request Processing" Use Case Digram  245  ,  Figure 8—17: "Request Materials" Activity Diagram  247  Figure 8—18: "Process Materials Request" Activity Diagram  250  Figure 8—19: "Source And Allocate Materials To Request" Activity Diagram  251  Figure 8-20: The Business Object View of the ITPMS Implementation Model  253  Figure 8-21: Association of Images of Real Objects (e.g., documents) with Business Objects  254  Figure 9-1: The Evaluation/Validation Relatinships Among Major Research Deliverables  257  Figure 10-1: An Schematical Speculation of the Horizon of Data Modeling and Exchange Technology Development & Adoption  281  xii  Figure A - l : The Domain-Neutral Component  ..:  299  Figure A - 2 : The Graphical Notations of Basic Modeling Elements in E X P R E S S - G (p. 1/2)  302  Figure A - 3 : Example IDEF Activity Diagram (Construct Stud-Wall Frame)  304  Figure A-A: The Breakdown Structure of I D E F Diagrams  305  0  0  Figure A - 5 : A Node Tree of an IDEF Model  :  0  306  Figure A - 6 : The Graphical Notations of Basic Modeling Elements of the U M L (p. 1/2)  310  Figure A - 7 : An Example of a Use Case Diagram  312  Figure A - 8 : Use Case, Actors, and their Relationships in a Use Case Diagram..  313  Figure A - 9 : An Example of Presentation of Stereotypes  :.  ...316  Figure A-10: The Graphical Notations and Meanings of the Basic Modeling Elements of a Streams Model (p. 1/2)  :  ..318  Figure A - l 1: A Simplified Metamodel of the Streams  320  Figure A-12: The Streams User Interface Elements  322  Figure A - l 3: Two Specification Windows for an Activity and an Object.  323  Figure C - l : A Reference Architecture for Distributed, Model-Based, Integrated Systems.  334  Figure C - 2 : The Major Components of the JDS version 0.6  336  Figure C - 3 : The Workflow Involved in Creating the "Jigsaw Application Objects" Component (Using the JMT and M S - V B )  '.. '.. 338  Figure C-A: The Main J M T Interface  339  Figure C - 5 : The JMT's Import/Export Interface...  339  Figure C-6: Relationships Between Tables  ".  340  Figure C-7: The Database Tables Populated with Cost Data  341  Figure C-8: Multiple Tree Views for Simultaneous Reviewing and Editing of Project Data....  342  Figure C-9: The Intitial Setting of Connection Type to X M L Data Source  343  Figure C-10: Opening an Existing Project File ( X M L Format)  344  Figure C - l 1: The Project Information Displayed in the Tree-View Window  345  Figure C-12: Viewing and/or Editing Grneral Project Information  346  Figure C - l 3 : Selecting and Adding a Type of Material from the Materials Database  347  Figure C-14: Project Material Information Form Updated with Detailed Information from the Materials Database  348  Figure C-15: Adding A New Procurement Task to the Project  348  Figure C-16: Assigning a Material Type to a Task Using Tree View Window  349  Figure C - l 7 : Exporting the Project Model as a M S Project File (Saving Interfaces)  350  Figure C-18: Exporting the Project Model as a M S Project File (Log Options Window)  351  xiii  Figure C-19: Exporting the Project Model as an M S Project File (Log Window)  351  Figure C-20: Exporting the Project Model as an M S Project File (Planning Windows)  352  Figure C-21: Importing the Project Model in the A M S Tool  353  xiv  List of Abbreviations AEC:  Architecture, Engineering, and Construction  AEC/FM:  Architecture, Engineering, Construction, and Facility Management  AP:  Application Protocol  APCM:  A E C / F M Project Core Model  API:  Application Programming Interface  BCCM:  Building Construction Core Model  BPR:  Business Process Reengineering  CAD:  Computer-Aided Design  CASE:  Computer-Aided Software Engineering  CIC:  Computer Integrated Construction  CIM:  Computer Integrated Manufacturing  CM:  Construction Management  CPMF:  Conceptual Project Management Framework  DBMS:  Database Management System  FFB/P:  Form, Function, and Behavior (or Performance)  HR:  Human Resource  HRM:  Human Resource Management  IAI:  International Alliance for Interoperability  IFC:  Industry Foundation Classes  IDEF:  I C A M (Integrated Computer Aided Manufacturing) Definition  IDEFo:  Integrated Definition for Function Modeling  IDEFIX:  Integrated Definition for Information Modeling Extended  IR:  Integrated Resource  ISO:  International Organization for Standardization  IT:  Information Technology  ITPMS:  Integrated Total Project Management Systems  JDS:  Jigsaw Distributed System  JMT:  Jigsaw Modeling Tool  MDI:  Multiple Document Interface  MM:  Materials Management  MS-VB:  Microsoft Visual Basic™  MS-Access: Microsoft Access™  XV  OOAD:  Object-Oriented Analysis and Design  OOSE:  Object-Oriented Software Engineering  PM:  Project Management  PMBOK:  Project Management B o d y of Knowledge  PMPW:  Process M o d e l i n g Practice Workshop  PMI:  Project Management Institute  QM/QC:  Quality Management/ Quality Control  RM:  Resource Management  SADT:  Structured Analysis and Design Technique  SGML:  Standard Generalized Markup Language  STEP:  STandard for the Exchange of Product model data  UI:  User Interface  UML:  Unified M o d e l i n g Language  XML:  extensible M a r k u p Language  xvi  Acknowledgement In The Name of God, The Compassionate, The Most Merciful  This dissertation was made possible with contribution of many individuals and organizations that deserve my sincere thanks. Specifically, I would like to express my sincerest gratitude to: •  M y research supervisor, Dr. Thomas Froese, for his encouragement throughout the course of research and his valuable guidance and comments on several drafts of the dissertation.  •  M y other research committee members, Dr. Alan Russell (Civil Engineering) and Dr. Jerzy Wojtowicz, (Architecture) for their time spent on reviewing the dissertation and for their profound comments, which helped improve the quality of the dissertation dramatically.  •  Dr. Richard Rosenberg (Computer Science), Dr. Tarek Sayed (Civil Engineering), Dr. Farraokh Sassani (Mechanical Engineering), and the extarnal examiner, Dr. Brenda McCabe (Civil Engineering, University of Totonto), for examining the dissertation.  •  The construction organizations and practitioners, especially the University of British Columbia Properties Trust, Mr. Robert Malcolm (the principal and C E O of the Timberline Construction Group Western, TCGW), and Robert Currie and Steve Patitucci (the TCGW's Superintendents), for providing me the access to their construction fields and information resources.  •  Ensemble Systems Inc., for its generous provision of a free copy of Ensemble Streams™ to the research, and the invaluable supports of its technical staff.  •  The many other software companies, who responded to my requests with their invaluable information and provided trial- or full-version copies of their software solutions.  •  And last but not the least, my beloved ones: my dearest, my mother, who dedicated herself to build the foundation of my current position and encouraged me to continue my studies; my true love and my source of hope, my wife, for her endless love, understanding, and encouragement, and for providing me the possibility to concentrate on my research; and my endless source of joy and inspiration, my children, for their patience and understanding in this journey. I wish them all the blessings of God and a real success in their personal, social, and business life.  Abdolhamid Ghanbari Vancouver, Canada May 2006.  xvii  CHAPTER 1 Introduction to the Research This dissertation addresses the field of computer integrated construction (CIC) with a focus on model-based integrated total project management (PM) systems: a class of computer systems that include a suite of applications that support a wide range of PM functions and can flexibly and openly contribute to and draw from a shared pool of project information irrespective of the type of environment. More specifically, it examines how various types of construction project information could be modeled in an integrated manner to support integration of various functions involved in the management of the project throughout its life cycle. This chapter provides an overall description of the research—the background, problem statement, objectives, scope, methodology, and deliverables—and the structure of the dissertation. 1.1  Introduction  Construction projects are characterized by their complexity, which provides the basis for fragmentation in the AEC/FM (architecture, engineering, construction, and facility management) industry. Among the factors that collectively contribute to this complexity are the uniqueness and relatively short life span of projects, the high volume of (often non-standardized) information exchanged among a large number of ever-changing project participants, and the different views of participants on the project information. In this context, information management is a key to technical integration (e.g., data integrity and consistency) as well as managerial integration (e.g., who is responsible for what, where, and when). Information Technology (IT) has been used as an effective strategy to improve both efficiency and effectiveness in organizations [Cash et al. 1994]. In the AEC/FM industry, however, despite its use in a variety of application areas, computers have not been employed to their maximum potential. Many reasons for such failures have been identified, and potential solutions have been suggested [Howard et al. 1989; Bedard et al. 1991; Teicholz and Fischer 1994; Amor and Faraj 2001]. In particular, computer integrated construction (CIC) has been proposed as a strategy to overcome the inherent fragmentation of the industry (section 1.2.1) [Howard et al. 1989; Teicholz and Fischer 1994]. Existing commercial software application systems serve a variety of design, engineering, and PM functions (e.g., estimating, scheduling, accounting, etc.); however, integration between these functions has not yet occured [Paulson 1995; Eastman 1999], a situation that is referred to as "islands of automation". Some of the areas for potential computer-based integration have been addressed by researchers [Fischer et al. 1994; Amor and Faraj 2001]. Central to this integration is the formalization and standardization of information.  1  Different approaches have been taken towards this formalization and standardization of information in the A E C / F M industry. Many models have been proposed and many prototypes have been developed [e.g., Bjork et al. 1993; Stumpf et al. 1995; Rezgui and Debras 1995]. However, the use of standard objects and the development of core models integrating some related application models (section has received the most attention [Froese 1992; Teicholz and Fischer, 1994; Wix and DP 1995; Froese 1996a &1996b; Rezgui and Cooper 1998; IFC R2x, 2001]. One of the recent efforts in this information standardization is the on-going IAI (International Alliance for Interoperability) project [IAI 2005]: an industry project parallel to the ISO standard 10303, STEP (STandard for the Exchange of Product model data) [Froese 1996c; Wix and DP 1995]. It has applied the STEP-based technology to the industry's software products to create a project data standard called the Industry Foundation Classes (IFC's) aimed to provide software interoperability in A E C / F M industry at the international level. Due to the central role of product information (e.g., the physical and geometrical attributes of a building and its physical components) on an A E C / F M project, product modeling has been a major focus to most of A E C / F M information modeling efforts (as opposed to other types of project information such as processes, costs, organizational information, etc.). Product information is normally a central reference to operations of most C M (Construction Management) functions; however, such information is not explicitly represented in current C M systems and, thus, is not readily available to these functions [Fischer et al. 1995; Ghanbari and Froese 1999]. In general, product information is dealt with and modeled more from a designer's perspective and less from a construction manager's view. Moreover, due to the very close relationship between different types of information in a project, a need has also been recognized for the integration of all types of information (i.e., product, process, cost, resource, etc.) into a common project information/object model (section [Teicholz and Fischer, 1994; Fischer et al. .1995; Froese 1996a &1996b]. Yet, there still seems to be gaps between existing models and those required for the true CIC environment. The methodology adopted by current CIC projects involves a loose link between the modeling workflows and their related artifacts, especially the process models (specifying the way the business runs) and information models (specifying the structure of the information communicated between processes). This issue can impact the effectiveness of the resulting models. This lose link is observed in the IAI project's methodology [IFC R2.0, 1999c]. In the current IFC object model [IFC R2x2-1, 2004], which represents the state-of-the-art model, there is a lack of coverage of all functions involved in the management of an A E C / F M project and their related information requirements. There is a need for a framework that comprehensively covers all possible P M functions (i.e., not limiting to estimating, planning, and scheduling), and there is a need to examine how P M functions view and use project information.  2  This dissertation investigates model-based integrated total PM systems. It examines how AEC/FM product and process information can be integrated into a unified AEC/FM project model that can support a wide range of construction project management (PM) functions, with an emphasis on materials management, within the context of a CIC environment. It places an emphasis on the process of modeling; i.e., integration of business process modeling and software engineering [Jacobson et al. 1999]  in the context of CIC integrated total PM systems development. This dissertation presents the research results as follows: •  an overall description of the research—the background, problem statement, objectives, scope, methodology, and deliverables of the research—and the structure of the dissertation (this chapter);  •  an extensive critical review of current literature and models related to the knowledge areas of the research and the research's views on identified issues and to a set of research criteria (Chapter 2);  •  a description of the bottom-up (i.e., from specific to general) investigations that contributed to the understanding of the requirements for integrated project management systems in general and materials management in particular: examination of current P M / C M software applications, software prototyping, field investigations (observation of processes, collection and analysis of field documents, and models, and field interviews), and a Process Modeling Practice Workshop (Chapter 3);  •  a top-down examination (i.e., from general concepts to detailed requirements) of current A E C / F M information models to identify their level of support for P M functions and requirements of an A E C / F M project information model (Chapter 4);  •  a conceptual A E C / F M Project Core Model (APCM) addressing the requirements (Chapter 5);  •  a Conceptual Project Management Framework (CPMF) proposed and used by the research for classification of P M functions (Chapter 6);  •  an Integrated Total Project Management System (ITPMS) model for integration of models of A E C / F M business and software systems, and an overall explanation of its application (Chapter 7);  •  the results of an implementation of the ITPMS model in a Computer-Aided Software Engineering (CASE) tool—i.e., a set of Materials Management (MM) process and object models (Chapter 8);  •  an evaluation of the research results against the research criteria and the requirements defined in earlier chapters (Chapter 9); and  •  a conclusion to the dissertation (Chapter 10). The proposed models ( A P C M , CPMF, ITPMS, and M M process and object models) correspond  to successive layers (from abstract to concrete) that build towards the creation of IT solutions for A E C / F M interoperability, and each model builds upon, implements, and validates (in part) the previous  3  model. The research encompasses a coupling of top-down and bottom-up approaches, and places a special emphasis on derivation of information requirements through business process analysis and modeling. It is envisioned that the results of this research will contribute to the CIC movement by informing on-going, major CIC projects.  1.2  A General Background This section presents the key definitions and research ideas and highlights the various dimensions  of the research. It is intended to facilitate the definition of the research's problem statement and plan.  1.2.1 Definitions of Basic Terms In this dissertation, the term project is used to refer to a temporary endeavor undertaken to build a unique constructed facility. Construction management (CM) involves the project delivery activities, from conceptualization to construction and hand-over of the product to the owner. Moreover, the term project management (PM) is broadly used in the context of construction projects to refer to the management of any portion of the development life cycle of any type of facility [Kavanagh et al. 1978; PMI 1996]. The term " A E C " stands for architecture, engineering, and construction [Howard et al. 1989], and refers to construction and related industries. " A E C / F M " broadens the scope to include a wider life span of construction projects, including facility management. In this dissertation, A E C , A E C / F M , and construction are all used interchangeably to refer to construction projects (including their complete lifespan from cradle to grave) and their related industries. The construction industry is distinguished from other industries (especially from manufacturing) by its complex nature, which is mainly due to a series of interrelated characteristics of the industry [Hendrickson and A u 1989; Howard et al. 1989; Bedard et al. 1991; Teicholz and Fischer 1994]: 1) Project-Orientation:  The industry is project based, as opposed to ongoing repetitive work.  2) Uniqueness: Each project is unique (e.g., in products, processes, organization, and resources). 3) Short Duration of Business: Projects generally have a short, finite life cycle (typically a few years, which is a short time period relative to the lifespan of the large organization carrying out the project). 4) Work Place: Construction projects take place on sites that are different for each project and that generally involve challenging outdoor work environments. 5) Business Instability (in terms of organization and processes): Resources are usually aquired on an asneeded basis, while this is not normally practiced in a hospital or manufacturing environment, for instance. Moreover, the initiation of a project generally means the start of a new business venture with a new set of players coming into the overall business of the enterprise.  4  6) Technological Diversity: The industry embraces a wide range of technologies (e.g., building materials, equipment and tools). 7) Diversity of Skills and Views: The industry comprises a large number of small groups of narrowskilled trades with widely differing views and interests and levels of technological capabilities and adaptability (i.e., a desire to change). The industry is heavily dependent on individuals' knowledge, which widely varies from one person to another. 8) Non-Standardization and Fragmentation: A lack of standardization exists in the all dimensions of the industry (in terms of products, resources, processes, procedures, organization, and information). This contributes to the fragmentation of the industry in all its dimensions. The sum of the aforementioned characteristics contributes to the inherent complexity of the construction industry, causing many challenges for the planning and management of AEC/FM projects. Computer Integrated Construction (CIC) has been put forward as a strategy to overcome the inherent fragmentation of the industry through technical integration (e.g., data integrity and consistency) and, consequently, managerial integration (e.g., what is where, and who is responsible for what), which results in enhanced efficiency and effectiveness of processes. CIC is defined as a business process that links the project participants in a facility project into a collaborative team through all phases of a project. Use of information technology to share data and knowledge between team members, in a realtime manner, is an integral part of CIC [Teicholz and Fischer, 1994]. CIC is analogous to Computer Integrated Manufacturing (CIM), used in other branches of industry.  1.2.2 The Key Research Ideas  Interoperability and The Unified Project Object Model Today's typical computer programs in the AEC/FM domains could be described as being largely  stand-alone application systems owning and managing their own data. These systems range from generalpurpose tools (e.g., word processing, image processing, accounting, drafting, and scheduling) to specialized tools (e.g., construction-oriented drafting and design, construction cost estimating and cost control packages). They have some limited ability to exchange data with other programs through some specific file formats (e.g., using DXF file format in CAD—-computer aided drafting/design—programs), but they are not interoperable to any significant degree, and human interpretation and manual translation of data is required to move data from one program to another. In most cases, there is no common language for communication among related applications; i.e., no consensus on project concepts/objects (e.g., material, product, process, resource, and order) and their relationships (e.g., a process uses one or  5  more resources) among the programs that use and manipulate them. To overcome this problem, the idea of a unified project object model has been evolved [Teicholz and Fischer, 1994; Froese 1996b; IAI 2005]. Figure 1-1 illustrates this emerging idea, which was fundamental to this research, by a scenario in .which a set of related P M software application systems logically share the unified project object model. The systems can exchange data with each other using the vocabulary (i.e., the A E C / F M domain objects and their relationships) defined in the commonly shared model. The model is a communication mechanism providing for understandability of the information that is being communicated, rather than a physical database (e.g., a physically centralized database from which the users of the application systems pull data). The model acts like a logical language for communication between related software agents. The physical databases of projects and/or enterprises are built based on the definitions made in the model. Such databases may potentially be managed in a centralized database. Alternatively, they may be physically distributed among the systems. Application (e.g., CAD System)  *^  Local Application Database  Application (e.g., Estimating)  | ItcActor | lllcActoiSelecfl  Shared Project Database ;;|  'HeActorRoJe^J  Application^^N (e.g., Scheduling) _ing)  J  Application (e.g., Doc. Mngt.)  Figure 1-1: The Basic Idea: A Unified Project Object Model for Communication of Project Information  6  Integration of Business M o d e l i n g w i t h the Software D e v e l o p m e n t Process  The process of software development has been described in different ways, depending on the methodology adopted [Sommerville 1997; Coad and Yourdon 1991a; Jacobson et al 1992; Jacobson et al. 1999]; however, the new emerging methodologies for software system development propose an integrated process approach, which tightly integrates processes and their resulting models from definition of the problem to the design and development and realization of a solution (i.e., the supporting information system). Since a software system is usually intended to be used and to support some business process  (what people physically do in the organization), business process modeling has been suggested to be no only a part but also the driving vehicle of the software development process [Jacobson et al. 1995; Eriksson and Penker 2000]. The current CIC projects have not fully and formally benefited from the idea  of integration of business process modeling and software engineering processes (see section The current software development methodologies differ in their focus and extent of coverage of the workflows of the software development process. Figure 1-2 schematically shows this coverage for some of the key methodologies in comparison with this research by illustrating the basic workflows (before testing and deployment) and their related models in the upper part of the figure. These workflows and their related models as well as the methodologies are elaborated in Chapter 2 of this dissertation. The dissertation goes through most of the workflows of the software development process in the context of construction P M . However, a special emphasis is placed on the interface between business process modeling and software engineering, a concept that is emerging within the framework of the Unified Process [Jacobson et al. 1999; Jacobson and Bylund 2000]. The frameworks (i.e., principles or ideas) and models (i.e., representations) developed in this research encompass the integration of business  process modeling with the software development process, especially the requirements analys system analysis stages. The software design and implementation was also addressed through a prototype system, which served as a proof-of-concept for certain elements of the research (Appendix C).  7  Approach  Scope  Coverage of Stages and Artifacts for the Method  (Methodology)  (Assumption)  (Excluding Testing and Deployment) Business Env..  U  -4 General Approach (The Base)  f  Generic/Neutral  | ' R e q u i r e m e n t ^ ( System ^ \ Analysis \ Analysis \  Business 1 Requirements 1 Analysis 1 Model J Model J Model J  Coad's OOA/D [Coad & Yourdon 1991a & 1991bl Booch's OOD [Booch 1991]  Specific System Specific Client  Rumbaugh's OMT [Rumbaugh et a l . 19911 Jacobson's OOSE [Jacobson 1992]  Specific System Specific Client  Jacobson's Business Modeling [Jacobson 19951 Jacobson's USDP (Unified Process) [Jacobson 19991  Specific System Specific Client  This Research  Business Modeling  Software Environment r  System ^ System Design \ Implementation r  Design Model  >  1 Implementation Model  J  Specific System Specific Client  Specific System Specific Client  _, j  Specific System Specific Client Generic (AEC/FM Industry)  1  Figure 1-2: The Research's Modeling Approach Compared with Software Development Methodologies  1.2.3 Project Management Functions and the CIC Projects Effective information management is a key to the integration of P M functions, and it requires the on-time availability of the right information. Such a requirement is often not met in construction projects for many reasons. For. example, M M processes are usually performed in several different parts of organizations such as purchasing, production control, transportation, warehousing, materials handling, operations, receiving, and logistics, and materials information is scattered throughout these organizational departments and sections [Stukhart 1995]. The information is represented from different perspectives in different formats and systems. The consequences of this include little consolidation of materials information and, thus, inconsistencies in the materials information. These problems propagate to other related P M functions such as planning, scheduling, quality assurance/control, cost estimating, and cost budgeting and control, resulting in efficiency and effectiveness losses in various levels of organizations (the project, enterprise, and industry) [CII 1986]. Standard models of materials information integrated with other types of project information can help to overcome such consequences.  8  Project management (PM) has traditionally emphasized a few managerial functions (e.g., planning, controlling, and administration processes) [Kavanagh et al. 1978],-while-operational functions (e.g. physical production and logistics) have received less focus. Over the past two decades, many research and development and data standardization projects have tried to achieve the goals of CIC using different approaches and techniques. Some of these projects have adopted a narrow scope (in terms of the type of information, application areas, and geographical location of the concern), while others have taken a somehow larger scope (e.g., information spanning the whole project and at an international level). These efforts range from information modeling and implementation of a specific application area to integration of several applications within a specific domain of A E C / F M (e.g., design of H V A C systems) and integration of the whole A E C / F M domain at different institutional, national, and international levels. Examples of these projects include A T L A S (EP-2780; for large scale engineering) [ATLAS 1997], C O M B I N E (COmputer Models for the Building INdustry in Europe) [Augenbroe 1995], C O M M I T (Construction Modeling and Methodologies for the Intelligent inTegration of information) [Brown et al. 1996], CONDOR (ESPRIT 23 105) [Rezgui and Cooper 1998], G A R M (General A E C Reference Model) [Gielingh 1988], GDCPP (Generic Design and Construction Process Protocol) [GDCPP 2001], I B P M (Integrated Building Process Model) [Sanvido 1990], ICON (Integration of Information in CONstruction) [ICON 1994], IAI (International Alliance for Interoperability) [IAI 2005], and STEP (STandard for the Exchange of Product model data) [ISO 1992]. As will be discussed in chapters 2 and 4 of this dissertation, however, the proposed models have not yet fully addressed the goals of CIC. There has been more effort on formalizing and standardizing product information (e.g., a physical building and its elements) reflecting a designer's view and less on other types of information (e.g., processes, resources, costs, and organizational information) involved in the management of projects and the integration of the two. Also, there is a lack of coverage of most P M functions in current models; thus requiring an extension to the scope of such models to cover a wider range of application areas [Froese etal. 1997a; Y u et al. 2000; Y u 2002]. Moreover, the existing A E C / F M information modeling projects have generally adopted a top-down approach to formalizing and standardizing information; thus it is suggested that their effectiveness should be examined through bottom-up evaluation approaches (i.e., by reviewing, testing, and implementation of the models) [van Nederveen and Tolman 2001].  1.2.4 The Materials Management Function The M M function was selected as a subject area in this research for a number of reasons. First, it has a high impact on construction, productivity [Thomas et al. 1999]. The cost of materials and equipment usually runs about 60% of total project costs with construction labor costs at about 25% [CICE 1982]. A  9  10-12% increase/decrease in labor productivity has been reported in construction projects due to the quality of M M . This labor cost savings originates from a reduction in nonproductive labor time spent waiting or searching for materials [CICE 1983a; CII 1986; Ballard et al. 1994]. Second, the preliminary investigation of this research showed that, with few exceptions for specific application areas, M M processes (e.g., materials ordering, receiving, storing, and testing) have not been generally supported in current P M systems (section 3.1): Consequently, limited aspects of materials are separately modeled and scattered throughout a few applications (e.g., materials cost in estimating and cost accounting). Moreover, like other types of information, the materials information generated by one application system is not easily transferable to other potential systems. Third, the M M function has not previously been addressed by the existing A E C / F M information standardization efforts (section 4.1.6). Materials information has not been modeled as used in construction processes (e.g., the bulk of material received and processed by construction personnel) but rather as used in the design phase of the project (i.e., material properties). Finally, information about the final-target product (e.g., a building, a wall, etc.) is closely related to the materials incorporated into the product (e.g., door, window, concrete, brick, etc:) (section This relation has loosely been represented in some existing P M software and A E C / F M standard data models. This research has aimed at investigating suitable ways of representing these two interrelated concepts so that the resulting model could be shared among related application systems (e.g., specification, purchasing, and storing/warehousing).  1.2.5 The State-of-the Art in CIC Developments With the formation of the International Alliance for Interoperability (IAI) as a not-for-profit international consortium in September 1995, the standardization efforts in the A E C / F M industry entered a new stage. The IAI, a major industry effort to standardize A E C / F M project information, has resulted in the Industry Foundation Classes (IPC's)—a computer data standard that enables software interoperability across different A E C / F M industry domains in the whole life cycle of a building project. The IFC's is, in fact, the specification of an object-based data model of a building project to be commonly used by multiple vendors of software applications.for data exchange. The software products using the IFC's could then share and exchange information using this common data model. So far, the IAI has published four major releases of the IFC, R1.0, R1.5, R2.0 and R2.x [IFC R2x, 2000a]. The latest version of the last release is R2x2-1 (Release 2x, Edition 2, Addendum 1) [IFC R2x2-1, 2004; IAI 2005]. The IAI project represents the state-of-the-art A E C / F M information standardization effort. Its formation was, in fact, a response to the slow progress of earlier standardization efforts in the A E C / F M  10  industry [van Nederveen and Tolman 2001]. There is usually a gap between IT and its standardization process , mainly due to the slowness of the development and adoption of the standards [Ng et al. 2001; 1  Samuelson 2002]. The higher level of involvement of related software companies in the standardization process can increasingly reduce this gap. Ultimately, it is the software companies that should take action to apply the standards and bring them into use. The effectiveness of the process can be further enhanced with participation of a wide range of the required expertise (e.g., internationalization and many disciplines). To a large extent, the IAI project embraces all these characteristics, and thereby has the potential to reduce the gap. Moreover, the IAI project has built upon the experiences of its predecessors, though with a larger scope (in terms of geographical coverage, involvement of software vendors and required expertise and other resources). It inherits from such standardization projects as C O M B I N E [Augenbroe 1994; C O M B I N E 1995], A T L A S [ATLAS 1997], and STEP (specifically B C C M , AP225) [ISO 1995a; ISO 1997]. The modeling techniques and methodology applied in the development of the IFC's were drawn largely from the STEP project. For example, the EXPRESS language and its graphical component, EXPRESS-G [ISO 1991] (Appendix A), were chosen for definition and specification of the IFC object model. Adoption of a layering approach to data modeling is another example of this commonality between the IAI and STEP projects. An overview of the IAI project and the IFC model is presented in Chapter 2 of this dissertation. The IFC model has aimed at identifying, defining, and representing all the common information  requirements of all industry processes across all AEC/FM domains. However, despite the m advantages offered by the model, the following major issues remain to be resolved: 1) The coverage of all processes across all AEC/FM domains has not yet taken place (e.g., facility management [Froese et al. 1997a; Y u et al. 2000]). This could be the result of limited resources. Construction management functions have not been fully dealt with. At present, only two functions of estimating and scheduling have received attention within the North American P M group of IAI. Therefore, there is a need to consider the total scope of PM within a single framework. 2) Reflecting the emphasis of IAI projects to date, the IFC object model is heavily design oriented (section, mainly due to the number of design-domain projects involved in its development. By definition, the IFC's should address the information requirements of all A E C / F M domains, not only building design and a few other functions. Moreover, true CIC calls for an object model that  The information standardization process generally involves model development (by modelers), model implementation/adoption (by software vendors), evaluation (by A E C / F M companies), model standardization, (by standards organizations), and standards adoption (by software vendors). 1  11  reflects the information requirements of all activities in the delivery and facility  management  processes of any type of A E C / F M project, not only buildings. 3) Business processes, through which information flows, are not explicitly modeled in the current IAI standardization effort. Word processing and spreadsheet applications are generally the main tools used for managing the modeling process workflows, and links between process and object models are not made explicit—e.g., no mapping of the information input and output represented in IDEF  0  diagrams and the objects defined in the object model [IFC R2.0, 1999c]. A framework that provides a comprehensive picture of all A E C / F M project processes and their information requirements as well as their explicit links could considerably raise the efficiency and effectiveness of both the modeling process and the resulting models. It helps in the standardization of both processes and information. The aforementioned issues are not intended to undermine the importance and advantages of the IFC's but to identify opportunities for improvement and to highlight the directions of this research.  Problem Statement  1.3  Many research  and development projects  have worked towards the formalization and  standardization of the information involved in the management of A E C / F M projects to provide for software interoperability in a CIC environment. The initial review of these projects as well as their related knowledge areas resulted in the identification of a number of significant areas for improvement, as summarized in the following. 1) The with  top-down  approach of the existing A E C / F M information modeling projects needs to be coupled  bottom-up evaluations  2) The need to model  (i.e., reviewing, testing, and implementation of the models).  integrate product  and process  information  into a  unified project  information/object  has already been realized, but current initiatives do not go far enough. Such initiatives need to  be reviewed and critiqued, and effective solutions for the continuation of this work need to be addressed. 3) Despite their central role to almost all C M processes, product information and materials information have previously been modeled mainly from a designer's view, rather than from the perspective of C M functions. There is a need to model  product and material information  as used by CM.  The M M  function is one of most important functions that has received little attention in current information modeling projects and P M software systems. Therefore, the MM  function  is a good candidate for  detailed study and modeling as a significant, representative component of a model and integrated total PM systems.  12  unified project object  4)  Best practices in software engineering methods generally suggest a progression from business process modeling to information modeling. The reliability and usefulness of the information models and resulting information systems are dependent on how formally and explicitly such information is elicited from the business process models [Eastman 1999]. The  current A E C / F M information  modeling projects have used a variety of development techniques and with varying degrees of  formality and explicitness. An examination of the information modeling process itself can help to the ways to enhance the usefulness of A E C / F M information models. 5)  In current systems and A E C / F M models, P M functions have been traditionally limited to a few functions such as estimating, planning and scheduling. There is a need for a framework that provides  for modeling all possible PM functions and their information requirements in an integrate Due to the central role of business process modeling to the identification, definition, and specification of the information, a special emphasis needs to be placed on integration of this workflow with other workflows involved in the software development process and integration of the artifacts (models) of the whole process (section 2.1.3). 1.4  The R e s e a r c h Plan This section describes the research plan in terms of research objectives, scope, methodology, and  deliverables and contributions. 1.4.1  The Objective and Research Questions Considering the previous problem statement, the overall objective of this research was to  investigate how AEC/FM. product and process information could be integrated into a unifie  project model that could support a wide range of construction project management (PM) f  an emphasis on materials management, within the context of a CIC environment. This objectiv  addressed through the research hypothesis: the distinct views of the functions involved in an AE  project on the project information can be brought together into a unified project model, w  used as a central repository for a wide range of PM application systems reflecting the CIC en  this may be accomplished through the modeling of PM business processes and their inf requirements, within a unified software development process.  The basic research challenge posed by the objective (how to model project information in order to be useful for PM functions) was further decomposed into the following research questions: 1)  What is the state-of-the art in process and information modeling (concepts, terminologies, methods, techniques, tools, and models), especially in the A E C / F M industry?  2)  What are the (product and process) information requirements of P M functions?  13  3) How could the information requirements of P M functions be formalized into a conceptual A E C / F M project information model? 4) What are the full range of P M functions, and how could they be classified? 5) How could models of A E C / F M systems (i.e., process and information models of both business and software systems) be integrated into a single framework to support the integrated total P M systems development process? 6) Given a specific P M context (i.e., the M M function), how could the proposed models be implemented (i.e., using the frameworks to model the functional and information requirements of M M systems)? The basic approach, then, was to survey a broad range of references (from literature, data collection field studies, etc.) in order to identify the strengths and weaknesses of each, then to develop a series of models that combine the best features and solve the primary problems of the references. The primary research challenges lay in the acquiring, reviewing, analyzing, and synthesis of the very wide range of references, and in developing the resulting models, which are complex because of their broad scope, their multiple layers of abstraction, and the numerous relationships between them (particularly linking the process views with the information views). The above challenges required the scoping/rescoping of the research subjects and deliverables at various levels of abstractions (e.g., conceptual modeling versus detailed object modeling). They also required considerable amount of time for planning (e.g., methodology preparation), executing, and controlling (e.g., revising) of the various research activities to achieve the predefined objectives. The resource-and-time use of major A E C / F M information modeling projects is noticeable in this regard—e.g., 70 person-years in the C O M B I N E project [Augenbroe 1995], which had a much narrower scope than the ongoing IAI project [IAI 2005].  1.4.2 The Scope Considering the research objectives, six major knowledge areas were considered within the scope of the research, as illustrated in Figure 1-3. These knowledge areas helped define the points of departure for the research (Chapter 2). Figure 1-4 further illustrates the underlying domains of various modeling activities of the research. Other subjects were considered out of scope for the research, such as the following: 1) business process re-engineering [Hammer and Champy 1993]; 2) . business process  modeling for purposes  other than information modeling (e.g., workflow  management, process planning/scheduling);  14  3) implementation of software based on the research results (other than the preliminary prototype described in Appendix C); 4) the strategic aspects of IT; and 5) low-level information definitions such as geometry representation (of, for example, a building and its elements), representation of material properties (e.g., density, vapor resistivity, thermal conductivity, etc.), and presentation objects (e.g., tables, graphs, etc.).  Figure 1-3: The Knowledge Areas Within the Scope of the Research AEC/FM Industry  -• For the Whole Research ->• For Conceptual Business Process & Information Modeling -• For Detailed Business Process & Object Modeling -• For Prototype System Development  Figure 1-4: The Modeling Domains of the Research  15  7.4.3 The Methodology This section describes the research methodology in terms of the basic research activities and workflows, the modeling techniques and tools used, and the major deliverables of the research.  Research Activities and Workflows The major research activities and workflows are schematically shown in Figure 1-5 in the form of  a U M L (Unified Modeling Language) activity diagram [UML 1.4 2001] overlaid on dashed boxes, which group the activities and workflows into the major knowledge areas of the research. In order to avoid complexity, however, the figure does not show all decision points and feedback loops: In the U M L notation (described more fully in Figure A-6 of Appendix A of this dissertation), a round box represents an activity, while a rectangular box represents the input and output objects to and from activities (underlined items represent the primary research deliverables). Simple arrows.indicate transition (i.e., completion of one activity and start of another). Dashed arrows are used to mean object flow and dependency between elements. Diamonds are decision points and indicate a branch or merge in the flow. Horizontal thick lines illustrate synchronization—a branching of the flow into parallel flows or a joining of parallel flows which all complete before the flow continues. The start state and end states are represented with a filled circle and a filled circle in a blank circle, respectively.  16  Figure 1-5: The Research Activities and their Workflows  Modeling Techniques and Tools The research used U M L notations [ U M L 1.4, 2001] and EXPRESS-G notations [ISO 1991]  (Appendix A) extensively for process and information modeling purposes. It also benefited from the promising advantages of C A S E (Computer-Aided Software Engineering) tools (section 2.3.4) for both modeling and documentation purposes. The U M L use case modeling and activity diagramming techniques were specifically used for modeling of processes and objects within both business and computer environment. The reasons for selecting these techniques are elaborated in Chapter 2, with the main points being as follows: 1) They are a part of an important defacto standard (UML), which is intended to bring all software development methodologies into a shared language of communication and which is becoming an international standard through ISO [OMG 2005]. 2) Use cases can portray an external-functional view of systems of any kind. 3) Use cases focus on what the system does, independent of how and why concerns. 4) When the external view is established and agreed upon, the internal view (i.e., the "how" issues such as sequencing, objects and their flows, etc.) may become of the concern. Activity diagrams can portray this view. EXPRESS-G (the graphical-notation component of EXPRESS modeling language, a part of the STEP standards [ISO 1991]) was selected for presenting existing information models as well as the object models suggested by this research for two major reasons: 1) its simplicity (to draw and comprehend), and 2) its use for many other existing A E C / F M data models (so no conversion would be required for comparison purposes). Ensemble Streams™ (Streams) [2000] (Appendix A), which is a C A S E tool that supports U M L notations, was used for implementation of the ITPMS model. More specifically, it was used for: 1) listing and modeling of business processes in the form of use case models, 2) describing the internal behavior of use cases, which represent processes, in the form of activity diagrams (i.e., activities and their possible workflows), and 3) eliciting and listing of data objects involved in business processes (especially in M M ) by adding object flows to the activity diagrams. The Chapter 2 of this dissertation provides the background information about current modeling methods, techniques, and tools, especially those used in this research.  18  Research Deliverables The research objectives and methodology suggest the following major deliverables:  1) A comprehensive, critical review of the relevant knowledge areas; specifically process and information modeling technologies (concepts, terminologies, methods, techniques, tools, and models) and P M / M M concepts. 2)  A conceptual AEC/FM  Project Core Model (APCM), encompassing product and process information  requirements of P M functions. 3)  A conceptual PM Functions Framework (CPMF), useful for eliciting P M functions.  4)  A classification of PM functions and MM Processes.  5)  An Integrated Total Project Management System (ITPMS) model architecture, capable of capturing  the functional (i.e., processes) and information requirements of A E C / F M systems (i.e., both business and computer environments) in an integrated manner. 6)  A n implementation of the ITPMS model for the domain of MM using the Streams CASE tool, yielding a set of MM process models and domain object models, and providing a test of the ITPMS model.  Of these, items 2 to 6 have the highest importance and are regarded as the primary research deliverables. In addition, there are other intermediate deliverables and activities that played an important role in validati