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

Download

Media
831-ubc_2006-199817.pdf [ 31.03MB ]
Metadata
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
831-1.0063231-fulltext.txt
Citation
831-1.0063231.ris

Full Text

Model-Based Integrated Total Project Management Systems, with an Emphasis on Materials Management ABDOLHAMID 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 FULFILMENT OF T H E REQUIREMENTS FOR THE DEGREE 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 OF BRITISH COLUMBIA 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 top-down 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 top-down 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. i i T A B L E OF CONTENTS A B S T R A C T ii T A B L E O F C O N T E N T S i" LIST O F T A B L E S •. . • ix L I S T O F F I G U R E S . • x L I S T O F A B B R E V I A T I O N S xv A C K N O W L E D G E M E N T ............xvii C H A P T E R 1 I N T R O D U C T I O N T O T H E R E S E A R C H 1 1.1 INTRODUCTION l 1.2 A GENERAL BACKGROUND ; : ; 4 1.2.1 Definitions of Basic Terms : 4 1.2.2 The Key Research Ideas • • 5 1.2.2.1 Interoperability and The Unified Project Object Model ...5 1.2.2.2 Integration of Business Modeling with the Software Development Process :.: 7 1.2.3 Project Management Functions and the CIC Projects , 8 1.2.4 The Materials Management Function 9 1.2.5 The State-of-the Art in CIC Developments • 10 1.3 PROBLEM STATEMENT : 12 1.4 THE RESEARCH PLAN .: :.. 13 1.4.1 The Objective and Research Questions 13 1.4.2 The Scope.... 14 1.4.3 The Methodology 1.6 1.4.3.1 Research Activities and Workflows 16 1.4.3.2 Modeling Techniques and Tools •••• : 18 1.4.3.3 Research Deliverables ...19 1.4.3.4 The Evaluation and Validation of The Research ..: 19 1.5 THE ORGANIZATION OF THE DISSERTATION • 20 1.6 CHAPTER CONCLUSIONS , 21 C H A P T E R 2 POINTS O F D E P A R T U R E A N D R E S E A R C H V I E W S 2 2 2.1 MODELING AND SOFTWARE DEVELOPMENT (TERMS AND CONCEPTS) 22 2.1.1 Some Basic Definitions : , , 22 2.1.1.1 Data, Information, and Knowledge : : 23 2.1.1.2 Process .... .23 2.1.1.3 Object-Oriented Modeling 24 2.1.1.4 Software Engineering, Software Reengineering, and Information Engineering ....25 2.1.2 Evolution of Software Development Methods and Techniques 25 2.1.3 Software Development Process 27 2.1.4 From Requirements Model to the Design Model 30 2.1.4.1 Domain Object Model 30 2.1.4.2 Use Case Model... •'• 31 2.1.5 Summary of Modeling and Software Development 31 2.2 BUSINESS PROCESS MODELING (CONCEPTS AND VIEWS) 32 2.2.1 From Functional Orientation to Process Orientation 32 2.2.2 Business System versus Software System 33 2.2.3 Business Process versus Software Process 33 2.2.4 Business Object Model versus Software Object/Class Model 34 2.2.5 Process Reuse, along with Object Reuse 35 i i i 2.2.6 Advantages of Basing Information Systems on Process Models 35 2.2.7 Summary of Business Process Modeling : 36 2.3 MODELING TECHNIQUES AND TOOLS 37 2.3.1 Modeling Techniques 37 2.3.1.1 Information Modeling Techniques 37 2.3.1.2 Activity/Process Modeling Techniques 38 2.3.2 Advantages of Object-Oriented Concepts and Technology.... 39 2.3.3 The Unified Modeling Language: A Technology for Integration of Models 40 2.3.4 CASE Tools 42 2.3.5 XML (extensible Markup Language) Technology.. 43 2.3.6 Summary of Modeling Techniques and Tools 45 2.4 A E C / F M INFORMATION MODELING 46 2.4.1 Types of Information/Data Models 46 2.4.1.1 Meta-Models — 46 2.4.1.2 Conceptual Models • ; 46 2.4.1.3 Core (or Reference) Models versus Application Models 47 2.4.1.4 Type Models versus Instance Models 47 2.4.2 Product and Product Model 48 2.4.3 Product (data) Model versus Process (data) Model 48 2.4.4 An Overview of Some of the Existing AEC/FM Information Models 50 2.4.4.1 G A R M [Gielingh 1988] • ,50 2.4.4.2 STEP (ISO 10303) [ISO 1995a] 52 2.4.4.3 B C C M (ISO 10303-106) [ISO 1995b and 1997] 52 2.4.4.4 AP225 (ISO 10303-225) [ISO 1995a] : 53 2.4.4.5 C O M B I N E [1995] 54 2.4.4.6 CONDOR (ESPRIT 23 105) [Rezgui and Cooper 1998] : 57 2.4.4.7 IAI[2005] 57 2.4.4.7.1 A Brief Background 58 2.4.4.7.2 IFC Model Architecture • 58 2.4.4.7.3 IFC Specification Development Process '—60 2.4.4.7.4 The IFC Object Model 60 2.4.5 Summary of AEC/FM Information and Process Modeling 65 2.5 A E C / F M PROCESS MODELING ( P M FUNCTIONS)... 65 2.5.1 A Review of Selected AEC/FM Process Models 66 2.5.1.1 Project and Project Management • 66 2.5.1.2 The IBPM Approach [Sanvido 1990] 66 2.5.1.3 The ICON Approach [1994].. 71 2.5.1.4 The MoPo Project [Karstila and Bjork 1999] '. 77 2.5.1.5 The GDCPP Approach [2001] 77 2.5.1.6 The P M B O K Approach [PMI 1996] '. : • 81 2.5.1.7 The U B C Approach 83 2.5.2 Issues and Resolutions in Modeling PM Functions 83 2.5.2.1 Complexity and Integration Issues • 84 2.5.2.2 Subjectivity Issue •. 84 2.5.2.3 Context Issue (Specific versus Generic) •• 85 2.5.2.4 The Base of Classification : : 86 2.5J The Research Methodology for AEC/FM Process Modeling 87 2.5.4 Summary of AEC/FM Process Modeling 90 2.6 MATERIALS MANAGEMENT SYSTEMS : 90 2.6.1 Importance of Materials Management '-90 2.6.2 Categories of Materials Management Literature 92 2.6.3 Materials and Materials Management: Definitions and Technologies 94 2.6.3.1 Construction Materials — 94 2.6.3.2 Materials Management and its scope 96 2.6.3.3 Evolution of M M Systems and Use of IT : 97 2.6.4 Materials Management and other PM Functions 98 2.6.5 A Review of Selected MM Modeling Research 100 2.6.5.1 Cheng and O'Connor [1996] • 100 2.6.5.2 Cheng and Chen [2002] 100 iv 2.6.5.3 Echeverry and Beltran [1997] : : 101 2.6.5.4 Kong, Li, and Love [2001] = 101 2.6.5.5 Pheng and Chuan [2001] 102 2.6.5.6 Riley and Sanvido [ 1995 and 1997] 103 2.6.5.7 Sullivan [1989] • • 105 2.6.5.8 From Tommelein and Zouein [1993] To Riley and Tommelein [1996] 106 2.6.5.9 Summary of MM Literature Review 107 2.6.6 The Approach to Modeling MM Processes and Information Requirements 108 2.6.6.1 The Scope '• • 108 2.6.6.2 The Methodology : 109 2.6.7 Summary of Materials Management Systems : 112 2.7 CHAPTER CONCLUSIONS • 112 CHAPTER 3 BOTTOM-UP INVESTIGATIONS AND RESEARCH CRITERIA 113 3.1 A REVIEW OF CURRENT P M / C M SOFTWARE APPLICATION SYSTEMS.. : 113 3.2 SOFTWARE PROTOTYPING - 1 1 4 3.3 FIELD INVESTIGATIONS : 115 3.3.1 The Goal and Objectives • 115 3.3.2 The Methodology and Results , :.- 116 3.3.3 The UBC Faculty and Staff Housing (Thunderbird) Project 117 3.3.4 CM/MM in the Thunderbird-1 Project : 117 3.3.5 An Overall Assessment of the Thunderbird Project.... 121 3.3.6 The Use of Information Technology •• • 124 3.3.7 Major Outcomes and Lessons Learned 125 3.3.8 Summary of Field Investigations : • 126 3.4 T H E PROCESS MODELING PRACTICE WORKSHOP 128 3.4.1 The Goal and Objectives • 128 3.4.2 The Methodology and Participants ': '.. •• 128 3.4.3 Results and Lessons Learned : 129 3.4.4 Summary of the PMPW : 130 3.5 SETTING RESEARCH CRITERIA 133 3.5.1 General Modeling Criteria : • 133 3.5.2 Flexibility as a Basic Requirement , 133 3.5.3 Summary of Research Criteria • 134 3.6 CHAPTER CONCLUSIONS , 135 CHAPTER 4 A E C / F M PROJECT INFORMATION MODELING REQUIREMENTS 136 4.1 A E C / F M PRODUCT INFORMATION MODELING 136 4.1.1 Product-Related Concepts: Target Product, Space, and Material 136 4.1.2 Form, Function, and Behavior/Performance ; 137 4.1.3 Products and their Environment: The Concept of Agent..:... 138 4.1.4 Views —• 139 4.1.5 Product Models and PM Functions: Examining Existing Product Models 139 4.1.5.1 Target-Product and Space Concepts in Models 140 4.1.5.2 Form Information , 142 4.1.5.3 Functional Information..... 143 4.1.5.4 Behavior/Performance Information 145 4.1.5.5 Change and Versioning : • 147 4.1.6 Material Information Modeling • 150 4.1.6.1 Material: Evolution and Changing Roles 150 4.1.6.2 Material Information In AEC/FM Information Models.. : 152 4.1.6.3 Material Information in the IFC Model • 154 4.1.6.4 Summary of Material Information Modeling : 158 4.1.7 Summary of AEC/FM Product Information Modeling 158 4.2 BEYOND PRODUCT INFORMATION: MODELING PROJECT INFORMATION 159 4.2.1 Properties and Relationships of Objects 159 4.2.1.1 Some Modeling Issues on Properties and Relationships 159 4.2.1.2 Properties and Relationships in the IFC Model 160 v 4.2.1.3 Summary of Properties and Relationships ; 162 4.2.2 Levels of Specificity of Objects: Type and Occurrence Information..... 163 4.2.2.1 Type and Occurrence Information • • 163 4.2.2.2 Type and Occurrence Information in Models : 164 4.2.2.3 Type and Occurrence Information in the IFC Model 166 4.2.2.4 How Type and Occurrence Information are Used and Related 166 4.2.2.5 Summary of Type and Occurrence Information 167 4.2.3 Roles of Objects : -168 4.2.3.1 Role Players and Roles • 168 4.2.3.2 Roles in the IFC Model , • -168 4.2.3.3 Beyond Organizational Roles 171 4.2.3.4 Some Guidelines for Modeling Roles 172 4.2.3.5 Summary of Roles of Objects 173 4.2.4 Transactions in Construction Projects ; • • 174 4.2.4.1 Process-Centered Construction • •••• 174 4.2.4.2 The Need for Standardization of Transactions : 174 4.2.4.3 Transaction Information in the IFC Model 176 4.2.4.4 Some Guidelines for Modeling Transactions : •••• 178 4.2.4.5 Summary of Processes and Transactions '. • 179 4.2.5 An Examination of the IFC Object Model Using Coad's DNC Model 180 4.2.6 Summary of Modeling Beyond Product Information 181 4.3 CHAPTER CONCLUSIONS • 181 CHAPTER 5 A CONCEPTUAL A E C / F M PROJECT CORE MODEL (APCM) 183 5.1 T H E SCOPE OF THE MODEL '. 183 5.2 T H E BASIC STRUCTURE OF THE MODEL 183 5.2.1 Subtypes of Occurrence Object • 184 5.2.2 Subtypes of Type Object.... '. ..- 184 5.2.3 Subtypes of Property Definition 185 5.2.4 Subtypes of Relationship • 185 5.3 LOWER -LEVEL OBJECTS OF THE MODEL : 186 5.3.1 Subtypes of Thing 186 5.3.2 Subtypes of Physical Thing 187 5.3.3 Subtypes of Role .....188 5.3.4 Subtypes of Event • 189 5.3.5 Subtypes of Process 190 5.3.6 Subtypes of Transaction 190 5.3.7 Subtypes of Aspect : • • • 192 5.4 CHAPTER CONCLUSIONS 195 CHAPTER 6 PROJECT MANAGEMENT FUNCTIONS CLASSIFICATION 196 6.1 DIMENSIONS OF PROJECT MANAGEMENT '. 196 6.7.7 Project Objectives 196 6.1.2 Basic PM Functions .....797 6.1.3 Project Elements 198 6.2 A CONCEPTUAL PM FUNCTIONS FRAMEWORK (CPMF) 200 6.3 FURTHER EXPLORATION OF P M FUNCTIONS 202 6.3.1 A Tabular Listing of PM Functions 202 6.3.2 A Hierarchical Classification of PM Functions 208 6.4 CHAPTER CONCLUSIONS..... •• 211 CHAPTER 7 THE INTEGRATED T O T A L PROJECT MANAGEMENT SYSTEMS (ITPMS) MODEL 212 7.1 TH E ITPMS MODEL ARCHITECTURE '. 212 7.2 THE META -MODEL OF THE ITPMS MODEL . . . . : : 214 7.3 A N APPLICATION OF THE ITPMS MODEL 217 7.4 CHAPTER CONCLUSIONS '. 218 vi CHAPTER 8 THE MATERIALS MANAGEMENT PROCESS AND INFORMATION MODELING... 219 8.1 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 8.2.1.1 The High-Level Components of the Model 230 8.2.1.2 The M M Package at a Glance : ...231 8.2.1.3 The Assignment of Stereotypes to Model Elements • 233 8.2.2 MM Initiation... 233 8.2.3 MM Planning. ...... 234 8.2.3.1 Materials Requirements Planning • 234 8.2.3.2 M M System Planning 237 8.2.4 MM Organizing. • • — 239 8.2.5 MM Execution • 239 8.2.6 MM Controlling ; 242 8.2.6.1 Materials Controlling 242 8.2.6.2 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 8.3.2.1 Use Case: "Request Materials" —- • 245 8.3.2.1.1 The Scope .' • 245 8.3.2.1.2 Preconditions 246 8.3.2.1.3 Postconditions 246 8.3.2.1.4 Main Flow of Events (MFE) '. 246 8.3.2.1.5 Exceptional Flows of Events (EFE) '. 246 8.3.2.1.6 Activity Diagrams • 246 8.3.2.2 Use Case: "Process Materials Request" 248 8.3.2.2.1 . The Scope : '. ...... •  248 8.3.2.2.2 Preconditions .• .. 248 8.3.2.2.3 Postconditions .' .' • -248 8.3.2.2.4 Main Flow of Events (MFE) —•• 248 8.3.2.2.5 Exceptional Flows of Events (EFE) 248 8.3.2.2.6 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 CHAPTER 9 EVALUATION AND VALIDATION OF THE RESEARCH 256 9.1 THE OVERALL RESEARCH EVALUATION AND VALIDATION 256 9.2 AN EVALUATION OF THE A P C M . . 261 9.2.7 Advantages and Limitations of the Model -— • 267 9.2.2 Linkage between the APCM and the IFC Model. : 264 9.3 AN EVALUATION OF THE C P M F MODEL. — 267 9.4 AN EVALUATION OF THE ITPMS MODEL — 267 9.5 A N EVALUATION OF THE M M SYSTEMS MODELS • 270 9.5.7 Advantages and Limitations of the Results 270 9.5.1.1 The Conceptual Classification of M M Processes 270 9.5.1.2 ITPMS-Based M M Models '. -271 9.5.2 The CASE Tool Evaluation • 272 9.5.3 Other Observations and the Next Steps 273 v i i 9.6 CHAPTER CONCLUSIONS 274 C H A P T E R 10 C O N C L U S I O N S A N D R E C O M M E N D A T I O N S . 275 10.1 SUMMARY 275 10.1.1 Problems , 275 10.1.2 The Overall Objective and Premise 276 10.1.3 Actions, Results, and Values 276 10.2 CONTRIBUTIONS AND BENEFITS 278 10.3 RECOMMENDATIONS. ; : .....279 10.4 FURTHER RESEARCH 280 R E F E R E N C E S • •••• 283 A P P E N D I X A : S E L E C T E D M O D E L I N G T E C H N I Q U E S A N D T O O L S 297 A P P E N D I X 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 S T U D I E D 324 A P P E N D I X C : A P R O T O T Y P E M M A P P L I C A T I O N S Y S T E M 330 A P P E N D I X 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... : 17 Figure 2-1: The Unified Software Development Process: Phases and Core Workflows 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 COMBINE 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: An 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 I l l 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: An Example of a Label Stuck on Window's Glass (in the 3 r d 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 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 COMBINE. . . 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 COMBINE 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: An 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 EXPRESS-G (p. 1/2) 302 Figure A - 3 : Example IDEF 0 Activity Diagram (Construct Stud-Wall Frame) 304 Figure A-A: The Breakdown Structure of IDEF 0 Diagrams 305 Figure A - 5 : A Node Tree of an IDEF 0 Model : 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 MS-VB) '.. '.. 338 Figure C-A: The Main JMT 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 MS Project File (Saving Interfaces) 350 Figure C-18: Exporting the Project Model as a MS Project File (Log Options Window) 351 xiii Figure C-19: Exporting the Project Model as an MS Project File (Log Window) 351 Figure C-20: Exporting the Project Model as an MS Project File (Planning Windows) 352 Figure C-21: Importing the Project Model in the A M S Tool 353 xiv List of Abbreviations A E C : Architecture, Engineering, and Construction A E C / F M : Architecture, Engineering, Construction, and Facility Management AP: Application Protocol A P C M : A E C / F M Project Core Model API: Application Programming Interface B C C M : 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 C M : 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: ICAM (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 M M : Materials Management MS-VB: Microsoft Visual Basic™ MS-Access: Microsoft Access™ XV O O A D : Object-Oriented Analysis and Design O O S E : Object-Oriented Software Engineering P M : Project Management P M B O K : Project Management Body of Knowledge P M P W : Process Model ing Practice Workshop P M I : Project Management Institute Q M / Q C : Quality Management/ Quality Control R M : Resource Management S A D T : Structured Analysis and Design Technique S G M L : Standard Generalized Markup Language S T E P : STandard for the Exchange of Product model data UI : User Interface U M L : Unified Model ing Language X M L : extensible Markup 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: • My 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. • My 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 CEO 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 2.4.1.3) 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 1.2.2.1) [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 (APCM, 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 life-span 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 Au 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 as-needed 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 narrow-skilled 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 real-time 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 1.2.2.1 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 general-purpose 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. | ItcActor | lllcActoiSelecfl Application (e.g., CAD System) Local * ^ Application Database Shared Project Database ;;| 'HeActorRoJe^ J Application (e.g., Doc. Mngt.) Application (e.g., Estimating) Application^^N (e.g., Scheduling) _ing) J Figure 1-1: The Basic Idea: A Unified Project Object Model for Communication of Project Information 6 1.2.2.2 I n t eg ra t i on o f B u s i n e s s M o d e l i n g w i t h the S o f t w a r e D e v e l o p m e n t P r o c e s s 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 not 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 1.2.5). 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 analysis, and 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 (Methodology) Scope (Assumption) Coverage of Stages and Artifacts for the Method (Excluding Testing and Deployment) General Approach (The Base) Generic/Neutral Business Env.. -4 U Software Environment f Business | Modeling \ 'Requirement^ ( System ^ Analysis \ Analysis \ r System ^ Design \ r System > Implementation Business 1 Model J Requirements 1 Model J Analysis 1 Model J Design 1 Model J Implementation Model Coad's OOA/D [Coad & Yourdon 1991a & 1991bl Specific System Specific Client Booch's OOD [Booch 1991] Specific System Specific Client Rumbaugh's OMT [Rumbaugh et a l . 19911 Specific System Specific Client Jacobson's OOSE [Jacobson 1992] Specific System Specific Client _, j Jacobson's Business Modeling [Jacobson 19951 Specific System Specific Client Jacobson's USDP (Unified Process) [Jacobson 19991 Specific System Specific Client This Research 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], COMBINE (COmputer Models for the Building INdustry in Europe) [Augenbroe 1995], COMMIT (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], IBPM (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; Yu et al. 2000; Yu 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 4.1.6.1). 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 process1, mainly due to the slowness of the development and adoption of the standards [Ng et al. 2001; 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 COMBINE [Augenbroe 1994; COMBINE 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 many 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; Yu 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 4.1.6.3), 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 1 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). 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. 1.3 Problem Statement 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 top-down approach of the existing A E C / F M information modeling projects needs to be coupled with bottom-up evaluations (i.e., reviewing, testing, and implementation of the models). 2) The need to integrate product and process information into a unified project information/object model 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 unified project object model and integrated total PM systems. 12 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 find 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 integrated manner. 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 Research 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 unified AEC/FM project model that could support a wide range of construction project management (PM) functions, with an emphasis on materials management, within the context of a CIC environment. This objective has been addressed through the research hypothesis: the distinct views of the functions involved in an AEC/FM project on the project information can be brought together into a unified project model, which can be used as a central repository for a wide range of PM application systems reflecting the CIC environment; this may be accomplished through the modeling of PM business processes and their information 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 COMBINE 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. 1.4.3.1 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 1.4.3.2 Modeling Techniques and Tools The research used U M L notations [UML 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 1.4.3.3 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) An 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 validating the primary deliverables. For example, the construction field data and documents (collected in the field investigation activity) served as materials used in the development of the primary deliverables (e.g., M M object models) and are not listed above. 1.4.3.4 The Evaluation and Validation of The Research The methodology and primary deliverables of the research were supported by several evaluation/validation mechanisms. First, the frameworks and models of the research were developed in an iterative manner, which resulted in their continuous evaluation-and-reshaping. Second, the top-down development of the primary deliverables generally evolved in a chain of concretization; i.e., one model being used as a framework for development of, and thus testing by, another model. For instance, the validity and usefulness of the C P M F model was tested by being used as a framework for development of the ITPMS model and its implementation. The deliverables also gained their validity through a third mechanism: the bottom-up investigations. The bottom-up investigations (Chapter 3), which were carried out to complement the extensive critical literature and models reviews, included observation of real business processes, field interviews, collection and analysis of field documents and models, software prototyping, examination of current P M / C M software applications, and a Process Modeling Practice Workshop. The results of these activities 19 served as input materials for the evaluation/validation and reshaping of the models produced in the top-down development approach. 1.5 The Organization of the Dissertation The structure of this dissertation generally reflects the steps described in the research methodology (section 1.4.3). The dissertation is organized into ten chapters plus appendices: • Chapter 1: provides an overall description of the research-—the general background, problem statement, objectives, scope, methodology, and deliverables of the research—and the structure of the dissertation. • Chapter 2: presents the foundation used for building the frameworks and models of the research. In addition to reviewing other work, this chapter provides definitions, explanations, and discussions of the terms, concepts, methods, and technologies related to the knowledge areas of the research. • Chapter 3: describes the bottom-up investigations that contributed to the understanding of the requirements of integrated project management systems in general and materials management in particular: examination of current P M / C M software applications, software prototyping, field investigations, a Process Modeling Practice Workshop, and the research criteria. • Chapter 4: focuses on the information modeling part of integrated A E C / F M application systems development at a framework level. In a top-down analytical approach (from general concepts to detailed requirements), it examines current A E C / F M information models to identify their level of support of P M functions and lays out the requirements of an A E C / F M project information model. • Chapter 5: presents a synthesis of the earlier analytical materials and describes the scope, structure, and characteristics of a conceptual project information model (called the A E C / F M Project Core Model, APCM), which addresses the requirements identified earlier. • Chapter 6: focuses on the process modeling part of the total P M systems development process at a framework level. It describes the first step of the research towards formalizing P M processes, i.e., the development of an analytical framework (called Conceptual P M Functions Framework, CPMF) within which a fairly comprehensive list of P M functions could be explored. It lays down the theoretical bases of the framework, introduces the C P M F model, and describes how the model was used to identify and classify P M functions. • Chapter 7: describes the architecture and underlying structure of the Integrated Total Project Management Systems (ITPMS) model, which is proposed by the research for integration of models of A E C / F M business and software systems, as well as its application. 20 • Chapter 8: advances another step towards concretization of the ideas and models suggested by the research by exploring the applications of the previous results (the C P M F model, the P M functions classifications system and the ITPMS model) in a specific P M context (i.e., the M M function)^ based on a set of predefined criteria. It presents the results of implementation of the ITPMS model in a C A S E tool (i.e., a set of M M process and information models useful for integrated M M systems development). • Chapter 9: presents an evaluation of the research results (i.e., primary research deliverables) mainly by referring to the research criteria defined in earlier chapters. It highlights the advantages and implications of the deliverables. • Chapter 10: concludes the dissertation with recommendations, contributions and benefits of the deliverables of the research. It addresses the future research directions suggested for a full realization of the promises of this research. • References and Appendices: include a list of references cited by the research as well as a set of appendices, which provides more detailed information about various dimensions of the research. The appendices include: 1) a description of several modeling techniques and tools that are used or referred to in the research; 2) a list and attributes of some of the commercial P M / C M software applications reviewed in the research; 3) a description of the prototype M M system tool developed in the research; and 4) a list of M M business objects definitions suggested by the research. 1.6 Chapter Conc lus ions This chapter introduced the main dimensions of the research aimed at the integration of product and process information for the purpose of development of integrated computer systems supporting construction P M functions. It described the objectives, methodology, and deliverables of the research. Some of the significant characteristics of the research include its amalgamation of top-down analyses and bottom-up investigations and exploitation of the advantages of the latest modeling languages (e.g., the U M L ) and a C A S E tool in the A E C / F M systems modeling context. Given the objectives and methodology of the research, the study of related topics and development of the listed deliverables are not intended to define or introduce new technologies, per se, but rather to specify an environment in which new, as well as established, technologies can be feasibly applied so that the results can contribute to current CIC movements. The integration of process and information modeling processes (i.e., emphasis on the systems development process and its effectiveness) as well as integration of product and process information (i.e., emphasis on effectiveness of the models and systems) are believed to be the major opportunities promised by the research. 21 CHAPTER 2 Points of Departure and Research Views This chapter serves as a point of departure to the main body of the research and critiques aspects of the underlying knowledge areas of the research (listed in section 1.4.2). Formalization and standardization of A E C / F M information and processes are the very first steps towards CIC, and they require methods, techniques, and tools. Therefore, a major part of this chapter is dedicated to elaborating on some of the terms and concepts related to this formalization and standardization process and the methods and techniques involved in the process. This chapter includes seven major sections. The first section focuses on software development process in general and elabo