"Applied Science, Faculty of"@en . "Civil Engineering, Department of"@en . "DSpace"@en . "UBCV"@en . "Ye, Jianguo"@en . "2010-01-12T15:14:24Z"@en . "2009"@en . "Doctor of Philosophy - PhD"@en . "University of British Columbia"@en . "Recent trends in construction IT have introduced the ability to produce large, comprehensive, and integrated data sets describing each project. With emerging technologies, these data models can be exchanged between the computer tools that have traditionally been used to support the various construction applications. To date, however, it has not been possible for users to interact with the full range of integrated data in a way that allows them to configure custom views as needed to support ongoing management tasks. This barrier to working with integrated project data models can be decomposed into three categories of problems of IT application in the industry: 1) a data integration problem, 2) a data view configuration problem, and 3) an information presentation integration problem. These call for a new class of software environment named as an Information Aggregator. \n\nThis dissertation explores computer technologies\u00E2\u0080\u0099 ability to work with integrated model-based project information and solve these three categories of problems. A Unified Construction Project Management Arena (UCPMA) is designed for an Information Aggregator, which allows access to the project information contained in the whole data set and facilitates flexible user-configuration of different views for different project management tasks by exploiting the technologies of data modeling and Industry Foundation Classes data standards, On-line Analytical Processing technologies, and information visualization. The UCPMA consists of three interrelated components corresponding to the three types of problems respectively: a Central Data Model, a Data Winnow, and a Visualization Configuration Model. These components leverage existing technologies and work together to deliver the UCPMA framework which promises benefits of data sharing for information integration, view sharing to incorporate disciplinary work, and dynamic data analysis in a flexible visual configuration environment. A UCPMA prototype system was developed to demonstrate the framework\u00E2\u0080\u0099s ability to fulfill these promises and potential in improving the current construction project management practice, through testing scenarios involving construction project change, risk management and quality control."@en . "https://circle.library.ubc.ca/rest/handle/2429/18030?expand=metadata"@en . " INTEGRATING DATA MODELS, ANALYSIS AND MULTIDIMENSIONAL VISUALIZATIONS: A UNIFIED CONSTRUCTION PROJECT MANAGEMENT ARENA by JIANGUO YE B.E., Beijing Agricultural Engineering University, 1990 M.E. Beijing Agricultural Engineering University, 1993 A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY in THE FACULTY OF GRADUATE STUDIES (CIVIL ENGINEERING) THE UNIVERSITY OF BRITISH COLUMBIA (VANCOUVER) December, 2009 \u0001 Jianguo Ye, 2009 ii ABSTRACT Current construction practice features information fragmentation that overburdens communications, hinders work cooperation, leads to errors and reduces productivity. Information Technology (IT) is widely recognized as being able to effectively improve the fragmentation issue, yet this capability has not been significantly realized in the construction industry. In particular, recent trends in construction IT have introduced the ability to produce large, comprehensive, and integrated data sets describing each project. With emerging technologies, these data models can be exchanged between the computer tools that have traditionally been used to support the various construction applications. To date, however, it has not been possible for users to interact with the full range of integrated data in a way that allows them to configure custom views as needed to support ongoing management tasks. This barrier to working with integrated project data models can be decomposed into three categories of problems of IT application in the industry. 1) A data integration problem: current construction management involves \u00E2\u0080\u009CInformation Islands of Automation\u00E2\u0080\u009D and various IT applications have minimal interoperability; moreover, presumed state-of-the-art solutions lack implementation and are not clear enough what data are needed for construction project management. 2) A data view configuration problem: voluminous data generated in construction calls for effective solutions tailored for construction management, which facilitate users to work with partial subsets (data views) of a central data model. 3) An information presentation integration problem: multidimensional construction data requires consistent, sharable presentation in multi-view visualization to facilitate gaining insights into project information. These call for a new class of software environment named as an Information Aggregator. This dissertation explores computer technologies\u00E2\u0080\u0099 ability to work with integrated model- based project information and solve these three categories of problems. A Unified Construction Project Management Arena (UCPMA), as a major deliverable of this research, iii is designed for an Information Aggregator, which allows access to the project information contained in the whole data set and facilitates flexible user-configuration of different views for different project management tasks by exploiting the technologies of data modeling and Industry Foundation Classes data standards, On-line Analytical Processing technologies, and information visualization. The UCPMA consists of three interrelated components corresponding to the three types of problems respectively: a Central Data Model represents construction project data in a central, conceptual project model; a Data Winnow provides dynamical data exploration services; and a Visualization Configuration Model supports visual presentation of processed multidimensional data in multiple sharable views to end users. These components leverage existing technologies\u00E2\u0080\u0094each one providing an innovation in the application of the technology to the field of project management. The primary contribution, however, is in the way that the components work together to deliver the UCPMA framework, which allows project managers to harness the potential of project information in a uniquely integrated and flexibly user-configurable way. UCPMA promises benefits of data sharing for information integration, view sharing to incorporate disciplinary work, and dynamic data analysis in a flexible visual configuration environment. A UCPMA prototype system was developed to demonstrate the framework\u00E2\u0080\u0099s ability to fulfill these promises and potential in improving the current construction project management practice. The prototype is composed of a central data repository/database, data analysis services, a view engine, and a visualization configuration module. Using testing scenarios involving construction project change, risk management and quality control, the system has demonstrated the UCPMA\u00E2\u0080\u0099s capabilities as an Information Aggregator. The implementation of the system has confirmed the feasibility of the technical approach described in this dissertation. iv TABLE OF CONTENTS ABSTRACT ............................................................................................................................ii TABLE OF CONTENTS......................................................................................................iv LIST OF FIGURES .............................................................................................................xii ACRONYMS .................................................................................................................... xviii ACKNOWLEDGEMENTS.................................................................................................xx CHAPTER 1: INTRODUCTION .........................................................................................1 1.1 BACKGROUND .................................................................................................................1 1.1.1 Layers of Models in IT-Supported Construction Project Management ..................2 1.1.2 Integration of IT Systems in Construction Project Management ............................4 1.1.3 A Change Order Process Case ................................................................................6 1.1.4 A Vision of Improved Integration...........................................................................7 1.2 PROBLEMS AND RESEARCH MOTIVATION........................................................................9 1.2.1 Problems in Current Practice...................................................................................9 1.2.1.1 The Data Layer\u00E2\u0080\u0094Information Fragmentation in Applications......................10 1.2.1.2 Application Logic Layer\u00E2\u0080\u0094Incompatibility of Data Views and Inflexibility in User-Configuration.....................................................................................................11 1.2.1.3 The Presentation Layer\u00E2\u0080\u0094Simplicity and Independence of Information Visualization...............................................................................................................12 1.2.2 State-of-the-Art Information Technologies and Shortcomings.............................14 1.2.3 Formulated Problems and Motivation of Research for Information Aggregator..16 1.3 RESEARCH GOAL AND OBJECTIVES ...............................................................................19 1.4 THE PROPOSED SOLUTION -- UCPMA ..........................................................................20 1.5 RESEARCH PREMISES, SCOPE AND LIMITATIONS ...........................................................23 1.5.1 Previous Research .................................................................................................23 1.5.2 Research Scope and Limitations ...........................................................................23 1.5.3 Contributing Work ................................................................................................24 1.6 RESEARCH METHODOLOGY ...........................................................................................25 v 1.7 READER\u00E2\u0080\u0099S GUIDE...........................................................................................................27 CHAPTER 2: POINTS OF DEPARTURE........................................................................30 2.1 BACKGROUND ...............................................................................................................30 2.2 MULTI-VIEW REPRESENTATION FOR PROJECT MANAGEMENT ......................................31 2.2.1 Project Management Functions and Relationships ...............................................31 2.2.2 Multi-View Representation of Project Information ..............................................34 2.2.3 State-of-the-Art Tools Supporting Multi-View Representation............................37 2.2.3.1 Timberline\u00E2\u0080\u0099s Office ........................................................................................38 2.2.3.2 Autodesk Solutions ........................................................................................40 2.2.3.3 Primavera Solutions .......................................................................................42 2.2.3.4 Microsoft Project............................................................................................44 2.2.3.5 Common Point Project 4D Solution...............................................................45 2.2.4 Summary of Multi-View Representation ..............................................................46 2.3 PROJECT MODELING TECHNOLOGIES ............................................................................47 2.3.1 Product and Process Modeling..............................................................................47 2.3.2 Data Standards.......................................................................................................49 2.3.2.1 Standard for the Exchange of Product Model Data........................................49 2.3.2.2 The International Alliance for Interoperability ..............................................50 2.3.3 Multidimensional Modeling Initiatives .................................................................52 2.3.4 Summary of Project Modeling Technologies........................................................54 2.4 DATA WAREHOUSING AND OLAP.................................................................................55 2.4.1 Data Warehousing .................................................................................................56 2.4.2 OLAP ....................................................................................................................56 2.4.3 Data Warehousing and OLAP in Construction .....................................................58 2.4.4 Summary of Data Analysis Technologies .............................................................61 2.5 INFORMATION VISUALIZATION ......................................................................................61 2.5.1 Information Visualization Strategies.....................................................................63 2.5.2 Multi-View Coordination......................................................................................66 2.5.3 Visualization in Industrial Applications................................................................69 2.5.4 Summary of Information Visualization.................................................................70 2.6 CONCLUSIONS ...............................................................................................................71 vi CHAPTER 3: UNIFIED CONSTRUCTION PROJECT MANAGEMENT ARENA ..73 3.1 ORIGINS OF THE FRAMEWORK .......................................................................................73 3.2 THE UCPMA FRAMEWORK...........................................................................................76 3.2.1 Definition ..............................................................................................................76 3.2.2 Integral Components .............................................................................................76 3.2.3 UCPMA as a Whole System .................................................................................79 3.2.4 UCPMA Features ..................................................................................................80 3.2.4.1 Holism ............................................................................................................80 3.2.4.2 Information Integration ..................................................................................81 3.2.4.3 Flexibility in User-Computer Interaction .......................................................83 3.3 VALUE OF THE PROPOSED FRAMEWORK........................................................................83 3.3.1 Generic Computer-Supported Construction Management ....................................83 3.3.2 Multidimensional Data Presentation .....................................................................86 3.3.3 Data Exploration and Analytical Services.............................................................87 3.4 CONCLUSIONS ...............................................................................................................91 CHAPTER 4: INTEGRATING PROJECT MANAGEMENT INFORMATION IN A CENTRAL DATA MODEL................................................................................................93 4.1 INTRODUCTION ..............................................................................................................93 4.2 PROJECT MANAGEMENT FUNCTIONS AND INFORMATION ..............................................94 4.2.1 Project Management Concept ...............................................................................94 4.2.2 Perspectives on Project Management Functions ...................................................95 4.2.3 Primary Functions and Fundamental Information ..............................................101 4.2.3.1 Scope Management ......................................................................................101 4.2.3.2 Cost Management.........................................................................................102 4.2.3.3 Schedule Management .................................................................................102 4.2.3.4 Resource Management .................................................................................103 4.2.3.5 Quality Management ....................................................................................103 4.2.3.6 Risk Management.........................................................................................104 4.2.3.7 Organization Management ...........................................................................105 4.2.3.8 Information Management .............................................................................105 4.3 CENTRAL DATA MODEL ..............................................................................................106 vii 4.3.1 Modeling Scope and Developing Methodology..................................................107 4.3.2 Scope Management Data Model .........................................................................108 4.3.2.1 Specification.................................................................................................109 4.3.2.2 Phase.............................................................................................................110 4.3.2.3 PerformanceMetric.......................................................................................111 4.3.3 Cost Management Data Model............................................................................112 4.3.4 Schedule Management Data Model ....................................................................113 4.3.4.1 Event.............................................................................................................115 4.3.4.2 Transition .....................................................................................................115 4.3.5 Resource Management Data Model ....................................................................116 4.3.6 Quality Management Data Model .......................................................................117 4.3.6.1 QualityControl..............................................................................................118 4.3.6.2 QualityComplianceNotice ............................................................................119 4.3.6.3 QualityIndicator ...........................................................................................119 4.3.7 Risk Management Data Model............................................................................120 4.3.7.1 Risk...............................................................................................................121 4.3.7.2 RiskTrigger...................................................................................................121 4.3.7.3 RiskResponse ...............................................................................................121 4.3.8 Organization Management Data Model ..............................................................121 4.3.8.1 CommunicationChannel...............................................................................123 4.3.8.2 Meeting.........................................................................................................124 4.3.8.3 Responsibility...............................................................................................124 4.3.8.4 ProcurementProcess .....................................................................................125 4.3.8.5 Trade.............................................................................................................125 4.3.9 Information Management Data Model ................................................................125 4.3.10 Central Data Model ...........................................................................................126 4.4 INFORMATION INTEROPERABILITY ISSUES ...................................................................129 4.4.1 Data from Applications .......................................................................................130 4.4.2 Information Exchange Architectures ..................................................................131 4.4.3 Data Mapping......................................................................................................133 4.4.4 Information Consistency .....................................................................................134 viii 4.5 CONCLUSIONS .............................................................................................................135 CHAPTER 5: THE DATA WINNOW SUPPORTING INFORMATION ANALYSIS ..............................................................................................................................................138 5.1 CONCEPT OF A DATA WINNOW....................................................................................138 5.2 DATA WINNOW MODELS.............................................................................................140 5.3 DIMENSIONS OF DOMAIN INFORMATION .....................................................................142 5.3.1 Dimension Design Procedure..............................................................................142 5.3.2 Review of Information Classification Systems...................................................143 5.3.2.1 MasterFormat ...............................................................................................143 5.3.2.2 Uniclass ........................................................................................................144 5.3.2.3 OmniClass ....................................................................................................144 5.3.3 Common Dimensions ..........................................................................................145 5.3.3.1 Product Dimension.......................................................................................147 5.3.3.2 Process Dimension .......................................................................................149 5.3.3.3 Cost Dimension ............................................................................................152 5.3.3.4 Resource Dimension ....................................................................................154 5.3.3.5 Actor Dimension ..........................................................................................155 5.3.3.6 Document Dimension...................................................................................156 5.3.3.7 Time Dimension...........................................................................................158 5.4 INTEGRATED DOMAIN VIEWS ......................................................................................159 5.4.1 Domain Views Identification ..............................................................................159 5.4.2 Integrated Representation of Domain Views ......................................................161 5.4.2.1 Features of Domain Views...........................................................................161 5.4.2.2 Common Views Design, Functionalities and Representations ....................162 5.4.2.3 View Composition Approach.......................................................................165 5.5 DIMENSIONS AND VIEWS FOR THE CHANGE ORDER PROCESS .....................................166 5.6 CONCLUSIONS .............................................................................................................169 CHAPTER 6: VISUALIZATION CONFIGURATION MODEL.................................170 6.1 FROM DATA VIEW CONFIGURATION TO VISUALIZATION.............................................170 6.2 CONCEPT OF THE VISUALIZATION CONFIGURATION MODEL .......................................172 6.2.1 Model Definition and Roles in the UCPMA Framework ...................................172 ix 6.2.2 Initial Idea about the Model ................................................................................173 6.3 DEVELOPMENT OF THE VISUALIZATION CONFIGURATION MODEL ..............................174 6.3.1 Model Schema.....................................................................................................174 6.3.2 Mapping from Data to Visualization...................................................................176 6.3.3 Model Advantages...............................................................................................177 6.4 VISUALIZATION COMPONENTS ....................................................................................178 6.4.1 Graphic Element..................................................................................................178 6.4.2 Graph ...................................................................................................................179 6.4.3 View ....................................................................................................................181 6.4.4 Scene ...................................................................................................................182 6.5 VISUALIZATION PRINCIPLES AND STRATEGIES ............................................................183 6.5.1 Visualization Principles.......................................................................................183 6.5.2 Visualization Strategies.......................................................................................184 6.5.2.1 Functional Requirements and Interactions ...................................................185 6.5.2.2 Data Type versus Graphs .............................................................................186 6.5.2.3 A Combined Taxonomy Classifying Visual Techniques .............................187 6.5.2.4 Application of Retinal Properties. ................................................................189 6.6 VISUALIZATION COORDINATION .................................................................................190 6.6.1 Classification of Presentation Tasks for Coordination Design ...........................190 6.6.2 Coordination Mechanism ....................................................................................191 6.6.3 Visual Coordination Model .................................................................................193 6.6.3.1 Coordination Formulation ............................................................................193 6.6.3.2 A Derived Coordination Model....................................................................194 6.6.3.3 MVC Design Pattern Associated with the Coordination Model ..................195 6.7 PRESENTATION OF THE CHANGE ORDER PROCESS IN VCM.........................................197 6.8 CONCLUSIONS .............................................................................................................201 CHAPTER 7: SYSTEM IMPLEMENTATION AND EVALUATION........................202 7.1 INTRODUCTION ............................................................................................................202 7.2 THE UCPMA PROTOTYPE SYSTEM AND IMPLEMENTATION ........................................203 7.2.1 Overview of the System ......................................................................................203 7.2.2 System Architecture ............................................................................................205 x 7.2.3 System Implementation.......................................................................................207 7.2.3.1 Database .......................................................................................................207 7.2.3.2 Data Analysis Services.................................................................................209 7.2.3.3 View Engine .................................................................................................212 7.2.3.4 Visualization Configuration Module............................................................214 7.3 SYSTEM EVALUATION .................................................................................................220 7.3.1 Demonstration of Operations ..............................................................................221 7.3.1.1 Populate Data Model ....................................................................................221 7.3.1.2 Create a View ...............................................................................................224 7.3.1.3 Configure a Scene ........................................................................................226 7.3.2 Testing Scenarios ................................................................................................228 7.3.2.1 Scenario 1 \u00E2\u0080\u0093 Build up a Change Order Process Overview...........................229 7.3.2.2 Scenario 2 \u00E2\u0080\u0093 Monitor Potential Impact and Review Resource Usage..........232 7.3.2.3 Scenario 3 \u00E2\u0080\u0093 Acquire Change Information for Updating a Schedule...........232 7.3.2.4 Scenario 4 \u00E2\u0080\u0093 Verify Actual Resource Usage for a Specific Change ............235 7.3.2.5 Scenario 5 \u00E2\u0080\u0093 Information Drill-down ...........................................................237 7.3.2.6 Scenario 6 \u00E2\u0080\u0093 Explore Information on a Risk Management Scene................238 7.3.2.7 Scenario 7 \u00E2\u0080\u0093 Present a Quality Control Overview .......................................242 7.3.3 Comparison with Existing Systems.....................................................................245 7.4 RESULTS ......................................................................................................................247 7.4.1 Achievements ......................................................................................................247 7.4.2 UCPMA Applicability and Limitations ..............................................................251 7.4.2.1 Applicability.................................................................................................251 7.4.2.2 Limitations ...................................................................................................254 7.5 CONCLUSIONS .............................................................................................................254 CHAPTER 8: CONCLUSIONS........................................................................................256 8.1 SUMMARY ...................................................................................................................256 8.1.1 Research Problems and Objectives .....................................................................256 8.1.2 Accomplishments and Exceptions ......................................................................259 8.2 CONTRIBUTIONS ..........................................................................................................260 8.3 RECOMMENDATIONS FOR FUTURE WORK....................................................................262 xi 8.3.1 Advance the UCPMA Framework ......................................................................262 8.3.2 Extend System Functions ....................................................................................263 REFERENCES ...................................................................................................................265 APPENDIX A: A CHANGE ORDER PROCESS CASE...............................................273 A.1 CHANGE ORDER PROCESS SCENARIO .........................................................................273 A.1.1 Change Initiation ............................................................................................274 A.1.2 Change Proposal Evaluation ..........................................................................275 A.1.3 Change Order Execution ................................................................................276 A.2 MODELING THE CHANGE ORDER PROCESS .................................................................276 A.2.1 Change Order Process Activities Dissection......................................................276 A.2.2 Process Model in UML Notations......................................................................279 A.3 INFORMATION INVOLVED IN CHANGE ORDER PROCESS..............................................281 A.3.1 Participants .........................................................................................................281 A.3.2 Documents..........................................................................................................282 A.3.3 Information Recorded in Documents .................................................................282 A.4 CHANGE ORDER PROCESS DATA MODEL ...................................................................287 APPENDIX B: UCPMA DATA MODEL ASPECTS.....................................................289 APPENDIX C: SCHEMA OF COMMON DIMENSIONS............................................298 APPENDIX D: VIEW ENGINE FUNCTIONS AND INORMATION FLOW SEQUENCE DIAGRAM...................................................................................................302 D.1 VIEW ENGINE FUNCTIONS ..........................................................................................302 D.1.1 Translate User Instructions.................................................................................302 D.1.2 Populate and Present Visualization ....................................................................303 D.1.3 Coordinate Views ...............................................................................................304 D.2 INFORMATION FLOW SEQUENCE DIAGRAM ................................................................305 APPENDIX E: RISK MANAGEMENT AND QUALITY CONTROL CASES..........308 E.1 RISK MANAGEMENT SCENARIO ..................................................................................308 E.2 QUALITY CONTROL AND ASSURANCE SCENARIO........................................................309 xii LIST OF FIGURES Figure 1.1: A person uses information about the real-world project to form a mental model. 2 Figure 1.2: A person\u00E2\u0080\u0099s mental model of the project is informed by the information models that exist with the information systems (paper and electronic document and computer applications). ....................................................................................................................3 Figure 1.3: Information systems contain information models at three layers of data, application logic, and presentation...................................................................................4 Figure 1.4: Information flows for solving some task on a construction project: 1) accessing project information via a one computer application, 2) interacting with the application to form a mental model and manipulate the information to form a solution, 3) using a second application to document the solution, and 4) communicating the solution through a third application to 5) inform other users.........................................................5 Figure 1.5: Different Product-Location Logic Views ............................................................11 Figure 1.6: Simple Information Presentation Examples ........................................................13 Figure 1.7: Integration of information systems at different levels. Even with integration at the data layer, current approaches still extract \u00E2\u0080\u009Csilos of information\u00E2\u0080\u009D as shown on the right, whereas a more fully integrated approach would allow integration at the view configuration and information presentation layers, as shown on the left.......................18 Figure 1.8: UCPMA Components and Contributing Research Work ....................................22 Figure 2.1: Wideman\u00E2\u0080\u0099s Function-Process-Time Relationships in Project Management .......33 Figure 2.2: Wideman\u00E2\u0080\u0099s Concept Map of Project Management..............................................33 Figure 2.3: Samples of REPCON\u00E2\u0080\u0099s Physical View,...............................................................35 Figure 2.4: Concept of Process Perspectives (Curtis et al., 1992) .........................................37 Figure 2.5: RFI Creation and Related Accounting and Project Management via Timberline Solutions.........................................................................................................................40 Figure 2.6: Autodesk Revit\u00E2\u0080\u0099s Snapshot of Multiple Building/Product Views.......................42 Figure 2.7: Primavera\u00E2\u0080\u0099s Collaborative Project Management System ....................................43 Figure 2.8: Example of Planning and Scheduling of Primavera E/C Solution ......................44 Figure 2.9: Example of Microsoft Project Gantt-Chart View................................................45 Figure 2.10: Example of Common Point Project 4D Modeling.............................................46 Figure 2.11: IFC Model Architecture and Modules in Layers (IAI, 2007)............................52 Figure 2.12: Example of Microsoft OLAP Data Structure ....................................................58 Figure 2.13: Example of Interactive Browser-based Query for Drawing Status ...................59 xiii Figure 2.14: Chau \u00E2\u0080\u0098s Material Inventory Star Schema...........................................................60 Figure 2.15: Qin\u00E2\u0080\u0099s User-Oriented (Upper Table) and Developer-Oriented (Bottom) Frameworks ....................................................................................................................65 Figure 2.16: Keim\u00E2\u0080\u0099s Orthogonal Classification of Visualization Techniques .......................66 Figure 2.17: Boukhelifa\u00E2\u0080\u0099s Abstract Model for Coordination in Exploratory Visualization ..67 Figure 2.18: Analogy between Relational Database Concepts and........................................67 Figure 2.19: CIFE WorkSpace\u00E2\u0080\u0099s Message Passing System ...................................................68 Figure 2.20: Model-View-Controller Design Pattern Diagram .............................................69 Figure 3.1: An Example Scenario of Unified Approach to Project Management..................74 Figure 3.2: Configurable Environments\u00E2\u0080\u0099 High-Level Architecture .......................................75 Figure 3.3: Information Interdependency Problems vs. UCPMA Solutions..........................78 Figure 3.4: Integrated UCPMA Framework Schema.............................................................80 Figure 3.5: Information Interdependency between UCPMA Components............................82 Figure 3.6: TOPS Element Relationships (Yu, 2002)............................................................83 Figure 3.7: Efforts of Design, Cost, and Schedule Integration Using Commercial Tools (Staub-French & Fischer, 2001).....................................................................................85 Figure 3.8: Nagappan\u00E2\u0080\u0099s Compositional Model of Visualization............................................88 Figure 3.9: Sample of Navigational Models, Linking Entities of Product and Process Model (Reinhardt et al., 2004)...................................................................................................89 Figure 3.10: An IFC Aspect Example -IFC Cost Aspect (VTT, 2005) .................................90 Figure 4.1: Lille Work Session\u00E2\u0080\u0099s \u00E2\u0080\u009CMind Map\u00E2\u0080\u009D ......................................................................97 Figure 4.2: Project Management Functions from Different Perspectives ..............................99 Figure 4.3: Primary Functions of Project Management .......................................................100 Figure 4.4: Scope Management Data Model........................................................................110 Figure 4.5: Project Management Performance Assessment Matrix and Example Data ......111 Figure 4.6: Cost Management Data Model ..........................................................................113 Figure 4.7: Schedule Management Data Model...................................................................114 Figure 4.8: Resource Management Data Model...................................................................116 Figure 4.9: Quality Management Data Model .....................................................................118 Figure 4.10: Risk Management Data Model ........................................................................120 Figure 4.11: Organization Management Data Model...........................................................122 Figure 4.12: Communication in the CM Delivery System...................................................123 Figure 4.13: Information Management Data Model ............................................................126 xiv Figure 4.14: Central Data Model for Integrated Project Management.................................128 Figure 4.15: Classes of the Central Data Model ..................................................................129 Figure 4.16: Batch/File-based Data Exchange Architecture ................................................131 Figure 4.17: Model-Based/Repository Data Exchange Architecture...................................133 Figure 4.18: Application Data Scheme (Yu, 2002)..............................................................134 Figure 4.19: Object Register Scheme...................................................................................135 Figure 5.1: Sample Models of Data Winnow......................................................................140 Figure 5.2: Mapping from the Data Winnow to the Central Data Model ...........................141 Figure 5.3: Procedure of Dimension Design ........................................................................142 Figure 5.4: Challenge of Information Mapping between Dimensions.................................143 Figure 5.5: Example of Dimension Members Associated at Different Levels ....................145 Figure 5.6: Matrix of Functions vs. Information Classes.....................................................146 Figure 5.7: Product Dimension Schema...............................................................................149 Figure 5.8: Process Dimension Schema..............................................................................151 Figure 5.9: Cost Dimension Schema....................................................................................153 Figure 5.10: Resource Dimension Schema ..........................................................................154 Figure 5.11: Actor Dimension Schema ................................................................................156 Figure 5.12: Document Dimension Schema.........................................................................157 Figure 5.13: Time Dimension Schema.................................................................................158 Figure 5.14: Information Interdependency between Views, Dimensions, Data Models .....162 Figure 5.15: Dimensions and Functional Requirements of UCPMA Views .......................164 Figure 5.16: View Composition Diagram ............................................................................165 Figure 5.17: Changer Order Process Views in Microsoft Visio UML Notation..................168 Figure 6.1: Diagram of Information Visualization Process Procedures..............................171 Figure 6.2: Flowers in a Natural View.................................................................................174 Figure 6.3: The VCM Schema .............................................................................................175 Figure 6.4: Correspondence between Data Winnow Entities to VCM Components ...........176 Figure 6.5: The VCM\u00E2\u0080\u0099s Data Schema..................................................................................178 Figure 6.6: Taxonomy of Graphic Elements and Retinal Properties ...................................179 Figure 6.7: Sample Graphs in the Engineering Field: (1) pie chart displays 1D data; (2) scatterplot display 2D data; (3) 3D geometric model; (4) stock chart shows temporal data vs. daily stock volume; (5) CPM shows network/graph data; (6) tree and (7) tree map displays hierarchical data; (8) fisheye and (9) histogram displays multiple dimensional data...........................................................................................................180 xv Figure 6.8: Primavera Cost-Schedule Based Performance View.........................................181 Figure 6.9: Visual Strategies by Data Types (Songer, et al., 2004) .....................................186 Figure 6.10: Identification of Data Types in Dimensions ....................................................188 Figure 6.11: Requirement-based Classification of Visual Techniques ................................188 Figure 6.12: An Example of Project Schedule in a Gantt Chart ..........................................189 Figure 6.13: Presentation Tasks vs. Functional Requirements ............................................191 Figure 6.14: Sample Coordination through Panning and Zooming .....................................192 Figure 6.15: View Coordination Scenario............................................................................193 Figure 6.16: The Visualization Coordination Data Model in Microsoft Visio UML Notation ......................................................................................................................................194 Figure 6.17: MVC Diagram Implying the Implementation of the Observer Pattern (D' Aoust, 2002).............................................................................................................................196 Figure 6.18.1: Context View Presenting the Change Order Process ...................................198 Figure 6.18.2: Plan View Presenting the Change Order Process .........................................199 Figure 6.18.3: Supply View Presenting the Change Order Process.....................................199 Figure 6.18.4: Effect View Presenting the Change Order Process ......................................200 Figure 6.18.5: Reference View Presenting the Change Order Process ................................200 Figure 7.1: Interrelationships among System Components .................................................204 Figure 7.2: System Architecture...........................................................................................206 Figure 7.3: Implemented Classes of Central Data Model ....................................................207 Figure 7.4: Aspects of the Central Data Model....................................................................208 Figure 7.5: Process Aspect - Process Data Model Schema..................................................209 Figure 7.6: Dimensions and Process Dimension Schema ....................................................210 Figure 7.7: Dimension Panel Listing Dimensions for a Particular Scene and Scene Panel Listing Created Scenes for Project Management .........................................................211 Figure 7.8: Sample of SQL Language for Selecting Designated Dimensional Data ...........211 Figure 7.9: View Engine Components and Application Architecture .................................212 Figure 7.10: Create View in the Data Layer .......................................................................213 Figure 7.11: Examples: Compound JOIN Queries...............................................................213 Figure 7.12: Simplified View Coordination Model Implying the Observer Pattern...........214 Figure 7.13: Set up Visualization by Clicking a Menu Item...............................................215 Figure 7.14: Edit a Registered Graph Component ...............................................................216 Figure 7.15: Built Graph Components for View Configuration ..........................................217 xvi Figure 7.16: Select a Graph Component by Clicking an Icon on the Graph Button Bar ....218 Figure 7.17: Views Common to Primary Project Management Functions ..........................219 Figure 7.18: Example Interfaces for Entering Project Data .................................................222 Figure 7.19: Import Product Data from the ArchiCAD Application ...................................223 Figure 7.20: Define a View by Clicking the Attributes Menu Item.....................................224 Figure 7.21: View Layout Design ........................................................................................225 Figure 7.22: View Schema Design.......................................................................................226 Figure 7.23: Create a Scene by Adding Available Views to Its View List..........................227 Figure 7.24: Edit Relationships between Plan & Supply Views to Compose a Scene ........228 Figure 7.25: Presentation of a Scene Composed of Five Common Views. ........................231 Figure 7.26: User Interaction on Views to Acquire Change Information ............................234 Figure 7.27: Establish Link between Time Sheet View and Plan View ..............................235 Figure 7.28: Coordination between Plan View and Time Sheet View ................................236 Figure 7.29: Information Drill-down Scenario ....................................................................238 Figure 7.30: A Construction Risk Management Scene in Five Common Views.................240 Figure 7.31: User Interaction to Explore Risk Control Information ....................................242 Figure 7.32: A Construction Quality Control Scene in Five Common Views.....................244 Figure 7.33: A Typical P3E/C Project Schedule Layout .....................................................247 Figure 7.34: Mapping View Requirements to Project Management Activities ...................253 Figure A.1: Found Sinkhole in Construction Site ................................................................274 Figure A.2: Change Order Process Dissection (To Be Continued)......................................277 Figure A.3: UML Activity Diagram - Change Initiation .....................................................279 Figure A.4: UML Activity Diagram - Change Proposal Evaluation....................................280 Figure A.5: UML Activity Diagram - Change Order Execution .........................................281 Figure A.6: Request for Information (RFI) Form Sample ...................................................285 Figure A.7: Change Proposal Form Sample.........................................................................286 Figure A.8: Change Order Sample.......................................................................................287 Figure A.9: UML Class Diagram \u00E2\u0080\u0093 Change Order Process Data Model .............................288 Figure B.1: Cost Aspect Schema..........................................................................................289 Figure B.2: Document Aspect Schema ................................................................................290 Figure B.3: Organisation Aspect Schema ............................................................................291 Figure B.4: Product Aspect Schema ....................................................................................292 Figure B.5: Project Aspect Schema......................................................................................293 xvii Figure B.6: Resource Aspect Schema ..................................................................................294 Figure B.7: Time Aspect Schema ........................................................................................295 Figure B.8: Risk Aspect Schema..........................................................................................296 Figure B.9: Quality Aspect Schema.....................................................................................297 Figure C.1: Cost Aspect Schema..........................................................................................298 Figure C.2: Actor Aspect Schema........................................................................................299 Figure C.3: Document Aspect Schema ................................................................................300 Figure C.4: Process Aspect Schema.....................................................................................300 Figure C.5: Product Aspect Schema ....................................................................................301 Figure C.6: Resource Aspect Schema ..................................................................................301 Figure C.7: Time Aspect Schema ........................................................................................301 Figure D.1: Concrete Adaptor Classes .................................................................................303 Figure D.2: Visualization Presentation Sequence Diagram .................................................306 Figure D.3: View Coordination Sequence Diagram ............................................................307 Figure E.1: Job Safety Analysis Report for Drilling through Frozen Slough .....................312 Figure E.2: Daily Inspection Report of Undergroundings Construction .............................313 Figure E.3: Base Inspection Report of Undergroundings Construction...............................314 Figure E.4: Non-Compliance Report Sample ......................................................................315 xviii ACRONYMS AEC/FM Architecture, Engineering, Construction and Facility Management BCCM Building Construction Core Model of STEP CBS Cost Breakdown Structure CCD Contract Change Directive CCDC Canadian Construction Documents Committee CIFE Center for Integrated Facility Engineering CM Construction Management CPM Critical Path Method DS Data Source GUI Graphic User Interface IAI International Alliance for Interoperability IFC Industry Foundation Classes ISO International Origination for Standard IT Information Technology KPI Key Performance Indicator MDX Multidimensional Expressions MVC Model-View-Controller OLAP On-line Analytical Processing OO Object-oriented technology PDF Physical Data Format PMBOK Project Management Body of Knowledge PMI Project Management Institute QA/QC Quality Control / Quality Assurance REPCON REPresenting CONstruction RFI Request for Information SQL Structured Query Language STEP Standard for the Exchange of Product Model Data xix TOPS Total Project Systems UCPMA Unified Construction Project Management Arena UML Unified Modeling Language VCM Visualization Configuration Model WBS Work Breakdown Structure XML Extensible Markup Language xx ACKNOWLEDGEMENTS The completion of this dissertation represents the culmination of a long but not lonely journey through life. Without the persistent support of many people, the pilgrimage would not have been possible. To them I now express my gratitude. First, I want to thank my supervisor, Professor Thomas Froese, for his advice, encouragement and inspiration. With great patience, he advised me on how to research the topic and how to work with others. He encouraged me whenever the task seemed hopeless, prodded me to hold to the perspective of domain research, and guided me in bringing all the components together. In short, he has been a great advisor and a major influence on my life. Thanks, Tom! My gratitude goes as well to the other members of the dissertation committee, including Professor Alan Russell, Professor Sheryl Staub-French, and Professor Lloyd Waugh, as well as the external examiner, Professor Lucio Soibelman, for their careful review of draft chapters and provision of many suggestions for improving the dissertation. I would also like to express my appreciation to many friends and colleagues in the University of British Columbia, who spent much time helping me track down research sources and develop my ideas. These people include Heli Torres, Sanjaya DeZoysa, Hsin- Chieh Frank Lin, Ming-En Li, Zonghai Han, Kehui Zhang, Min Zhu, Hao Nie, Yugui Wang, Branka Kosovac, Arezou Pouria, Asad Udaipurwala, Hsi-Kun Wang, Tanaya Korde, and many others. Additionally, I wish to acknowledge my friend Dr. David Holm, a retired history instructor from the College of New Caledonia. He encouraged me by sharing his own story of frustration as a Ph.D. student decades ago. He also took time to edit one of my late drafts for grammatical errors. xxi Very special thanks to my wife, Wenxin Wendy Liu, for her persistent efforts to keep my life balanced and optimistic, and for her toleration of my occasional discouragement and irritation when struggling with research problems. Thank you, too, to our daughter, Sasha Yudi Ye, who has been patient despite receiving little attention from me. Not least, I thank my parents for their endless support and love. Soli deo gratia. Introduction 1 CHAPTER 1: INTRODUCTION This chapter introduces the research topic: the development of a Unified Construction Project Management Arena framework for an Information Aggregator. It analyzes an example case of change order processing and formalizes problems existing in the current IT-supported practice, outlines the research goal and identifies objectives to achieve data, analysis and information visualization and integration. The chapter then introduces the proposed solution and research contributions, clarifies the research scope and premises and, finally, provides a reading guide for the dissertation. 1.1 Background A construction project is decomposed into processes or distinct work packages. A process, in turn, is divided into individual tasks, which are performed by different participants. These participants often work for different organizations and towards different goals, with minimal focus on integrating the work (Froese & Staub-French, 2003). Moreover, individual tasks typically are carried out with different software tools that each adopts a different information perspective, generating a wide range of fragmented project datasets or data models in which the data structures are heterogeneous and the presentation is complex (non-integrated views represent interdependent, multidimensional information). This practice contributes to the fragmentation in the industry (Russell & Froese, 1997) (Laitinen, 1998) (M. Hassanian, 2002), and calls for integration. Information Technology (IT) is widely recognized as an enabling technology that can improve the fragmentation problem, especially in aspects of information integration and system interoperability (Froese, 2003a) (Eastman, 1999). This dissertation is predicated upon this premise. Introduction 2 1.1.1 Layers of Models in IT-Supported Construction Project Management This research is directed towards the application of IT in the construction project management (PM) domain in order to achieve information integration and system interoperability. The research relies heavily on the concept that project information constitutes a model of the project\u00E2\u0080\u0094i.e., a partial, abstract representation of the real-world project that conveys useful facts and/or enables performance predictions\u00E2\u0080\u0094and that project management practice is heavily influenced by the ability of these information models to convey the project reality. Various types of project information and information systems provide a variety of project models. Figure 1.1 illustrates the simplest conceptualization of an information model, in which a person (e.g., a project manager) is participating in a construction project. Through their interaction with the project, the person builds up an understanding of many aspects of the project. The person thereby forms a mental model of the project. Figure 1.1: A person uses information about the real-world project to form a mental model. In reality, much of a project manager\u00E2\u0080\u0099s information about the project does not come from their direct interaction with the physical project (indeed, a large portion of their work occurs before the project physically exists). Rather, the project manager works with information models of the project that exists in the form of paper or electronic documents and computer Real-world Project Person\u00E2\u0080\u0099s Mental Model Introduction 3 applications, as illustrated in Figure 1.2. The person\u00E2\u0080\u0099s mental models, therefore, become highly dependent on the information systems\u00E2\u0080\u0099 information models. Figure 1.2: A person\u00E2\u0080\u0099s mental model of the project is informed by the information models that exist with the information systems (paper and electronic document and computer applications). However, the computer applications do not contain a single uniform information model. Following the basic layered architecture of computer applications, the information systems can be separated (see Figure 1.3) into a data layer (dealing with the physical representation and storage of the project information), the application logic layer (dealing with the logical representation and manipulation of the project information), and the presentation layer (dealing with the graphical representation and user interface of the project information). Real-world Project Person\u00E2\u0080\u0099s Mental Model Information System Introduction 4 Figure 1.3: Information systems contain information models at three layers of data, application logic, and presentation. 1.1.2 Integration of IT Systems in Construction Project Management A project manager carries out many different duties on a construction project, each involving different models (i.e., different views or perspectives) of the project information and frequently different computer applications. In a typical problem solving situation (shown in Figure 1.4), (1) a user may access some project information via one computer application (e.g., accessing project dimensions through a CAD application). (2) The user then works with the application to understand the information and form mental models of the problem and possible solutions (e.g., completes quantity take-off calculations). (3) The user may then use a second application to document the solution (e.g., document a bill of quantities in a spreadsheet). (4) This information is then communicated electronically to another user (e.g., send as an email attachment). (5) Finally, the second user uses a third Real-world Project Person\u00E2\u0080\u0099s Mental Model Information System Application Logic Layer Data Layer Presentation Layer Introduction 5 application to access and work with the information (e.g., reading the bill of quantities into an estimating application). Figure 1.4: Information flows for solving some task on a construction project: 1) accessing project information via a one computer application, 2) interacting with the application to form a mental model and manipulate the information to form a solution, 3) using a second application to document the solution, and 4) communicating the solution through a third application to 5) inform other users. The construction industry\u00E2\u0080\u0099s fragmentation, introduced earlier, is manifested in the fact that, although all of the information deals with the same real-world project, each of the steps involves different computer applications, each working with different, heterogeneous data sets modeled in different logical views and presented to the user through an interface that is idiosyncratic to each application. In contrast, an integrated solution would involve seamless interoperability between many of these steps and applications. The characteristics and issues of integrated IT solutions will be discussed more fully later in this chapter, focusing on the Real-world Project People\u00E2\u0080\u0099s Mental Model Information Systems Application 1 Application 2 Application 3 1 2 3 4 5 Introduction 6 thesis objectives of advancing information systems integration at all three of the described layers. 1.1.3 A Change Order Process Case To illustrate the scenario described above, a change order process of a building project is taken as an analytical example case, to which reference will be made repeatedly in subsequent chapters. The change order process has been selected because the changes that occur in almost every project have interdependent impacts on the project scope, schedule, cost, and other project objectives; they can draw upon information from the entire corpus of project data; and they involve interactive communication among many construction parties. As such, change orders can be thought of as a microcosm of the overall task of construction management and therefore provide an appropriate test case for research on integrative project management issues. A more complete presentation of this case appears in Appendix A. This change order process deals with an unexpected sinkhole during excavation for a small office building. At first, the excavation subcontractor found a sinkhole below the existing grade at grid 2-A and notified the contractor\u00E2\u0080\u0099s field engineer of the discovery by correspondence. The field engineer verified the finding mainly by reviewing the drawings, specifications and the geotechnical report in order to confirm if it was included in the defined work scope. Upon determining that the sinkhole was an unexpected issue, the field engineer then prepared a Request for Information (RFI) form requesting work direction. The RFI was submitted to the project architect who reviewed the request and gave instruction for preparing a change order proposal. Preparing the change proposal involved the contractor\u00E2\u0080\u0099s cost estimator, scheduler, and the field engineer, since it needed to specify work quantity, cost method, cost total, and possible schedule extension. The change order proposal was sent to the architect and the owner (or his/her representative) for review. After approval, a change order, as modification of the signed work contract, was issued to the contractor and affected subcontractors. Finally, the extra work was carried out and the extra costs were paid. Introduction 7 In the process, there were three critical tasks involving substantial data exploration and analysis. These were: verifying the issue and preparing the RFI, preparing the change order proposal, and issuing the change order. Here the first task is taken as an example for illustrating the data exploration and analysis steps listed in Section 1.1.2. Supported with applicable computer tools, verifying the sinkhole issue and preparing an RFI would likely include the following steps: \u00E2\u0080\u00A2 Browsing information in paper-based or electric documents: site plan, architectural and structural foundation plan (in AutoCAD, e.g.), structural notes, General Requirements-site work, Site Preparation and Demolition, Earthwork, the boring report at the location of the footing. For large projects, a web-based document management system is usually applied in support of browsing information. \u00E2\u0080\u00A2 Analyzing collected information and generating a mental model of how to deal with the issue as a change process. The mental model includes the appropriate procedure to process changes \u00E2\u0080\u0093 who should be contacted, what should be presented, what order of activities should be followed, etc. \u00E2\u0080\u00A2 Using different applications and interfaces to create a RFI form according to individual understanding. For example, Microsoft Word, or Meridian Project Systems (Meridian, 2008), or others are typically used to clarify the issue in detail and specify the response as well as its needed date. \u00E2\u0080\u00A2 During the preparation of the RFI, the field engineer may discuss applicable information with the superintendent and involved subcontractors; after preparing the RFI, the field engineer will usually discuss it with various persons to continue the process. For example, the field engineer might tell the office administrator to track and submit the RFI (the administrator would track the RFI transmittal in a log through another computer tool), and call the architect to explain to him/her the issue described in the RFI, etc. 1.1.4 A Vision of Improved Integration As illustrated in the preceding scenario of preparing an RFI for the sinkhole issue, routine project management tasks require data from a wide range of sources that typically must be Introduction 8 sought out and integrated using time-consuming, manual processes. Recent trends in construction IT improve data interoperability but do little to improve this issue. To supplement existing software tools that work with individual data views, we envision a new approach for combining and working with integrated project data that we call an Information Aggregator. The core functionality of an information aggregator is that is can combine a comprehensive range of data from the target domain (here, construction project management), including the interconnections that exist among the data; it allows users to define any reasonable subset of the data to meet the requirements of arbitrary work tasks (with particular emphasis on subsets that capture multiple data views or dimensions); and it presents the data through appropriate user interfaces. This core functionality can be further decomposed into requirements at the three system architecture layers: \u00E2\u0080\u00A2 Data layer. o It must be able to accommodate the data that is common to the field of construction project management. o In order to combine data from a wide range of sources, it must be compatible with data exchange standards for system interoperability. \u00E2\u0080\u00A2 Logic Layer. o It must be possible to extract data views derived from the central data model. o It must be possible for users to define the data views at configuration time. o It should be possible for end users to work on partial models (data views) through manipulating dimensions and levels for specific analysis purposes. \u00E2\u0080\u00A2 Presentation Layer. o The system should present the PM data through appropriate and consistent user interface elements. o It should be possible for end users to dynamically generate their own custom views. Introduction 9 o Users should be able to interact with the user interface elements to navigate and explore the data sets. 1.2 Problems and Research Motivation 1.2.1 Problems in Current Practice From Section 1.1, we can see that computer tools are capable of supporting many tasks \u00E2\u0080\u0093 browsing, searching document, generating reports, etc. To some extent, they can reduce problems in construction processes resulting from erroneous, untimely or incomplete information. The tools applied for architecture, engineering and construction (AEC) management are claimed to be able to bring more benefits in information sharing, analysis, and better coordination and cooperation (Russell & Froese, 1997) (Garrett et al., 2004). In comparison with our vision of improved integration, however, the full potential for effective improvement of project management has not yet been realized (Froese, 2003a & 2003b). More specifically, technologies are emerging that allow project information from a wide variety of construction-related applications to be exchanged and combined into a comprehensive integrated project model. This model can be passed from one application to another to achieve a high degree of data interoperability. Yet, even as these technologies reach industrial viability, they achieve only a limited form of information sharing since they are largely bound by the single-perspective computer applications that have traditionally been used in the industry, or by new tools designed around some specific multi-dimensional perspective. It is not possible for users to fully access the combined data model in a way that allows them to draw from the full range of project information, bring the required information into an integrated view, and use appropriate data visualization techniques to analyze and work with the data\u00E2\u0080\u0094all in a flexible, user-configurable manner to suite the demands of ongoing design and management processes. This thesis attempts to address this problem by developing a technical framework (a conceptual design) for an information aggregator system that can achieve the desired degree Introduction 10 of integration. The following sections discuss how this general challenge of creating an information aggregator decomposes into systems integration challenges at all three of the system architecture layers introduced previously: The data layer, the application logic layer, and the presentation layer. 1.2.1.1 The Data Layer\u00E2\u0080\u0094Information Fragmentation in Applications The data used by different applications is generally associated with each specific application and is not readily interoperable. It is generally physically fragmented, existing on different computers or at least in files available to specific applications. Furthermore, the data files are designed for particular problems, applications usually generate information represented in vocabularies and formats (text, numerical, video, etc.), which vary from one environment to another (Kosovac et al., 2000). This heterogeneity of information representation makes it difficult for a tool to read or understand data from different sources. For example, in the change order process scenario, a transmittal log might be created with Microsoft Excel, while the RFI form might be generated through a Meridian product. Due to different representational formats, their information items may not be able to transact directly with each other. A major trend in construction information technology has been the development of system interoperability through shared data models of construction projects, or Building Information Models (BIM). With shared BIM-based models, and the Industry Foundation Classes (IFC) data standard in particular, the potential of a high degree of information interoperability has been achieved (with its major efficiencies and information coordination benefits). However, each user still completes their separate tasks using their separate (largely traditional) tools, adopting their own perspective of the project information. Those tools still work with silos of project information, since they are incapable of accessing all relevant project information by aggregating them together into a common project data model as a whole, and do not allow users to explore all the data and particularly, their interrelationships between different data views. In summary, technology and data standards have emerged to support the integration of much of the available project information, but this technology alone does not provide a solution for goals of an information aggregator. Introduction 11 1.2.1.2 Application Logic Layer\u00E2\u0080\u0094Incompatibility of Data Views and Inflexibility in User-Configuration Applicable IT tools in construction management, such as AutoCAD and Meridian Project Systems mentioned in the change order process case, work on data sets which are modeled into idiosyncratic logic views - logic views in one application are incompatible to others. For example, a Product and a Location may be defined having a direct relationship in one application (see Scenario 1 in Figure 1.5). Once the sinkhole change order is related to a foundation wall (#234), indicating that the change impacts the construction of this wall, it is easy to obtain the wall\u00E2\u0080\u0099s location of Grid 2-A by navigating from Product to Location. Many other design and project management applications used on a project would not have representations of both products and locations. Even those that do, however, are likely to have different logic representations of the information, like Scenario 2 shown in Figure 1.5. Such differences at the logic layer hinder the ability to integrate data across different applications. Figure 1.5: Different Product-Location Logic Views Introduction 12 With the trend towards standardized project data models, some efforts have been made to define logical data views as subsets of an overall project data model, e.g., to support customized data import/export application modules; or more recent efforts to develop standardized data views to support specific data exchange situations. However, these approaches define data views at system-design time. They do not provide a solution to the desired feature of an information integrator that users can configure their own data views as part of a system configuration process. 1.2.1.3 The Presentation Layer\u00E2\u0080\u0094Simplicity and Independence of Information Visualization Many software applications that are well established within project management, such as scheduling, estimating, cost control, or CAD, have well developed graphical interfaces. They are effective at supporting their target PM tasks. However, these interfaces were designed to reflect a view or perspective that focuses on individual tasks independent of each other. As a result, such graphic layouts may hide inherent data interdependencies, which are important for finding problems and their causes, predicting some trends (e.g. cost overruns), or coordinating works with each other (Songer et al., 2004). For example, in the change order process case, the Time Record Card was visualized in a text view; while the cost breakdown in the Change Proposal was presented with a two-dimensional visualization/table (shown in Figure 1.6). These two data graphics are standalone interfaces on which different persons acted. The Time Record Card shows that the employee #321-3 was a level 3 operator (backhoe operator) working on May 3rd, 2006 for 6 hours; and her job code on that day was 5033 indicating that she served as a backhoe operator for the sinkhole job (assuming that cleaning the sinkhole and backfill needs two days and the designated employee worked on a different job site on May 4th, 2006). In the cost breakdown table, a cost item shows that a backhoe (including operator) usage was 8 hours. From these two visualizations, we can see that information about working hours in the Time Record Card doesn\u00E2\u0080\u0099t match the backhoe usage in hours. Due to simplicity and independence of information presentation, these two graphics do not explicitly present relationships between data items and convey the existing information conflict. Introduction 13 Figure 1.6: Simple Information Presentation Examples Moreover, these interfaces were specialized for visualizing their particular data views designed by the developers, lacking an interactive analysis environment which allows users to actively change visual parameters (Boukhelifa & Rodgers, 2003) and support arbitrary user-configuration of multidimensional data views. For example, among software tools mentioned in the change order process case, most employ a visualization strategy suitable for one-dimensional data types and support ad hoc user-interactions designed by software developers. Generally, in order to formulate end users\u00E2\u0080\u0099 own questions for analysis, it is ineffective for users to change visualization strategies by adding one or many sophisticated graphs in order to expose the influence of a change order on other processes, or to rapidly filter, progressively refine search parameters, continuously reform goals and manipulate visual scanning (Ahlberg & Shneiderman, 1994). Introduction 14 At each of the three layers, then, current systems exhibits a common shortcoming (as suggested by Froese & Staub-French, 2003)\u00E2\u0080\u0094they assume fairly specific perspectives and perform well within these perspectives, but are weak at addressing the inevitable interdependencies that exist between these narrow perspectives, and they have not been combined into an overall solution described above. 1.2.2 State-of-the-Art Information Technologies and Shortcomings There are many IT solutions dedicated to information integration and system interoperability (refer to Chapter 2). From among these, this thesis proposes a set of specific technologies as appropriate candidates for supporting integration at the three architectural layers of an information aggregator. At the data layer, this thesis adopts and evaluates model-based data standards; at the application logic layer, the research employs some Online Analytical Processing (OLAP) techniques; and at the presentation layer, a coordinated set of information visualization techniques are used. The following section introduces these technologies and describes the research challenges to be addressed in applying the technologies to the information aggregator problem. Standard data exchange languages are able to provide effective solutions for information integration and system interoperability within the AEC (Architecture, Engineering and Construction) industry (Russell & Froese, 1997) (Eastman, 1999) (Froese, 2003a). A great deal of work has been done, resulting in BIM technology in general, and the IFC data standard in particular. The IFCs have been widely used to exchange building product information between different design systems within the AEC industry, for example, from one CAD system to another, or from the CAD design system into an energy analysis, or quantity takeoff system. However, the scope of the IFCs includes not only building product information, but also a wide range of project management data, such as actors, processes, schedules, cost estimates, reference documents, etc. Furthermore, although the purpose of the IFC schema is to support data exchange between systems (interoperability), the model is also suitable to be used as the schema for an integrated database system capable of housing complete project data models. Introduction 15 A technical solution for the data layer of a project management information aggregation environment as envisioned, then, is largely pre-existing in the current IFC model. However, little research and development attention have been given to the project management portions of the IFC model and their suitability for supporting project management integration is largely untested (Section 2.3.2.2 and 2.3.3). The data layer requires combining all of project data in an integrated dataset. However, no single application or task can work with the entire data set as a whole, each must extract a subset or data view from the overall dataset to meet the data needs of the individual application. For this practice, the technology used at the application logic layer should support end user configuration of data views, but should take advantage of as much pre- defined knowledge of project management information as possible in order to simplify and structure the users\u00E2\u0080\u0099 data view configuration task. Online Analytical Processing (OLAP) technology was found to provide a suitable solution to these requirements. OLAP is a category of data mining tools enabling users to gain insight into different dimensions of multidimensional data through fast, consistent, interactive access to databases. OLAP technology is built upon a foundation of relational databases\u00E2\u0080\u0094they are not directly applicable to complex object-oriented data sets such as IFC models and they have seen very few previous applications reported in the AEC literature; yet, they do provide an effective technology for deriving multi-dimensional, interconnected data views from large complex datasets which provide elements of a technical solution for integration of AEC information at the application logic layer. Raw data in data views is of little use; it must be made available to the user through appropriate presentation and visualization interfaces. Visualization is the process of forming a mental image by encoding data with images in an appropriate manner. Many of the traditional areas of AEC computer applications have well-developed visualization capabilities (e.g., CAD systems, network scheduling systems). However, these are generally unique to their particular data views and they offer little or no provision for visualization of integrated multi-dimensional views of project management data (which, to date, have only Introduction 16 existed in rare, highly specialized situations). Thus, the ability to integrated project management data at the presentation layer has received limited attention to date. Furthermore, the technical solution for integration at the data layer, application logic layer, and presentation layer must work in concert with each other to deliver a functional holistic approach to integrated AEC information systems. Various elements of the above technologies have been previously developed in research and commercial efforts, such as Autodesk Revit and BIM (Building Information Model) (Autodesk, 2004), the Primavera E/C solution, the Web-based OLAP-integrated system (Nie et al., 2007). The research refers to these efforts; as yet, however, there remain no well- established technical solutions for integration at all three of the information layers based on open standards. Chapter 2 explains in greater detail why these technologies have been selected and the technical challenges to be addressed. 1.2.3 Formulated Problems and Motivation of Research for Information Aggregator From Section 1.2.1 and 1.2.2, we can see that in the industry, there are significant issues impacting the effectiveness of IT application in construction management, and that the current state-of-the-art technical solutions have shortcomings in solving these issues. The overall problem addressed in this thesis is as follows: \u00E2\u0080\u00A2 While the emerging ability to produce comprehensive integrated project models is leading to improved functionality in computer applications and improved data interoperability between them, the technology does not reach its full potential for supporting ongoing management activities since it does not allow users to work with any definable data view of the full range of integrated data presented through appropriate visualization interfaces in a flexible user-configurable manner. Underlying this general problem, the industrial issues and technical shortcomings can be formulated into three categories of problems: \u00E2\u0080\u00A2 Data integration. The current situation involves \u00E2\u0080\u009CInformation Islands of Automation\u00E2\u0080\u009D and various IT applications have minimal interoperability. Presumed state-of-the-art Introduction 17 solutions, such as IFC, BIM, etc., include some construction project management data but lack implementation and testing. In addition, in IFC models or BIM, it is not clear enough what data are needed for construction project management. \u00E2\u0080\u00A2 Data view configuration. Individual users, software applications, and work processes don\u00E2\u0080\u0099t work with a central data model as a whole\u00E2\u0080\u0094they work with partial subsets of the total combined data. These partial subsets are called data views, or partial data models derived to support specific application logic from the overall underlying data model. Some existing software can present users with partial data views, but they are not derived from or integrated with an overall integrated data model. Existing IFC or BIM technology has done very little to date related to defining and working with views. OLAP database technology is a typical approach for this issue, however, there has been very little work to date in exploring the use of OLAP for construction management, and there are several substantial technical challenges (Nie et al., 2007). \u00E2\u0080\u00A2 Information presentation. Existing software interfaces reflect individual perspectives that participants work on but lack coordination of multidimensional views. Meanwhile, these software interfaces are usually defined ad hoc by developers. They are weak in user-configurability. In addition, no solution that meets these requirements is tailored to OLAP and construction project management. These three categories of problems exist at different levels of information abstraction, as shown in Figure 1.7. The first problem category involves the aggregation of all data sources into a single conceptual (if not physical) data source. Again, this is the form of AEC integration that has received the most attention to date and many (but by no means all) of the technical issues have been solved. With current integration technology, traditional applications map their data to and from this common data source (as shown on the right side of the figure), such that information still reaches the users in \u00E2\u0080\u009Csilos\u00E2\u0080\u009D representing a single view or perspective. In contrast to this approach, the second problem category addresses the configuration of multi-dimensional views of data derived from the common data source. The third problem category then addresses presentation technologies for interfacing between the multi-dimensional views and users. Introduction 18 Figure 1.7: Integration of information systems at different levels. Even with integration at the data layer, current approaches still extract \u00E2\u0080\u009Csilos of information\u00E2\u0080\u009D as shown on the right, whereas a more fully integrated approach would allow integration at the view configuration and information presentation layers, as shown on the left. Current IT-supported project management over-emphasizes decomposition of a project into independent tasks. Traditional IT tools perform well in supporting such traditional, stand- alone perspectives, but do not do a good job of information integration between these levels of underlying project data, computer tools, individual tool views and documents, and people\u00E2\u0080\u0099s mental images. Essentially, they don\u00E2\u0080\u0099t offer the potential to improve construction fragmentation and reduce work coordination overburdens. Therefore, although each participant has some sense that his/her work follows certain work, must precede other work Real-world Project People\u00E2\u0080\u0099s Mental Model Information Systems DS DS DS DS DS DS Original Data Sources Data Integration Information Presentation Integration View Configuration Traditional Application Introduction 19 or may influence other participants, and a few individuals exert their efforts at overall coordination, on the whole, participants adopt separate views focused on their individual work and do not pay much attention to integration of the entire project. My interest in improving construction fragmentation and pursuing fully information integration in the industry motivated me to do this research, an effort to explore a solution, through integrating current state-of-the-art IT technologies in data standards, data analysis and information visualization to problems formulated above. The solution should meet the requirements of information aggregation, as envisioned in Section 1.1.4. We call this type of system an Information Aggregator (or Information Integrator), and we call the specific information aggregator application developed in this thesis Unified Construction Project Management Arena (UCPMA). 1.3 Research Goal and Objectives This research applies appropriate information technologies to the design of an Information Aggregator. Given the research goal described above, objectives supporting the goal include the following: \u00E2\u0080\u00A2 To develop a Unified Construction Project Management Arena (UCPMA) as a technical framework for an Information Aggregator. Within this overall framework, the following primary components are included: o Develop the requirements for an integrated PM data model, assess the IFCs for meeting these requirements, and extend as necessary. o Design an OLAP-based technical solution for view configuration and suggest a set of common PM views o Propose and develop a visualization technology tailored to integrated PM data presentation. \u00E2\u0080\u00A2 To develop a prototype of UCPMA to illustrate the proposed framework, validate the UCPMA architecture, test its capabilities of solving problems formulated in Section Introduction 20 1.2.3, and demonstrate its potentials in improving the current construction project management practice. The prototype also serves as a platform for future multidimensional PM data analysis and visualization research. 1.4 The Proposed Solution -- UCPMA The UCPMA framework, a major deliverable of this research, is expected to be capable of achieving the requirements defined in Section 1.1.4 and solving the three categories of integration problems identified in Section 1.2.3. It requires data sharing for information integration, view configuring for flexible data analysis and information visualization with user-configurability; specifically, it should be able to: (1) bring PM data from project data models to bear on PM tasks, and operate on data that is modeled based on IFC standards, (2) flexibly configure data views for user-specific tasks, (3) visualize PM data appropriately and support view coordination between multiple views in an integrated visualization interface. Corresponding to those problems, it is envisioned to have three components functioning in three different layers respectively (shown in Figure 1.8): \u00E2\u0080\u00A2 Central Data Model: a domain data model in the data layer that captures and represents fundamental information for primary construction management functions, leveraging technologies of data standards. The central PM data model levering the IFC technology is intended to solve the Data Integration problem. \u00E2\u0080\u00A2 Data Winnow: a tool for analyzing large sets of construction data stored in a Central Data Model. It is built upon data warehousing and OLAP technologies and tailored to flexibly manipulate data view configuration for various analysis purposes. \u00E2\u0080\u00A2 Visualization Configuration Model (VCM): a model or approach for visually presenting processed multidimensional data to end users. The model incorporates information visualization theories and serves as a tool against the Information Presentation Integration problem. Introduction 21 These components function at different layers, adapt existing technologies in data modeling, analysis and visualization to the UCPMA framework. Between layers, mappings from a Central Data Model to a Data Winnow and from the Data Winnow to a VCM integrate the three components into a whole system, in which the Central Data Model provides underlying support enabling information integration and system interoperability, the Data Winnow facilitates manipulation of PM datasets in a structure for efficient view configuration, and the VCM formalizes visualization in a structured way corresponding to services of the Data Winnow. While each of these components offers their own contributions, none is considered to be a major innovation in itself. The primary contribution comes from the combination of these components to achieve the overall goal of the UCPMA. A detailed description of UCPMA and its functional components is contained in Chapter 3. A central feature of the information aggregator approach is that the project data is extensively inter-linked within the central data model. While all of the target project management data currently exists within traditional software applications, these inter- connections generally do not, and they constitute the one type of \u00E2\u0080\u009Cnew\u00E2\u0080\u009D information required. However, there are various ways that this linking data might be obtained. If a project follows advanced BIM techniques throughout, then much of the project information will be inter-linked at its time of creation, and the BIM project models will be able to carry these connections throughout the project data lifecycle. There are opportunities for semi- or fully automating the process of linking of related project data. Finally, applications can be developed to allow users to manually define the interconnections between different data sets (using breakdown structure inheritance to reduce the total number of linkages required). The task of creating these interconnections is not addressed in this thesis, where it is taken as an assumption that a fully-interconnected project data model is available. The UCPMA does address the challenge of representing and working with these interconnections. In the following, Section 1.5 addresses research premises, scope and contributing work against research challenges in developing the UCPMA framework. Section 1.6 outlines the methodology carried out to fulfill the research objectives. 22 Figure 1.8: UCPMA Components and Contributing Research Work Introduction 23 1.5 Research Premises, Scope and Limitations 1.5.1 Previous Research As described in Section 1.1, the research was based on the major premise that IT can enable great improvement of the fragmented construction industry, especially through information integration and software system interoperability. The research assumes that the widespread data integration capabilities offered by technologies such as the IFCs will come to full fruition. In addition, the proposed UCPMA framework in this dissertation evolved from two conceptual approaches \u00E2\u0080\u0093 the \u00E2\u0080\u009CUnified Approach to Project Management\u00E2\u0080\u009D (Froese & Staub- French, 2003) and the configurable environments approach (O'Brien et al., 2003). Section 3.1 addresses details about their work. 1.5.2 Research Scope and Limitations First, this dissertation does not include a detailed study of data exchange, on the assumption that construction data can be obtained from various sources without technical difficulty. Instead, this dissertation focuses on improvement of data interdependency between system layers. Second, the framework is suitable for common PM tasks. It does not focus on bringing highly detailed task information to the fore, but rather on outlining fundamental information which is typical of communication among users; the developed common views are currently limited to the presentation of generic information of those common tasks for the purpose of illustrating the proposed framework. Third, the UCPMA addresses visualizing multidimensional PM data in different views. VCM features a layered structure. Between layers, elements cooperate through visualization strategies and view coordination. A combined taxonomy considering data type, functional requirements, visual techniques and domain application is described, extending other research results; but since this is a potentially vast area of technology and research in itself, the depth and validation provided here is limited to the application of the techniques to the needs of the UCPMA system only. Fourth, the UCPMA currently deals with single construction projects only (not the combined information from multiple projects). Fifth, the development of the UCPMA system is not Introduction 24 intended to replace commercial IT solutions; rather, the system is envisioned as a critical supplement solution aggregating emerging individual IT solutions and tying together available views used by participants. 1.5.3 Contributing Work To fulfill the development of the UCPMA framework, work is done mainly in three areas corresponding to its three functional components (see the column of \u00E2\u0080\u009CWork in this Ph.D. Research\u00E2\u0080\u009D in Figure 1.8): \u00E2\u0080\u00A2 Develop a Central Data Model suitable for integrated construction project management. Some project management data are included in IFCs, BIM, etc. Yet we must investigate what requirements and data are central, what can be adopted from presumed solutions, and what extensions might be required for existing models. \u00E2\u0080\u00A2 Design a Data Winnow, a domain-oriented technical solution for data exploration and analysis. Drawn from OLAP technology where applicable, the solution is designed for defining and working with data views from the underlying integrated construction project management data model. In the design, we have to identify primary dimensions involved in project management, specify dimension levels supporting flexibly interactive information visualization and identify a set of views common to a project management team. \u00E2\u0080\u00A2 Propose and develop a tool for integrating multidimensional data visualization. The solution requires being flexible in view configuration, integrated with OLAP and a central PM data model and effective in view coordination for presenting multidimensional data. We must identify visualization model elements, design a model schema and view coordination approach tailored to multidimensional PM data presentation and set up mapping of entities between a Data Winnow and VCM. These research efforts are addressed in detail in Chapter 4, 5 and 6 respectively. They separately made contributions to the improvement of IT application in construction project management, while their integration contributed to a unified approach, the focus of this research. Among them, the development of VCM was given more attention than the others since there is no visualization technology closely meeting the requirements mentioned above. Introduction 25 1.6 Research Methodology This research takes the following steps and methods in order to fulfill the outlined research goal and objectives. Identify Research Problems The research takes a change order process as an analytical example. First, several issues in the current construction project management practice are found through case analysis and literature review, and based on the author\u00E2\u0080\u0099s work experience as well as IT knowledge. Those issues are then formulated into three main research problems combined with industrial requirements and current IT technical shortcomings, which include data integration, data view configuration integration and information presentation integration problems. Against these problems, the research goal and objectives are identified. Literature Review to Establish Research Background A literature review is conducted in four main areas: project modeling, multi-view representation, data warehousing and OLAP, as well as information visualization. The review introduces available information technologies and relevant research and development, addresses their capabilities / benefits to this research, and outlines their shortcomings in effectively solving the problems mentioned above. Propose the Conceptual UCPMA Framework The conceptual framework is proposed in order to solve the problems stated in Section 1.2.3. The framework schema is designed have three fundamental components leveraging different IT solutions. These components will be developed to utilize different IT solutions against the research problems and function in two interdependent \u00E2\u0080\u009Cstages\u00E2\u0080\u009D (refer to Figure3.3). In comparison, the framework\u00E2\u0080\u0099s value and features are clarified. Introduction 26 Technical Development Technical development is based on the logic implied in the UCPMA schema. First, a central PM data model is designed. In the research, eight primary functions and their fundamental information (used for developing the Data Winnow) in construction project management are identified through research and development investigation. Models for the eight primary functions are then developed using the IFC modeling approach and represented in UML notations. Among these functional models, some classes are directly quoted from the IFC models, while others are added for its supplements. Finally, a central data model is generated, combining all eight functional models (as sub-models of a Central Data Model). In addition, issues of data exchange between models are discussed for extending this research in the future. A Data Winnow solution is designed to have two models: Generic Analytic Model which utilizes the Microsoft OLAP technology and Domain Analytic Model which is developed by populating the generic analytic model with identified fundamental PM information. In a Domain Analytic Model, seven information dimensions and five primary views are identified as common for PM through analysis of the fundamental information and literature review. Also, for each dimension, a dimension schema and dimension levels are designed. In addition, a mixed view composition approach is proposed to manipulate quantitative and qualitative PM data. A VCM is inspired by natural flower patterns. First, the VCM is envisioned to be composed of four categories of components: Graphic Element, Graph, View and Scene. These components are placed in four coaxial layers. Second, the VCM establishes correspondence to the generic analytical model of the Data Winnow. Third, discussion is given to how and what visualization principles and strategies are fitful in development of the VCM. Last, view coordination approaches are investigated and a derived coordination approach is proposed to combine merits of previous research approaches. The derived approach will be implemented in a simplified Model-View-Controller (MVC) design pattern in a prototype system. Introduction 27 Prototype Design for Theory Illustration, Testing and Validation The development of the software prototype, a UCPMA System, utilizes Microsoft Visual Basic .Net and Microsoft SQL Development Server and Analysis Services. The system is designed to have components of a database, data analysis services, a view engine, and visualization configuration modules, which are deployed in architecture with three logic layers. These components implement most functions of the Central Data Model, Data Winnow and VCM (refer to Section 7.2.1 for what has been not implemented). With several PM scenarios, the prototype validated the possibility of the proposed framework and tested its abilities of improving integration against the three problems. It also demonstrated great potential in improving the current construction project management practice. The research methodology is one of formulating a proposed solution for a defined problem, and then implementing the proposed solution to generate data relating to the solution\u00E2\u0080\u0099s capabilities. This methodology has been common in construction IT and computer science. For example, Johnson (2009) describes the methodology as follows (he further discusses disadvantages of the approach): \u00E2\u0080\u009CPerhaps the most intuitively persuasive model for research is to build something and then let that artefact stand as an example for a more general class of solutions. There are numerous examples of this approach being taken within the field of computer science\u00E2\u0080\u00A6The proof by demonstration approach has much in common with current engineering practice. Iterative refinement can be used to move an implementation gradually towards some desired solution. The evidence elicited during previous failed attempts can be used to better define the goal of the research as the work progresses.\u00E2\u0080\u009D 1.7 Reader\u00E2\u0080\u0099s Guide The dissertation is organized as follows: Introduction 28 Chapter 2: Points of Departure. The chapter establishes a research background by reviewing research and development in areas of project modeling, multi-view representation, data warehousing and OLAP, as well as information visualization. Chapter 3: UCPMA Overview. This chapter presents the Unified Construction Project Management Arena framework (UCPMA) which consists of integrated components: a Central Data Model, a Data Winnow and a Visualization Configuration Model, which are described in detail in Chapters 4, 5 and 6. The chapter then addresses the UCPMA\u00E2\u0080\u0099s fundamental mechanisms. Last, it further addresses UCPMA\u00E2\u0080\u0099s value by comparing it with other research and development. Chapter 4: Central Data Model. This chapter investigates project management functions, and presents models that capture fundamental information involved in each function. Then it presents a central data model built upon IFC technology and examines IFC extensions in terms of illustrated functional data models. It also discusses some data exchange issues. Chapter 5: Data Winnow. This chapter presents the Data Winnow, consisting of a generic data analytic model and domain data analytic model. The dissertation focuses on the development of the domain analytic data model with a set of fundamental dimensions and common views. Chapter 6: Visualization Configuration Model. This chapter proposes the Visualization Configuration Model (VCM). The dissertation first reviews the information visualization process, and then presents the coaxial layered VCM, as well as its configurable components. The chapter discusses visualization strategies fitting the model, illustrates the view coordination mechanism, and proposes a combined visual coordination approach adopted in the VCM for integrating information presentation. Chapter 7: System Implementation and Evaluation. This chapter describes the development of a prototype system, including its components and layered architecture. The prototype Introduction 29 tests the capabilities of the proposed framework and demonstrates the potential that UCPMA can offer to integrate data modeling, analytical exploration and visualization. Chapter 8: Conclusions. This chapter completes the dissertation by describing research deliverables, summarizing research contributions and suggesting future work. Appendix A: A Change Order Process Case. This appendix addresses and models the change order process case for illustrating the UCPMA framework described throughout the dissertation. Appendix B: UCPMA Data Model Aspects. This appendix displays eight data model aspects of the Central Data Model, which are implemented with Microsoft SQL 2000 Server application. Appendix C: Schema of Common Dimensions. This appendix presents identified common dimensions of the Data Winnow in the Microsoft Analysis Services environment. Appendix D: View Engine Functions and Information Flow Sequence Diagram. This appendix describes primary view engine functions and presents a sequence diagram of information flow among components. The view engine is a core module fulfilling creation and coordination of views in visualization. Appendix E: Risk Management and Quality Control Cases. This appendix introduces a risk management case and a quality control case of an oil sands infrastructure project in Canada. The risk case addresses risk management event of drilling through frozen slough to take depth measurements; and the quality control case addresses inspection and testing of base areas for underground manholes, catch bases, and oily water pipes. Points of Departure 30 CHAPTER 2: POINTS OF DEPARTURE This research is built upon previous research and development in the following main areas: 1) multi-view representation for project management, 2) project modeling (product modeling and process modeling), 3) data warehousing and OLAP, and 4) information visualization. This chapter provides a review and analysis of the state-of-the-art research and development efforts in these areas. 2.1 Background As described in Chapter 1, there are three categories of problems in current IT-supported construction project management practice: data integration, data view configuration integration and information presentation integration. Corresponding to these problems, UCPMA, conceptually evolving from research efforts (Froese & Staub-French, 2003) and (O'Brien et al., 2003) which will be addressed in Section 3.1, is envisioned to offer three integrated functional components: a Central Data Model, a Data Winnow and a Visualization Configuration Model. These functional components involve knowledge and techniques including data modeling, data standards and information exchange, project management functions, data warehousing, information visualization theory, view coordination and presentation, etc. The development of UCPMA requires, first, a review of research and development relevant to these knowledge and techniques to identify the departure points. This chapter presents an overview of a set of selected commercial and academic research references in three areas corresponding to UCPMA components. Section 2.2 investigates research and development regarding multi-view presentations of project management functions. Section 2.3 reviews project modeling technologies. Both sections relate to the Points of Departure 31 development of the Central Data Model. Section 2.4 introduces data warehousing and OLAP technologies leveraged in the Data Winnow. Section 2.5 examines information visualization theories for the Visualization Configuration Model development. 2.2 Multi-View Representation for Project Management 2.2.1 Project Management Functions and Relationships What is project management? What functional elements should project management include? How are information items and their relationships described so that project participants are able to understand the project and carry out work cooperatively? To address these questions, many competing perspectives are presented in project management models. The Project Management Institute\u00E2\u0080\u0099s Project Management Body of Knowledge (PMBOK) describes a sum of knowledge related to project management. In it, project management is defined as \u00E2\u0080\u009Cthe application of knowledge, skills, tools, and techniques to project activities in order to meet or exceed stakeholder needs and expectations from a project\u00E2\u0080\u009D (PMI, 2008). The PMBOK provides a conceptual project management framework consisting of: \u00E2\u0080\u00A2 Integration management, including integrated plan development, plan execution and overall change control. \u00E2\u0080\u00A2 Scope management, including initiation, scope planning, scope definition, scope verification and scope change control. \u00E2\u0080\u00A2 Quality management, including quality planning, quality assurance and quality control. \u00E2\u0080\u00A2 Time management, including activity definition, activity sequencing, activity duration estimating, schedule development and control. \u00E2\u0080\u00A2 Cost management, including resource planning, cost estimating, cost budgeting and cost control. \u00E2\u0080\u00A2 Risk management, including risk management planning, risk identification, qualitative risk analysis, quantitative risk analysis, risk response planning, and risk monitoring and control. Points of Departure 32 \u00E2\u0080\u00A2 Human resource management, including organizational planning, staff acquisition, and team development. \u00E2\u0080\u00A2 Procurement management, including procurement planning, solicitation planning, solicitation, source selection, contract administration, and contract closeout. \u00E2\u0080\u00A2 Communications management, including communications planning, information distribution, performance reporting and administration closure. Wideman (2003a) suggested a project management model as shown in Figure 2.1. It represents project management elements and their relationships in a 3D view with project management function on one axis, project life span phases on another axis, and project management integration on the third axis. These project management elements are the same functions defined in the PMBOK framework. The model indicates that project management efforts are distributed throughout the whole project lifecycle, yet most of the efforts are concentrated in the project execution phase. The model also illustrates that project management elements need to be integrated at all phases in a spiral progress. Figure 2.2 shows the relationships of project commitment (in scope, quality, time and cost) with client environment, management processes, real time and integration (e.g. objectives, teamwork, skills, etc.). The purpose of the figure illustrates that it is important to understand relationships among project elements and further, it is vital for the project management team to keep its delivery commitment to the project sponsor, owner or clients. Points of Departure 33 Figure 2.1: Wideman\u00E2\u0080\u0099s Function-Process-Time Relationships in Project Management Figure 2.2: Wideman\u00E2\u0080\u0099s Concept Map of Project Management Points of Departure 34 2.2.2 Multi-View Representation of Project Information A view is essentially a representation of a project dataset, reflecting users\u00E2\u0080\u0099 perception, expectation, judgment or interpretation. A project and its functions can be represented in a set of views, which help project participants discuss issues, communicate, and coordinate work with each other. Hence, much effort has been spent trying to design a set of such views and integrate them in a consistent and complete project model. In general, these efforts can be grouped into three categories: interface, information model, and system architecture, between which there may be some overlap. Russell & Froese proposed a framework for thinking about Computer-Integrated Management Systems in the form of major project views (Russell & Froese, 1997). These views are essential to the management personnel in performing their various functions, and partially supported by current commercial software. The authors enumerated several primary construction management functions: scheduling, productivity analysis, progress measurement and billings, change order management, contract negotiation, and human resource management. These functions are organized into four main views: Physical and Environmental View, Process View, Cost Views, and As-built View. The Physical and Environmental View describes what is to be built. The Process View describes how the project will be constructed. The cost view deals with the cost structure of individual parts as well as the overall project from various perspectives. The As-built View describes what happened during the journey, why and what actions were taken. Each of the four views may be broken down into a number of sub-views, and high-level views can also be defined based on sub-views. A high-level view may reflect an overall corporate view. Russell (2004) further expanded the conceptual framework with nine views for project management: Physical, Process, Cost, As-built, Quality, Change, Organizational/contractual, Environmental and Risk (see Figure 2.3). The framework was demonstrated with the REPresenting CONstruction system (REPCON). Initiated in 1985, REPCON was intended to create an integrated and intelligent computer-based environment for designing and controlling the construction process (Russell, 2004). These nine views were implemented in Points of Departure 35 different modules, in which hierarchical structures are used to display sets of related components. These components in a view, for example in the Physical view, can be assigned values, and associated with components in the same view, and with activities, methods, resources, pay items, change orders, and/or project records in other views (Russell, 1997). The linking of these components is generally performed manually or is captured in libraries of planning standards (these linkages can frequently be done at higher levels in the view hierarchies and inherited down to the lower levels); views are associated with each other by assigning components to other views. Figure 2.3: Samples of REPCON\u00E2\u0080\u0099s Physical View, Process View and As-Built View Lilies and Presley (1996) proposed a conceptual approach to modeling enterprise processes. The approach consists of five views: business rule/information view, activity view, business process view, resource view and an organization view. The functions of these five views are: \u00E2\u0080\u00A2 The Business Rule (or Information) View defines the entities managed by the enterprise and the rules governing their relationships and interactions. Points of Departure 36 \u00E2\u0080\u00A2 The Activity View defines the functions performed by the enterprise (what is done) while the Business Process View defines a time sequenced set of processes (how it is done). \u00E2\u0080\u00A2 The resources and capabilities managed by the enterprise are defined in the Resource View. \u00E2\u0080\u00A2 The Organization View is used to define how the enterprise organizes itself and the set of constraints and rules governing how it manages itself and its processes. Similar to the REPCON framework (Russell, 2004), the Lilies and Presley approach suggests a perspective on enterprise processes using views capturing inherent process attributive information of requirements, resources, schedule and organization. In software design, Curtis (1992) affirmed that information in many forms needs to be integrated in order to adequately describe a process. Questions related to information that process modeling is intended to capture were considered to include: what is going to be done, who is going to do it, when and where will it be done, how and why will it be done, and who is dependent on its being done. To represent perspectives related to these questions, the author identified four views as common to each process (see Figure 2.4): \u00E2\u0080\u00A2 The Functional view represents what process elements are being performed, and what flows of informational entities (e.g., data, artifacts, products), are relevant to these process elements. \u00E2\u0080\u00A2 The Behavioral view represents when process elements are performed (e.g., sequencing), as well as aspects of how they are performed through feedback loops, iteration, complex decision-making conditions, entry and exit criteria, and so forth. \u00E2\u0080\u00A2 The Organizational view represents where and by whom (which agents) process elements are performed, the physical communication mechanisms used for transfer of entities, and the physical media and locations used for storing entities. \u00E2\u0080\u00A2 The Informational view represents the informational entities produced or manipulated by a process. These entities include data, artifacts, products (intermediate and end), and objects. This perspective includes both the structure of informational entities and the relationships among them. Points of Departure 37 Figure 2.4: Concept of Process Perspectives (Curtis et al., 1992) Other researches were also engaged in organizing views and rendering of visualizations to a screen. Nagappan (2001) proposed a compositional model for constructing complex visualization instances by describing them as a set of smaller interconnected modules. Each module represents some model aspects or a view of data. Combining sets of small views presents a broader view of the larger module. Baldonado (2000) investigated the usage of multiple view systems to support a single concept entity and presented eight guidelines for information visualization. Songer (2004) discussed a framework for visual representation of construction control data, proposed a taxonomy of current graphic representations of typical construction project control processes, and explored the potential of using different information visual presentations to get insights from data. 2.2.3 State-of-the-Art Tools Supporting Multi-View Representation This section reviews state-of-the-art tools in the AEC/FM field and discusses their functional characteristics and integration issues in representing construction project Points of Departure 38 management functions. These tools demonstrate good interfaces in presenting project management information to end users. Section 2.5.3 addresses their visualization features. 2.2.3.1 Timberline\u00E2\u0080\u0099s Office Built upon accounting and estimating software, Timberline Office is a collection of products that includes accounting, estimating, procurement, product management, project management, property management, report & other tools, and service management (Timberline, 2004). It is intended to become a cross-functional system incorporating all perspectives for streamlined, single-source control. Below, the Project Management software is taken as an example to show what functions it provides for construction project management. Timberline Project Management is targeted to simplify project management by providing access to real-time costs, contracts and document information. Currently its functions include the abilities to (see Figure 2.5): \u00E2\u0080\u00A2 Create, track and distribute documents, such as RFIs, submittals and transmittals using automated delivery methods; e-mail and fax documents directly from an entry screen. \u00E2\u0080\u00A2 Issue prime contracts, subcontracts, purchase orders and (potentially) change orders, then release these items to accounting for review, approval, and use. \u00E2\u0080\u00A2 Access subcontract and project overall status, initial and revised totals, pending and approved changes, and amounts invoiced, retained and paid. \u00E2\u0080\u00A2 Work with contracts, estimates, forecast change orders, and presents cost details. \u00E2\u0080\u00A2 Set up jobs and enter contact information in one centralized location. \u00E2\u0080\u00A2 Create a job directory with job-specific contact information and set up unlimited distribution lists. \u00E2\u0080\u00A2 Instantly log all project-related e-mail, Microsoft Word and Excel documentation as users work with a single click, or add summary detail for easy sorting if desired. \u00E2\u0080\u00A2 Document and coordinate the distribution of current drawings and sketches to all interested parties. Points of Departure 39 \u00E2\u0080\u00A2 Create meeting agendas and record meeting discussions, action items and persons responsible. Automatically roll forward outstanding items into the next meeting agenda. \u00E2\u0080\u00A2 Access pre-designed reports and inquiries or design according to user requirements. \u00E2\u0080\u00A2 Personalize style: secure access to information or the ability to perform tasks by individual or by job; customize most drop-down lists and add custom fields to fit a particular business. Information or reporting available in the tool include: job status overview combining accounting and project management details on one report; job cost by date range, monthly cost and cost type analysis, including un-posted costs; contract status showing accounts receivable invoices and payments; purchase orders and subcontracts showing accounts payable invoices and checks; RFI overdue and unanswered logs and summaries; submittal logs by company, status, and summary report; transmittal logs by date, company, and status; Insurance and lien documents. In short, the Project Management tool provides services in accounting, estimating, and document management, as well as other functionalities such as input, output, meeting tracking, multimedia communication, etc. This tool serves as a good reference for identification of primary project management functions and definition of detailed UCPMA common views\u00E2\u0080\u0099 functionalities. Points of Departure 40 Figure 2.5: RFI Creation and Related Accounting and Project Management via Timberline Solutions Among Timberline Office products, it is worth mentioning the Scheduling Integrator of the Timberline Estimating package. The Scheduling Integrator was specifically developed to connect commercial scheduling software, in particular for Primavera Project Planner (P3) and SureTrak Project Manager, and Microsoft Project. Although the connection occurs at a high level and is one-way (from the Estimating to other scheduling software), incorporation of these commercial tools with different perspectives shows promising potential for implementation of information interoperability and view coordination which UCPMA requires. 2.2.3.2 Autodesk Solutions Autodesk provides manufacturing solutions in support of creating, managing and sharing design data (Autodesk, 2004). Among these solutions, Autodesk Revit is a context-based parametric CAD tool suitable for AEC/FM (http://www.autodesk.com/revit). It consistently represents 2D (e.g. floor plan, roof plan, sections, etc.), 3D and schedule (specification) Points of Departure 41 views through a parametric building model (see Figure 2.6). Main features of the tool include: \u00E2\u0080\u00A2 Bidirectional associability. Using shared product information, changes in one view are automatically propagated to related views. \u00E2\u0080\u00A2 Integrated scheduling. A schedule refers to a collection of specifications of product components. It is displayed in a view of a building or its elements in tabular form with icons. Thanks to bidirectional associability, for example, deleting a window from a view placed on a sheet causes the window to be deleted from the schedule. \u00E2\u0080\u00A2 Visualization and presentation. Autodesk Revit provides a convenient capability for creating and modifying presentation materials directly in the model. In addition, users can export and import bitmap and other graphic file formats, activate walkthrough animation exportable to AVI files, create color-filled diagrams that show space utilization, material usage, or other categories of space. \u00E2\u0080\u00A2 Coordinating with consultants. The tool allows free import, export, and linking of users\u00E2\u0080\u0099 AutoCAD data, and also supports import, export, and linking to DXF\u00E2\u0084\u00A2 files and MicroStation DGN files. \u00E2\u0080\u00A2 Sharing data with other applications. Revit supports industry standards. For example, it provides the functionality of extracting quantities of products for cost estimating. \u00E2\u0080\u00A2 Integrated site modeling. \u0001 Points of Departure 42 Figure 2.6: Autodesk Revit\u00E2\u0080\u0099s Snapshot of Multiple Building/Product Views 2.2.3.3 Primavera Solutions Primavera was initially developed in 1983, and has become a widely known provider of web-based and Microsoft Windows-based comprehensive project management software. Among a set of solutions that Primavera offers for all business projects, the Primavera Engineering & Construction (E/C) solution, \u0002\u0001 collaborative\u0001 project management system designed particularly for construction professionals, is intended to improve productivity by providing flexible planning systems, cost management, workgroup collaboration and early warning indicators. Components and functionalities of the solution basically include (see Figure 2.7): \u00E2\u0080\u00A2 Planning and scheduling: provides Critical Path Method (CPM) and \u00E2\u0080\u009Cwhat-if\u00E2\u0080\u009D analysis, supports multiple baseline categorization and control, and presents information in Gantt charts, timescale logic diagrams and trace logic views. \u00E2\u0080\u00A2 Reporting and analysis: prepares dashboard highlighting cost, milestones, schedule metrics, and look-ahead reports. \u00E2\u0080\u00A2 Resource management: classifies technical disciplines, manages resource availability, determines billing rates, and forecasts direct and indirect labor requirements. Points of Departure 43 \u00E2\u0080\u00A2 Cost management: combines cost and schedule information, models both direct and indirect project costs, and creates an earned value management system in order to track budgeted and actual expenditures. \u00E2\u0080\u00A2 Accountability management: manages regular field updates, integrates contractor schedules and provides subscription based email alerts. \u00E2\u0080\u00A2 Contingency management: recognizes change issues or potential changes, and develops a sound mitigation plan responding to a risk. \u00E2\u0080\u00A2 Standards management: implements standards across teams, groups and organizations \u00E2\u0080\u00A2 Mobile management: captures real site activity information by using Microsoft Pocket PC and Palm OS handheld devices. Figure 2.7: Primavera\u00E2\u0080\u0099s Collaborative Project Management System These components present comprehensive project management functionalities and fundamental information in several views from different disciplinary perspectives. Among functionalities mentioned above, planning and scheduling, the core of the Primavera E/C solution, can help to plan, schedule and manage activities, establish the critical path for completing the project on time and on budget, and allow tracking of multiple baselines to manage the changes in the schedule and to use built-in functionalities to compare projects. Figure 2.8 shows an example snapshot of project scheduling. Different colors are adopted to Points of Departure 44 track active work, remaining work and critical remaining work. In a bar chart below the schedule Gantt chart, different colored columns stand for human resource usage along time, and a linear graph depicts accumulated human resource usages throughout the construction life. \u0001 Figure 2.8: Example of Planning and Scheduling of Primavera E/C Solution 2.2.3.4 Microsoft Project Microsoft Project is a component of the Microsoft Office package offering generic planning and scheduling for all kinds of projects. One of its features, which make it popular among various project management agents, is flexibility in representing project schedules and resource usage with multi-views such as Calendar, Gantt Chart, Network Diagram, Task Usage, etc.(see Figure 2.9). These views suit different users\u00E2\u0080\u0099 preferences in formulating problems and finding their solutions. Points of Departure 45 Figure 2.9: Example of Microsoft Project Gantt-Chart View 2.2.3.5 Common Point Project 4D Solution Project 4D, a product of Common Point Inc. in use since 1993, was developed to make users effective in communicating, planning, and analyzing project scope and schedule with 4D modeling technology (See Figure 2.10). Main features of this solution include (Common Point, 2005): \u00E2\u0080\u00A2 Convenience in importing 3D and schedule data from common industrial formats, as well as navigating a 3D model. \u00E2\u0080\u00A2 Visualization in sequencing construction. \u00E2\u0080\u00A2 Simulation of site planning in visualization to show site/work context and interactively view site issues to analyze what-if scenarios. \u00E2\u0080\u00A2 4D model representation from multiple perspectives for better communication. \u00E2\u0080\u00A2 Capability in reformulating user requirements to focus on the specific flow and sequence of work. \u00E2\u0080\u00A2 Capability in alternating and comparing different schedules. \u00E2\u0080\u00A2 Focus on system sequencing and work coordination. Points of Departure 46 Figure 2.10: Example of Common Point Project 4D Modeling 2.2.4 Summary of Multi-View Representation In summary, the research and development mentioned in section 2.2.2 focused on presenting project information in views, in which a great bulk of information is similarly organized and represented according to project or process elements\u00E2\u0080\u0099 inherent interdependency. These view- related efforts reflect project practice: a project is broken down into processes, and in turn, a process into tasks; participants perform tasks according to certain perspectives (views), and views call for integration. These efforts serve as a good foundation for developing UCPMA. The UCPMA framework identifies project management functions based on the PMBOK, Russell, and Wideman\u00E2\u0080\u0099s conceptual models. Similar to Curtis\u00E2\u0080\u0099s work, UCPMA organizes project management fundamental information into several views, from different process perspectives. It can be expanded by adding views to support management of the entire project system. Enlightened by Nagappan and Songer\u00E2\u0080\u0099s ideas, UCPMA offers an information presentation environment which is flexible in configuration and rich in visualization. Section 2.2.3 addressed the functional characteristics of several state-of-the-art tools that vendors are selling to the AEC industry. These functional characteristics establish Points of Departure 47 requirements that are generally common to construction project management and will serve as good references to the design of UCPMA\u00E2\u0080\u0099s views. These tools also represent the technological leading edge of construction management data visualization (this will be discussed later in this chapter). All of these systems provide some degree of integration of different project management views. Generally, however, they have added a limited treatment of different views to improve the functionality of their core view (e.g., adding cost data to the time view in a scheduling application so that cash flows can be displayed). Among these systems, Timberline Office is cost-centered, Revit is design-centered, Microsoft Project is process-oriented and Common Point 4D Solution focus on simulation of construction in sequence, relying heavily on schedule and time data. Primavera E/C Solutions covers relatively more project management information than the other tools, including cost, resource, schedule, actor, etc.; yet, construction project management involves more data views than Primavera Solutions provide. None of the tools here are built around a comprehensive project model that spans the majority of project management views (Chapter 4 will discuss the information views necessary for construction project management). Even more significantly, none of these systems provide the potential for interoperability throughout the industry through the use of data interoperability standards such as the IFCs. Finally, although the systems here provide some excellent interfaces for certain views, they do not provide the fully customizable views across all views envisioned for UCPMA. At all three of the system architecture layers, then, current project management applications do not meet the functional requirements for an information aggregator as described in section 1.1.4. 2.3 Project Modeling Technologies This section reviews research and development relevant to project modeling technologies, which support the development of the Central Data Model of the UCPMA framework. 2.3.1 Product and Process Modeling Here, product and process modeling (also termed project modeling) refer to a semantic description or representation of a product and its construction process. It usually consists of information models and relevant technologies, such as data standards, representing Points of Departure 48 structures, etc. The purpose of product and process modeling is to facilitate data sharing and exchange among different parties in the AEC/FM industry. Early product modeling was closely related to Computer-Aided Design (CAD) technologies. Eastman (1999) gave a detailed introduction to the evolution of CAD and other technologies involved in building, and pointed out that \u00E2\u0080\u009Ca new paradigm for building modeling is emerging, based on 3D and solid modeling, object-oriented languages and databases, effective graphical user interfaces and web-based communication.\u00E2\u0080\u009D Recently, product modeling has been extending its original scope from traditional 3D geometrical information to cover processes, documents, costs, etc. Moreover, it is widely agreed that product models must support coordination and exchange for all activities throughout the whole project lifecycle (Eastman, 1999) (Koivu, 2001). Extension of product models calls for process modeling. Hence, many projects have been carried out to model processes at different detail levels in order to pursue information interoperability and system integration. A typical project is ICON, which developed a \u00E2\u0080\u009Cstrategic level model\u00E2\u0080\u009D of the construction procurement process (Aouad et al., 1994).The model represents information formats and flow throughout the process, but it\u00E2\u0080\u0099s limited to three data sources used (an Architect, Quantity Surveyor and a Contractor) (Sheath et al., 1996). Later on, Froese (1995), Laitinen (1998), and Wix (2001) introduced several projects about AEC process modeling and system integration. Moreover, Froese (1997) proposed a conceptual systematic platform, Total Project Systems (TOPS), which had characteristics of comprehensiveness, integration and flexibility and was targeted to incorporate various researches into integrated, computer-based tools supporting construction management. Yu (2002) developed a framework for TOPS, which consisted of a broad range of comprehensive AEC/FM applications, system architecture, information models, information content and work practices. Wix and Liebich (2001) developed a detailed process-based information flow matrix, which identified the process breakdown within the whole project chain in building and construction, and related it to the parties involved within the building construction processes. Points of Departure 49 In general, these modeling efforts cover most of the required functions for construction management and demonstrate the potential of integration through shared data representations. 2.3.2 Data Standards Product and process modeling requires standard data models as a common language for communication among integrated systems in the AEC/FM industry. 2.3.2.1 Standard for the Exchange of Product Model Data One of the largest international efforts for product data standardization is STEP (Standard for the Exchange of Product Model Data) or the ISO standard 10303, developed by the ISO Technical Committee on Industrial Data and Processes (TC184), Subcommittee on Industrial Data (SC4). In SC4, there are many groups working on STEP, among which Working Group 3 (WG3) is responsible for the development of product models, and Team 12 in WG3 is responsible for the area of Architecture, Engineering and Construction (AEC). The main objective of STEP is to develop international standards for the representation and exchange of product data throughout their life cycle. These standards are independent of any particular system or software, and description of product data throughout the life cycle of a product. STEP consists of a collection of standards (individual parts), termed Application Protocols (APs), which are based on a common underlying methodology e.g. STEP physical file format, EXPRESS data definition language, etc. Among these parts, STEP Part 106 is a work item on the Building Construction Core Model (BCCM). BCCM is intended to serve as a unifying reference for building construction application protocols. It comprises four major types of project objects: BC_ProcessObject, BC_ResourcesObject, BC_ProductObject and BC_ControlObejct, above which BC_Object is an abstract, root object. The four project objects are also abstract objects inherited by sub-objects representing project information. This model can be exchanged using the STEP physical file format for simple file exchange or STEP Standard Data Access Interface (SDAI) for on line file exchange (Froese, 1996). Points of Departure 50 2.3.2.2 The International Alliance for Interoperability The International Alliance for Interoperability (IAI) is a global, industry-based consortium for the AEC/FM industry, starting from 1995. The IAI\u00E2\u0080\u0099s scope includes the entire lifecycle of a building project from strategic planning, design and engineering, and construction, to building operation. Its mission is to enable interoperability among industry processes across all different professional domains in AEC/FM projects by allowing the computer applications to share and exchange project information. The goal of IAI is to define Industry Foundation Classes (IFCs), building on the collective knowledge of the global construction and facilities management industries (IAI, 2002). At present, developing and extending IFCs, as well as testing application of the data standards are directed by buildingSMART, an international membership organization with representation in North America, Europe, Asia and Australasia. The IFC model architecture takes a layered modular structure. There are four layers within the architecture, and at each layer, a set of sub-models is defined (see Figure 2.11). The four layers are (IAI, 2007): \u00E2\u0080\u00A2 Resource Layer \u00E2\u0080\u0093 the lowest layer, describing distinct underlying concepts, e.g., geometry, property, actor, cost, constraint, quality and measures, etc. \u00E2\u0080\u00A2 Core Layer includes Kernel and several Core Extensions, e.g. Process Extension, Product Extension, Control Extensions etc. The Kernel defines all basic concepts for the IFC model and determines the model structure and decomposition. The Core Extensions provide extension or specialization of concepts/classes in the Kernel. \u00E2\u0080\u00A2 Interoperability Layer defines schema that model data common to different domain models. It facilitates interoperability between domain models. \u00E2\u0080\u00A2 Domain Layer, the highest layer, provides a number of modules tailored for specific AEC industry domain or application. For example, it supports Architecture domain, HVAC domain, Construction Management domain, Electrical domain, etc. Classes in these domains may use or reference any class defined in the Core or Resources Layer. The Domain Layer provides facilities for attaching information from external properties. Points of Departure 51 In the IFC model, information integration is achieved via interdependent references between modules or classes within each module. For example, The IfcProcess captures the concept of activities and handles work being carried out over a period of time. It is defined in the Kernel, inherited from IfcObject. IfcProduct defines any object related to a geometric or spatial context, including information of shape representation and a local placement within the project structure. IfcProcess can be associated with IfcProduct using IfcRelAssignsToProcess, which handles the assignment of an object that the process works on. Reference between classes follows the so called \u00E2\u0080\u009Cgravity principle\u00E2\u0080\u009D; namely, at any layer, a class may be related to another class at the same layer or lower layer but cannot be related to one at a higher layer. For example, resource classes may only be related to other resources since they are at the same and lowest layer; while classes at the most top layer, the domain layer, may reference any classes in any layer including itself. Points of Departure 52 Figure 2.11: IFC Model Architecture and Modules in Layers (IAI, 2007) 2.3.3 Multidimensional Modeling Initiatives In recent years, a major trend of research and development for information integration and application interoperability in the AEC/FM industry has been to incorporate multiple disciplines\u00E2\u0080\u0099 information with 3D product modeling in order to satisfy most participants\u00E2\u0080\u0099 demands, such as product maintainability, accessibility, sustainability, energy performance, as well as cost, time, etc. This trend becomes explicit in two aspects: Points of Departure 53 \u00E2\u0080\u00A2 The data standards, IFCs, are increasingly extended from product information to project management processes involving various functions, such as project management of scope, resources, risk, cost, time, communication, and procurement. \u00E2\u0080\u00A2 Data exchange and presentation technologies have been extending from structured approaches to hybrid approaches, from file-based exchange to distributed, transaction-based exchange, from standalone objects to intelligent objects, and from 3D \u00E2\u0080\u009Cstatic\u00E2\u0080\u009D simulation to \u00E2\u0080\u009Cdynamic\u00E2\u0080\u009D 4D (3D +Time) visualization. In the IFCs aspect, buildingSMART presented the most recent version of IFCs with limited classes for PM. Those classes (under Kernel, Process Extension, Shared Management Elements, and Construction Management Domain in Figure 2.11) center on cost, schedule, organization, and information management. No record indicates that application for extending IFCs in Risk and Quality Management is ongoing. In previous research and development, little effort has been given to IFC for PM. Froese and Gokce tried to test limited classes mostly for cost and schedule management (Froese & Yu, 1999) (Froese et al., 1999) (Gokce et al., 2007). In addition, Salford (2003) initiated the\u00E2\u0080\u009C3D to nD research project\u00E2\u0080\u009D (nD refers to 3D plus time, cost, etc.). The project aimed to develop a tool for incorporating various concerns (e.g. maintainability, accessibility, etc.) within a central building information model, from which information could be portrayed in different views; and identified some key research topics for nD-enabled construction, which include: 1) integrating nD into the design and construction processes, as well as related organizational processes; 2) developing nD tools built upon central data models; 3) ensuring significant nD training and education and developing a culture of value. Froese (2003b) introduced some issues and research at the University of British Columbia, related to the integration of nD modeling technologies including: 1) nD model versus document, 2) nD versus workflows, and 3) nD versus Unified Project Management. Dawood (2003a) developed a 4D visualization and simulation model called \u00E2\u0080\u009CProVis,\u00E2\u0080\u009D based on an integrated database using Uniclass, the unified classification system for the construction industry. The Uniclass approach was intended to provide a Points of Departure 54 medium for integrating Product Breakdown Structure and Work Breakdown Structure in order to facilitate process-product linking. In the data exchange and presentation field, BLIS is a project addressing application and implementation of IFC in the AEC/FM industry. BLIS utilizes a small set of end user \u00E2\u0080\u009Cuse cases\u00E2\u0080\u009D which are supported by industrial tools. Objects associated with these \u00E2\u0080\u009Cuse cases\u00E2\u0080\u009D are subsets of the IFC model. Semantic sharing of these subsets of the model is conceived to support application interoperability (BLIS, 2002). Dawood and Sriprasert (2003b) proposed a \u00E2\u0080\u009Cmulti-constraint planning\u00E2\u0080\u009D methodology supported by an integrated decision support system that incorporated web-based and mobile information management system, 4D- visualisation system, and evolutionary optimization system. In addition, research has also focused on exploring new technologies using 4D in the construction industry. For example, Kam and Fischer (2002) introduced the PM4D (Product Model and Fourth Dimension) approach used in the project of design and construction of the Helsinki University of Technology Auditorium Hall 600 (HUT-600) in Finland. It was applied for constructing and maintaining object-oriented product models with explicit knowledge of building components, spatial definitions, material composition, and other parametric properties, in order to leverage object intelligence from 3D models for data interoperability. Moreover, the approach was claimed to support visualization tools in reviewing spatial designs in virtual walk-through, comparing lighting schemes in photo-realistic renderings, and comprehending construction sequences in 4D animations. 2.3.4 Summary of Project Modeling Technologies Sections 2.3.1 and 2.3.3 briefly introduced product and process modeling approaches, data standards and the IFC technology. The development of IFC incorporated earlier product and process modeling efforts, extending information from a building product to building project processes. The IFC is widely considered as an effective technology enabling information integration system interoperability. UCPMA\u00E2\u0080\u0099s Central Data Model will be built upon the IFC model. However, there has been very little implementation of the project management portions of the IFCs, and much work remains in exploring, validating, and potentially extending the representation of this information. Points of Departure 55 Section 2.3.3 addressed recent research exploring opportunities or environments of information integration and system interoperability. Froese (1999) and Gokce (2007) mentioned their efforts to implement IFCs for PM. University of Salford (2003) presented several research initiatives of multidimensional modeling and applications, relying on a central information model. Froese (2003b) introduced some explorations extending product and process modeling to several specific multidimensional integration. These research efforts provide important foundations for the development of UCPMA, but they have focused on the central data model with limited classes for PM and on linking this with individual applications. They have not addressed the areas explored by UCPMA\u00E2\u0080\u0094general, configurable techniques at the data view and presentation layers. Dawood (2003b) combined a Uniclass approach with a model-based approach facilitating information linking and exploration. UCPMA will use a similar approach facilitating data analysis, but encompass more integrated solutions than those presented by Dawood. In addition, Dawood (2003a) (2003b) and Kam & Fischer (2002) all addressed 4D modeling and data exchange. These efforts focus on information presentation of 3D product dimensions plus a time dimension, as good examples in extending multidimensional modeling, information distribution and presentation. However, this research presents only limited presentation views (generally 3D geometry plus time), rather than generalized, configurable construction management information visualization, as envisioned by UCPMA; moreover, no one has addressed how to effectively explore multidimensional PM data in a configurable presentation environment. 2.4 Data Warehousing and OLAP A central data model usually contains voluminous data of construction management. Exploiting these data calls for advanced technologies. Data Warehousing and OLAP are typical technologies in this regard and will be utilized in the design of the Data Winnow, one of the UCPMA components. Points of Departure 56 2.4.1 Data Warehousing Voluminous construction data need advanced techniques to explore, extract and restructure the information for analysis by project participants. Since the early 1990s, data warehousing has been recognized as one such techniques effectively capable of the afore-mentioned functions. Data warehousing involves: 1) business planning for a particular purpose; 2) designing, implementing, or identifying data sources; 3) extracting required data from various data sources, transforming the extracted data in a form through cleansing, dimensionalizing, normalizing and calculating (summarizing, splitting, etc.) (SDG, 2005), and loading it into the data warehouse; 4) presenting data to users for access and manipulation. A data warehouse, usually built upon a large relational database, is a subject-oriented, integrated, nonvolatile, and time-variant collection of data in support of management\u00E2\u0080\u0099s decisions (Inmon, 2005). A data warehouse can be distributed over several computers physically located at different places. 2.4.2 OLAP Online Analytical Processing (OLAP), a software technique, is able to provide quick, consistent, and interactive access to a large volume of enterprise data using multidimensional views. OLAP functions encompass basic navigation and browsing (known as \"slice and dice\"), complex calculation and analysis, such as time series and complex modeling through hierarchies and/or across members (OLAP Council, 1997). OLAP enables users to manipulate data in multi-dimensions, and gives insights into data relationships and demands for decision-making. Compared to data warehousing, OLAP has abilities not only in answering \u00E2\u0080\u009Cwhat\u00E2\u0080\u009D and \u00E2\u0080\u009Cwho,\u00E2\u0080\u009D but also in supporting answers to \u00E2\u0080\u009Cwhat-if\u00E2\u0080\u009D and \u00E2\u0080\u009Cwhy\u00E2\u0080\u009D (OLAP Council, 1997). OLAP research has been underway since the mid 1990s. At present, there are several OLAP systems available in the market, e.g. Oracle OLAP, IBM OLAP, Microsoft OLAP, and so on. They all provide basic functions of business information data processing. In this research, Points of Departure 57 we selected Microsoft OLAP as a useful tool due to its ease of user-interaction and integration with other products such as SQL and the Microsoft .Net package. The formal release of Microsoft OLAP-related services, Microsoft SQL Server\u00E2\u0084\u00A2 Analysis Services (including OLAP and data mining capabilities) became available around 1997. The structure of the Microsoft OLAP multidimensional data model consists of the following components (MSDN, 2006): \u00E2\u0080\u00A2 A Cube is a set of data organized and summarized into a multidimensional structure defined by a set of dimensions and measures. Dimensions define the structure of the cube, while measures provide the numerical values of interest to the end user. The main functions of a cube include selection, roll-up, drill-down and slice, aggregation, and partition. \u00E2\u0080\u00A2 A Dimension is a structural attribute of a cube, which is an organized hierarchy of categories (levels) that describe data in the fact table. A dimension typically describes a collection of similar members for user analysis. \u00E2\u0080\u00A2 A Measure is a central value that is aggregated and analyzed, and is based on a column in the cube\u00E2\u0080\u0099s fact table. \u00E2\u0080\u00A2 A Level is the name of a set of members in a dimension hierarchy, such that all members of the set are at the same distance from the root of the hierarchy. It describes the hierarchy from the highest level to lowest level. \u00E2\u0080\u00A2 A Member is an item in a dimension representing one or more occurrences of data. \u00E2\u0080\u00A2 A Cell is the atomic element of a cube, or the unique logical intersection of one member from every dimension associated with the cube. Essentially, a cube is composed of cells organized by measures, levels, and dimensions. \u00E2\u0080\u00A2 A Fact Table is a central table in a data warehouse schema that contains numerical measures and keys relating facts to dimension tables. Figure 2.12 shows a Microsoft OLAP data structure sample, in which the shaded cell is the intersection of the following members and dimensions: the air member of the Route dimension, the Africa member of the Source dimension, the 4th quarter member of the Time dimension, and the Packages member of the Measures dimension (MSDN, 2006). Points of Departure 58 Figure 2.12: Example of Microsoft OLAP Data Structure 2.4.3 Data Warehousing and OLAP in Construction Data warehousing and OLAP have been under study and development for a quite a long time. However, there are few papers regarding its use in the construction industry. Among them, Dawood (2003b) introduced multi-constraint information query components in their decision support system. The components utilize the On-Line Analysis Processing (OLAP) service to create interactive browser-based queries and multi-dimensional and aggregated view of data for decision-makers. Figure 2.13 shows an example of an interactive browser- based query for drawing status. In this case, the OLAP with cube, dimension, etc. is logically constructed, and then connected to Microsoft PivotTable for data exploration. The result can be exported to Microsoft Excel, and further meaningful charts can be generated through Pivot Chart features. Points of Departure 59 Figure 2.13: Example of Interactive Browser-based Query for Drawing Status Chau (2002) proposed a decision support system for construction management (CMDSS). The system employs Microsoft OLAP services and data warehouse technology. The data warehouse stores preprocessed queries on data residing in a multiple, possibly heterogeneous, operational query base, while OLAP enables transformation of stored data into strategic information for decision-making. Points of Departure 60 Figure 2.14: Chau \u00E2\u0080\u0098s Material Inventory Star Schema Figure 2.14 displays an example of how a material inventory star schema is generated from a relational database. It includes a fact table with measures of material price, quantity and amount, and warehouse, time, storekeeper, material, and supplier dimension tables. The material cube and relevant dimensions can then be created with Microsoft Wizards based on this schema. Through OLAP services such as Microsoft Cube Browser and Excel, data can be explored and analyzed from different perspectives and levels through functions of aggregation, roll-up, drill-down, selection and slice. Nie (2006) proposed a Web-based, OLAP-Integrated prototype system for project cost control and manpower allocation analysis in the construction field. The system employs OLAP and data warehousing technologies like (Chau et al., 2002), and utilizes Microsoft Business Intelligence Portal as the end-user application for presenting OLAP data. In the system, two OLAP cubes were created with 5 dimensions including Time, Product, Task, Participant and Cost Type. Cubes use a star scheme. Using several cost and manpower analysis scenarios, the system efficiently performs Data Slice & Dice, as well as Drill- Through from different perspectives, and displays potentials of presenting project information in multidimensional visualization in a flexible and quick manner. Points of Departure 61 2.4.4 Summary of Data Analysis Technologies Sections from 2.4.1 to 2.4.3 introduced the data warehousing and OLAP technologies, and address their state-of-the-art applications in the construction industry. These research efforts demonstrated how OLAP can bring great potentials in flexibly extracting required data from data sources, interactively configuring extracted data into various data views, and quickly calculating and presenting data views to end users. UCPMA will use the OLAP technology for one of its important solutions supporting flexible data analysis. These research efforts mentioned above are good indicators on how to use the OLAP technology in the development of UCPMA. Work of (Sriprasert and Dawood, 2003) (Chau et al., 2002) and (Nie et al., 2006) essentially is similar in utilizing OLAP: defining dimensions and cubes from data sources, designing fact-tables linking to dimensions and using the Microsoft OLAP pivot table service to manipulate business data, all for particular application areas within the broad field of project management. However, the pivot table service is strong in processing numerical data, but weak in supporting analysis of data in other types. In addition, none of these efforts comprehensively describe common dimensions required by primary construction project management functions. Developing the UCPMA system cannot be based solely on OLAP. The Data Winnow of UCPMA will use the OLAP technology for analyzing not only numeric data but textural, XML and other data as well. Data included in the Data Winnow are extracted from a central data model supporting primary construction functions (Chapter 4); and data from the Data Winnow are required to be in a format supporting flexible information visualization configuration (Chapter 6). Thus, UCPMA builds upon and extends this earlier research into applications of OLAP for project management. 2.5 Information Visualization Information visualization, stimulating humans\u00E2\u0080\u0099 perspective system to see or read what is represented and using humans\u00E2\u0080\u0099 cognitive system to understand what is seen or read, can Points of Departure 62 provide the potentials to obtain insights from data so as to achieve effective communication (Ahlberg & Shneiderman, 1994) (Brautigam, 1996) (Spence, 2001) (Songer et al., 2004). Information visualization is a process of visualizing data to obtain meaningful information. There are two types of data in the engineering domain for visualization (Spence, 2001). One is physical data used to depict a physical, tangible object, e.g. a wall; the other is abstract, intangible concepts or events, e.g. cost and stress. Similarly, data for visualization in the construction domain also have these two types. In this research, we will focus mainly on visualization issues of the later type. Visualizing data employs retinal properties (such as size, color, texture, shape, etc.) and marks (point, line, area, surfaces, volume, and so on) to form images, and further to represent data in various types. According to data structural formats, data types can have univariate, bivariate, trivariate, and hypervariate/multidimensional types (Spence, 2001); while by data contents, data can be classified into groups: nominal/categorical, ordinal/ordered, and quantitative/continuous (Stolte et al., 2002). Different data types require corresponding strategies for visualizing data. Moreover, visualizing of data also should allow users to interactively browse and explore data by providing tools such as zooming, panning, scroll-down, overview, brushing/linking, focusing, fish-eyeing, etc. For example, navigational bars are usually designed for dynamical query in formulating problems and solutions; panning and zooming typically support finding details from a massive data or a larger data area (e.g. map; brushing/linking is most common in locating connected objects). In addition, multi-view visualization is an effective approach for exploring multidimensional data. Hence, besides visualization strategies, many research and development efforts have been devoted to the study of formal and consistent coordination of views from heterogeneous or homogeneous systems. These efforts have built a foundation for developing the Visualization Configuration Model of the UCPMA framework. Points of Departure 63 2.5.1 Information Visualization Strategies There is no axiom for how to visualize data. Users can choose graphics for data representation according to their own preference. Yet there is a common sense among researchers that selection of visualization strategies must consider domain needs, data type, visualization theory and density (Songer et al., 2004) (Qin at el., 2003). One of the primary considerations is visualizing data by data types (Spence, 2001) (Shneiderman, 1996). Shneiderman (1996) proposed a \u00E2\u0080\u009Ctype vs. task\u00E2\u0080\u009D taxonomy of information visualizations. The left side of the taxonomy consists of data types, while the top side of the taxonomy displays task-domain information actions. A set of identified tasks at a high level of abstraction includes: \u00E2\u0080\u00A2 Overview: to gain an overview of the entire collection of shown information items. \u00E2\u0080\u00A2 Zoom: to zoom in on items of interest by users. \u00E2\u0080\u00A2 Filter: to filter out items not of interest. \u00E2\u0080\u00A2 Details-on-demand: to select an item or group and get their details. \u00E2\u0080\u00A2 Relate: to view relationships between information items. \u00E2\u0080\u00A2 History: to keep a history of actions performed. \u00E2\u0080\u00A2 Extract: to extract a sub-collection of items and query parameters. In the taxonomy there are seven data types: \u00E2\u0080\u00A2 1Dimensional: linear data such as textual documents, program source code, and alphabetical lists of names which are all organized in a sequential manner. \u00E2\u0080\u00A2 2Dimensional: planar or map data such as geographic maps, floor plans, or newspaper layouts. \u00E2\u0080\u00A2 3Dimensional: real-world objects. \u00E2\u0080\u00A2 Temporal: a time line on which items are distributed according to their start and finish time attributes. \u00E2\u0080\u00A2 Multidimensional: most relational and statistical databases, in which each item/row has multiple attributes. \u00E2\u0080\u00A2 Tree: a structure of a collection of items, in which an item has a link to a parent item (except the root). Points of Departure 64 \u00E2\u0080\u00A2 Network: a structure, in which items are linked to an arbitrary number of other items, shaped like a net. Still other research has proposed methods of categorizing visualization techniques for visualization development. Wenzel at el. (2003) proposed taxonomies of visualization techniques from a graphics point of view and an information-related point of view. From research and development review, Qin at el. (2003) obtained findings that factors classifying visualization techniques can have: data type, display mode, interaction style, analytic task, and based model. They asserted that visualization merges representation function and interaction function, and its real role is analysis rather than display. Based on this point, they proposed a taxonomic framework of data type vs. analytic task for end users, and a framework of representation mode vs. interaction level for system developers (Figure 2.15). Keim (2002) suggested an orthogonal classification method with three axes, namely data type to be visualized, visualization technique, and interaction and distortion technique, as shown in Figure 2.16. The orthogonal method promises that \u00E2\u0080\u009Cany of the visualization techniques may be used in conjunction with any of the interaction techniques as well as any of the distortion techniques for any data type.\u00E2\u0080\u009D 65 Figure 2.15: Qin\u00E2\u0080\u0099s User-Oriented (Upper Table) and Developer-Oriented (Bottom) Frameworks Points of Departure 66 Figure 2.16: Keim\u00E2\u0080\u0099s Orthogonal Classification of Visualization Techniques 2.5.2 Multi-View Coordination Much research has been dedicated to visualization coordination, since interactive visualization can improve effectiveness in exploring a large volume of data (Boukhelifa & Rodgers, 2003). Coordination can be implemented as interaction between information objects, events, or visualization components. The research and development described below addresses various visualization coordination mechanisms and serves as a good indicator of the development of UCPMA\u00E2\u0080\u0099s Visualization Configuration Model. Boukhelifa and Rodgers (2003) proposed a model for representation-oriented coordination and data-centric coordination, using a layered approach based on a dataflow model (Figure 2.17). The model consists of basic visualization processes and states, the coordination space, the events and the translation and notification functions. The space, like a middleware layer, contains coordination objects that manage combinations of entities (e.g. parameters) controlling aspects of the linked views. Each coordination action is defined with one coordination object. Views are coordinated by sharing common coordination objects. When Points of Departure 67 an event occurs, the object worked on is changed, and the system then notifies registered views which share the object. Using information provided by the object via its translation functions (e.g. f1.1 in the figure), the notified views are updated. Figure 2.17: Boukhelifa\u00E2\u0080\u0099s Abstract Model for Coordination in Exploratory Visualization Figure 2.18: Analogy between Relational Database Concepts and Snap Visualization Concepts Model (North at el., 2002) Points of Departure 68 North (2000) proposed a Snap visualization model which provides coordination between data design and visualization design. The primary guiding principle of the model is to establish a tight analogy between relational data concepts and visualization concepts (see Figure 2.18) (North at el., 2002). Through the model, coordination is generated according to Join association of data schemas; thus, Snap provides convenient coordination without the need of user\u00E2\u0080\u0099s programming. In addition, various joins are introduced in the model: self join, single join, compound join, and multiple alternative joins. Hartmann et al. (2003) introduced the CIFE WorkSpace and proposed its advancement by integrating it with a 3D CAD environment. Based on an event-based message-passing system, the WorkSpace integrated Autodesk Architectural Desktop (ADT) with Microsoft Project, Microsoft Office, and Common Point 4D in order to represent relations between geometrical properties of structural elements and construction activities (Figure 2.19). In the system, applications are located on different computers, on which are installed a client event-heap system. The event-heap system communicates with an Event-Heap Server, which passes or receives messages to and from individual applications. Relationships between objects in applications are initially established and installed in a database. Data mapping is performed when a client application has received a message; matched objects in the application are then notified. Figure 2.19: CIFE WorkSpace\u00E2\u0080\u0099s Message Passing System Points of Departure 69 In addition, the application of the Model-View-Controller (MVC) design pattern in programming can support view coordination. Such design brings an intermediate component\u00E2\u0080\u0094the controller\u00E2\u0080\u0094between the Model and the View, so that data and user interface are separate: changes to the user interface do not impact data handling, and data reorganization does not change the interface. As shown in Figure 2.20, a user interacts with the View in some way (e.g. selecting information items on a view). Then an event is triggered and sent to the Controller which, in turn, activates a process to access the Model to change the View including any impacted instances. The View may get its own data from the Model or use the Model to generate an appropriate interface. MVC provides a simple and effective approach to multi-view coordination, and will be adopted in this research (Chapter 6). Figure 2.20: Model-View-Controller Design Pattern Diagram 2.5.3 Visualization in Industrial Applications The research described previously provides good tools for building UCPMA\u00E2\u0080\u0099s visualization component. Besides, applications adopted in the AEC/FM area appear to support our research in visualizing construction data. For example, among the state-of-the-art domain applications introduced in Section 2.2.3, Autodesk Revit, Microsoft Project and the Primavera E/C solution more-or-less use information visualization theories and make presented data more understandable for end users. Revit, built upon CAD techniques, features multi-view presentation of product Points of Departure 70 information; those 2D or 3D views adopt retinal properties to present data items and display good integration with other graphs (e.g. its \u00E2\u0080\u009Cschedule\u00E2\u0080\u009D of product specifications) based on shared information in the same system. Microsoft Project presents rich views in presenting process information; those views are coordinated in an ad hoc way that also relies on shared data in the same source. Similar to Microsoft Project, the Primavera E/C solution presents multiple views with more functions specifically dedicated to construction project management. However, these applications share common disadvantages in information visualization. In particular, the applications have minimal ability to present information from outside of their primary data views, and end users cannot generate new, coordinated views for specific requirements other than those defined by system developers. UCPMA is intended to provide solutions with enhancement in these regards. 2.5.4 Summary of Information Visualization The state-of-the-art applications in the AEC/FM domain do not offer solutions for information visualization that meet UCPMA\u00E2\u0080\u0099s objectives. Therefore, the VCM is initiated as an important component of the UCPMA framework. The VCM (Chapter 6) utilizes available information visualization theories of visualization strategies and multiple view coordination, which are briefly introduced in Sections 2.5.1 and 2.5.2 respectively. Detailed technical review and application of these theories will be addressed in Chapter 6. In summary, several pieces of research introduced in Section 2.5.1, such as (Songer et al., 2004) (Spence, 2001) (Shneiderman, 1996) (Wenzel at el., 2003) (Qin at el., 2003) and (Keim, 2002), include a body of visualization principles as guidelines of using appropriate encoding approaches to meaningfully present multidimensional construction data. The guidelines will be summarized in Section 6.5.1. Choosing the right visualization theories call for appropriate classification of visual techniques. Keim, Qin, and Songer proposed several taxonomies for this purpose. This research will take the taxonomy by data type (referred to Shneiderman and Songer\u00E2\u0080\u0099s work), and modify it by considering functional requirements, visualization theory, user interactive preference, etc. Moreover, Wehrend (1990) and Qin Points of Departure 71 (2003) presented a comprehensive knowledge of functional requirements in visualization. Shneiderman, Spence and Keim addressed presentation tasks forming a body of visualization interactions to fulfill those functional requirements. In short, these research efforts are combined into a foundation of the development of VCM. Boukhelifa and North proposed solutions for multiple views coordination, introduced in Section 2.5.2. The VCM will take their advantageous features in order to fit in the UCPMA. Hartmann is a good reference to implementation of communication among views. In the UCPMA prototype system (Chapter 7), the MVC design pattern will be tailored into the implementation of VCM. 2.6 Conclusions This chapter establishes a background of knowledge and techniques for UCPMA development by reviewing research and development involving multi-view representation for project management, project modeling (product modeling and process modeling), data warehousing and OLAP, and information visualization. The review concludes that none of mentioned techniques or tools can meet all of UCPMA\u00E2\u0080\u0099s requirements. The combination of these techniques provides great potential for information integration throughout the whole IT-supported construction practice. The goal is not to simply \u00E2\u0080\u009Cassemble\u00E2\u0080\u009D separate technologies; but to integrate them with each other so as to form a whole system, UCPMA. Data standardization enables information integration and system interoperability. Data warehousing and OLAP, as a multidimensional data processor, facilitate selecting, filtering and transforming data from a Central Data Model, and loading it for flexible exploration and presentation. Theories of information visualization, regarding visualization strategies, view coordination, etc., have built up foundations for developing UCPMA\u00E2\u0080\u0099s Visualization Configuration Model. The challenge is how to integrate information flow at different layers leveraging these technologies and make them work together. The following chapters describe the research Points of Departure 72 effort in taking on this challenge and exploring its potential. Chapter 3 gives a broad overview of the UCPMA framework; Chapters 4, 5, and 6 elaborate details of the Central Data Model, Data Winnow and Visualization Configuration Model respectively, which together make up UCPMA. Unified Construction Project Management Arena 73 CHAPTER 3: UNIFIED CONSTRUCTION PROJECT MANAGEMENT ARENA This chapter presents the framework of the Unified Construction Project Management Arena for an Information Aggregator, which calls for three major components. These are the Central Data Model, the Data Winnow and the Visualization Configuration Model, corresponding to the three layers\u00E2\u0080\u0099 information interdependency. Fundamental mechanisms and principles of these components are outlined. The chapter also addresses the framework\u00E2\u0080\u0099s feature characteristics. In addition, through comparison with other previous research and development, UCPMA\u00E2\u0080\u0099s value is further clarified. This chapter presents the overall concept; subsequent chapters will develop the main components. 3.1 Origins of the Framework The Unified Construction Project Management Arena (UCPMA) framework, the main research objective, evolves from the concept of the \u00E2\u0080\u009CUnified Approach to Project Management\u00E2\u0080\u009D illustrated in Figure 3.1 (Froese, 2003b) (Froese & Staub-French, 2003). The approach is intended to \u00E2\u0080\u009Cbring an integrative view to the forefront, centered on the notion of defining multiple views of the project and the interrelationships that exist between the views.\u00E2\u0080\u009D This is based on the fact that project organization and work are typically fragmented, and insufficient effort is placed on effective incorporation of different disciplines until the physical structure begins to take shape. Under UCPMA, a construction project is conceived to be built upon the \u00E2\u0080\u009Cvirtual building\u00E2\u0080\u009D model: first all work tasks will focus on the model through shared views, then the physical product will be constructed, more like an \u00E2\u0080\u009Congoing manufacturing process than a one-time event\u00E2\u0080\u009D (Froese, 2003b). Unified Construction Project Management Arena 74 Figure 3.1: An Example Scenario of Unified Approach to Project Management Another approach, from which the development of UCPMA draws, is the Configurable Environments (CE) approach proposed by (O'Brien et al., 2003). The authors asserted that there was \u00E2\u0080\u009Cconsiderable difficulty accessing needed information in a form useful for decision making,\u00E2\u0080\u009D because of the contextual specialization of applications that data and tools are suited for. By reviewing previous approaches of problem-solving environments, the authors reasoned that the configurable environments approach should combine information technologies such as interoperability, mediation, data visualization, user modeling, intelligent user interfaces, etc; have capabilities of analysis and visualization; integrate multiple heterogeneous data sources; and be easy for users to customize software for specific requirements. Figure 3.2 shows its high-level architecture. The integrated data component of the CE provides an organized view of data specific to user needs; the application layer provides analysis and query capabilities; and the user model directs configuration of the components of the CE. Unified Construction Project Management Arena 75 Figure 3.2: Configurable Environments\u00E2\u0080\u0099 High-Level Architecture Xie et al. (2003) designed a system employing the user model concept in the field of construction project management in order to retrieve information based on user requirements. In this system, a business user model is specified with components of view, diagram, object and process. A view is defined as an abstraction of one or more aspects of the business; each view has one or more diagrams demonstrating a portion of business information regarding objects, processes, business goals and the like. An object refers to a physical or abstract business element, while a process stands for a function in which one business interacts on another; objects and processes represent the business\u00E2\u0080\u0099 logic and situations. The \u00E2\u0080\u009CUnified Approach to Project Management\u00E2\u0080\u009D approach centers on defining multi-views, while the Configurable Environments approach tends to design a technical data access environment. These two approaches are similar in respect of \u00E2\u0080\u009Cunifying\u00E2\u0080\u009D data modeling, analysis and visualization to access \u00E2\u0080\u009Cneeded information data in a useful form\u00E2\u0080\u009D (O'Brien et al., 2003). However, they are just concepts on how to improve project management. Xie contributed a system that employed the User Model of O'Brien\u00E2\u0080\u0099s concept, yet seemly did not provide solutions on how to efficiently configure data views and design visualizations allowing for user-interaction. The UCPMA framework merges merits of these two approaches into a new tool which can flexibly define multi-views for project management, emphasize information interdependency and leverage middleware like the mentioned User Model to configure user interfaces, application layer, and data components. Unified Construction Project Management Arena 76 3.2 The UCPMA Framework 3.2.1 Definition UCPMA, as an Information Aggregator, is an approach to integrate data sources and to provide consistent capabilities of analysis and visualization through leveraging technologies of data standard, data warehousing and OLAP, and information visualization. UCPMA brings \u00E2\u0080\u009Can integrative view to the forefront,\u00E2\u0080\u009D focusing on incorporating different management tasks, and emphasizing their seamless relationships. Through UCPMA, it is envisioned that participants work on a common set of project management views generated and supported by data, analytical and visualization models so that all involved jobs can smoothly fit together towards the whole project, rather than independent work pieces. UCPMA fosters a systematic project management environment consisting of many elements and their sub-elements (e.g., Data Winnow elements in Chapter 5 and graph elements in Chapter 6) in hierarchical structures where elements retrieve and contribute shared information and information flows across these elements. UCPMA would support all project management participants and to improve their communication for understanding, analyzing, evaluating and decision-making during construction processes. It would function like an arena where scenes are presented to people who are not just audience but actors during construction. Actors use a common language or data standards for valid information exchange pertaining to construction products (such as buildings, roads, bridges, etc.) and processes. Related data remains consistent by being input just once in an application, and can be organized/aggregated at different levels of detail. In general, UCPMA as a system is envisioned to be independent of any other systems, yet be able to communicate with them in an appropriate way and be open to expand functions according to user specific requirements. 3.2.2 Integral Components Corresponding to problems formulated in Section 1.1.3, the UCPMA framework consists of a front stage and back stage and it comprises three components\u00E2\u0080\u0094a Central Data Model and Unified Construction Project Management Arena 77 a Data Winnow in the back stage, and a Visualization Configuration Model (VCM) in the front stage (see the right panel in Figure 3.3; also refer to the UCPMA architecture in Chapter 7). Each component is designed to enhance information interdependency throughout system layers. The Central Data Model captures and represents construction information in a model, leveraging data standard technologies such as IFCs. In the model, information of objects with common attributes is captured in a class, such as a Product containing information of a building or its elements. Relational logic is established by appropriately connecting one class to another (for instance, linking a column to the task of placing rebar for the column) according to their interdependency. In this way, information interdependency can be presented explicitly. However, in practice some relationships are implicit. For example, should the cost of infrastructure excavation overruns be attributed to changes during excavation or to the fact that during these days precipitation exceeded historical records? To such an issue, the data model provides only a list of cost items and a collection of changes during excavation. It doesn\u00E2\u0080\u0099t uncover whether cost overrun resulted from changes or the abnormal weather without support of other applications. The Central Data Model serves as a common language that fosters smooth communication for different parties to interpret their relational logic, or for software tools to exchange information easily by reading output from one and feeding to another, or directly by sharing the same data model. The development of the Central Data Model was referenced to IFC models, but the model focuses on representation of construction project management information. In Chapter 4, the Central Data Model is presented in detail. Unified Construction Project Management Arena 78 Figure 3.3: Information Interdependency Problems vs. UCPMA Solutions The Data Winnow provides analytical services through a collection of domain entities. As the size of a data model grows by adding a broad range of domain information, it becomes harder for users to access and obtain data from the model. For example, Reinhardt (2004) asserted that the application of new techniques such as mobile computing can produce a large amount of data and information which challenges the efficiency of interaction with large datasets. Meanwhile, each party is usually interested in a particular dataset relevant to its own business. Quick access and flexibility in changing queries places heavy demands on a tool like the Data Winnow. Similar to a grain winnow (a device to separate chaff from grain), the Data Winnow arranges various disciplinary data into a multidimensional structure, filters data as required, and transforms data for further manipulation. The Data Winnow is built upon data warehousing and Microsoft OLAP technology. Through the tool, information in the Central Data Model can be virtually structured in dimensions, and dimensions then organized into views. Each construction process or main issue is regarded as a view or combination of several views. Moreover, dimensions with several levels are organized in a hierarchical structure. Each dimension is derived from one or more data tables in the Central Data Model. Chapter 5 elaborates the Data Winnow in detail. Unified Construction Project Management Arena 79 The Visualization Configuration Model depicts a paradigm where data graphics are employed to visually display data on a screen, and sophisticated views are configured by arranging data graphics in appropriate manners to express abundant, yet easily understandable information. Voluminous construction data calls for appropriate visual presentation methods which can give affected parties the best insight; however, current construction domain software tools employs very simple visual capabilities (Songer et al., 2004). The VCM is a method that facilitates flexible and comprehensive use of visualization capabilities for effective comprehension of construction data and interaction with supporting systems. The VCM is inspired by flower patterns. In nature, all flowers are made with almost uniform patterns: layered structures with different shaped petals rich in retinal properties. These patterns make flowers beautiful, and the configuration of different flowers display natural brilliance. The VCM adopts similar patterns for visualizing construction information. It belongs to the front stage or layer, composed of scene, view, graphs, and graph elements in a coaxial layer structure (see Chapter 6 for details). 3.2.3 UCPMA as a Whole System The UCPMA framework is a system in which three components are integrated and should work together providing required services (see Figure 3.4). The Central Data Model enables information integration, yet requires an effective way to manipulate datasets to dynamically create data views from different user perspectives. The Data Winnow fulfills this requirement through organizing datasets in functional dimensions and provides data analysis services (splicing, dicing, etc.) through \u00E2\u0080\u009Cshuffling\u00E2\u0080\u009D dimensions. The VCM structures and organizes visualization elements matching data elements via the Data Winnow. Supported by the Data Winnow, users can visually configure and work with multidimensional views for PM. Hence, none of the three integral components can be separated from the system, while the framework still meets functional requirements. Unified Construction Project Management Arena 80 Figure 3.4: Integrated UCPMA Framework Schema 3.2.4 UCPMA Features The UCPMA framework serves as a fully integrated approach, effectively supporting primary processes of construction project management. It features a number of key characteristics described in the following sections. 3.2.4.1 Holism A term invented by Jan Smuts in the early 1920s, holism was defined as \u00E2\u0080\u009CThe tendency in nature to form wholes that are greater than the sum of the parts through creative evolution.\u00E2\u0080\u009D A holistic approach promotes system thinking \u00E2\u0080\u0093 considering a system as a whole comprised of interactive components. UCPMA\u00E2\u0080\u0099s three components, the Central Data Model, the Data Winnow and the Visualization Configuration Model, do not stand alone in their functioning, but process, link and interact with each other based on information interdependency (Figures 3.3 and 3.4) This forms the basis of UCPMA\u00E2\u0080\u0099s holism. Unified Construction Project Management Arena 81 Figure 3.5 displays an example of interdependent information relationships between UCPMA components at a high level of detail. In implementation, information captured by the Central Data Model is stored in a central relational data model, which provides flexibility in storing, sorting, editing and representing a collection of datasets. Each table in the relational data model keeps a class of data; each row or record in the table holds attribute values of an object instance. In the Data Winnow, a dimension is derived from tables; one or many dimensions constitute a view. Thus, from the Central Data Model to the Data Winnow, information is completely interdependent; such interdependency enables their correspondence described in Section 5.2. Dimensions and other entities in the Data Winnow have corresponding elements in the VCM (Visualization Configuration Model), as described in Section 6.3.3. Each graphic element in the VCM model is a visual presentation of a dimension member\u00E2\u0080\u0099s property. A graph portrays dimension information, while a view consists of one or more dimensions. Therefore from the Data Winnow to the VCM, information is consistent. Concurrently, the Data Winnow enhances the flexibility of the VCM in reformulating user requirements (e.g. visually browse information in low levels), and changing visual strategies (e.g. select different graphs to represent the same set of data). 3.2.4.2 Information Integration The framework captures and represents project information in the Central Data Model built upon IFC data standards, which enables interoperability among industry processes across all different AEC/FM domains. Meanwhile, through a set of UCPMA\u00E2\u0080\u0099s common views, participants can read, edit, and analyze construction data, as well as integrate different mental models for decision-making. These views share data from the same model central to all generic management processes, and can be created by constructing a Visualization Configuration Model (Section 3.2.2) instance. External system views are allowed to be incorporated for specific issues. 82 Figure 3.5: Information Interdependency between UCPMA Components Unified Construction Project Management Arena 83 3.2.4.3 Flexibility in User-Computer Interaction Flexibility stems from the holistic approach mentioned above. Also it is ascribed to the powerful data analysis tool which facilitates quick access and query of different information for different user requirements, and to the dynamic visualization model by which end users just need to drag and drop graphs in order to configure a new view or to change view coordination. 3.3 Value of the Proposed Framework UCPMA is intended to benefit IT-based construction practice mainly in three ways, data sharing for information integration, view sharing for interface consistency, and dynamic data analysis in a flexible visual configuration environment, as required in Section 1.4. The following section clarifies UCPMA\u00E2\u0080\u0099s value by comparing it with competing systems which fall into three categories: generic computer-supported construction management, multidimensional data presentation, and data exploration and analytical services. Demonstration of the proposed approach\u00E2\u0080\u0099s value is addressed in Chapter 7. 3.3.1 Generic Computer-Supported Construction Management There has been much research dedicated to finding IT solutions to improve construction project management. Yu (2002), Amor (2001) and Froese (1992) summarized efforts for leveraging IT in construction and envisioned future development trends. Those efforts are regarded as being \u00E2\u0080\u009Cgeneric,\u00E2\u0080\u009D since they typically focused on computer-supported construction management integration at a low level that deals with data sharing between systems mostly by data modeling. Here, two examples are taken for analysis in comparison with UCPMA. Figure 3.6: TOPS Element Relationships (Yu, 2002) Unified Construction Project Management Arena 84 Total Project Systems (TOPS) (Froese, Rankin, & Yu, 1997) is a class of computer systems intended to \u00E2\u0080\u009Cpush computer tools past the point of \u00E2\u0080\u0098critical mass\u00E2\u0080\u0099 where broadly-applicable computational models become the primary vehicle for practicing construction management.\u00E2\u0080\u009D As shown in Figure 3.6, TOPS based systems call for elements of a broad range of comprehensive AEC/FM Applications, System Architecture, Information Models, Information Content and Work Practices (Yu, 2002), yet the most significant requirement of TOPS are common data structures facilitating extensive information sharing across AEC/FM applications. Like UCPMA, TOPS emphasizes data sharing based on common data models and system interoperability for improving management of various construction processes. However, less effort in Yu\u00E2\u0080\u0099s research was given to efficiently exploring voluminous multidimensional data for specific user requirements and to integrating construction data visual presentations for consistent interpretation. The Center for Integrated Facility Engineering (CIFE) of Stanford University initiated the Sequus Pharmaceuticals Pilot Plant facility project in 1998 (Staub-French & Fischer, 2001), which tried to electronically maintain integration of schedule-cost-time models during project design and its construction. As shown in Figure 3.7, efforts at information integration were oriented towards two main aspects: \u00E2\u0080\u00A2 Design-cost integration. Cost assemblies were linked to design objects in order to automate extraction of object quantities from architectural design software into cost estimating software. \u00E2\u0080\u00A2 Design-schedule integration. The research tested in reading design object geometry data, creating schedule activities and calculating their durations, then importing them to 4D visualization for simulating construction processes. Unified Construction Project Management Arena 85 Figure 3.7: Efforts of Design, Cost, and Schedule Integration Using Commercial Tools (Staub-French & Fischer, 2001) The project demonstrates a valuable referential scenario that commercial tools can be linked to integrate design and project management information by leveraging 3D models. However the project proves that the links between these tools were ad hoc: first, one tool must have an ability to read heterogeneous data from a particular electronic file generated by another tool; second, an information item from one tool may need to be refined in order to correspond to a matched item in another tool. Therefore, the project calls for data standards so that information is consistently represented and shared by independent tools. In this regard, UCPMA provides a solution with its Central Data Model referenced to IFC data standards. Moreover, UCPMA is envisioned to be able to integrate independent tools not only through integrating data exchange (details of which are beyond the scope of this dissertation), but also by visualization integration (view coordination). In addition, many available commercial tools such as Autodesk solutions, Primavera solutions, Common Point 4D solution, and Microsoft Project support construction management. Compared with these tools, UCPMA benefits from its holism: integration in its data model, data analysis and visual presentation of its information (see Section 7.3 for demonstration and evaluation). As described in Section 2.2.4, none of the others include integration solutions in all three areas. And, unlike UCPMA, these tools do not provide sufficient flexibility in user-computer interaction. Unified Construction Project Management Arena 86 3.3.2 Multidimensional Data Presentation Autodesk Revit, introduced in Section 2.2.3, is a good comparison for UCPMA development. Similar to UCPMA multi-view presentation, it displays 3D products in multiple views, and provides functionalities in configuring a physical product by drag-and- drop features, as well as in exploring different levels of components. However, Autodesk Revit presents information exclusively for design rather than generic purposes of project management. Also, it does not show great capabilities in data sharing for other participants, e.g. cost estimator or planner. In comparison, UCPMA is designed to integrate information for primary project management functions and provide consistent visual presentation through a set of common views. REPCON, introduced in Section 2.2.2, performs well in terms of multidimensional data representation. The nine views generally reflect basic requirements of project management. These views bring users an entire view of the project, indicating what a project looks like, how it is carried out and who has responsibility for each task. Each view represents related functional information, corresponding to a particular dataset in its underlying data model. Views are linked according to information interdependency represented in the model. In this sense, there are similarities between REPCON and UCPMA, yet they each have quite different focus areas. REPCON relies heavily upon generalized planning structures that enable linear planning and other related analysis\u00E2\u0080\u0094these provide significant power and efficiency but reduce interoperability since the approach is uncommon in other industry systems. REPCON also excels at embodying detailed construction management knowledge and practices into its functions and views\u00E2\u0080\u0094with a consequence that these views are specified at the time of system design rather than at the time of end-user configuration. Conversely, UCPMA addresses interoperability by building upon industry data standards, and focuses on generic, user-configurable approaches for data view configuration and information presentation. Some aspects of these two different approaches could be complimentary but others are contradictory, with both approaches offering significant advantages and disadvantages. Unified Construction Project Management Arena 87 Other research regarding multidimensional data representation tends to focus either on view design in the data layer or view design in the presentation layer. The first attempts to identify a set of objects, specify their attributes, and define the objects\u00E2\u0080\u0099 relationships. (Curtis et al., 1992) and (Wix & Katranuschkov, 2002) introduced in Section 2.2 have followed this path. The other approach tries to explore visualization strategies in order to appropriately encode data items and leverage applicable visualization mechanisms for presenting multidimensional information. Efforts of (Nagappan, 2001) (Baldonado et al., 2000) (Songer et al., 2004) (Stolte et al., 2002) (Nottingham et al., 2001) (North at el., 2002) and (Boukhelifa & Rodgers, 2003) fall into this category. These research and development efforts provide only partial solutions to the problems formulated in Section 1.2, and do not meet UCPMA requirements that integrate data models, flexibly support analysis, nor integrate user interfaces for consistent view presentation. 3.3.3 Data Exploration and Analytical Services Data standards, e.g. the IFC model, are asserted to be able to enable information integration and system interoperability; however, there is a challenge in effectively using their voluminous data: easily filtering, retrieving, aggregating, etc. A few research efforts, such as (Sriprasert and Dawood, 2003) (Chau et al., 2002) (Nie et al., 2006) introduced in Section 2.4, have focused on application of data warehousing and OLAP techniques in the construction industry. They provide good comparisons for UCPMA to leverage OLAP technologies. However, these solutions are based on application-dependent data models; moreover, less attention is paid to the front layer and its problems of how to present information effectively and facilitate consistent interpretation. Nagappan\u00E2\u0080\u0099s composition model for multidimensional data visualization mentioned in Section 2.2.2 takes a strategy similar to \u00E2\u0080\u009Cdivide-and-conquer.\u00E2\u0080\u009D As shown in Figure 3.8, data is decomposed into a collection of simple components, which are then mapped to individual visualizations. Individual visualizations are \u00E2\u0080\u009Cclustered\u00E2\u0080\u009D to form a large complex visualization. Data components and visualization components are presented in a tree-like hierarchical structure. Relationships established in such a structure facilitate users\u00E2\u0080\u0099 Unified Construction Project Management Arena 88 exploration of visualization elements, and in turn, their presented data. UCPMA adopts this strategy in data analysis and information visualization, but uses a more flexible visualization approach with correspondence between the Data Winnow and the Visualization Configuration Model (see Chapter 6). Figure 3.8: Nagappan\u00E2\u0080\u0099s Compositional Model of Visualization Still other research has focused on how to navigate, access and organize data effectively in a large model through reorganizing model entities in different structures unlike the OLAP\u00E2\u0080\u0099s. Navigational models proposed by Reinhardt et al. (2004) are constructs that have leaf nodes containing and referring to data in a product and process model of a hierarchy. As shown in Figure 3.9, high-level nodes are aggregations of lower-level nodes with parent-child associations. The purpose of navigational models is to provide flexibility and dynamics in navigating and interacting with data sets in the construction product and process model in different groupings and different levels of detail. UCPMA\u00E2\u0080\u0099s Data Winnow resembles the navigation model approach in using a hierarchical structure; while nodes are replaced with dimensions, levels and properties, which are constituent elements of the Data Winnow tool Unified Construction Project Management Arena 89 and cannot be aggregated directly from one to others. Only high-level dimension members in such a structure may have parent-child associations with low-level members. This approach facilitates establishing correspondence between elements in the Data Winnow and in the VCM. On the whole, the navigational model approach leverages the object navigation characteristic of object-oriented technologies and the flexibility of the hierarchical structure; but the Data Winnow takes advantage of the power of the underlying relational database and effective information classification (described in Section 5.3.2), which support to integrate three UCPMA components into a whole. Figure 3.9: Sample of Navigational Models, Linking Entities of Product and Process Model (Reinhardt et al., 2004) Unified Construction Project Management Arena 90 Figure 3.10: An IFC Aspect Example -IFC Cost Aspect (VTT, 2005) The Pro IT development project, initiated in Finnish in 2002, resulted in IFC Aspects which regroup elements of IFC in different groups according to domain user requirements. The purpose is to facilitate definition of data exchange use cases and implementation in software. As shown in Figure 3.10, an IFC aspect has attributes of: relevant IFC Object Model subset Unified Construction Project Management Arena 91 in EXPRESS-G format, description, and instantiation example and its description, as well as implementation rules (VTT, 2005). This idea provides a favorable indicator of identifying common dimensions and formulating view definition for UCPMA\u00E2\u0080\u0099s Data Winnow. Like the IFC Aspects approach, a dimension is one element or associated elements in the Central Data Model, and a view stands for a subset of the model. In addition, organizing a great number of Central Data Model elements into model aspects supports effective view composition in the data layer and flexible view configuration in the presentation layer. Currently, the Pro IT work and other IAI efforts have evolved into an IFC IDM (Information Delivery Manual) and MVD (Model View Definitions) approach which is under development. The approach specifies a structured format for information exchange among applications through identifying (mapping) a process, defining information exchange requirements, regulating IFC implementation, and representing exchange requirements as model views expressed with IFC MVD notation (these MVD are actually aspects of the IFC model) (IAI, 2006) (buildingSmart, 2008). It can be foreseen that leveraging the IFC IDM& MVD in UCPMA\u00E2\u0080\u0099s data layer will formalize information exchange and enhance view configuration in the presentation layer; this work leaves for future research related to unified construction project management (see Section 1.5 for the research scope). 3.4 Conclusions This chapter has presented the UCPMA by describing its basic concept, features, components and interrelationships, as well as its value in comparison with other research and development efforts. The interactive components include the Central Data Model, the Data Winnow and the Visualization Configuration Model. The framework adopts the knowledge and techniques of standard data models, OLAP technology, and information visualization in different system layers. Incorporating these techniques facilitates UCPMA\u00E2\u0080\u0099s components integration, and in turn, makes UCPMA holistic and flexible. Unified Construction Project Management Arena 92 UCPMA benefits IT-based construction management mainly in areas of data sharing for information integration, view sharing for interface consistency and dynamic data analysis in flexible visual configuration environment. Chapters 4, 5 and 6 elaborate on each of UCPMA\u00E2\u0080\u0099s components. Integrating Project Management Information with Central Data Model 93 CHAPTER 4: INTEGRATING PROJECT MANAGEMENT INFORMATION IN A CENTRAL DATA MODEL This chapter presents, the Central Data Model, one of the components comprising the Unified Construction Project Management Arena (UCPMA) framework. Development of the model follows the IFC modeling approach, adopts some IFC classes, and also extends the IFC model by adding new entities as required. The dissertation here first investigates primary project management functions and studies their information needed as fundamental input and/or output. Then a central domain PM data model is presented through integrating eight functional domain data models. The chapter focuses on developing the Central Data Model for construction project management, based on the assumption that fundamental information can be successively available (mentioned in Section 1.6). Some issues regarding data exchange are also discussed for future work. 4.1 Introduction The current IFC model is suitable for a technical solution for the data layer of a project management information integrator system; yet, the challenge remains that the project management portions of the IFC model have received very little research and development attention, and their suitability for supporting project management integration is largely untested (Section 1.2). Therefore, at the data layer, the goal for this research was to establish the data requirements needed to support project management integration, to evaluate the IFC model against these requirements, and to suggest possible extensions to the IFC model if necessary. Integrating Project Management Information with Central Data Model 94 In developing the model, the first step is to develop the scope \u00E2\u0080\u0093 namely, to make clear what functions for construction project management are primary and what fundamental information is critical to the functions since there are different perspectives in defining project management. The second step is to check what is available in the IFC model for representing those fundamental PM information. Then, identify classes in IFC for PM and supplement new elements as required, and finally present the model with all identified elements. At the current stage of this research, proposed new classes remain conceptual; detailing to meet IFC extension requirements is left for future research. The focus of this chapter is to represent what is primary for PM and represent required information items at a high level of abstract. The following sections are organized in this way accordingly. Section 4.2 investigates project management functions and studies required fundamental information; Section 4.3 presents models of primary functions and displays a domain data model called Central Data Model; and Section 4.4 discusses some issues about information interoperability for future research work. 4.2 Project Management Functions and Information Project management is regarded as a set of interrelated functions about project elements, yet researchers have different perspectives on the set of functions. Through review of research and development, eight functions including Scope Management, Cost Management, Schedule Management, Resource Management, Quality Management, Risk Management, Organization Management, and Information Management, are identified as the most primary functions in current practice. 4.2.1 Project Management Concept Project management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements (PMI, 2008). It is typically accomplished by forecasting, organizing, commanding, monitoring, reporting, and control. Project management usually focuses on management of fundamental project elements such as scope, Integrating Project Management Information with Central Data Model 95 cost, quality, time, risk, resource and information. Consequently, project management is characterized by: \u00E2\u0080\u00A2 Decomposed structure. A project is typically described as a body of many elements. And project management usually consists of different activities which are carried out in order to accomplish those elements by project personnel in different project phases. \u00E2\u0080\u00A2 Systemic body. Functions that manage project elements form a whole body, in which each needs to be coordinated toward project success. Good project management results from seamless integration such that each part can be put together so as to form an entire puzzle, and is capable of being adjusted for any change rising from the inside of the body or caused by outside influence. 4.2.2 Perspectives on Project Management Functions As addressed in Chapter 2, Wideman (2003a) identified eight functions as basic elements of project management in his diagram of function-process-time relationship, as displayed in Figure 2.1. These functions include Scope, Quality, Time, Cost, Risk, People Resources, Contractual or Procurement, and Information or Communication. They are conducted through processes such as Plan, Organize, Execute, Monitor and Control, which are performed along the project\u00E2\u0080\u0099s life cycle spanning phases of Concept, Definition & Planning, Execution and Transfer. The model of project management proposed by Wideman is different in labels, yet similar in content to PMI\u00E2\u0080\u0099s framework of project management, which also encompasses management of Scope, Time, Cost, Quality, Human Resource, Procurement and Communication (PMI, 2008). However, the latter adds project integration (including processes of plan, execute and change control) as a parallel function in the body of project management knowledge. Similar opinion on project management is expressed in (Russell, 2004)\u00E2\u0080\u0099s project management framework, which includes nine views, namely Physical, Process, Cost, As- built, Quality, Change, Organizational/Contractual, Environmental and Risk. The framework and its research emphasize industrial practice issues such as schedule generation as well as short cycle scheduling, payment reporting, documentation management, change order Integrating Project Management Information with Central Data Model 96 management, daily site reporting, productivity analysis, automated analysis of current project status, and, completion report generation including post-project analysis, or lesson summarization (Russell & Froese, 1997). Compared to PMI\u00E2\u0080\u0099s framework and Wideman\u00E2\u0080\u0099s model, it sets environmental management as a category of separate project management elements, and divides PMI\u00E2\u0080\u0099s Integration Function into Change and As-built views in terms of functional requirements. 97 Figure 4.1: Lille Work Session\u00E2\u0080\u0099s \u00E2\u0080\u009CMind Map\u00E2\u0080\u009D Integrating Project Management Information with Central Data Model 98 From a personnel perspective, the Lille Working Session on \u00E2\u0080\u009CGlobal Performance Based Standards for Project Management Personnel\u00E2\u0080\u009D, held in 2003, developed a \u00E2\u0080\u009Cmind map\u00E2\u0080\u009D reflecting the responsibilities of most project managers. The \u00E2\u0080\u009Cmind map\u00E2\u0080\u009D is generated from 48 topics, which are categorized into 13 groups. They were regarded as significant functions that would likely need to be performed by a project manager (GlobalPM, 2003). Shown in Figure 4.1, the 13 groups include: Project Start-up, Relationship Management, Interpersonal, Resource Management, Project Planning & Control, Project Evaluation and Improvement, Scope Management, Time Management, Cost Management, Quality Management, Risk Management, Finalization, and Legal Issues. The foregoing review of efforts to describe project management faces a challenge of function selection. For example, if we focus on the as-built view of functions, then how about functions of \u00E2\u0080\u009Cas-required,\u00E2\u0080\u009D \u00E2\u0080\u009Cas-designed\u00E2\u0080\u009D and \u00E2\u0080\u009Cas-used?\u00E2\u0080\u009D It seems that these views belong to project lifecycle contexts. Or, if we consider functions based on the Project Manager\u00E2\u0080\u0099s responsibilities, then how do we describe views of other roles such as Sponsor, Contractor and Owner? Thus, the question is what primary project management elements are fundamental to a construction project? To obtain a solution to the question, a matrix of research approaches (including frameworks, models and commercial tools) vs. specified functions is built up to illustrate what functions are involved from which different perspectives (Figure 4.2). The matrix serves as a pool for selection of a set of project management functions reflecting the current construction practice. It should be noted that to certain extent, some functions are similar or overlap in content despite of their different names. Integrating Project Management Information with Central Data Model 99 Figure 4.2: Project Management Functions from Different Perspectives Given the matrix described above, guidelines are set up to select project management functions that are primary for most projects. In general, project management should be: \u00E2\u0080\u00A2 Related to the project\u00E2\u0080\u0099s inherent characteristics, such as scope, cost, quality, lifecycle, etc. For example, the project scope must be clarified and controlled to ensure that work performed meets the requirements specified by the project client or owner. It should be noted that time is every project\u00E2\u0080\u0099s important characteristic. A construction project lifecycle usually spans from start-up, planning, design and construction, to close-out. Therefore, project management must be conducted consistently throughout the project lifecycle. \u00E2\u0080\u00A2 Process-oriented. Project management must deal with issues about what has to be done, who is responsible for the work, when it is to be done and how. Also it should specify interdependent relationships among these aspects. \u00E2\u0080\u00A2 Committed to project delivery. This commitment triggers the establishment of relationships among Owner/Customer, Project Manager and Contractor. Integrating Project Management Information with Central Data Model 100 \u00E2\u0080\u00A2 Systematic. Project management functions form a systematic framework, in which elements are interrelated. Requirements of these functions may be updated as the project progresses. Therefore project management must feature its elements\u00E2\u0080\u0099 completeness, interdependency, and dynamism throughout the project\u00E2\u0080\u0099s lifecycle. According to these principles, there are eight primary functions which reflect current construction practice. As displayed in Figure 4.3, these functions include Scope Management, Cost Management, Schedule Management, Resource management, Quality Management, Risk Management, Organization Management, and Information Management. From the number of occurrences shown in cells of Figure 4.2, most of these functions appear to be \u00E2\u0080\u009Ccommon\u00E2\u0080\u009D to the four perspectives addressed above . Figure 4.3: Primary Functions of Project Management Although these identified functions are similar to elements of PMI\u00E2\u0080\u0099s project management framework, we extend PMI\u00E2\u0080\u0099s Human Resource Management to Resource Management, and add Organization Management, which includes project procurement management and management of contractual relationships of stakeholders. Moreover, we exclude PMI\u00E2\u0080\u0099s Integrating Project Management Information with Central Data Model 101 Project Integration Management, because integration is a fundamental requirement for the whole project process. Integration in our research means not only project delivery planning at a high level as depicted in PMI, but also refined harmonization of time segments, work items, information exchange, and systems transaction. 4.2.3 Primary Functions and Fundamental Information This section defines the eight primary functions and specifies fundamental information blocks which serve as input or output for each function. An information block here refers to a collection of information items for a particular purpose. For example, the cost information block may include estimate, unit prices, budget and its allocations, activity duration, cost baseline, etc. to describe Cost Management. Information blocks are identified through a review of literature such as (Sayed, 1995), (PMI, 2008), etc., an investigation of commercial tools described in Section 2.2.3, and the author\u00E2\u0080\u0099s work experience in project management. 4.2.3.1 Scope Management Scope Management should describe what needs to be performed and what requirements should be met, as well as what processes a project may include. Fundamental information includes: \u00E2\u0080\u00A2 Product description \u00E2\u0080\u00A2 Project profile \u00E2\u0080\u00A2 Project development plan (e.g. constructability review) \u00E2\u0080\u00A2 Constraints (description including physical, contractual, resource and information constraints (Dawood & Sriprasert, 2003b) \u00E2\u0080\u00A2 Project requirements (legal, administrative, deadlines, financial, market, etc.) \u00E2\u0080\u00A2 Work breakdown structure \u00E2\u0080\u00A2 Organization \u00E2\u0080\u00A2 Cost (estimates, budgets, etc.) \u00E2\u0080\u00A2 Performance measurement \u00E2\u0080\u00A2 Scope change and change control, and \u00E2\u0080\u00A2 Documentation of scope management (design, as-built drawings, etc.) Integrating Project Management Information with Central Data Model 102 4.2.3.2 Cost Management Cost Management requires determining and estimating resources (including human resource, material, equipment, etc.), allocating the overall estimated cost to activities/tasks, as well as controlling cost changes in order to meet relevant requirements specified in Scope Management. Fundamental information pertaining to Cost Management includes: \u00E2\u0080\u00A2 Activity, product \u00E2\u0080\u00A2 Resource \u00E2\u0080\u00A2 Quality (requirements) \u00E2\u0080\u00A2 Cost (e.g. estimate, unit prices, budget and its allocations, activity duration, cost baseline, etc.) \u00E2\u0080\u00A2 Work breakdown structure or cost breakdown structure \u00E2\u0080\u00A2 Financial information (e.g. payment, cash flow, cash allowances, etc.) \u00E2\u0080\u00A2 Schedule (including time\u00E2\u0080\u0094project lifecycle, etc.) \u00E2\u0080\u00A2 Delivery method \u00E2\u0080\u00A2 Scope (its attributes regarding project and product content and requirements), \u00E2\u0080\u00A2 Risk (its attributes regarding cost estimates and response plan) \u00E2\u0080\u00A2 Bid \u00E2\u0080\u00A2 Cost and change control (e.g. cost variance, forecast analysis, etc.) \u00E2\u0080\u00A2 Performance measurement (e.g. earned value), and \u00E2\u0080\u00A2 Documentation of cost management 4.2.3.3 Schedule Management Schedule Management may be termed Time Management, which emphasizes how to accomplish the project timely. Fundamental information includes: \u00E2\u0080\u00A2 Process and process breakdown structure (task, activity, sequence, duration, etc.) \u00E2\u0080\u00A2 Plan (e.g. critical path, float, task, dependencies, project lifecycle, etc) and schedule change control (e.g. time variance, percentage complete) \u00E2\u0080\u00A2 Work breakdown structure \u00E2\u0080\u00A2 Scope (its attributes regarding project and product content, requirements, etc.) \u00E2\u0080\u00A2 Constraints (e.g. milestones) Integrating Project Management Information with Central Data Model 103 \u00E2\u0080\u00A2 Resource \u00E2\u0080\u00A2 Calendar \u00E2\u0080\u00A2 Coding system \u00E2\u0080\u00A2 Representation (e.g. bar charts) \u00E2\u0080\u00A2 Performance measurement, and \u00E2\u0080\u00A2 Documentation of time management 4.2.3.4 Resource Management Resource Management involves resource procurement, utilization, book keeping, and human resource management. It mainly requires identifying, acquiring and determining both human resources and other resources, organizing a work team, assigning roles to processes, and reporting performance or usage. Fundamental information includes: \u00E2\u0080\u00A2 Team (e.g. stakeholders in various disciplines, roles, project manager, etc.) \u00E2\u0080\u00A2 Material \u00E2\u0080\u00A2 Equipment \u00E2\u0080\u00A2 Resource procurement schedule (tracking, bookkeeping, project lifecycle, etc.) \u00E2\u0080\u00A2 Process \u00E2\u0080\u00A2 Work breakdown structure \u00E2\u0080\u00A2 Organization \u00E2\u0080\u00A2 Financial (payment, funding, etc.) \u00E2\u0080\u00A2 Performance measurement, and \u00E2\u0080\u00A2 Documentation of resource management 4.2.3.5 Quality Management Quality Management is a distinct management framework/system to ensure that a project will meet its specified requirements. It consists of a set of processes which may go through all other management functions. Fundamental information includes: \u00E2\u0080\u00A2 Quality plan \u00E2\u0080\u00A2 Quality assurance Integrating Project Management Information with Central Data Model 104 \u00E2\u0080\u00A2 Quality control (sampling, causes, tolerance, prevention, inspection, testing, improvement results, etc.) and quality control measurements \u00E2\u0080\u00A2 Process and Schedule (including time\u00E2\u0080\u0094project lifecycle) \u00E2\u0080\u00A2 Work breakdown structure \u00E2\u0080\u00A2 Scope (of project) \u00E2\u0080\u00A2 Cost (of quality) \u00E2\u0080\u00A2 Organization and human resource (roles and responsibilities) \u00E2\u0080\u00A2 Requirement, standards and regulations (e.g. acceptance, checklist, prequalification), and \u00E2\u0080\u00A2 Documentation of Quality Management 4.2.3.6 Risk Management Risk here refers to possibility of loss, and uncertainty of hazard occurrence. Risk Management is to identify, analyze, and respond to project risk in order to minimize adverse consequences to the project. Fundamental information pertaining to Risk Management includes: \u00E2\u0080\u00A2 Product and quality (requirements, standards, etc.) \u00E2\u0080\u00A2 Schedule (processes, project lifecycle, etc.) \u00E2\u0080\u00A2 Organization and human resource (e.g. roles and responsibilities) \u00E2\u0080\u00A2 Project development plan, risk management plan \u00E2\u0080\u00A2 Scope and change \u00E2\u0080\u00A2 Work breakdown structure \u00E2\u0080\u00A2 Risk identification, categorization (probability and uncertainty, etc.), and ranking \u00E2\u0080\u00A2 Risk response (avoidance, transference, mitigation, acceptance, etc.) \u00E2\u0080\u00A2 Risk monitoring and control (response audit, review, earned value analysis, technical performance measurement, corrective action, change request, planning, etc.) (PMI, 2008) \u00E2\u0080\u00A2 Risk Tolerance \u00E2\u0080\u00A2 Budget for risk control, and \u00E2\u0080\u00A2 Documentation of Risk Management Integrating Project Management Information with Central Data Model 105 4.2.3.7 Organization Management Organization Management mainly deals with work acquisition and assignment, construction team establishment, and management of communication among different disciplinary parties. Fundamental information includes: \u00E2\u0080\u00A2 Human resource (roles and responsibilities, etc.) \u00E2\u0080\u00A2 Project and product description (scope, etc.) and constraints (e.g. funds availability, insurance, etc.) \u00E2\u0080\u00A2 Work team \u00E2\u0080\u00A2 Organization architecture \u00E2\u0080\u00A2 Work breakdown structure \u00E2\u0080\u00A2 Project delivery methods \u00E2\u0080\u00A2 Solicitation and procurement planning (product requirements, quotation, bid, offer, proposal, potential sources, evaluation, etc.) \u00E2\u0080\u00A2 Contract, contract change and control (e.g. negotiation, quality control, etc.) \u00E2\u0080\u00A2 Financial (e.g. payment), and \u00E2\u0080\u00A2 Documentation of Organization Management 4.2.3.8 Information Management Information Management describes how project information is generated, collected or disseminated, reviewed and approved, distributed or stored, and finally disposed of. It supports human understanding of a project, work results documentation, communication and work coordination. Fundamental information includes: \u00E2\u0080\u00A2 Document and presentation formats \u00E2\u0080\u00A2 Information exchange standards \u00E2\u0080\u00A2 Information flow \u00E2\u0080\u00A2 Organization (contractual constraints, contract conditions, e.g.) and human resource (roles and responsibilities, etc.) \u00E2\u0080\u00A2 Schedule (project lifecycle, project closure, etc.) \u00E2\u0080\u00A2 Scope of product and project \u00E2\u0080\u00A2 Meta-data Integrating Project Management Information with Central Data Model 106 \u00E2\u0080\u00A2 Work results or deliverables \u00E2\u0080\u00A2 Site meeting and reporting \u00E2\u0080\u00A2 Information management system or tool, and \u00E2\u0080\u00A2 Documentation of information management (e.g. information management plan) The information identified above basically reflects inherent quality, content, reference, and other characteristics of each function. These information blocks provide prerequisite resources for development of UCPMA\u00E2\u0080\u0099s Central Data Model. Comparing these functions and their information blocks with each other, we find that to some extent information in one block may overlap with another one; moreover, many blocks are \u00E2\u0080\u009Credundant\u00E2\u0080\u009D across several functions. For example, information blocks of scope, lifecycle (time), and work breakdown structure also appear in Cost Management, Schedule Management, Quality Management and Resource Management. Such information redundancy results from discrete representation of project management elements, but requires research attention since functions usually intersect through redundant information which may determine information items\u00E2\u0080\u0099 interdependency. The following sections address the modeling of identified project management functions, representing their information interdependencies, and integrating them into a data model central to all applications. 4.3 Central Data Model This section mainly focuses on presenting the Central Data Model at a high level of abstraction, first displaying data models for identified primary functions, and then combining these models into a central model. Development of the model does not start from scratch, but is based on IFC data standards. Functional data models are derived from the IFC model, but extend the IFCs by adding new classes as required. In this research, newly added classes and their attributes are addressed conceptually; detail definition and testing are left for future research. Integrating Project Management Information with Central Data Model 107 4.3.1 Modeling Scope and Developing Methodology The Central Data Model for UCPMA represents fundamental project management data such as cost, schedule, product, etc. It is intended to structure information blocks central to the eight functions described in Section 4.2.3. These information blocks include physical product information such as building elements (door, column, roof, slab, etc.), and non- product information such as process, cost, risk, etc. However, the model does not represent details of all project information (e.g. attributes of a class); rather, it displays fundamental information for primary project management functions at a higher level of abstraction. It allows extension as IFC does. Model extensibility and detailed-leveled design are not the main focus of this research. Development of the model proceeds as follows. First, there is analysis of functional requirements regarding what to do and how to do it; identification of inputs, outputs, constraints, methods used, and services that each function provides. This step resembles the IDEF0 modeling method in analyzing functional requirements. Second, there is analysis of information about the requirements mentioned above. Information can be conceptualized and structured from functional requirements and project management documents. Sayed (1995) provided good references about such documents. Third, there is an exploration of the IFC model in order to find classes that can capture required fundamental information and to associate identified classes into a functional data model. If such an appropriate class is unavailable, then use the UML approach (Rumbaugh, 1999) to define a new class(es). Lastly, there is a combination of all functional data models into the Central Data Model. In the following subsections, functional data models are represented and described one by one. Yet, details on how these data models are developed step by step are not described here; readers can refer to (Rumbaugh, 1999). In these models, quite a few classes adopted directly from the IFCs 2X Edition 3 (IAI, 2007) are briefly described; other classes which the IFCs do not explicitly define are elaborated in detail (Appendix B displays some attributes of classes for common data model aspects / data views). All data model diagrams are displayed in Microsoft Visio UML notation. The shapes drawn with dashed lines represent example Integrating Project Management Information with Central Data Model 108 instances which could be used to describe detailed information used in the primary functions of PM. 4.3.2 Scope Management Data Model Figure 4.4 shows a conceptual data model schema representing scope management. Classes for capturing information as specified in Section 4.2.3.1 include IfcOrganization, IfcDocumentInformation, IfcCondition, IfcConstraint, IfcProject, IfcProduct, IfcProjectOrder, IfcWorkPlan, IfcWorkSchedule, IfcProcess, IfcTask, IfcClassification, Phase, PerformanceMetric, IfcConstructionZoneAggregationProduct and Specification. Among these IFC classes, IfcWorkPlan and IfcWorkSchedule inherited from IfcWorkControl, which is a subtype of IfcControl. An IfcWorkPlan class usually contains a set of work schedules in an IfcWorkSchedule. An IfcWorkSchedule class includes a set of work processes represented in an IfcProcess class; each IfcProcess may consist of several tasks in an IfcTask class. IfcProject can be linked to documents referenced with IfcDocumentInformation, which captures the metadata of an external document. Each project has a set of constraints as construction requirements, which are represented in an IfcConstraint class. IfcClassification may capture information on a work breakdown structure, by which project work is broken down into work packages assigned to different stakeholders. Each product has a status or condition at a specific time, whose information is captured with IfcCondition. An IfcProject class may have many project orders represented in an IfcProjectOrder class. The IfcConstructionZoneAggregationProduct class is associated with the IfcProduct class, representing a construction zone or a construction aggregation area. Here, it adopts a component relative system for cost estimating or scheduling. Taking a building product as an example, it may include zones / areas such as substructure, superstructure, wall, etc. New classes added to capture information that the current IFC model does not cover are as follows. Integrating Project Management Information with Central Data Model 109 4.3.2.1 Specification The Specification class captures construction information on a product or its components. It is associated with the Product class. Attributes of the Specification class may include subject, category, material requirements, work quality, and other specific fundamental requirements. For example, under the cementitious grout specification subject, there are attributes of type of grout, selection of grout, materials (requirements of water, sand, stone, etc.), work quality, forming, mixing, temperature, placing, finishing, and curing. Specifications can be categorized into different groups according to the variety of trades involved. We suggest three levels of hierarchical structure for categorizing specifications. The first level corresponds to the project system level; the second is similar to MasterFormat, which has basic divisions of Concrete, Masonry, Metals, Wood and Plastics, Thermal and Moisture, Finishes, Specialties, Equipment, Special Construction, Conveying System, Mechanical, and Electrical. At the third level, each category can be broken down into sub- categories as required. For example, the Concrete category can be further separated into grout, forming, and reinforced steel groups. Integrating Project Management Information with Central Data Model 110 Figure 4.4: Scope Management Data Model 4.3.2.2 Phase In the IFC model, Phase is one of the IfcProject attributes and has a data type of IfcString; it does not effectively support a breakdown structure. Here, Phase is defined as a separate class for abstracting information about particular stages of a project or a process. A phase may consist of many stages. For example, a construction project may be divided into Planning, Design, Pre-Construction, Construction and Close-Out phases. Each phase, at which a significant portion of the project has been achieved, can be further broken into sub- phases as needed. A high-level work breakdown structure often corresponds to this level of project phases. In practice, work is performed continuously, or is paralleled in many phases for fast-tracking delivery; therefore, the Phase class can also be associated with the Process class, directly used to develop the work breakdown structure. Integrating Project Management Information with Central Data Model 111 4.3.2.3 PerformanceMetric A PerformanceMetric class abstracts more information about measurement of project performance or achievement than an IfcMetric class which is a subtype of an IfcConstraint class. At a high level of abstraction, this research identifies its attributes including Management Level (e.g. top management level, project level, construction level, etc.), Date, Role (or its Group for different trades), Indices to TimeIndicator, CostIndicator, QualityIndicator, SafetyIndicator and EnvironmentIndicator. Figure 4.5: Project Management Performance Assessment Matrix and Example Data Through literature investigation (DETR, 2000) (Cox et al., 2003) (Cheung et al., 2004), five categories of key performance indicators (KPI, defined in Cox et al., 2003) are regarded as Integrating Project Management Information with Central Data Model 112 being important for representing project or process performance. As shown in Figure 4.5, these five categories are Cost, Time, Quality, Safety and Environment. Detailed indicators falling into each category are listed in a matrix for performance assessment. The matrix consists of three dimensions: time in months, trade and performance indicator categories. Values in the matrix are for illustration only. For example, the actual total monthly cost is one of the Cost performance indicators. In January and February, 2005, the foundation subcontractor cost $3453 and $2321 respectively, which indicated measurement of the subcontractor\u00E2\u0080\u0099s performance or work achievement in these two months. Corresponding to the five categories, five indicator classes are identified as subclasses of the Performance class. As an example, QualityIndicator is addressed in Section 4.3.6. This research does not cover details of other indicators. 4.3.3 Cost Management Data Model Classes that capture information about cost management include IfcWorkSchedule, IfcWorkPlan, IfcProcess, IfcDocumentInformation, IfcProduct, IfcProjectOrder, IfcResource, IfcConstructionResource, IfcCostSchedule, IfcCostItem, and IfcCostValue, as shown in Figure 4.6. IfcControl is the generalization of all controls, including IfcCostSchedule, IfcWorkPlan, etc. A cost schedule is composed of a collection of cost items with each cost item having a cost value. IfcWorkSchedule is associated with IfcCostSchedule. A project process or related order uses resources represented in IfcResource; IfcConstructionResource is a subclass of IfcResource. A collection of processes form a work schedule and its documents are linked to a process. A process may work on a physical product. A project order, e.g. a change order issued on the construction site, may also need to be scheduled and estimated. In some research, a work cost is directly linked to a product, but we think that it makes cost information meaningful only by linking a cost item to a process or a task since a cost value usually depends upon human resource rates, which are influenced by the construction method applied in the process. Integrating Project Management Information with Central Data Model 113 Figure 4.6: Cost Management Data Model 4.3.4 Schedule Management Data Model Classes capturing information about Schedule Management include IfcCostItem, IfcCostSchedule, IfcProcess, IfcWorkschedule, IfcWorkControl, IfcWorkPlan, IfcDocumentInformation, IfcProjectOrder, IfcDateAndTime, IfcResource, IfcProduct, IfcElement and IfcElementComponent, IfcConstructionZoneAggregationProduct, IfcOrganization and IfcConstraint, which have been introduced previously. Classes newly defined or identified from the IFCs include IfcActor, IfcPerson, IfcActorRole, Event, and Transition, as shown in Figure 4.7. IfcActor is associated with IfcProcess in order to indicate responsibilities of persons or organizations involved in a particular process. During construction, each laborer or subcontractor (represented in IfcLaborResource) assigned to a process can be displayed by an IfcActor object. IfcLaborResource emphasizes labor\u00E2\u0080\u0099s skills or crafts and is used to calculate labor usage, while IfcActor emphasizes the distinct role and responsibilities Integrating Project Management Information with Central Data Model 114 assumed by an actor. An actor has a specific role represented in the IfcActorRole class. Persons affected, defined in IfcPerson, belong to a particular organization represented in IfcOrganization. Figure 4.7: Schedule Management Data Model Processes and tasks can be allocated by days represented in IfcDateAndTime. A process may be related to another process as a predecessor. IfcConstraint can be associated with IfcProject, IfcProcess or other classes to set a constraint or scope boundary. An event may trigger a process or task transition; transition information can be used in representing a workflow (document review, change order process, etc.) to specify specific connections between tasks. IfcProcess is associated with IfcProduct to display what process is performed Integrating Project Management Information with Central Data Model 115 where. A product is composed of a collection of elements, each of which may consist of a list of components (represented in IfcElement and IfcElementComponent respectively). A product may be a building, bridge, or a section of highway, or a product\u00E2\u0080\u0099s elements and components; IfcProduct is a generalized abstract class. In addition, two new classes are defined to support Schedule Management representation. 4.3.4.1 Event An event is a significant occurrence or happening that may trigger task transition and invoke task response. It occurs at a specific moment, rather than over a period of time, and is regarded as a functional observation. For example, when submittals are returned with the \u00E2\u0080\u009Crejected\u00E2\u0080\u009D status, the originator may request discussion of the evaluation. At that point, the event \u00E2\u0080\u009CRequest Meeting for Discussion\u00E2\u0080\u009D triggers tasks of setting meeting agenda, arranging meeting, etc. The Event class is associated with the IfcProcess class and also with the Transition class; it is considered as an independent class for workflow design (e.g. identifying iteration with the Transition class). Its attributes include, but are not limited to, event description, event initiator, event purpose, date and time, approach to the purpose, tool used, occurring frequency, etc. 4.3.4.2 Transition Transition describes navigations between different tasks or decompositions of one task into others (VEGA, 1997). Tasks are connected with each other by transitions of two types: sequential transitions which specify continuing navigation from one task to another and, parallel transitions including And Split, Or Split, Or Joint, And Joint, and Iteration, which support synchronized tasks or unsynchronized tasks, and loops of tasks. Here, transition is modeled as a separated \u00E2\u0080\u009Ctask\u00E2\u0080\u009D to facilitate workflow flexibility in handling exceptional cases and to support task cooperation in different scenarios. Processes, such as document review, change order process, submittal process, etc., can be defined as workflows; a work flow is a special process. Integrating Project Management Information with Central Data Model 116 Its attributes include transition type, description, the start-transiting task (s), the end- transiting task(s), and transition condition. 4.3.5 Resource Management Data Model Classes borrowed from the IFCs for Resource Management include IfcCostItem, IfcCostSchedule, IfcWorkSchedule, IfcActorRole, IfcActor, IfcOrganization, IfcProcess, IfcProjectOrder, IfcProduct, IfcDocumentInformation, IfcInventory, IfcResource and its subtype IfcConstructionResource which generalizes information on all construction resources utilized such as subcontractor, material, equipment, labor and product (e.g. formwork) (see figure 4.8). Figure 4.8: Resource Management Data Model A process consumes resources and its cost should be estimated. IfcResource is associated with IfcInventory for the purpose of the procurement process, since material or equipment procurement schedules are mainly determined by the construction schedule, and an Integrating Project Management Information with Central Data Model 117 inappropriate purchase process may have significant impact on the construction schedule. For resource procurement, quantity-related attributes including volume of the remaining, location of placement, a list of purchase records (including information on the date, the supplier, examining documents or reference, price, and batch purchasing quantity), a list of usage (including information on user, quantity, and the date), etc., should also be represented in IfcInventory or IfcResource. IfcResource is referenced to IfcDocumentInformation, which may refer to a material specification, for example. 4.3.6 Quality Management Data Model To represent Quality Management, several IFC classes are utilized as elements of the data model. They include IfcWorkPlan, IfcWorkSchedule, IfcCostSchedule, IfcCostItem, IfcProcess, IfcProduct, IfcElement, IfcActor, and IfcDocumentInformation, as shown in Figure 4.9. A project needs a quality management system to assure its construction quality. The QualityControl class associated with IfcWorkSchedule may contain a list of activities for quality control. Similar to the construction schedule, a quality control schedule must identify the parties responsible for a particular quality control process. IfcProcess is linked to IfcProduct, as described previously. Fulfilling a quality control plan involves a cost of labor, materials, and equipment, which are represented in IfcCostSchedule and IfcCostItem. Besides existing IFC classes, three new classes are defined to capture quality control information: QualityIndicator, QualityControl, and QualityComplianceNotice. Quality control results in a Quality Compliance Notice; QualityControl contains quality indicators measuring the quality of a whole construction project or of each process. Information for class attributes is referenced to (PMI, 2008) (ASCE, 1997). Integrating Project Management Information with Central Data Model 118 Figure 4.9: Quality Management Data Model 4.3.6.1 QualityControl The QualityControl class captures information pertaining to a quality control plan, which focuses on what to control, what methods are to be used, and when and in what frequency the activity is to be carried out. Attributes of the class include, but not limited to: \u00E2\u0080\u00A2 Item: abstracts information on work items to be controlled. In this research, we suggest that control items should be associated with activities in the Process class in order to assure that each construction activity is under control. \u00E2\u0080\u00A2 Method: captures information on methods used to verify whether work meets requirements or not. Quality control can be structured in three levels. The first is the Integrating Project Management Information with Central Data Model 119 administrative or planning level, at which the work scope is specified and the inspection and test plan is implemented. The second is the site engineering level, at which procurement needs to be dealt with for more detailed work control. The third level describes work instructions directing detailed activities. \u00E2\u0080\u00A2 Date: indicates when to carry out work control \u00E2\u0080\u00A2 Frequency: refers to number of times to perform a control activity \u00E2\u0080\u00A2 Criteria: is acceptance standards for quality-controlled construction work \u00E2\u0080\u00A2 Responsible position: describes who is responsible for or performs a quality control activity \u00E2\u0080\u00A2 Reference: means documents referenced to control activities. A control activity can be indexed to a section of documented specification in drawings, or to standards (building codes, e.g.). 4.3.6.2 QualityComplianceNotice QualityComplianceNotice captures and structures information describing results of quality control activities. In practice, the contractor usually uses a variety of means to achieve required project quality, while the owner leverages quality assurance to monitor how quality is controlled by the contractor (Mincks et al., 1998). Quality compliance notices record those quality assurance activities, issues found (if any), action taken to prevent construction unconformity with standards or specifications, as well as issue improvement. Its attributes include: Quality Control Activity, Project ID and Location, Category of Quality Control outcome (e.g. non-compliance, work rejection, etc.), Notice Description, Actor Responsible for Inspection or Testing, Time and Cost Occurred to Close out the Issue, Reference to the quality compliance notice (e.g. Stop Work, Correction Notice, etc.). 4.3.6.3 QualityIndicator QualityIndicator class captures information on quality measures of project performance. Attributes include: number of inspections, number of received non-compliance records, number of rectified non-compliance records, work rejection due to lateness or workmanship, Integrating Project Management Information with Central Data Model 120 survey rejection due to lateness or workmanship, cost incurred for repairing work, and time incurred for repairing work, as illustrated in Figure 4.5. 4.3.7 Risk Management Data Model As shown in Figure 4.10, classes including Event, PerformanceMetric, IfcProjectOrder, IfcWorkSchedule, IfcWorkPlan, IfcCostSchedule, IfcCostItem, IfcProcess, IfcTask, IfcProduct, IfcActor, IfcActorRole, and IfcDocumentInformation for Risk Management have been introduced in previous sections. Classes that need to be added in the model include RiskResponse, Risk and RiskTrigger; information for their attributions is referenced to (PMI, 2008). Figure 4.10: Risk Management Data Model A risk is an uncertain event, usually warned or triggered by a causal event represented in RiskTrigger. RiskResponse contains orders or plans corresponding to each identified risk. Risk management requires determination of a risk response plan, persons involved, Integrating Project Management Information with Central Data Model 121 responsibilities, and budget to actions against risks. These information elements are represented in IfcProcess, IfcActor, IfcActorRole, IfcCostSchedule and IfcCostItem respectively. 4.3.7.1 Risk The Risk class captures information about an identified risk. Its attributes include, but not limited to, risk description, probability, qualitative impact rating, sequences, risk owner, risk category (technical risk, project management risk, organization risk, external risk, etc.), risk threshold, as well as attributes inherited from the Event class. 4.3.7.2 RiskTrigger RiskTrigger is an inheritance of the Event class described in Section 4.3.4.1, exclusively designed for capturing information about risk causes. Risk causes can be classified by a matrix of project phase (concept development, planning, design, operation and control) by disciplines (client, contractor, design, external administrative, and others such as force majeure). \u0001\u0001 4.3.7.3 RiskResponse RiskResponse is inherited from IfcProjectOrder. Attributes include risk response strategy (e.g. avoidance, transference, mitigation, acceptance, etc.), reporting format, budget and time constraints for response, contingency reserve amounts needed and changes (if applicable). 4.3.8 Organization Management Data Model Classes identified for Organization Management include IfcOrganization, IfcPerson, IfcDocumentInformation, IfcActor, IfcActorRole, Meeting, Event, IfcGroup, Responsibility, IfcProcess, IfcProject, ProcurementProcess, Trade and CommunicationChannel (see Figure 4.11). Integrating Project Management Information with Central Data Model 122 An actor may be a person or an organization. More than one role could be assigned to one person or organization. An event may invoke a meeting taken by actors. Meetings are repetitive and common processes in construction project management. A meeting usually deals with and generates many documents. Actor roles can be categorized into groups such as project management, construction, design, etc.; each group may have sub-groups which are often designed according to the disciplines involved. An actor role includes detailed responsibilities, which can be linked to a particular task(s). ProcurementProcess is a subclass inherited from IfcProcess; it involves many trades such as demolition, general excavation, drywall, roofing, etc. Figure 4.11: Organization Management Data Model New classes describing information for Organization Management are defined as follows. Integrating Project Management Information with Central Data Model 123 4.3.8.1 CommunicationChannel In a project delivery system, communication channels are often established between different management levels and documented in a contract. CommunicationChannel captures formal information on communication pathways for different roles needing to change or transmit project information throughout the whole project process. Its attributes include role IDs or names, communication mode, communication scope type, and navigation ability (PMI, 2008) (Mincks et al., 1998). Figure 4.12: Communication in the CM Delivery System Figure 4.12 shows an example of communication in the Construction Management (CM) delivery system. Communication mode includes directional and non-directional. Directional communication is bound to contracts or contractual agreements and usually conveys information in writing. Formal clarifications, changes and directions should be transferred in this mode. Non-directional communication refers to non-contract related communication. It could be verbal or written. Communication scope includes external and internal types. By the external type, information is transferred through different groups; while by the internal type, information flows within the same group or organization. Integrating Project Management Information with Central Data Model 124 4.3.8.2 Meeting The Meeting class abstracts information on all gatherings of people for project purposes. Meeting usually has attributes of: \u00E2\u0080\u00A2 Subject: is a meeting\u00E2\u0080\u0099s title \u00E2\u0080\u00A2 Location: indicates where the meeting is held \u00E2\u0080\u00A2 Attendee: indicates a list of actors attending the meeting \u00E2\u0080\u00A2 Issues: lists topics discussed including their description, status, due or responsibility \u00E2\u0080\u00A2 Notes: addresses attendee\u00E2\u0080\u0099s opinions or decisions \u00E2\u0080\u00A2 Time: includes the start and finish time \u00E2\u0080\u00A2 Reference: lists documents or media generated or referenced, e.g. the meeting agenda, the meeting minutes, etc. 4.3.8.3 Responsibility The Responsibility class abstracts information on a role\u00E2\u0080\u0099s duty throughout the project lifecycle. It indicates what work should be done to meet specific requirements. Its attributes may include role ID or responsibility title, duty, condition of duty, reference to a document or a document\u00E2\u0080\u0099s section, description and time or phase. Major responsibilities for basic roles can be found in the construction contract or contractual agreements. For example, clause 2.2.1 of (CCDC-2, 1994) describes consultant\u00E2\u0080\u0099s responsibilities as follows: \u00E2\u0080\u00A2 The consultant will provide administration of the contract, as described in the Contract Documents during construction \u00E2\u0080\u00A6 \u00E2\u0080\u00A2 The consultant will visit the Place of the Work at intervals\u00E2\u0080\u00A6 and to determine if the work is proceeding in the general conformity with the Contract Documents. Each instance of the Responsibility class can be associated with one or more tasks so that it is easy to assess whether a role should be responsible for a particular task, or whether a responsibility duty is fulfilled with respect to related tasks. This functionality will provide great potential for effective claim treatment if an argument arises. In this way the classes Integrating Project Management Information with Central Data Model 125 Role, Responsibility and Task form a layered structure of actors\u00E2\u0080\u0099 actions. To implement this functionality, project tasks must be defined to a low level of detail, for example, to the individual activity level. 4.3.8.4 ProcurementProcess ProcurementProcess is a subclass inherited from IfcProcess, exclusively defined for procurement processes such as bidding processes, material procurement process, etc. Similar to a change order process, a procurement process can be defined as a workflow process for its repeatability and complexity when routines are looped, forked or joined. 4.3.8.5 Trade The Trade class abstracts information describing trades involved in a project. Trade information is usually applied in high level management and accounting systems for payment. Its attributes include trade name, description, contract number, budget, work deadline, requirements, organization that undertakes a particular work, etc. 4.3.9 Information Management Data Model Information Management involves document reference and representation, as well as document process encompassing creation, review, approval, use, archive and disposal. Identified classes include IfcDocumentInformation, IfcDocumentReference, IfcProject, IfcProcess, IfcActor, IfcOrganization and DocumentReviewProcess, as shown in Figure 4.13. A document is usually created and edited with software applications (as external systems), e.g. AutoCAD for drawings, Microsoft Word for word files, etc. Representing external systems in detail does not belong to the model\u00E2\u0080\u0099s scope. Documents are managed according to the \u00E2\u0080\u009CMetadata\u00E2\u0080\u009D technology, and IfcDocumentInformation describes document metadata information. IFC does not define document contents; external documents are referred through IfcDocumentReference to their locations. In addition, a document may be related to a particular project, process or organization. Information about the document review process is represented in DocumentReviewProcess which is a subclass inherited from IfcProcess and can be defined as a workflow process. Integrating Project Management Information with Central Data Model 126 Figure 4.13: Information Management Data Model 4.3.10 Central Data Model The Central Data Model is developed by associating all the identified functional domain data models together. In the model diagram in simplified UML notation shown in Figure 4.14, IfcDocumentInformation captures documents\u00E2\u0080\u0099 metadata. It is alternatively replaced with IfcDocumentReference which is a reference to the location of a document. Like the IFCs, the Central Data Model does not define document contents. Moreover, IfcDocumentInformation may be associated with IfcProject, IfcOrganization, IfcProcess, IfcProject, or Event, although their relationships are not denoted in the schema for conciseness of the diagram. Likewise, the model does not show classes such as IfcConstructionEquipment, IfcLaborResource, IfcSubContractResource, and IfcConstructionMaterial, which contain information on different construction resources, IfcTask (a subclass of IfcProcess) and IfcWorkControl (consisting of instances of IfcWorkPlan). Figure 4.15 tabulates adopted IFC classes and proposed new classes for the Central Data Model. In general, the integrated model represents functional information involved in primary project management functions, as well as information interrelationships at a high level of Integrating Project Management Information with Central Data Model 127 abstraction. Take the \u00E2\u0080\u009CSinkhole Earthwork\u00E2\u0080\u009D change order process described in Appendix A as an example. Information items involved in the process include: persons to deal with the process, real time spanning the process, documents generated and referenced, cost and resources for the extra work, procedure to go through the process, etc. The change order process data model (see Figure A.9) captures these information items in classes of Actor, Project, Process, Task, Activity, Document, Resource, and Organization. Examination of Figure 4.14 finds that except for Task, Activity and Workflow, the Central Data Model encompasses most of these classes representing the change order process; moreover, the two models share the same links that associate these classes together. As for the three classes, Activity is a subclass of Task, and Task is a subclass of IfcProcess; they are omitted in order to make the figure clearer. In addition, Workflow, a specific IfcProcess class, is separately defined in order to distinguish some iterative processes (change order process, document review, etc.) from one-time processes (e.g. building a column). Therefore, the central domain data model represents information on the change order process; or, in another words, the change order process data model is a part of the Central Data Model. Yet the integrated model still requires extensions in scope and depth in order to thoroughly integrate project management in the AEC/FM domain. For example, more efforts need to be put into structuring information blocks of Risk Management and Quality Management and representing them in the IFC model. Although Risk Management and Quality Management often adopt systems separate from those of Cost Management, Resource Management, etc., in fact, information involved in Risk Management and Quality Management is interrelated with that of other functions. Integrating Project Management Information with Central Data Model 128 Figure 4.14: Central Data Model for Integrated Project Management Integrating Project Management Information with Central Data Model 129 Figure 4.15: Classes of the Central Data Model 4.4 Information Interoperability Issues The Central Data Model structures project management information and is described in a modeling language with semantic symbols. In the real world, data typically comes from IT application areas of drawing, scheduling, estimating and cost control, and document management. This data is represented in Microsoft Visio UML notations (as shown in Figure 4.14) in the model. On the other hand, such applications mentioned above require integrated models in support of \u00E2\u0080\u009Cincremental updates, change management, access and update management services\u00E2\u0080\u009D (Eastman, 1999). Thus, interaction between the Central Data Model and these applications (actually their data models) calls for integrated data exchange between applications or information interoperability. Integrating Project Management Information with Central Data Model 130 The following subsections briefly review the fundamental information available from typical applications. Then, based upon work done by other researchers (Eastman, 1999) (Yu, 2002), information exchange architectures and data mapping mechanisms are discussed, and a solution to keep information consistency during exchange is proposed. Initially, the UCPMA was envisioned to have the merit of information interoperability, yet discussions and proposals below are conceptual and serve as a reference for future research relevant to this aspect. 4.4.1 Data from Applications In practice, data in the Central Domain Data Model comes mainly from the application areas of drawing, scheduling, estimating and cost control, and document management. Typical software tools for drawing include AutoCAD, ArchiCAD, MicroStation, etc. Fundamental information items provided by these tools are mainly related to Product attributes including, for example, product element, coordinate location, material type, dimensional parameters, etc. At present, almost all major CAD vendors support saving data in an IFC-formatted file which can be read by IFC-compatible tools. Programs for scheduling typically include Microsoft Project and Primavera P3e/c (Primavera, 2004). Data models of these two applications center on the Task and Resource classes. Information items include task and resource attributes, such as duration, work hours, start date, finish data, precedence logic, hierarchical breakdown structure, resource type, rate, etc. Communication with Microsoft Project can use the Microsoft .Com technology, but it adopts a data model different from the developed central data model. Timberline Precision is a typical tool for cost estimating and control, and centers on the Cost class. Information items include attributes of cost item, material, unit price, item quantity, work package, crew, total amount, various factors, etc. An effort at information interoperability was the development of Timberline PECAD which brings ArchiCAD data Integrating Project Management Information with Central Data Model 131 for bidding and construction management. Also, Timberline Schedule Integrator was developed to read schedule data from applications such as Microsoft Project. Document management tools, which may be windows-based or web-based, typically track processes of change orders, bidding, submittal, contract maintenance, work control, quality control, risk management, and document treatment. Information items include attributes such as project participants, work package items, project documents, date, revision, approval, etc. (Sayed, 1995). Data models of these tools usually consider a document as a black box in which document contents and references are inaccessible. Treatment of documents is therefore usually implemented through managing document \u00E2\u0080\u009Cmetadata.\u00E2\u0080\u009D Currently document management tools are independent of other tools (e.g. Microsoft Project), few of which are cross-referenced to a document management system. 4.4.2 Information Exchange Architectures In general, there are two types of information exchange between domain applications. One is batch data exchange (or file-based data exchange); the other is repository data exchange (or model-based data exchange). Figure 4.16: Batch/File-based Data Exchange Architecture The batch/file-based approach is one-to-one information exchange (Figure 4.16). One application outputs a set of data, which is usually a collection of objects stored in a file; the other one reads the dataset file, translates the dataset through appropriate data mapping specifications, and then picks up related information for instancing a class in its data model. Integrating Project Management Information with Central Data Model 132 Data in the file may be organized and represented in data model standards, e.g. IFC\u00E2\u0080\u0099s. This approach is relatively straightforward and easy to implement (Yu, 2002). However, it is difficult to keep information updated throughout the project lifecycle. Moreover, the receiver (application) has no means to select what it really wants (perhaps a portion of the dataset). If information flow in this data exchange type is made bidirectional, another challenge of maintaining data consistency among more than three applications arises simultaneously. The model-based/repository approach exchanges data through a central model (Figure 4.17), as applied in this research. Each domain data model contributes to the central data model and also obtains required datasets from it. Data mappings bridge domain data models and the central data model. The central data model can be physically stored in one repository or in several distributed stores. Each object in the model may have a global ID. Applications access data in the model through interfaces which may be designed in advance, or created at run-time. Structuring the data model in a standard format, e.g. IFC, provides powerful support for information integration. One significant benefit is that changes in one domain model only need to be propagated to the central model; the latter then notifies the updates in other related domain models. In this way, maintenance of data mapping from the central data model to domain models is easier than in the batch/file-based approach; it also facilitates monitoring data consistency among those models. This approach is suited for large, complex projects, but for multi-applications usage, it needs implementation techniques to keep data from concurrent conflicts. Moreover, a large central data model faces the challenge of keeping data exploration efficient. Much effort has been devoted to these problems. Section 4.4.4 in this research proposes a simple and practical approach for implementation. Integrating Project Management Information with Central Data Model 133 Figure 4.17: Model-Based/Repository Data Exchange Architecture 4.4.3 Data Mapping Both types of data exchange described above involve data mapping between data models. Data mapping here means establishing correspondence between data models so that information elements in one format can be associated with elements in the other format. Yu (2002) described a data representation scheme, shown in Figure 4.18. Data generated or used in an application is conceptually defined in a data model, which is represented in a particular model language. Physically, data is stored in a Physical Data Format (PDF), which is specified by a particular physical data language (e.g. XML). According to this scheme, data mapping essentially associates data in one PDF with another. Corresponding to such a data mapping mode, there are three common scenarios. One is that two sets of data from the same data model are represented in different model languages and in different physical data format languages; another is that two data sets from different data models are described in different modeling languages yet in the same physical data format language; the Integrating Project Management Information with Central Data Model 134 third is that two sets of data from different data models are represented in the same modeling language and the same physical data format language (Yu, 2002). Figure 4.18: Application Data Scheme (Yu, 2002) According to three data mapping scenarios, an ideal solution is to adopt an industrial standard. The standard may be a data model which is central to most fundamental purposes so that it can comprehensively capture project management information. The standard should be represented in a widely accepted data modeling language; information from applications which adopt the standard should be saved in a standardized physical data format. With such an ideal solution, data mapping would not become an issue. However, for many reasons (e.g. technical, industrial practice, etc.), there is a very long way to go to reach this objective. 4.4.4 Information Consistency This research mainly concerns the model-based or repository information exchange. Take model #A in Figure 4.16, for example. Information elements a1, a2, and a3 are initiated in model #A, and all exist in the central data model. Model #B uses elements a2 and a3; model #C uses a3. A probable scenario is that if model #A updates its information a2 and a3, how will changes be propagated to model #B and model #C to their used elements? Giving model #C the right to update a3 (as model #A does) may engender conflict. Integrating Project Management Information with Central Data Model 135 This raises the transaction concurrency issue. We believe that a solution favors the role of the central data model in dealing with this issue. An object register is one way proposed to solve concurrency issues. Similar to a computer memory register, the object register records all objects in the model (see Figure 4.19). Each item in the register is a special object which contains a domain information object\u00E2\u0080\u0099s global id, lock-status, initiator and a list of models that use this element. The object also can contain the domain information object\u00E2\u0080\u0099s metadata, such as class, relationship, attributes, etc. (Yu, 2002). Once an information element in a domain model is updated and the central data model is notified, a system or a server holding the central data model firstly searches the object register to find which domain model is sharing the particular element, and then notifies all the involved models to update. If there are more than two models having the right to change an element, the first one accessed sends a signal to the object register to set the lock-status \u00E2\u0080\u009CON\u00E2\u0080\u009D in order to avoid the element from being \u00E2\u0080\u009Cinterrupted.\u00E2\u0080\u009D Once changes are finished, the lock-status is set back to \u00E2\u0080\u009COFF.\u00E2\u0080\u009D Notification of updates can be executed in an application implementation by, for example, sending a message through a server. Figure 4.19: Object Register Scheme 4.5 Conclusions Through investigating literature and development review, this chapter identified eight primary functions for PM, namely Scope Management, Cost Management, Schedule Management, Resource Management, Risk Management, Quality Management, Organization Management and Information Management. Integrating Project Management Information with Central Data Model 136 Based on these foundations for project management, this chapter has presented a detailed information analysis for each of the project management functions. Information blocks for these functions are developed, and data models related to eight functions are also designed based on the IFC model. The results constitute the data views of the IFCs for each project management function. In total, forty-five classes are represented in those data views; among them, there are sixteen newly defined classes which were deemed necessary to fully support the views. They are Specification, Phase, PerformanceMetric, Event, Transit, QualityControl, QualityComplianceNotice, Risk, RiskTrigger, RiskResponse, CommunicationChannel, Meeting, Responsibility, Trade and ProcurementProcess classes. The central domain data model, termed the Central Data Model, integrates all of the functional construction project management data models mentioned above. It serves as a common framework for data exchange supporting project management, not exclusively for a specific disciplinary application, and it constitutes a contribution of this thesis. The model consists of forty-five classes capturing voluminous functional information at a high level of abstraction. This model is sufficient to support the development of the UCPMA framework, and intended to support a wide range of full-scale project management practice. Future work to develop additional areas of project management or to support greater detail within the defined areas could further extended the model\u00E2\u0080\u0099s scope and breadth. The Central Data Model facilitates a model-based/repository information exchange approach, which can support effective data maintenance and transaction consistency. Information exchange needs data mapping. The proposed object register approach is believed to be effective in supporting data mapping and also in controlling concurrency of multi- application transactions. Future work of technical development in this aspect is required to thoroughly fulfill the UCPMA goal. The integrated domain data model leveraging object-oriented technologies theoretically facilitates information exploration by navigating objects from one to another. However, in practice, it is harder to achieve convenient object navigation once the number of model Integrating Project Management Information with Central Data Model 137 elements increases. Chapter 5 addresses a solution to this problem and presents a set of common views for unified construction project management. The Data Winnow Supporting Information Analysis 138 CHAPTER 5: THE DATA WINNOW SUPPORTING INFORMATION ANALYSIS This chapter presents the Data Winnow, one of three contributing components forming the conceptual UCPMA framework. The Data Winnow is a tool supporting data exploration and analysis. It consists of two models in different levels: a generic analytic model and a domain analytic model. The tool is based upon data warehousing and OLAP technologies; the purpose is to filter out irrelevant data from the Central Data Model (Chapter 4) as required, and then reorganize filtered data in a way facilitating analytical manipulation (e.g. drilling, slicing, etc.). Outputs from the Data Winnow will be visualized and presented to end users (Chapter 6). This chapter focuses on presenting the domain analytic model, especially a set of its dimensions and views, with an emphasis on information interdependency in a system context. 5.1 Concept of a Data Winnow The Central Data Model stores voluminous data in objects instanced from classes. These objects contain information involving various work performed by different stakeholders throughout the project lifecycle. Take the change order process for example. A typical change order includes, but is not limited to, information on the change order item and its description, cost code for accounting and its description, cost amount for compensation, the previous contract amount, revised contract amount, owner or contractor signature, and date of issuing the order. Moreover, participants hold roles, such as Architect, Owner or Owner\u00E2\u0080\u0099s representative, Superintendent, Subcontractor, etc., throughout the process. In practice, however, each participant is interested in only a few datasets relevant to his/her task at a time, and effectively retrieving these datasets from a large data repository is a big The Data Winnow Supporting Information Analysis 139 challenge. The Central Data Model enables information integration, but it does not directly support effective data exploration for different user requirements. For this challenge, the chapter here addresses research on how to apply OLAP techniques as appropriate to allow end users to effectively define queries to extract specific data views from the underlying common data model. Within the UCPMA, this component was called the Data Winnow. The Data Winnow is a tool supporting voluminous construction data exploration and analysis for integrated project management. It is established upon the OLAP technology, in that it is a suitable solution to the logic layer problem (refer to Section 1.2 and 2.4). Specifically, the Data Winnow organizes data in a structure analogous to the OLAP technology, composed of a collection of entities providing capabilities as a winnow: data items carried by objects are picked up from the central domain data model as required and organized in a hierarchical structure which facilitates data navigation, scroll-up, drill-down and so on. Yet, besides other entities borrowed from the OLAP technology, the Data Winnow has a \u00E2\u0080\u009Cview\u00E2\u0080\u009D entity (see Section 5.2 for the difference of View and Cube). Moreover, it features two models at different levels of information abstraction in order to fit construction practice. In addition, development of the tool establishes correspondence between elements of the Data Winnow and the Central Data Model. This correspondence is powerful in enabling information interoperability between different system layers, as described in Chapter 3 and Section 5.2. The following sections address the development of the Data Winnow, related to the questions: how can the OLAP technology be tailored for PM, what dimensions are common for PM functions identified in Chapter 4, how should dimension levels be designed to support data analysis and view configuration by \u00E2\u0080\u009Cassembling\u00E2\u0080\u009D or \u00E2\u0080\u009Cslicing\u00E2\u0080\u009D dimensions at a matching level, what data views are shared by the primary PM functions and how can the Central Data Model be integrated with the Data Winnow. Contribution of this chapter lies in dealing with these questions since previous work, such as (Chau et al., 2002) and (Nie, et al., 2006), covers only a few of them, does not propose data views similar to Data Winnow\u00E2\u0080\u0099s views, and provides solutions unsuitable for the UCPMA\u00E2\u0080\u0099s requirements. The Data Winnow Supporting Information Analysis 140 5.2 Data Winnow Models As shown in Figure 5.1. The Data Winnow has models at different levels of abstraction: a generic analytic model and a domain analytic model. The generic analytical model represents generic service information for classes, structures, relationships and attributes in entities. These entities include View, Cube, Dimension, Level, Member, Property, Measure, Dimension Schema, and Hierarchy. Here, a View refers to a schematic dataset or visualized dataset containing construction data, which may be composed of one dimension or several dimensions; while a cube has a different data schema consisting of two or more dimensions and must center on a fact-table (MSDN, 2006). A complex view is a composition of many views (plus external system interfaces as needed). A schematic dataset here refers to data represented with semantic symbols at a high level of abstraction. A visualized dataset means data presented in interfaces for intuitive recognition. Figure 5.1: Sample Models of Data Winnow In the generic analytic model, similar to the OLAP technology, a dimension is displayed in a specific schema. It may have several levels, under which there may be many members. A The Data Winnow Supporting Information Analysis 141 member may be designed with properties to describe its characteristics. A cube consists of several dimensions and measures. A view can be built upon a cube or across several cubes (as a complicated view). View, Dimension, Level, Member and Property make up a hierarchy structure. The generic analytic model establishes a direct correspondence between the Data Winnow and the Central Data Model (Figure 5.2). This correspondence enables dynamical data view configuration while keeping data consistent when one view is \u00E2\u0080\u009Cswitched\u00E2\u0080\u009D (like rotating a data cube) to another view. \u00E2\u0080\u00A2 A member\u00E2\u0080\u0099s property is mapped to a class attribute. \u00E2\u0080\u00A2 A member is mapped to a data table\u00E2\u0080\u0099s record which is equal to an instance of a class. \u00E2\u0080\u00A2 A dimension is mapped to a set of classes in one aspect of the data model. A class or many associated classes form a dimension. \u00E2\u0080\u00A2 A cube consists of many dimensions. A collection of dimensions is mapped to a collection of classes which are usually from different aspects of the data model. \u00E2\u0080\u00A2 More complex, a multidimensional or nD model is mapped to an advanced data model configured with more data model aspects. This case usually deals with a project management process such as a change order process, etc. Figure 5.2: Mapping from the Data Winnow to the Central Data Model Different from the generic analytic model, the domain analytical model represents information in entities described in the generic analytical model. It serves to organize information in Central Data Model in a hierarchy, and enables effective data exploration and analysis. In the following sections, several dimensions and views are identified for the The Data Winnow Supporting Information Analysis 142 domain analytical model. We believe that they are common, yet not complete, for most project management processes. Extension may be required for specific application purposes. 5.3 Dimensions of Domain Information 5.3.1 Dimension Design Procedure Dimension design is built up in steps as shown in Figure 5.3. First, a set of dimensions is identified through analyzing a matrix of project functions versus information classes in each functional data model. This set of dimensions is considered common to primary project management functions. Second, a schema type is selected for each identified dimension, and then the dimension is configured by selecting data tables and relating them if applicable. Data underlying a dimension can come from one single table (containing a collection of class instances) or multiple associated tables. Third, attributes from selected data tables are chosen and set as dimension levels. By setting up levels in the dimension, information items can be organized in a hierarchy, in which each level may encompass many dimension members, e.g. \u00E2\u0080\u009CJohn\u00E2\u0080\u009D and \u00E2\u0080\u009CJoseph\u00E2\u0080\u009D as members at the person level of the Actor dimension. Fourth, members are specified with properties associated with corresponding attributes in selected data tables. Figure 5.3: Procedure of Dimension Design The Data Winnow Supporting Information Analysis 143 5.3.2 Review of Information Classification Systems Information items can be represented in a hierarchical structure after dimension levels are established. However, a challenge arises as information items are related from one dimension to another in order to facilitate navigation and aggregation. The challenge lies in mapping items at different levels of detail. For example, in the Product dimension shown in Figure 5.4, concrete Wall#1 is at the lowest level, while in the Process dimension, below the Wall#1 level there is one level of information describing construction of this wall. Then, the issue is with which level in the Process dimension the third level of Product should be associated. To solve the issue, we resort to standard information classification systems. Figure 5.4: Challenge of Information Mapping between Dimensions 5.3.2.1 MasterFormat MasterFormat was initiated for specifications concerning nonresidential building projects in North America in 1960s. It classifies construction information into 16 divisions, forming a hierarchical system, which includes General Requirements, Site work, Concrete, Masonry, Metals, Carpentry (wood and plastic), Thermal and Moisture Protection, Doors and Windows, Finishes, Specialties, Equipment, Furnishings, Special Construction, Conveying Systems, Mechanical, and Electrical. Generally each division may include two lower levels (three levels in total), but users are allowed to define more according to specific requirements. MasterFormat is widely used in bidding and cost estimating as a standard work breakdown structure (WBS). The Data Winnow Supporting Information Analysis 144 5.3.2.2 Uniclass Uniclass (unified classification) was developed by a combination of the work of ISO (TC59/SC13 WG2) and the National Building Specifications Services (London) in 1997. Uniclass is intended to be applicable for all project lifecycle information classification. It is structured with a facet system which includes: Form of Information, Subject Disciplines, Management, Facilities, Construction Entities, Spaces, Elements for Buildings, Elements for Civil Engineering Works, Work Sections for Buildings, Work Sections for Civil Engineering Works, Construction Products, Construction Aids, Properties and Characteristics, Materials, and UDC (Universal Decimal Classification) (Kang & Paulson, 2000). These facets are labeled with letters from A to Q respectively, and detail items within each facet are classified in decimal scale. Uniclass can be used to make a WBS and create a combined code in it for representing a hierarchy of process, product, cost, etc. 5.3.2.3 OmniClass Omniclass, originally called the Overall Construction Classification System, is a set of interrelated tables intended to provide a standard for classifying objects describing the built environment. This industry-wide initiative currently is led by the Construction Specifications Institute and Construction Specifications Canada. The most recently published Omniclass consists of 15 tables, including Construction Entity by Function, Construction Entity by Form, Spaces by Function, Spaces by Form, Elements, Work Results, Products, Phases, Services, Disciplines, Organizational Roles, Process Aids, Information, Materials and Properties. Each table presents a unique facet view. Entries from different tables can be combined to classify and identify very discrete objects of the built environment (OmniClass, 2004). In this research, we classify information based primarily on the Omniclass system, since this reflects the construction practice in North America. Moreover, concepts of Omniclass are derived mostly from ISO standards (ISO/DIS12006-2, ISO/PAS 12006-3), and its content and structure are adopted from Uniclass as needed. The Data Winnow Supporting Information Analysis 145 Figure 5.5: Example of Dimension Members Associated at Different Levels By leveraging the standard information classification system, members of different dimensions can easily be associated at a matched level. For example, Figure 5.5 shows how members of Cost, Process and Product dimensions (these dimension will be described in Section 5.3.3) are linked at three levels. The cost dimension has five levels as shown in the figure. Among them, we are interested in the Cost Division, Cost Section and Cost Item levels. These three levels match the Process Dimension\u00E2\u0080\u0099s Stage, Task, and Activity levels and also, the Product Dimension\u00E2\u0080\u0099s System, Subsystem and Element levels respectively. These levels are designed according to OmniClass tables, as denoted in the column entitled \u00E2\u0080\u009CNotes.\u00E2\u0080\u009D With these levels specified, a cost item of Exterior Concrete Block Wall corresponds to the activity of Erect Exterior Walls (including #1, #2, etc.), which in turn, is related to the Block Wall product element. 5.3.3 Common Dimensions In order to identify dimensions shared by project management functions, a matrix is established with functions expressed in columns and classes of data models in rows. As shown in Figure 5.6, the matrix is not complete; those classes appearing only one time in data models are excluded. The Data Winnow Supporting Information Analysis 146 Figure 5.6: Matrix of Functions vs. Information Classes According to different represented contents, classes in the matrix are categorized into the following groups: \u00E2\u0080\u00A2 Document Information: involves IfcDocumentInformation. \u00E2\u0080\u00A2 Process: includes IfcProcess, IfcTask, IfcWorkSchedule and IfcWorkPlan. \u00E2\u0080\u00A2 Product: includes IfcProduct and IfcConstructionZoneAggregationProduct. \u00E2\u0080\u00A2 Project: have IfcProject, IfcProjectOrder, and WorkBreakdownStructure. \u00E2\u0080\u00A2 Cost: includes IfcCostSchedule (describing different cost types, instead of time issues) and IfcCostItem. \u00E2\u0080\u00A2 Actor: encompasses IfcOrganization, IfcActor, IfcPerson, and IfcActorRole. \u00E2\u0080\u00A2 Resource: contains IfcResource and IfcConstructionResource fall into this group. \u00E2\u0080\u00A2 Control and Generalization: classes IfcControl, IfcWorkControl, IfcConstraint, Performance and Event fall into this group. The Data Winnow Supporting Information Analysis 147 Given the categories listed above, we recognize the groups of Document, Process, Product, Cost, Actor, and Resource as common dimensions of information involved in project management functions, since most classes in these groups appears more frequently in the eight primary functions than other classes. Project, by contrast, only acquires distinctive characteristics as a dimension if multiple projects are analyzed; since this dissertation is limited to analysis of one project, information items regarding project description in one function will be subsumed under the other functions. Therefore, the Project category is excluded from the set of common dimensions. Moreover, classes such as IfcControl, Performance, etc. in the Control and Generalization group are abstract generalization and can be directly attached to various classes in the common dimensions identified above; hence it may be appropriate to separate this group from the list of common dimensions. In addition, we add Time as a common dimension since it is an inherent characteristic of project management. For example, information in the Process dimension becomes meaningful only when it is associated with time. As described above, seven dimensions were identified as common dimensions by which information on primary project management functions can be categorized, yet they are not complete or uniform for all purposes. Users may define other dimensions, such as Organization, Product Location/Zone, Project Disciplinary Group/Trade, Quality, Risk, etc., as required. The following sections describe these identified dimensions, including their levels, required core information, as well as data schemas. Data schemas illustrate dimension configuration with elements in the Central Data Model; attributes in each model element are for illustration only and are not complete. 5.3.3.1 Product Dimension A product here refers to a built entity or environment to serve a specific function. In the Data Winnow, the Product dimension represents what a product has (context objects) and how it can be organized and presented (representation structure). The purpose of the Product The Data Winnow Supporting Information Analysis 148 dimension is not to duplicate traditional 2D or 3D representation, rather to facilitate information exchange and support integration of functions, such as scheduling, cost estimating, document management, etc. Core information for the Product dimension includes, but is not limited to: product name, breakdown structure code (WBS), location, product type, and specification (including quality requirements). These may be grouped in different levels. Others such as area, formwork area, volume, elevation, etc. can be added if necessary. According to different physical product structures (such as buildings, bridges, etc.), information in the Product dimension can be classified according to the following levels: \u00E2\u0080\u00A2 Sub-product: is a part of a construction entity with distinct functions; or it can function independently but be necessary for fulfilling the whole project objectives, e.g., a section of a highway (which may have several sections, bridges and tunnels). \u00E2\u0080\u00A2 System: is a functionally related, interactive, or interdependent element group as a relatively independent complex whole. Referring to (Russell & Chevallier, 1997) and the Omniclass classification system, the system level may include Foundation, Structural, Substructure, Superstructure, Enclosure, Mechanical, Plumbing, Fire Protection, Electrical, Vertical Transportation, Interior Construction and Finishing, Site and Landscaping. \u00E2\u0080\u00A2 Sub-system: a lower level of the system level. In Omniclass Table 04, the Enclosure system may consist of Exterior Wall, Exterior Glazed Openings, Exterior Doors, etc. This level distinguishes one product object from others according to their functions or uses. \u00E2\u0080\u00A2 Element is a fundamental constituent of a system or subsystem. Elements of a system may include wall, column, slab, stair, insulation, window, door, roof, and beam, taking a building product as an example (ISO/DIS 12006-2 Table 4.8). This level of product indicates different product structures, materials, or specifications. \u00E2\u0080\u00A2 Component: an element may be further divided, if required, into many components placed in layers or zones. For example, the exterior wall may be composed of cladding, brick, insulation, vapor retarder, joints, etc. The Data Winnow Supporting Information Analysis 149 The Element level sets the \u00E2\u0080\u009CLocation\u00E2\u0080\u009D property for its members, which indicates the element placement. Location can be defined as a separate dimension for a complicated case as needed. A building product location was classified, for example by (Russell & Chevallier, 1997), into groups of Global, Site, Foundation, Parkade, Floor(s), Penthouse, etc. Moreover, the Element level may have member properties of \u00E2\u0080\u009Clabel\u00E2\u0080\u009D (e.g. #1 column according to indication in design), name, material (related to the Resource dimension) and quantity information (related to Cost Dimension). Figure 5.7: Product Dimension Schema Figure 5.7 shows the data schema of the Product dimension. It is built mainly upon IfcProduct class. Its association with IfcElement, IfcElementComponent and IfcConstructionZoneAggregationProduct forms a connection of \u00E2\u0080\u009Csnowflake\u00E2\u0080\u009D style- a logic table arrangement schema in a database, with a centered table connected to multi- dimensions. Levels are designed by picking up attributes from these classes. 5.3.3.2 Process Dimension Process refers to a series of actions to be performed in order to build or maintain a structure through planning, designing, work acquiring, constructing, or maintaining products, or to carry out a project order. Processes are placed in sequence (including overlapping for parallel tasks) in time (IAI, 2007), and consumes resources to obtain a result. The Process dimension should display what actions are taken, what objectives actions work on, sequence The Data Winnow Supporting Information Analysis 150 of actions, and quantities of resources consumed (including material, equipment, labors, time, and cost, etc.). For decades, a large amount of research regarding process modeling has been carried out in the AEC/FM industry. Froese (1995) discussed several conceptual models of AEC processes. These include the Information Reference Model for AEC (IRMA), Unified Approach Model, GenCom, PISA, COMBINE and STEP Building Construction Core Model. These models generally capture core information that can be used in the Process dimension. Core information involved in this dimension include: time, including duration, start/finish dates, float/slack time; task and its predecessors or successors, as well as task\u00E2\u0080\u0099s name, ID, description; work breakdown structure/code; resource usage including use of material, equipment and labor; product components; constraints, such as milestones, cost limitation, dependencies (physical, trade, resource and safety, e.g.); methods used to accomplish the process. These information items are actually contained in blocks listed in Section 4.2.3.3. Construction of a whole product (e.g. building, highway, etc.) can be regarded as a complete process with several phases to its lifecycle. In each phase, there are many tasks to be performed to achieve specified objectives. A task may consist of several activities, which in turn can be broken down into actions. Levels of the Process dimension are defined as follows: \u00E2\u0080\u00A2 Phase: A project has many phases constituting its lifecycle, and a project process can be broken down into several sub-processes accordingly. Here we take \u00E2\u0080\u009Cphase\u00E2\u0080\u009D as the level of these sub-processes. According to major project phases in the project lifecycle, levels of the Process dimension may have project identification, delivery planning, design, construction, and closeout. \u00E2\u0080\u00A2 Stage: In each phase, there may be several stages. In turn, each stage may encompass several tasks. Take a construction project as an example, (Willis, 1986) broke down project phases into 14 stages, namely Preconstruction, Engineering, Procurement, Job Mobilization, Site Preparation, Foundation Construction, Structure, Closing/Enclosure, Roughing in Electrical and Mechanical, Interior/Exterior Finish, Paving (outside), Landscaping, and Project Closeout. The Data Winnow Supporting Information Analysis 151 \u00E2\u0080\u00A2 Task: is a logic unit of a process, representing work processed to fulfill a phase objective. Take a Canadian highway project as an example. The delivery planning process may include Appoint Project Manager, Initiate Project, Register Project, Secure funding, Assemble Project Team, and Development of Project Delivery Plan. A task is usually associated with one or many generated documents. \u00E2\u0080\u00A2 Activity: is the actual pursuit of a task\u00E2\u0080\u0099s result, performed by a category of person(s) or an organization. For example, the task of \u00E2\u0080\u009CRegister Manager\u00E2\u0080\u009D in the Canadian highway delivery example may consist of the Identify a Manager Candidate, Discuss on Availability of the Candidate, (candidate) Accept the Duty, and (sponsor) Issue a Letter of Project Assignment activities. An activity may have many members. For example, the activity \u00E2\u0080\u009CErect Exterior Brick Walls\u00E2\u0080\u009D may include erecting of wall #1, wall #2, etc. An activity consumes resources. Resource information includes resource ID, quantity, and unit price. This dissertation does not involve cost details of product component installation, e.g. placing bricks for a wall. Therefore, a Task has one-to-one relationship with a Cost Item. Figure 5.8: Process Dimension Schema Figure 5.8 displays the Process dimension schema centered on IfcProcess. The association of IfcProcess with classes of Phase, IfcTask, IfcConstraint and IfcWorkSchedule forms a snowflake style. Levels including phase, stage, task, activity and action are picked up from these classes respectively. The Process dimension schema may become a parent-child style The Data Winnow Supporting Information Analysis 152 if associated attributes such as predecessors in the class are picked up as levels (as shown in a dashed link). 5.3.3.3 Cost Dimension Cost is one of the most important factors of project management. It is usually regarded as a distinct resource or as a combined expenditure of time, material, equipment and labor in order to achieve a goal. Cost is a kind of performance measure and may have different value types for various purposes. The Cost dimension describes how much is required to create a product; it also represents cost constituents (cost breakdown) so that the budget can be distributed, and work can be controlled in detail. Development of the dimension has recourse to several cost estimating models. (Froese, 1995) discussed an estimating application model based on Timberline Precision Plus. Basic information/objects in the model include Estimate, Phase, Item, Calculation, Location, Work Package, Category, Crew, and Work Package Item. (Froese & Yu, 1999) discussed the IFC Object Cost Model based on IFC version 1.5. The model represents cost information related to an object (including product and work) being estimated, and cost schedule describing a list of cost elements for various purposes. Derived from these models, core information of the dimension may include cost item/element name, description, cost item quantity, currency, cost breakdown structure/code (CBS), associated product components, associated resource usage and unit price. Referring to the MasterFormat information framework and the OmniClass system, the cost dimension can be grouped in to several levels as follows: \u00E2\u0080\u00A2 Cost Schedule: or cost type, indicates a particular collection of cost items for different requirements. IAI (2003) enumerated seven types, including budget, cost plan, estimate, tender, priced bill of quantities, un-priced bill of quantity, and schedule of rates. \u00E2\u0080\u00A2 Cost Division: an element of a cost schedule. Some estimators tend to use the Masterformat classification system (1995/2004 edition), which specifies 16 basic divisions. For example, Division 3 concerns concrete in this system. Others may The Data Winnow Supporting Information Analysis 153 classify cost information according to a work breakdown structure; for instance, a cost schedule can be divided into Demolition, Sitework, Foundations, Substructure, Superstructure, Exterior Skin, Roofing, Interior Construction, Conveying, Special Construction, Plumbing/Process Piping, Fire Protection, Mechanical, Electrical, Jobsite Management, Site Requirements, and Others (including permits and fees, construction contingency, allowances, etc.) \u00E2\u0080\u00A2 Cost Section: each division can be broken into sections. For example, Division 3\u00E2\u0080\u0094 Concrete\u00E2\u0080\u0094encompasses a lower section, Formwork; the Superstructure division has a section of Slab on Grade. \u00E2\u0080\u00A2 Cost Item: each section consists of one or many cost items. For instance, the Formwork section contains a cost item \u00E2\u0080\u009CBlock-outs in Walls\u00E2\u0080\u009D; the Slab on Grade section contains a cost item \u00E2\u0080\u009CForm Column Blockouts.\u00E2\u0080\u009D \u00E2\u0080\u00A2 Subitem: a cost item may be further broken into sub-items if needed. For example, the Formwork Blockouts cost item may be further distinguished according to wall types (e.g. Walls 1400*800). Figure 5.9 represents the cost dimension schema. It is built upon the IfcCostItem class and has a star or single-class style. Attributes including CostDivision, CostSection, CostItemName and SubItem are picked up as levels. The class can be split into several small classes, e.g. Cost Division, Cost Section, etc., in a relational database if a table containing data of IfcCostItem is too large. Attributes listed in the figure are expanded based on those in IfcCostItem of the IFC model. Figure 5.9: Cost Dimension Schema The Data Winnow Supporting Information Analysis 154 5.3.3.4 Resource Dimension The Resource dimension provides information needed to represent dimensions of Cost, Process, Product, and others. The purpose here is not to describe detailed characteristics of the resource itself, but to offer information on procurement and resource usage. Core information in the Resource dimension include resource name, description, owner history, unit, inventory (associated with IfcInventory class), and relations to other information as required. Dimension levels to decompose the resource information into details can have the following: \u00E2\u0080\u00A2 Category: is a collection of resource members that have certain functional attributes in common. These attributes serve to distinguish one resource (e.g. labor force) from another (e.g. equipment). \u00E2\u0080\u00A2 Subcategory: is a specifically defined division under the Category level. For example, under the Labor type, there may be Carpenter, Mason, and so on. \u00E2\u0080\u00A2 Item: is to separate members of one category from each other in terms of their different levels or models. Member properties may include Specification (e.g. Carpenter-Junior; Framing Studs-2*4*8, Roof Sheathing-\u00C2\u00BD\u00E2\u0080\u009D, etc.), Name, Supplier, etc. Depending on specific requirements, some resources may not be broken down to this level. Figure 5.10: Resource Dimension Schema The Data Winnow Supporting Information Analysis 155 Figure 5.10 displays the Resource Dimension\u00E2\u0080\u0099s schema centered on IfcResource. IfcInventory provides information on member properties for resource items. The two classes form a snowflake-style schema. Information associated with other dimensions such as Process and Cost is not included in this dimension. 5.3.3.5 Actor Dimension Actor refers to a person or organization playing roles during construction. An actor can be a \u00E2\u0080\u009Clabor\u00E2\u0080\u009D resource, working for a particular organization; but in this research, \u00E2\u0080\u009Clabor\u00E2\u0080\u009D as a Resource instance is separated from Actor since we emphasize Actor\u00E2\u0080\u0099s organizational characteristic and its responsibility. The Actor dimension represents information about a project team, including organizations and individuals, as well as their relation to the processes. Information involved in the Actor dimension includes actor name, description, organization or party involved, discipline, group belonging to, as well as responsibility or role taken in the project team. Actor levels include the following: \u00E2\u0080\u00A2 Discipline: indicates the discipline to which an actor belongs. Referring to Omniclass Table 08, the Discipline level may include divisions of facility conception, facility design, surveyors, project management, construction, planners, other disciplines, owner/sponsor representatives, and facility managers. \u00E2\u0080\u00A2 Subdiscipline: indicates the detailed level of a discipline. For example, under the project management level, there may be general management, estimating, scheduling, cost control, contract administration, procurement, and quality assurance and quality control. Subdiscipline may set Organization as one of its member properties in order to indicate the disciplinary responsibility taker. \u00E2\u0080\u00A2 Role: each participant (an individual or an organization) in a project team has a role. A process task is usually assigned to an actor according to the actor\u00E2\u0080\u0099s role. Based on Omniclass Table 08, roles include Designer, Engineer, Specifier, Insurance Agent, Realtor, General Contractor, Project Manager, Project Engineer, Laborer (Electrician, Mason, Painter, etc.), Subcontractor (i.e. Carpenter, Laborer, Roofer, Welder), and Owner, Facility Manager. The Data Winnow Supporting Information Analysis 156 \u00E2\u0080\u00A2 Name: indicates a human being or organization with member properties of full name, contact method, address, specialty, etc. Information about Actors as described above may be split into Actor and Organization dimensions if required in some cases. In such a design, Actor emphasizes a participant\u00E2\u0080\u0099s responsibility in the project, while Organization emphasizes structural relationships between people. Figure 5.11: Actor Dimension Schema Figure 5.11 represents the Actor dimension schema centered on IfcActor. Classes including IfcOrganization, IfcPerson, IfcGroup, IfcActorRole and Responsibility associated with IfcActor form a snowflake style schema. Levels are picked up from attributes in these classes. Member properties can be also selected from them as required. 5.3.3.6 Document Dimension Documents include any document information referenced or utilized during construction project management (OmniClass, 2004). A document may be model-based or file-based. The Document dimension deals with file-based information and represents communication information about who needs what documents, when they are needed, how they are transmitted to users, and who distributes the document (PMI, 2008). The Data Winnow Supporting Information Analysis 157 Core information in the Document dimension is metadata that describes attributes of traditional document management. (Dublin, 2003) presented a set of metadata elements as a standard of cross-domain information reference description. These elements embody Title, Creator, Subject, Description, Publisher, Contributor, Date, Type, Format, Identifier, Source, Language, Relation, Coverage, Discipline, Location, and Rights. Besides these, we add Version, Discipline, Reviewer and Approver as additional metadata elements. Version refers to a variation of an earlier or original one; Reviewer or Approver is a person or organization that reviews or approves the file; Discipline indicates a service for which information is generated or used. The IFCs also define a set of similar metadata items (IAI, 2007). Levels of the Document dimension are defined as follows: \u00E2\u0080\u00A2 Type: indicates inherent document characteristics. Wix and Liebich (2001) identified several document types including: approval, cost plan, external reference, list (e.g. punch list), mail, order, payment, schedule, coordination (e.g. communication letters, emails), legislation (e.g. standards, codes regulation), document (e.g. reports, contracts) and shape representation (e.g. drawings). \u00E2\u0080\u00A2 Item: distinguishes individual documents from each other. Member properties may include title, URL, Initiator, etc. Figure 5.12: Document Dimension Schema The Data Winnow Supporting Information Analysis 158 Figure 5.12 represents the Document dimension centered on IfcDocumentInformation, which provides many categories of Levels from different perspectives. For example, the Document dimension may have Status and Creation Time levels to serve the timeliness point of view. 5.3.3.7 Time Dimension Time is one inherent characteristic of project management. Each of the other dimensions described previously has an attribute related to the Time dimension. Such a relation makes a process dynamic rather than static, and requires integration of management efforts throughout the project lifecycle. The Time dimension represents project phases (including stages if applicable) and calendar dates. Information in the Time dimension may have project phases, stages, year, month, week, and day. Levels of the Time dimension include: \u00E2\u0080\u00A2 Phase: is composed of transitory stages in the process. Wix and Liebich (2001) described a project having four phases including Pre-project, Pre-construction, Construction and Post-construction/Closure; these four phases then were divided into 10 stages. Stage is a section of a phase. Definition of the Phase and Stage levels may follow those of the Process dimension. \u00E2\u0080\u00A2 Date: a full-length date/time including properties of year, month and day. It may be replaced with Year, Month, Week and Day levels. Figure 5.13: Time Dimension Schema The Data Winnow Supporting Information Analysis 159 Figure 5.13 displays the Time dimension\u00E2\u0080\u0099s schema. The schema is composed of Time and Phase classes, and presented in a snowflake style. Alternatively, levels may only be related to information of a standard calendar day including year, month and date, and then the dimension is built only upon the Time class in a star style. Choosing levels and the style schema depends on the analytic requirements of end users. 5.4 Integrated Domain Views This section describes a set of views common to project management. First, the section identifies and defines five common views. Second, analysis exposes their integration features arising from the linkages between the Data Winnow and the Central Data Model (as mentioned in Section 5.2). Third, the section addresses how views are developed\u00E2\u0080\u0094by composing dimensional information items into views\u00E2\u0080\u0094and reviews various approaches for view composition. Fourth, taking the change order process as example, the section presents five views in Microsoft Visio UML notation. 5.4.1 Domain Views Identification No matter what type a process is, information items regarding what (scope), how (planning and time), who (organization and human resource), how much (cost & resources), and how well (evaluation, resource usage, etc.) are core to the process; and any participant involved in the process must address this information to accomplish his/her task(s). UCPMA\u00E2\u0080\u0099s views represent domain information in these regards and are common to participants. Enlightened by process perspectives of Curtis (Section 2.2.2), a set of common UCPMA views are designed to reflect different fa\u00C3\u00A7ades of a construction management process. Reorganizing information items as described above, five primary views are identified for the UCPMA framework as follows: \u00E2\u0080\u00A2 Context view: defines a particular process\u00E2\u0080\u0099 \u00E2\u0080\u009Cportfolio\u00E2\u0080\u009D consisting of a collection of process attributes that make it distinct from others, and also represents its procedure and status as a workflow, if applicable. In addition, the view gives a background of the process among a collection of processes in the same type. For example, in the The Data Winnow Supporting Information Analysis 160 \u00E2\u0080\u009CSinkhole Earthwork\u00E2\u0080\u009D case, a Context view can present attributes such as location, initiated date, work responsible organization, etc.; it can also indicate the status of the process at a specific time, and list all occurred changes to show their relationships that may impact the project schedule. \u00E2\u0080\u00A2 Plan view: represents the tasks that pertain to a particular process, where they are performed, what sequence they follow, as well as which activities an individual does for each task. The view imitates a schedule view similar to Microsoft Project\u00E2\u0080\u0099s Gantt chart; yet it not only shows a schedule for a process, but also displays individual responsibility in daily activities for each process\u00E2\u0080\u0099s task. For example, the view can represent the \u00E2\u0080\u009CSinkhole Earthwork\u00E2\u0080\u009D change order process\u00E2\u0080\u0099 tasks, and also display daily activities for each task in which a field engineer may be involved. \u00E2\u0080\u00A2 Supply view: indicates resource consumption in finishing a task or process. It represents resources (material, equipment, labor, cost, etc.) as input required in a process\u00E2\u0080\u0099 lifecycle, and serves as a schedule for material procurement. Moreover, it displays measurement of disciplinary effort summarized over time. \u00E2\u0080\u00A2 Effect view: portrays a physical 2D/3D world or a hierarchical list of product components. It basically displays which product is influenced by a process or one of its tasks. Sometimes, the view shows what output product(s) is associated with a process or a particular task. \u00E2\u0080\u00A2 Reference view: represents a particular required information element, the information necessary to locate and access the information element (a paper-based document or electronic file) as input or output of a process, to which document the information element is referenced, and what relationships it has with other information elements in the file. Referenced information can serve as input to a process or task. Some researchers propose views in terms of process information representation. Shunk et al. (2003) carried out a thorough investigation on process modeling and presented several views or perspectives describing processes. These views include function (or activity), information, behavior (or dynamics), organization (or structure), resource (or control), business, decisions, goals and actors (or person) views. Among these, function, information, dynamics and The Data Winnow Supporting Information Analysis 161 organization views were asserted to be the most common. Curtis et al. (1992) recognized four views as common to processes: functional view, behavior view, organizational view and informational view (refer to Section 2.1.2, Chapter 2). These views reflect a process from different fa\u00C3\u00A7ades. UCPMA\u00E2\u0080\u0099s five views are similar to Shunk and Curtis\u00E2\u0080\u0099 views in semantics, yet they differ in respect of views\u00E2\u0080\u0099 information interdependency. Other views represent information mainly for data transaction (data flow and transformation), while our views emphasize work coordination, presenting fundamental information common to participants. The following section addresses distinct features of the five domain views. 5.4.2 Integrated Representation of Domain Views 5.4.2.1 Features of Domain Views UCPMA\u00E2\u0080\u0099s shared domain views feature information consistency, commonality and dimensional composition. As shown in Figure 5.14, a set of UCPMA views on the top are supported by previously identified common dimensions. Each dimension consists of one or many information elements in the Central Data Model. Information elements with the same content in different views share the same data value stored in the model. Changes in views are automatically revealed as any information element in the model is updated. Moreover, dimensions upon which the views set are built are common to primary project management functions; this in turn results in commonality of the set of views. Commonality here means that these views\u00E2\u0080\u0099 information elements are required by most construction project processes. On the basis of these information elements, work relationships are established so that participants can work with these views and coordinate their work. In addition, each view in the set is composed of one or many dimensions, and each dimension uses one or many classes, which may embody one or many objects as detailed information containers. From a high-level management perspective, every project process, e.g. change order process, can be composed of these domain views representing common, core process information, as well as specific views custom-designed for the project or added from external systems for specific disciplinary purposes. The Data Winnow Supporting Information Analysis 162 Figure 5.14: Information Interdependency between Views, Dimensions, Data Models 5.4.2.2 Common Views Design, Functionalities and Representations The views are designed to capture required information elements and represent them in a modeling language. Here, the objective of design lies in identifying dimensions which can be applied for view representation. Dimension schemas have been displayed in Section 5.3.3. Steps taken in design include: determining a business\u00E2\u0080\u0099 functional requirements, analyzing input and output information according to functional requirements, identifying dimensions that embody the inputs and outputs of information elements, and then composing identified dimensions into a view by relating them to one another. The Data Winnow Supporting Information Analysis 163 Definition of the five domain views in Section 5.4.1 addresses views\u00E2\u0080\u0099 primary functionalities. These functionalities call for specific dimensions to be added in each view. For example, in the Plan view definition, \u00E2\u0080\u009Cwhat tasks\u00E2\u0080\u009D are associated with the Process dimension; \u00E2\u0080\u009Cwhere\u00E2\u0080\u009D is associated with the Product and its Location dimension; \u00E2\u0080\u009Cwhat sequence\u00E2\u0080\u009D is not only related to the Process dimension, but also to the Time dimension; and \u00E2\u0080\u009Cwhat information\u00E2\u0080\u009D is associated with the Document dimension. In addition, comprehensive review of commercial software tools, such as Autodesk Revit, Autodesk Streamline, Microsoft Project, Timberline Precision Estimating, Primavera P3, Meridian Project System, etc., gathers more functional information in order to expand the five views\u00E2\u0080\u0099 functionalities in future research work. As show in Figure 5.15, the column \u00E2\u0080\u009CFunctional Requirements\u00E2\u0080\u009D lists summarized functional requirements related to functionalities provided by those commercial tools mentioned above. These requirements are classified into five types, corresponding to the five UCPMA views. To simplify view design, dimensions that represent functional information and have been adopted into views are enumerated in the \u00E2\u0080\u009CMain Dimension\u00E2\u0080\u009D and \u00E2\u0080\u009CAssociated Dimensions\u00E2\u0080\u009D columns. Dimensions in the \u00E2\u0080\u009CAssociated Dimensions\u00E2\u0080\u009D column may not be from the set of identified common views. Each view can be integrated with other views in order to provide functionalities listed in the column; for example, to fulfill one of Plan view\u00E2\u0080\u0099s functionalities, \u00E2\u0080\u009CIntegrate with material supply flows for accurate forecast, inventory and production,\u00E2\u0080\u009D the view should be integrated with the Supply view. The following addresses how views are composed: \u00E2\u0080\u00A2 The Context View is derived primarily from the Process dimension, and can be associated with Workflow, Project Order, Time, and Project dimensions. \u00E2\u0080\u00A2 The Plan View is also supported by the Process dimension, but unlike the Context view, it represents schedule information on a particular process. The view can be composed of Process, Time, Actor, Product, Document, Resource and Group dimensions. Depending on actual requirements in implementation, a Plan view may not include all of these dimensions. \u00E2\u0080\u00A2 The Supply View is built mainly upon the Resource dimension, and can include Process, Cost, Group, and Organization dimensions as well. The Data Winnow Supporting Information Analysis 164 \u00E2\u0080\u00A2 The Effect View is derived primarily from the Product dimension. It should be associated with dimensions of Process, Group, Location, etc. to acquire functionalities listed in Figure 5.15. \u00E2\u0080\u00A2 The Reference View centers on the Document dimension, and can be associated with Process and Product to support the required functionalities of these two dimensions. Figure 5.15: Dimensions and Functional Requirements of UCPMA Views The data model schemas of these five views are composed of a combination of the schemas of the involved dimensions, which were displayed in previous sections. Here, no schema particular to a view is represented since developing a schema, in fact, becomes a matter of view composition (see the following section). In addition, functional requirements listed in The Data Winnow Supporting Information Analysis 165 Figure 5.14 exclude basic data editing tasks, such as input, save, report, etc.; the research scope does not include such details. 5.4.2.3 View Composition Approach Dimensions filter data in the Central Data Model and provide required datasets. The remaining issue is how to combine dimensional datasets into a new dataset or a view in the data layer for analysis. Combining datasets require linking relations in datasets. Figure 5.16: View Composition Diagram Linking relations, at first, calls for two or more relations to be linked. As shown in Figure 5.16, a relation is a table in a database. There are one or many tuples (or records in a table) in a relation; each tuple is characterized by many attributes which are represented in the fields of a table. In a relational database, one relation is linked to another by a primary key that forms a one-to-one or one-to-many relationship between relations, for example, in a Microsoft Analysis Services database. Then, linking relations to manipulate multidimensional data in datasets is fulfilled through joining linked relations. Microsoft Analysis Services leverages OLAP technology for data mining (Section 2.4). Data in an analytical database are structured as multidimensional data cubes corresponding to datasets. In each cube, dimensions are associated with a fact table in The Data Winnow Supporting Information Analysis 166 which quantitative fields are treated as measures. Pivoting on the fact table, the cube can be projected and presented to users from different points of view for data exploration with flexibility and completeness. The basic pivoting mechanism is to join relations by using the Multidimensional Expressions (MDX) language which is more advanced than the Structured Query Language (SQL) syntax. To join relations, basic operators of relational algorithm include Join, Union, and Cartesian product (Stolte et al., 2002) (Nagappan, 2001). MDX, as well as SQL, provides these functionalities. In this research, implementation of view composition takes a mixed approach that uses the OLAP technology for pivoting quantitative data and adopts the basic SQL algorithm in qualitative information manipulation. Details are addressed in Chapter 7. 5.5 Dimensions and Views for the Change Order Process The dissertation described the domain analytic model in previous sections. This section addresses representation of the \u00E2\u0080\u009CSinkhole Earthwork\u00E2\u0080\u009D change order process in terms of Data Winnow entities. The section serves to illustrate the data analysis theory. As shown in Figure A.2 (Section 2.1 in Appendix A), the whole process is separated vertically into three phases. The process is further dissected into detailed tasks, and in turn, each task can be broken down into activities if required to control individual performance. Horizontally, each task is assigned to an individual actor who might belong to different trades, and is associated with documents which might be the task\u00E2\u0080\u0099s output or its information input. On the whole, the figure presents which tasks must be done at a given time for a particular process, who is responsible for each task, and what information is needed to support task performance. However, due to its 2D representation, the figure does not cover all fundamental information. For example, details of \u00E2\u0080\u009CExecute Change Order\u00E2\u0080\u009D should include resource usages (material, The Data Winnow Supporting Information Analysis 167 equipment, and others, as shown in Figure A.7), but representing this information would require extra dimensions in the table. Moreover, the table in Figure A.2 and the data model (Figure A.9) do not give much sense of tasks\u00E2\u0080\u0099 procedure and process information interdependency. In addition, different actors, from their perspectives, may each need only a portion of all information items at a particular phase. Therefore, modeling and representing the change order process in a table and in a data model does not provide much help in data analysis. The Data Winnow combined with the Central Data Model is a better solution. Primary dimensions can be identified as Process, Document, Actor, and Resource. Information on trade and organization may be defined as attributes of Actor; alternatively, Group (trade) and Organization may be defined as dimensions. And Time, an inherent information dimension for each process, must be added. Moreover, the change order process can be treated as a workflow, a special process, as discussed in Chapter 4; a Workflow dimension may also be added as a primary dimension in a domain analytic model. Figure 5.17 shows data schemas of five common views in simplified UML notation, which represent the change order process. It includes seven common dimensions, as well as others which are required to support view functionalities sufficiently. In the figure, classes denoted in dark boxes stand for \u00E2\u0080\u009CMain\u00E2\u0080\u009D dimensional information as listed in Figure 5.14. Levels of each dimension are defined according to displayed class attributes. Compared to the Central Data Model, these schemas add some class instances, such as ProjectOrder, in order to represent more detailed information; and for succinctness, all classes have the \u00E2\u0080\u009CIfc\u00E2\u0080\u009D prefix removed. Moreover, some classes appear redundant within several view schemas. In the system implementation (Chapter 7), this \u00E2\u0080\u009Credundancy\u00E2\u0080\u009D will be eliminated through view coordination. 168 Figure 5.17: Changer Order Process Views in Microsoft Visio UML Notation The Data Winnow Supporting Information Analysis 169 5.6 Conclusions This chapter presents the development of the Data Winnow that uses the OLAP technology to bridge from the Central Data Model\u00E2\u0080\u0094which combines all the project management data into one integrated model at the data level\u00E2\u0080\u0094to a configurable and extensible set of data views\u00E2\u0080\u0094which support specific project management functions at the application logic level. The work presented here contributes an analysis and design of a set of dimensions that are common to most project management processes, including Product, Process, Cost, Actor, Resource, Document, and Time dimensions. These dimensions are represented at a high level. Their detailed specifications need to be elaborated during implementation. An additional contribution is provided by combining these dimensions into a set of composite views reflecting different business purposes. In construction projects, users often deal with a process from different points of view. Focusing on information relationships and work coordination, five views including Context, Plan, Supply, Effect, and Reference view are identified and illustrated with information quoted from the change order process example. The project management dimensions and the composite views are both novel advances to the application of OLAP to project management and are generally applicable across a wide range of project management functions. These elements match elements of the Central Data model; the establishment of such correspondence between them makes the Data Winnow an integrated component in the UCPMA framework. Chapter 6 describes how the views defined here at the application logic layer are presented and visualized for data analysis at the presentation layer. Visualization Configuration Model 170 CHAPTER 6: VISUALIZATION CONFIGURATION MODEL This chapter presents the Visualization Configuration Model (VCM), as a tool that is integrated with UCPMA\u00E2\u0080\u0099s other components to support data exploration and analysis visually. Inspired by the configuration pattern of natural flowers, the VCM consists of graphic elements, graph components, views and scenes, which are placed in coaxial layers. Moreover, the VCM establishes correspondence to the Data Winnow for integrating UCPMA\u00E2\u0080\u0099s three components into a whole system. In addition, development of the VCM follows guidelines of formulated visualization principles and strategies. Coordination of VCM visualization components adopts an approach evolved from previous research and combined with the Model-View-Controller design pattern. 6.1 From Data View Configuration to Visualization As addressed in the introduction of this theses (Section 1.2), a project manager usually interacts with project information and IT tools through user interfaces that provide some form of information visualization to the user (in the presentation layer of the information system). By and large, existing IT systems focus on individual data views, and their interfaces utilize limited visualization (e.g., presentation of limited data dimensions) (Songer et al., 2004) and they were usually defined during software development as opposed to being user-configured. However, there are relatively few opportunities for a user to improve these traditional interfaces; they have minimal and generally weak treatment of integrated and multi-dimensional project information. UCPMA\u00E2\u0080\u0099s objective for information visualization focuses on these issues, fostering generic, user-configurable interfaces for integrated and multi-dimensional project management information. Visualization Configuration Model 171 UCPMA follows certain procedures in information visualization (Spence, 2001) (Songer, et al., 2004). In the following, four stages are considered to be necessary to visualize construction management information. \u00E2\u0080\u00A2 Collect Data. At this step, business functional requirements are analyzed using UML technologies. Information elements involved are captured and structured in classes and business logic is represented in diagrams. All classes are combined into the Central Data Model that stores information within the specified business scope. \u00E2\u0080\u00A2 Filter Data. Only a limited amount of information is required for a particular analytical purpose by one party at a time. Data stored in the Central Data Model is queried and obtained through various mechanisms in the Data Winnow. Filtered datasets are organized in an appropriate way that facilitates data items mapping to graphic elements. \u00E2\u0080\u00A2 Map to Visualization Components. Data is not visualized randomly; visualization strategies serve as guidelines in symbolic coding. A visualization strategy is a plan of how to select visualization theories (regarding data type, density, etc.) in order to make data manageable, yet more understandable. \u00E2\u0080\u00A2 Render Views: Data is filtered and organized into smaller, interrelated datasets that reflect different perspectives. Each dataset is represented as a view or visualization instance (Nagappan, 2001). Views can be combined into a complicated one, thanks to underlying data interrelationships. Essentially, rendering a view is to lay out graphic components, arrange views on a screen, and make them as a whole, allowing dynamic user-computer interaction. Figure 6.1: Diagram of Information Visualization Process Procedures Visualization Configuration Model 172 As illustrated in Figure 6.1, previous chapters have addressed issues about the \u00E2\u0080\u009CCollect Data\u00E2\u0080\u009D and \u00E2\u0080\u009CFilter Data\u00E2\u0080\u009D stages for UCPMA. This chapter evaluates a full range of data presentation and visualization techniques, and proposes a cohesive approach supporting the \u00E2\u0080\u009CMap Data\u00E2\u0080\u009D and \u00E2\u0080\u009CRender Views\u00E2\u0080\u009D processes and being seamlessly integrated in the UCPMA framework. This work is called the Visualization configuration Model (VCM). The model is developed having four coaxial layers, which include Graphic Elements, Graphs, Views and Scene layers; visualization components in these layers establish correspondence to entities of the Data Winnow (Section 6.2, 6.3 and 6.4). The model takes advantage of a combined taxonomy which is developed to classify visual techniques used for multidimensional construction information visualization per various functional requirements (Section 6.5). The model is integrated through a derived coordination approach for binding individual visualization components together (Section 6.6). This related work constitutes a contribution of this chapter. 6.2 Concept of the Visualization Configuration Model 6.2.1 Model Definition and Roles in the UCPMA Framework In Section 3.2.2, the VCM was defined as a paradigm which visually presents data on a screen and dynamically configures data graphics in an appropriate manner to express abundant, yet easily understandable information. The VCM is one of UCPMA\u00E2\u0080\u0099s components, functioning at the top level of information presentation (referring to Figure 3.3). It is the most important unit in the UCPMA framework since the model supports provision of interactive interfaces where system requirements and functionalities are presented directly to end users. User-computer interactive interfaces can bring great benefits in flexibly formulating different goals and Visualization Configuration Model 173 illustrating meaningful information for analysis. VCM plays a critical role in fulfilling these requirements. Moreover, VCM is not functionally isolated, but integrated with the two other UCPMA\u00E2\u0080\u0099s components, the Central Data Model and the Data Winnow, to make the framework function as a whole. In fact, between the Data Winnow and the VCM, data items and images are tightly connected, as addressed below. 6.2.2 Initial Idea about the Model Information visualization theories offer great potential in presenting engineering data meaningfully so as to facilitate user-understanding and exploring hidden information value. The reality is, however, in the construction industry there is no predefined method which can be followed to represent construction data graphically; and few applications of construction data graphics focus on multidimensional data representation (Songer, et al., 2004). Moreover, according to our investigation of research and development, less effort has been directed to providing visualization flexibility for analysis purposes. Therefore, the need for a new method that supports construction data visualization with flexibility in user- computer interaction for effective data exploration prompts us to develop the VCM. The VCM draws inspiration from nature. Natural flowers consist of sepals and petals in different sizes, shapes, colors, and layers. A complex arrangement of flower components configured in diverse patterns appears naturally brilliant (see Figure 6.2). Enlightened by such a configuration, the VCM adopts a similar structure consisting of graphic elements, graph components, views and scenes, which are placed in coaxial layers. Such a structure supports the arrangement of data graphics in an appropriate way that can draw end users\u00E2\u0080\u0099 attention first to the overview and then to the details. Moreover, it facilitates flexible visualization configuration through simple drag-and-drop actions. Visualization Configuration Model 174 Figure 6.2: Flowers in a Natural View 6.3 Development of the Visualization Configuration Model 6.3.1 Model Schema As shown in Figure 6.3, the model consists of four coaxial layers. Different from other model structures or system architectures designed in layers where information typically flows from one layer to another, the VCM does not require information to flow between layers. Rather, it arranges all relevant information items for explicit presentation in a view(s). Moreover, the VCM schema shows a hierarchical relationship between layers where graphics in an outer layer are composed of those in a direct inner layer, while some systems, e.g. an AutoCAD system, display an organizational relationship between layers in which all attributes combine to produce an entire image and make it distinct from others. Visualization Configuration Model 175 Figure 6.3: The VCM Schema The VCM\u00E2\u0080\u0099s four layers include: \u00E2\u0080\u00A2 Graphic Elements Layer. Located at the center, this layer is composed of various atomic components, such as dot, line, button, etc., which may be in different sizes, colors, and tone and shade scales. \u00E2\u0080\u00A2 Graphs Layer. This layer presents simple graph components that are configured with graphic elements. Examples of graph components include, but are not limited to, table, bar chart, tree map, etc. \u00E2\u0080\u00A2 Views Layer. This layer presents common data views or user-defined specific views in visualization, which reflect a particular project issue from primary perspectives. A view may have one or many graph components to present its rich meaning. \u00E2\u0080\u00A2 Scenes Layer. This layer encompasses scenes composed of primary views presented in the Views layer. In a scene, views are user-interactive and coordinated with each other; information items in one view may be tied or linked to one or many items in another. Between the VCM layers, visualization components (including graphic elements, graph components, views and scenes) are bound together according to visualization strategies and Visualization Configuration Model 176 coordination methods which guide configuration of visualization from simple graph components to complex views. For example, selecting which shape, color or size to use in displaying an object depends on visualization principles and strategies; moreover, view coordination needs to be applied when combining relatively independent views to present their limited information interdependency. In Sections 6.5 and 6.6, visualization strategies and coordination methods will be further addressed. 6.3.2 Mapping from Data to Visualization In the VCM model, graph elements, graph components, views and scenes enable integrated presentation of project management complexities. These visualization components defined in layers establish correspondence to entities of the Data Winnow based on interdependent information relationships. Figure 6.4: Correspondence between Data Winnow Entities to VCM Components As shown in Figure 6.4, a graphic element represents a Data Winnow dimension\u00E2\u0080\u0099s member or its property; a collection of graphic elements forming a graph component in a visualization reflects members or their properties in a dimension. A view in a visualization, consisting of graph components, is a visualized dataset (mentioned in Section 5.2) linked to one or many dimensions; or it presents a Cube with numerical variables. Combination of dimensions in a view leads to a complicated multidimensional model or so-called nD model Visualization Configuration Model 177 (Salford 2003); accordingly, combination of many primary views makes a specific complicated view or a scene. In addition, Figure 6.4 also indicates layers\u00E2\u0080\u0099 hierarchical relationship as mentioned in Section 6.3.1, as well as their interactions which enable VCM integration. Detailed interactions between layers are addressed in Sections 5 and 6. 6.3.3 Model Advantages A relational data model, based on primitives of records, fields, tables, etc., has advantages of convenient data navigation through various tables\u00E2\u0080\u0099 associations (one-to-one, one-to-many, and many to many), data consistency with unique identifiers (primary keys) and quick data extraction through the well-defined query language (North, 2000). The Data Winnow is built upon such a relational data model: a member is mapped to a record in a database and a property to a record field; a dimension stands for a queried table consisting of many records, while a model is represented with many interrelated tables. Due to established correspondence between the Data Winnow entities and the visualization components in the VCM, the advantages of the relational data model are inherited by VCM: \u00E2\u0080\u00A2 Information consistency can be automatically maintained if two visualization components are mapped to the same data item or dataset in a data model. \u00E2\u0080\u00A2 VCM-based interfaces are able to support dynamic user-computer interaction in formulating various requirements based on the relational data query language. \u00E2\u0080\u00A2 Configuration of visualization components in the VCM to users\u00E2\u0080\u0099 preferences becomes easy, since their mapped data items or tables are associated through primary keys in a data model. Moreover, due to visualization characteristics, the VCM enhances human visual cognition of explicit/implicit data relationships by making them more perceptible or touchable (e.g. by brush-linking). In addition, by utilizing a variety of visualization theories (visualization strategies, view coordination methods, etc.), the VCM benefits construction project management with rich multidimensional data presentation. Visualization Configuration Model 178 6.4 Visualization Components The visualization components are grouped into four categories according to their layers. These four categories are Graphic Element, Graph, View and Scene. Figure 6.5 shows a representation of these categories in Microsoft Visio UML notation, in which classes abstracting relevant categories of information are displayed with rectangles, and lines with blacked diamonds indicate one-to-many class composition relationships. Figure 6.5: The VCM\u00E2\u0080\u0099s Data Schema 6.4.1 Graphic Element A Graphic Element is a type of atomic visualization component which is often used to encode data or indicate intentions such as task reminder, trend, flow, etc. Accordingly, there are two sub-categories of Graphic Element: glyph and icon, as shown in Figure 6.6. On a screen, a glyph marks data and an icon indicates intentions. Glyph components are referenced to (Stolte et al., 2002) (Bertin, 1983). Each glyph component has retinal properties of shape, size, orientation, color, and texture, which are helpful for end users to discriminate data record meanings from one another. In addition, a glyph component may have properties of position (e.g. relative or absolute coordinates) and transparency. As for icons, they typically appear to be buttons, navigating bars, reminder images, etc., which assist in data exploration and may be linked with an event or be clarified with text. A detailed discussion of visualization strategies is provided in Section 6.6. Visualization Configuration Model 179 Figure 6.6: Taxonomy of Graphic Elements and Retinal Properties 6.4.2 Graph Graph here refers to a visual technique comprised of multiple graphic elements and rendering them on a 2D (or 3D which consists of several 2D projections) coordinate system. Different combinations of retinal properties and other graphic attributes (e.g. position, temporal) have produced the innumerable types of graphs currently applied in the engineering field (see samples in Figure 6.7). These graphs are categorized into groups according to, for example, attribute value types (Stolte et al. 2002), presentation modes (Keim, 2002), data types of data items in visualization (Shneiderman, 1996) (Qin at el., 2003) (Songer et al., 2004), etc. From these categorization systems, development of the VCM utilizes the \u00E2\u0080\u009Cdata types\u00E2\u0080\u009D categorization approach since it provides clear guidelines for system developers or end users to select graphs suitable for specific data presentation. In this approach, data items for visualization are identified to have seven types (Shneiderman, 1996): \u00E2\u0080\u00A2 1D. Example 1D graphs are pie charts, histograms, etc. This type of graph may be used to illustrate a particular field of a record. \u00E2\u0080\u00A2 2D. Typical 2D graphs such as scatter plots fall into this type. This type of graph is usually used to discover patterns, trends, and relationships. Visualization Configuration Model 180 \u00E2\u0080\u00A2 3D. A typical 3D graph is a 3D geometric model. Usually it is used to understand objects' position, orientation, etc. (Shneiderman, 1996). \u00E2\u0080\u00A2 Temporal. A graph with time series reflects a procedure or uncovers trends over time. \u00E2\u0080\u00A2 Multidimensional. Graphs in this type encompass those in 2D or 3D, but with multiple attributes on a graphic element (e.g. stock plots), or a combination of them. \u00E2\u0080\u00A2 Hierarchical. Graphs in this type typically have trees and tree maps. This type of graph is often used for exposing parent-child relationships among records or data items. \u00E2\u0080\u00A2 Network/Graph. A typical example used in the construction industry is the Critical- Path-Method (CPM) diagram featuring acyclic, lattice, rooted/un-rooted, directed/undirected styles (Shneiderman, 1996) and is usually applied to find the optimal solution. Figure 6.7: Sample Graphs in the Engineering Field: (1) pie chart displays 1D data; (2) scatterplot display 2D data; (3) 3D geometric model; (4) stock chart shows temporal data vs. daily stock volume; (5) CPM shows network/graph data; (6) tree and (7) tree map displays hierarchical data; (8) fisheye and (9) histogram displays multiple dimensional data. Visualization Configuration Model 181 6.4.3 View Views at the UCPMA presentation level (Figure 3.3) intuitively reflect an issue or process (named as Scene) from different perspectives. In Chapter 5, we identified five views, common in construction project management, and represented them in data models. These include Context View, Plan View, Supply View, Effect View and Reference View. Users may design new views or add external views from commercial software tools as required. Integration of new or external views with the set of common views requires a visual coordination model (addressed in Section 6.6). Given views designed at the data layer, the next step is to design views in the presentation layer. Section 6.5.1 suggests guidelines for visualizing construction data from different perspectives. The mechanism is to configure graph components into views, where each view may consist of one or many graph components. Figure 6.8: Primavera Cost-Schedule Based Performance View Figure 6.8 shows an example. (Primavera, 2004) presents a cost-schedule based project performance view including four interfaces. Each interface contains one graph in a distinct visualization strategy (color, shape, size, texture, background, etc). This performance view Visualization Configuration Model 182 presents cost and schedule data in three combinations of axes and project earned values in a project matrix, in order to discover project problems and trends. However, this view reflects only the cost perspective of project performance and is limited in effectiveness by user- computer interaction. For example, users may demand a view of performance from a schedule or resource perspective, or want to change a line chart into a bar chart, or to show detail performance in a certain phase. The example view does not have this type of flexibility. By contrast, UCPMA with its Visualization Configuration Model provides this functionality (see Section 7.3) . In this research, a desired characteristic of visualization is flexibility so that users can quickly change visualization parameters by shifting query variables based on OLAP, and by drag-and-drop, views can be configured to user preference if data items marked by visualization components are interrelated in the model. Sections 6.7 and 7.4.5 will address and demonstrate this UCPMA flexibility. 6.4.4 Scene A scene reflects a theme in which project participants are interested. The theme may deal with one of the eight primary project management functions identified in Section 4.2.3, or a user-defined specific process, and it usually involves a great bulk of information represented in a complicated data model with many interdependent variables and several levels of detail. Learning and understanding this information consumes a high cognitive overhead for project participants. Scenes provide potential for reducing such cognition overhead. A scene integrates multiple views, which may be drawn from the set of common views identified in Chapter 5, or be user-defined specific views. These views reflect a theme\u00E2\u0080\u0099s different facades, their underlying information stemming from sub-models or model aspects of a central data model. In addition, a scene indicates what views need to be included, determines the layout of these views on a screen, and explicitly specifies their relationships. Comparatively, a view presents detailed information, while a scene displays an overview and exposes insights into, for example, trends, causal relationships, etc. Visualization Configuration Model 183 A sample scene of the change order process, based on the VCM, is illustrated later in this chapter (Section 6.7); it looks similar to the Multiple Building/Product Views of Autodesk Revit (shown in Figure 2.7). The Revit system includes a container that holds views of Floor Plan, Ceiling Plan, Section, and 3D. These views also share data in a data model so that changing or highlighting a component in one view will be automatically reflected in others respectively. However, a scene in the VCM is built upon data for the entire construction project rather than just design data. It is intended to show different facades of a construction management process, instead of a physical product for design. Moreover, the Revit system seems to lack the functionality of flexible data exploration for various disciplines and at management levels. 6.5 Visualization Principles and Strategies Given rich construction data treated with the Data Winnow (Chapter 5) at one end, and the data visualization techniques (such as those shown in Figures 6.6 and 6.7) at the other end, an important issue is to determine an appropriate way of encoding multivariable data items and representing them meaningfully and effectively with available visual techniques. Visualization principles and strategies are guidelines that bridge these two ends. In the following sections (from 6.5.1 to 6.5.4), visualization principles and strategies are reviewed to establish a solid foundation of visual techniques for VCM development. The research work here contributes a combined taxonomy to classify visual techniques for appropriately presenting construction management data in identified common dimensions and fulfilling various functional requirements via interfaces. 6.5.1 Visualization Principles Through literature review and investigation of several commercial tools\u00E2\u0080\u0099 interfaces (mentioned in Chapter 2), some primary visualization principles are summarized as follows. Visualization is not the end; rather, it is developed to support decision-making. Therefore, to develop visualization graphs, consideration should be given to data and functional Visualization Configuration Model 184 requirements. In this research, the visualization taxonomy by data type (Shneiderman, 1996) is referenced as visualization development strategies. Moreover, visualization should consider data density and color distinguishability. Displaying more data items in a view offers greater potential in finding information relationships. Minimizing color types and selecting an appropriate color scale help users to avoid confusion in distinguishing attributes. In addition, as mentioned in Section 6.4.4, a theme usually involves information with many interdependent variables and several levels of detail. Presentation of this information calls for multi-view visualization since it is impossible to convey all information variables and their relationships in one view in a simple way. Multi views are needed when different views can bring out correlations and/or disparities (Baldonado et al., 2000). A key point in utilizing multi-views is view consistency. It has two aspects: consistency of view status and consistency of view contents. Consistency of view status demands paralleling views. For example, choosing a component in an Autodesk Revit 3D view provokes exposure or highlighting of the component in plan views. Consistency of view contents requires consistent data representation across views. For example, in a traditional schedule view, activities are shown on a weekly basis; in a resource view for specifying activity resource usage, resource quantities should also be based on the same time series to avoid confusion or mental cognition overload. Likewise, the same color can be used to present a particular attribute in different views. 6.5.2 Visualization Strategies A visualization strategy here refers to a plan that uses visualization theories and computer techniques to represent a set of quantitative or qualitative data items visually so that the data items and their possible interrelationships can be easily understood and employed for business analysis. Visualization strategies are concerned with several issues: what is to be visualized (content, mentioned in Section 6.4.4), for what purposes (functional requirements), which graph(s) is to be used, and design of glyph components\u00E2\u0080\u0099 retinal properties. Corresponding to these issues, the following subsections address detailed technical review of visualization strategies and their application guidelines. Users may have Visualization Configuration Model 185 their own preferences following the basic visualization principles mentioned in Section 6.5.1, which promises cognitive effectiveness. 6.5.2.1 Functional Requirements and Interactions Functional requirements for visualization are referred to in several pieces of research (Wehrend et al., 1990), (Zhou et al., 1998) and (Qin, et al., 2003). These requirements include locating, identifying, distinguishing, categorizing, clustering, distributing, ranking, comparing, associating, correlating, revealing, outlining, emphasizing, portraying, quantifying, tracing, mapping, and generalizing. To some extent, these requirement tasks overlap in functionalities, yet they form a broad scope covering user intentions for visual analysis. Here, for simplicity and data analysis, these requirements are grouped into six types: \u00E2\u0080\u00A2 Overview, to get a general view of the dataset. \u00E2\u0080\u00A2 Detailing, to locate, identify and quantify a particular data item. \u00E2\u0080\u00A2 Comparison, to compare the same or similar attributes. \u00E2\u0080\u00A2 Clustering, to gather data items into groups. \u00E2\u0080\u00A2 Dependency, to expose data items\u00E2\u0080\u0099 relationships (e.g. causal relationship). \u00E2\u0080\u00A2 Distribution, to seek data evolution trends or patterns. Visualization fulfills these functional requirements by allowing users to interact with visualization components, and by ensuring that the presentation is implemented in such a way as to support user-computer interaction. Shneiderman (1996) proposed seven such tasks including overview, zoom, filter, details-on-demand, relate, history, extract. A similar set of tasks is proposed in (Spence, 2001): zoom, pan, overview, scroll, brush-link, focus and referred details (between views), and eyefishing (to remove irrelevant data). The orthogonal classification system (Keim, 2002) indicates presentation tasks including projection, filtering, zoom, distortion, link and brush. Generally, presentation tasks mentioned above form a body of visualization interactions supporting data exploration. Based on these interactions, visualization coordination, which Visualization Configuration Model 186 incorporates interaction and system response within a view(s), will be effectively implemented in the VCM. 6.5.2.2 Data Type versus Graphs Appropriate classification of visual techniques can help system end users or visualization developers to choose the right graphs for data analysis. Several taxonomies are proposed for the purpose (as described in Section 6.4.2). These include the attribute value type dependent taxonomy, the presentation mode dependent taxonomy, and the data type dependent taxonomy. Of these proposals, this dissertation takes the taxonomy by data type as the basis of visualization classification since determining a particular presentation heavily depends on the application domain, user and task (Spence, 2001), and the data type taxonomy enhances understanding of data that is visually presented. Figure 6.9: Visual Strategies by Data Types (Songer, et al., 2004) According to the data type taxonomy, Songer et al. (2004) further presented categorizes of visual techniques or visual strategies in a table. Figure 6.9 lists seven data types of data items for visualization: 1D, 2D, 3D, Multidimensional, Temporal, Hierarchical and Network. Corresponding to each data type, a number of visual techniques (termed Graphs in the VCM) are enumerated. This work benefits the development and implementation of the VCM. For example (see Figure 5.1), cost dimensional data items, which are organized in levels of cost Visualization Configuration Model 187 division, cost section and cost item, displays hierarchical characteristics. Guided by the table, cost data can be presented in a tree or tree map graph since these graphs are widely recognized as hierarchical structures showing parent-children nodes at various levels. 6.5.2.3 A Combined Taxonomy Classifying Visual Techniques In research and development, the taxonomy by data type governs in selecting appropriate visual techniques for visualizing data. However, utilizing this taxonomy by only one factor (data type) does not improve much operability of visualizing multidimensional data since appropriate presentation usually relies not only on data type, but on functional requirements, visualization theory, user preference, etc. Thus, Keim (2002) proposed a conceptual orthogonal visualization classification method (as shown in Figure 2.16), by which visual techniques are supposed to be suitable in conjunction with any data type and interaction. Qin et al. (2002) proposes frameworks from the user\u00E2\u0080\u0099s point of view and from the developer\u00E2\u0080\u0099s point of view (see Figure 2.15). In this research, a taxonomy for classifying visual techniques based upon Keim, Qin, and Songer\u00E2\u0080\u0099s work is established. It considers data type, functional requirements, visual techniques and domain application as necessary factors. As shown in Figure 6.10, in six identified dimensions, there is no single dimension that encompasses data items (such as map, planner, etc.) of the 2D data type. Meanwhile, except for the Product dimension, all others can be presented in the visual techniques of 1D. Moreover, data in the Process dimension may have visualizations belonging to the Temporal and Network data types, if they are associated with the Time dimension. Similarly, each dimension may be presented in visual techniques of the Multidimensional data type, if extra attributes from other associated dimensions are added. In addition, all dimensions with levels can take techniques falling in the Hierarchical group to visualize their data items. Visualization Configuration Model 188 Figure 6.10: Identification of Data Types in Dimensions Figure 6.11: Requirement-based Classification of Visual Techniques Figure 6.11 represents a classification of visual techniques, based on user functional requirements which are grouped into six types (as mentioned in Section 6.5.2.1). In the tabular figure, the Visual Techniques column includes typical techniques corresponding to different data types, which are borrowed from Songer\u00E2\u0080\u0099s work. Other columns list the six Visualization Configuration Model 189 requirement types. Under each column of functional requirements, a checked mark indicates that this type of requirement may be implemented in corresponding visual techniques. For example, visualizations in 2D, 3D, Hierarchical and Network types facilitate exploration of data dependency through user-computer interaction. In addition, visual techniques within different data types can be combined to fulfill many functional requirements. 6.5.2.4 Application of Retinal Properties. Appropriate use of retinal properties in visualization can improve understanding of data and quick grasp of issues (difference, trends, patterns, etc.). Referring to (Stolte et al., 2002) (Spence, 2001), the VCM takes advantage of retinal properties including shape, size, orientation, color, and texture. Shapes are typically applied for distinguishing different attributes. For example, in Figure 6.12, a bar stands for an activity, and a diamond indicates a milestone set to the activity. Different glyph sizes usually represent attribute numerical or ordinal values. Colors can be used to distinguish different attributes, the same attributes but different values, or patterns. Again in Figure 6.12, blue bars stand for non-critical activities, while red bars indicate activities on the critical path. Moreover, orientation can be set for a data pattern or a temporal data item; different orientations may be used to denote items\u00E2\u0080\u0099 sequences. In addition, textures used in the construction domain often indicate different materials. Figure 6.12: An Example of Project Schedule in a Gantt Chart Visualization Configuration Model 190 6.6 Visualization Coordination Multi-views support voluminous multidimensional data presentation. Integration of multiple views calls for visualization coordination which harmonizes visual performance in various strategies. Through coordination, user interaction in one view generates a direct response (e.g. content change during editing of data, data highlighting, or context scrolling for details) in other coupled views. This brings benefits of user performance improvement, discovery of unforeseen relationships within information, and unification of the desktop (North & Schneiderman, 1997). As a scene in the VCM consists of integrated views, the VCM requires view coordination for exploring multidimensional construction data. The following sections address and discuss visualization coordination theories and their application in the construction management domain. Section 6.6.1 introduces classification of presentation tasks for visual coordination design. Section 6.6.2 discusses the visual coordination mechanism. Section 6.6.3 reviews previous research on coordination models, and then proposes a new coordination model, combining advantages of previous peer efforts and tailored to UCPMA integration. On the whole, Section 6.6 focuses on application of relevant visual coordination theories in construction project management. The research work here contributes analysis and design of a visualization coordination model evolved from previous research efforts, as well as a proposal of its implementation using a MVC (Model-View-Controller) design pattern. 6.6.1 Classification of Presentation Tasks for Coordination Design As mentioned in Section 6.5.2.1, presentation tasks, including overview, zoom, pan, filter, scroll, details-on-demand, relate, brush-link, fish-eye drill-down, projection, extract, distortion, etc., fulfill visualization functional requirements. According to different system- responding modes, these tasks generally can be classified into three groups: \u00E2\u0080\u00A2 Navigating. Moving an item (image, icon, etc.) in one view synchronizes navigation of related items in other views. Example tasks include overview, zoom, pan, scroll, drill-down, etc. Visualization Configuration Model 191 \u00E2\u0080\u00A2 Transforming. Changing the standpoint of a view produces various \u00E2\u0080\u009Cfacades\u00E2\u0080\u009D of a dataset. Example tasks are filter, fish-eye, projection, distortion, etc. \u00E2\u0080\u00A2 Focusing. User actions such as details-on-demand, brush-link, relate, extract, etc. draw user attention to particular information or a set of data. Figure 6.13: Presentation Tasks vs. Functional Requirements In order to formulate selection of coordination strategies, a matrix of presentation tasks versus functional requirements is built upon research carried out by Shneiderman, North, Qin, and Keim (Figure 6.13). The matrix serves as a guideline in coordination design since effective coordination relies on functional requirements. In the matrix, a check mark at an intersection, for example between the Comparison requirement and the Transforming task group, indicates that this type of task is suited to comparison of different information items. In addition, tasks may be combined to achieve those unchecked requirements. 6.6.2 Coordination Mechanism The VCM calls for coordinating its model components between layers (shown in Figures 6.3 & 6.4). Coordination tightly couples two views or graph components through harmonizing content and appearance change, as well as graphic behavior response. For example, coordination with the brushing-link task often uses highlight colors: clicking a data item in one view will highlight the related or same data item in other views. Also, coordination with the filter task supports distillation of a dataset with queries, eliminating irrelevant data items Visualization Configuration Model 192 in order to obtain the required data items with attributes used in queries. Panning is another good example of behavior coordination: selecting and focusing on a particular portion of data will cause related data to be enlarged and focused, as demonstrated in Figure 6.14. Figure 6.14: Sample Coordination through Panning and Zooming In a coordination process, three types of elements are involved: a visualization component, a coordination model and a user action, as shown in Figure 6.15. A view may have more than one visualization component; each component may comprise several data items or objects. User actions or presentation tasks, which are organized in three groups as described in Section 6.6.1, are implemented in VCM to support integration of visualization components. A coordination model serves as a coordination mediator between the visualization components. Once a user acts on a component, an event is triggered and the relevant message (invoker, action type, influenced data, etc.) is distributed to other associated components, supported by the model. Affected components may then respond to notification and feed back through the coordination model. The coordination model may work as a translator if data items come from heterogeneous resources. Visualization Configuration Model 193 Figure 6.15: View Coordination Scenario 6.6.3 Visual Coordination Model Design of visual coordination requires modeling coordination processes. A coordination model represents coordination interaction with semantic notations, helping users to understand and effectively develop systems with view-coupling functionalities. Several models have been proposed for coordinating views or interfaces. These may be standalone initially. Typical models include the Snap model (North 2000) and the CViews related model (Boukhelifa & Rodgers, 2003), which were mentioned in Section 2.3.4.2. Snap is a salient method of coordinating views, utilizing concepts of relational database design. It takes a data-centric approach; however, if coupled views come from external systems, data access to these systems must be a prerequisite. The CViews related model seems more like a middleware based on MVC (Model-View-Controller) design, utilizing translation functions for different views, and adopting an event-based architecture. This research combines their advantageous features and tailors them for the integrated VCM. Further investigation and study of coordination models is beyond the scope of this research. 6.6.3.1 Coordination Formulation In terms of the Snap model, a user action invokes an event and can be expressed as: Event = (graph, action, dataset) Coordination can be expressed as a pair of two events, in which datasets must be related (in a one-to-one or one-to-many relationship), or may be the same: Visualization Configuration Model 194 Coordination = (Event1, Event2) = ((graph1, action1, dataset1), (graph2, action2, datasets)) Thus a scene in the VCM becomes a function of views and coordination as follows: Scene = (V, C) Where: V = (v1, v2, \u00E2\u0080\u00A6,vn) vi = (graphi1, graphi2,\u00E2\u0080\u00A6, graphin, dataseti) C = (c1, c2, \u00E2\u0080\u00A6, cm) cj = ((vp, actionp), (vq, actionq)) vp, vq\u00E2\u0088\u0088V This formula resembles North\u00E2\u0080\u0099s coordinated-visualization interface (CVI); yet it supports view-coordinated visualization where there may be more than one graph in each view. 6.6.3.2 A Derived Coordination Model From the semantic coordination formulation, a coordination data model is derived, shown in Figure 6.16. The model consists of the Coordination class, the Register class and the View class, defined according to the VCM model. The Coordination class defines various coordination events as objects which serve as mediators between connected views (Boukhelifa & Rodgers, 2003). The Register class constructs instances of linkage between views and keeps information about actions that each selected view encompasses. The model is distinct from Boukhelifa\u00E2\u0080\u0099s coordination model, in that instead of defining translation functions, coordination objects directly receive user instructions relevant to views, datasets and actions, and sends them to other associated views based on underlying data interrelationships. Figure 6.16: The Visualization Coordination Data Model in Microsoft Visio UML Notation Visualization Configuration Model 195 Consider a scenario where multi-views are coordinated and response to user actions is bidirectional. The scenario can be represented with a graph data structure in which visualizations are nodes and coordination connecting two nodes is labeled as edges (North 2000). Thus, there is an issue about propagation conflict that must be addressed. For example, a user triggers an event in view A, which invokes view B to respond. A bidirectional coordination makes it possible that the view B may in turn invoke view A to respond. To deal with this issue, the coordination model requires that an event message propagated to affected views include the initiator ID and the action type. The model then records these information items, and uses them to block off those responses which try to make a coordination execution cycle. 6.6.3.3 MVC Design Pattern Associated with the Coordination Model Figure 6.17 shows the MVC diagram associated with the derived coordination data model (D' Aoust, 2002). The MVC implies implementation of the Observer pattern. As introduced in Section 2.5.2, the Model-View-Controller (MVC) design pattern separates data from interface. Combined with the Observer pattern, the Model in such an MVC design can notify affected elements including views. Visualization Configuration Model 196 Figure 6.17: MVC Diagram Implying the Implementation of the Observer Pattern (D' Aoust, 2002) In this design scenario, the Subject class stands for a base class for distributed events; the Observer class abstracts interfaces; the Abstract View class generalizes various interfaces; the Model class stores views\u00E2\u0080\u0099 data, as well as information captured by the Coordination and Register classes of the derived coordination model. The Controller and Observer classes in the MVC diagram provide functionalities required by the Coordination and Register classes denoted in the model. The mechanism of the MVC may be summarized in the following steps. As a user interacts on an interface (a concrete view), an event is triggered and sent to the Controller via an observer object. Each interface embeds such an object inherited from the Observer class. The Controller receives the sent event with user-computer interactive information, draws data from MVC\u00E2\u0080\u0099s Model, and then propagates the event message as well as relevant data Visualization Configuration Model 197 retrieved from the Model to all affected, registered, observer objects. These objects at last notify their hosting subject objects to respond according to requirements. Implementation of MVC may vary from system to system. Section 7.2.3 will describe a simplified method applied in the implementation of a UCPMA prototype system. 6.7 Presentation of the Change Order Process in VCM Previous sections (from 6.2 to 6.6) present a unique visualization configuration model for construction management information visualization, which features four coaxial layers; components in those layers follows a combined visualization classifying taxonomy and are bound in a derived coordination model. In this section, visualization of the change order process in the presentation layer, as an example, is provided to illustrate the proposed VCM model. Example snapshots are taken from a UCPMA system prototype developed from scratch. Chapter 7 will address how the prototype is developed and how users can produce these examples using the system. Figures 6.18.1 to 6.18.5 display five interfaces which visually present information captured in the change order process\u00E2\u0080\u0099 five view schemas (Section 5.5). These views form a scene of the change order process; they are not complete, but present the process\u00E2\u0080\u0099 primary attributes according to five identified perspectives that are generic to project management. The set of views is constructed following the requirements of the VCM. For example, the Supply view comprises graphic components of the tree-list, customized Gantt chart, and attributes table- list. Among them, the customized Gantt chart graph consists of graphic elements (horizontal bars) in different colors, as well as a time scale. Configured from graphic elements and graph components to views, and then to the entire scene, these figures demonstrate the VCM\u00E2\u0080\u0099s configurability. As described previously in this chapter, views at the data layer and presentation layer establish correspondence based on data interrelationships. For example, the Context view at the presentation layer has a schedule graph component which is associated with Workflow and Time dimensions at the data layer; and different colored bars as elements of the graph Visualization Configuration Model 198 component display objects in the data model, standing for one change order instance processed within a certain time span. The established correspondence enables coordination between graph components within a view or multiple views. For example, in the Reference view, graph components of list, list view and document browser are integrated by visual coordination. An end user\u00E2\u0080\u0099s selection of one item (a document) in the list will trigger an event to display the item\u00E2\u0080\u0099s attributes in the list view and to open the file in the document browser simultaneously. Figure 6.18.1: Context View Presenting the Change Order Process Visualization Configuration Model 199 Figure 6.18.2: Plan View Presenting the Change Order Process Figure 6.18.3: Supply View Presenting the Change Order Process Visualization Configuration Model 200 Figure 6.18.4: Effect View Presenting the Change Order Process Figure 6.18.5: Reference View Presenting the Change Order Process Visualization Configuration Model 201 6.8 Conclusions This chapter presented the VCM (Visualization Configuration Model) for information visualization. The model was built in a coaxial layered structure, consisting of graphic elements, graph components, views, and scenes which range from the inner center to the outermost layer. The structure of the VCM is comparable to the structure of the Data Winnow, and mapping from VCM components to Data Winnow entities enables visual configurability and information integration between layers. Although visualization is common in project management tools, the VCM model is unique since it provides a strong structure for configuring graphical elements at various layers into visualization interfaces for run-time-defined, multi-dimensional data views (including coordinated user-input between the view elements) in support of project management data analysis at visualizations. Initiation and development of this model is the main contribution of this chapter. As a by-product of the primary contribution, the chapter also presents a combined taxonomy for classifying visual techniques used in construction information presentation. The taxonomy inherited merits of several research efforts in visualization principles and strategies. Moreover, the chapter proposed a derived coordination model to be implemented in a MVC (model-view-controller) design pattern. The coordination model enables individual components of VCM to communicate with each other in an integrated way. Since the study of visual techniques classification is not the focus of the thesis, it will not be discussed further. Finally, the model was illustrated with a presentation of the change order process in five common views. Implementation and evaluation of the VCM, as well as the whole UCPMA framework, will be illustrated in Chapter 7. System Implementation and Evaluation 202 CHAPTER 7: SYSTEM IMPLEMENTATION AND EVALUATION This chapter describes the development of a prototype system that illustrates the UCPMA framework for an Information Aggregator. Its components include a database, data analysis services, a view engine, and visualization configuration modules. The chapter also describes uses of the system, and testing of construction project change order process, as well as quality and risk control process cases for validating the framework architecture and examining its capabilities of integrating data representation, dynamically configuring data views and creating views and scenes in visualization for common construction project management purposes. At last, the results of the system implementation and testing are summarized. 7.1 Introduction The UCPMA framework consists of three integral components (Chapter 1 and 3), which together fulfill the framework\u00E2\u0080\u0099s functional requirements (Section 1.4) for an Information Aggregator in order to improve integration in three layers. As an approach for proof-of- concept, a UCPMA-based prototype system was implemented, operated and tested with construction project management cases, including a change order process, a risk management process and a quality control process. Specifically, implementation, operation and testing of the system are intended to illustrate the framework\u00E2\u0080\u0094showing how the technical design works as an Information Aggregator\u00E2\u0080\u0094 and to use the three integration problems to evaluate the ability to accommodate all common information for the identified primary PM functions in the Central Data Model, to dynamically configure end-user-designed data views, and to support PM information visualization, view coordination and user-interactions on visualized views. System Implementation and Evaluation 203 In the following sections, Section 7.2 describes the UCPMA prototype system and its implementation, Section 7.3 describes evaluation criteria, and demonstrates evaluation through two major processes: user operations on the system and validation through testing cases. In addition, Section 7.4 addresses summary of evaluation results. 7.2 The UCPMA Prototype System and Implementation 7.2.1 Overview of the System The prototype system, named the Unified Construction Project Management Arena (UCPMA) System, is implemented in the Microsoft Visual Basic .Net environment and its data layer is built upon Microsoft SQL Development Server and Analysis Services. The system mainly consists of a database, data analysis services, a view engine, and a visualization configuration module. Figure 7.1 displays their functional interrelationships, in which components in solid lines have been developed (see Section 7.2.3), while those in dash lines have not or are partially implemented. A user can give an instruction to configure or change views and scenes through the View Setup interfaces, invoking the View Configuration Module. Once receiving the instruction, the module communicates with the View Engine, requesting a response. The View Engine then deals with the request: reading configuration data in the database or fetching a configuration message packed in the user\u00E2\u0080\u0099s instruction, generating a visualization instance, populating it with project data also stored in the database, and presenting it to the end-user; meanwhile, the Engine saves all new or updated view configuration data in the database. Moreover, a user can also interact with views by actions such as navigating, clicking on an item, drilling data through Data Analysis Services, etc. The View Engine captures messages translated from these user actions, communicates with the database to read or write view configuration data and fetch construction project data accordingly, activate its controller to coordinate views if required, and then render all related information to the end user. System Implementation and Evaluation 204 Figure 7.1: Interrelationships among System Components These system components fulfill the key functions of the Central Data Model, Data Winnow and VCM, with the following exceptions shown in dash lines in the Figure 7.1: \u00E2\u0080\u00A2 Data exchange between different applications. The Central Data Model is built upon the IFC model, yet data exchange from other applications into and out of a central IFC model is beyond the research\u00E2\u0080\u0099s scope. It is assumed that data can be obtained from various sources. The system designed a few interfaces, e.g. the interface for importing product information from ArchiCAD with IFC and XML schema, for inputting some fundamental project management data to the UCPMA system, but further effort should be given to study on how to fetch data from other applications such as Timberline Cost Estimator, Primavera E/C, etc. System Implementation and Evaluation 205 \u00E2\u0080\u00A2 The research has implemented and tested most classes in the central data model schema (Figure 4.14). See Appendix B for implemented classes. However, a few classes, such as Meeting, Responsibility, CommunicationChannel, etc., are not used in testing cases and are uncompleted in the system. Moreover, Section 7.3.4.1.4 addresses selecting the Organization dimension to explore data on a view, yet further development should be carried out to test the Data Winnow with other dimensions. Implementing these requirements does not involve additional conceptual or technical difficulty, but they would require significant additional time. \u00E2\u0080\u00A2 Work is still required to incorporate external application views (AutoCAD, Timberline Cost Estimator, P3, etc.) as interactive visualization components into the UCPMA system. Some research efforts, e.g. the Snap-together (North at el., 2002), provide interesting solutions which, however, do not fit well with the UCPMA requirements. 7.2.2 System Architecture A project is like a drama performed by numerous actors cooperatively. The UCPMA system is intended to present a stage that exhibits construction project management events on a screen, emphasizing visualization of how cooperation among actors is achieved during progression from a virtual model to a physical entity. Analogous to the structure of a real theatre, the system is composed of a back stage and a front stage (Figure 7.2). The back stage, mainly consisting of a database, analysis services, and a view engine, provides services for storing and exchanging data, reading and translating instructions, \u00E2\u0080\u009Cmanufacturing\u00E2\u0080\u009D views according to user requirements and bringing them to the front stage, as well as coordinating views according to their relationships. The Central Data Model and the Data Winnow are implemented in this stage, which includes partial functionalities of the VCM. The front stage includes common views, custom scenes, as well as some interfaces for editing views and importing data from sources. It gives end users the ability to manipulate System Implementation and Evaluation 206 project data (input or output, browse, create, or edit, etc.). It also presents data in visualization for understanding and analysis, and supports decision-making through drilling data down to different levels and configuring custom views tailored to users\u00E2\u0080\u0099 specific requirements. This stage is the main site for implementing the VCM. Figure 7.2: System Architecture In the system implementation, components in these two stages are organized in three logic layers according to their information flow relationships (referring to Chapter 3). As shown in Figure 7.2, the bottom is the communication foundation using data modeling and IFC technologies; the middle layer refers to OLAP technology and embodies visualization strategies. The bottom level and the middle level exist in the back stage, while, the top level System Implementation and Evaluation 207 presents configured views and deals with their coordination based on the Model-View- Controller pattern. 7.2.3 System Implementation 7.2.3.1 Database The database is a central data repository developed on the Central Data Model. Figure 7.3 lists conceptual classes consisting of the Central Data Model. Among them, classes in Italic font and grey color are not implemented in the prototype; yet, this incomplete implementation does not impact testing of the overall functions of UCPMA as an Information Aggregator (see evaluation result in this chapter). Figure 7.3: Implemented Classes of Central Data Model System Implementation and Evaluation 208 Data items in the model are organized into various model aspects according to different functional requirements. As shown in Figure 7.4, the prototype system embodies ten data aspects including: Cost, Document, Organization, Process, Product, Project, Resource, Time, Quality and Risk. For design convenience, the Workflow aspect is separated from the Process aspect. Each aspect consists of many dimensions. For example, the Process aspect includes dimensions of Task_Sequences, Task_Constraints, as well as Relationships with Actors, Projects, Resources, etc. (Figure 7.5). The database is implemented on Microsoft SQL Server; Appendix B presents the nine data aspects implemented on this commercial platform. During prototype development, the names of model classes were simplified in the database tables shown in Appendix B to simplify programming and debugging; additional classes were added were necessary to reify some class interrelationships and facilitate object navigation. Figure 7.4: Aspects of the Central Data Model System Implementation and Evaluation 209 Figure 7.5: Process Aspect - Process Data Model Schema 7.2.3.2 Data Analysis Services The Data Winnow component for PM data analysis services is implemented upon the Microsoft OLAP Services, integrated with a data translator module and a view adaptor module in the View Engine (Section 7.2.3.3) in order to process numerical and non- numerical data, since most of current OLAP-embedded applications are effective in dealing with numerical data only. In particular, the UCPMA makes use of the data modeling constructs provided by Microsoft OLAP services (dimensions, cubes, etc.) and the OLAP abilities to combine, select, and filter data using these constructs (providing navigation and filtering operations such as \u00E2\u0080\u009Cdrill-down\u00E2\u0080\u009D and \u00E2\u0080\u009Cslice-and-dice\u00E2\u0080\u009D). It does not use OLAP functions for performing numerical operations across these data constructs. System Implementation and Evaluation 210 The Data Winnow consists of a set of entities providing functionalities for data analysis services, with which information in the Central Data Model can be virtually structured in dimensions. In turn, dimensions can be configured into a view. Furthermore, each construction process, such as the change order process, can be treated as a complicated view or combination of multi-views. In the prototype system, besides the seven identified primary dimensions, namely Actor, Cost, Document, Process, Product, Resource, and Time, there are five other dimensions: Group, Location, Organization, Workflow, and Project (Figure 7.6). Among them, the Project dimension is designed for drilling down or aggregating information items to different project levels in a multi-project management environment. The Group dimension displays disciplinary categories. The Location dimension displays information on physical product locations described in Section 4.3.2.4. The Organization dimension represents information regarding organization and human resources. And the Workflow dimension deals exclusively with representing workflow processes information. Each dimension encompasses many levels. For example, the Process dimension includes phase, stage, task and activity levels. (Implementation of seven common dimensions refers to Appendix C; detailed definitions of dimension levels are addressed in Chapter 5). Figure 7.6: Dimensions and Process Dimension Schema System Implementation and Evaluation 211 Leveraging the Microsoft OLAP Services application in the UCPMA system, users can select or change levels by picking the data table attributes in the schema window. On an interface, a panel docking on the system mainframe lists all scene-specific dimensions in a tree list for user manipulation (Figure 7.7). However, in the Microsoft OLAP Services system, a cube is a set of related dimensions constructed with numerical data, and each cube includes a single fact table from which cube measures are derived (MSDN, 2006). In order to process non-numerical data, the UCPMA prototype combines the OLAP technology with the MVC design pattern. In this way, an end user\u00E2\u0080\u0099s instruction of, for example, selecting a dimension or its levels is translated into the standard SQL language (Figure 7.8), by which the adaptor module in the View Engine obtains filtered data and passes it to those associated views which are affected. Figure 7.7: Dimension Panel Listing Dimensions for a Particular Scene and Scene Panel Listing Created Scenes for Project Management Figure 7.8: Sample of SQL Language for Selecting Designated Dimensional Data System Implementation and Evaluation 212 7.2.3.3 View Engine As shown in Figure 7.9, the View Engine consists of three modules: an Adaptor module, a Data Translator module and a MVC Controller module, of which the Adaptor and Data Translator are programmed from scratch using the Microsoft Visual Basic .Net application, and the MVC Controller is developed utilizing some classes from (D' Aoust, 2002). The Engine functions like a server in receiving user instructions through interfaces, translating user selections into view data input, creating views according to specified view parameters, and responding to user actions through view coordination. For example, to populate a Gantt Chart graph component in a resource usage view, a user may browse available data tables and select several fields in the DRES_TASK_USAGE and DTASKS tables to create a star-schema dimension (Figure 7.10). The user selection is converted to a string and saved in the database. To dynamically present a parameterized view, the View Engine takes the responsibility of splitting the string into parameters, transforming them into a compound SQL query for related tables (Figure 7.11), and constructing the required view by populating a view template. These functions are executed mainly by the Adaptor module and the Data Translator module. Figure 7.9: View Engine Components and Application Architecture System Implementation and Evaluation 213 Figure 7.10: Create View in the Data Layer Figure 7.11: Examples: Compound JOIN Queries View coordination is accomplished through an MVC pattern associated with the Observer pattern (addressed in Chapter 6). In the prototype system, a simplified view coordination model is adopted. As shown in Figure 7.12, one scene encompasses a concrete mediator object, and each mediator object implements an Observer object. Also, a scene may consist of one to many views, each of which comprises one to many GraphComponent objects. Links between Graph Component objects are registered by the Relationships class. As an end user manipulates one graph component in the system, user actions are recorded by the graph component. The graph then notifies the scene mediator through its embodied observer. After receiving an event-based notifying message, the mediator inquires Relationships (similar to a register) and propagates the message to those associated graph components which are affected. In addition, the system is designed to be scene exclusive; that means that no more than one project scene can be rendered to the screen simultaneously. Therefore, no human intervention is required to coordinate project scenes. Appendix D lists primary View Engine functions and displays information flow among its components. System Implementation and Evaluation 214 Figure 7.12: Simplified View Coordination Model Implying the Observer Pattern 7.2.3.4 Visualization Configuration Module The VCM has two basic conceptual parts: the view coordination model and a collection of visualization elements (namely graph elements, graph components, views, and scenes). In implementation, the view coordination model is organized in the View Engine, as mentioned in Section 7.2.3.3. A visualization configuration module, a system subroutine programmed in the Microsoft Visual .Net environment, is powered by the View Engine to create and edit visualization elements and their presentation layout. As shown in Figure 7.13, a menu item in the system main menu, named \u00E2\u0080\u009CSetup,\u00E2\u0080\u009D runs the module. Clicking the menu item, a visualization configuring window appears on the screen. It provides primary functionalities in creating and editing Graph Components Views and Scenes. System Implementation and Evaluation 215 Figure 7.13: Set up Visualization by Clicking a Menu Item 7.2.3.4.1 Graph Components The Graph Components page on the configuring window allows users to construct a new graph component or edit a registered one. As shown in Figure 7.14, an existing CAD Drawing Viewer graph component draws the users\u00E2\u0080\u0099 focus to edit. Users can change its name, window dock style, icon, and description. Also, users should be able to select preferred graph elements (dot, line, bar, etc.) to present a set of attributive data, e.g. to select a bar image for presenting a task duration and to set the highlighting color to red. However, in the current system, because of limited research time, few provisions have been provided for user-computer interactive convenience in this regard. System Implementation and Evaluation 216 Figure 7.14: Edit a Registered Graph Component At present, there are thirteen graph components built for generic purposes in the system. They are TableList, TreeList, ScheduleChart, DocumentViewer, Charts, ExternalApplication, DailyNoteBook, WorkflowIndicator, CADDrawingViewer, TextArea, ListView, AttributeList, and GanttChart, among which TableList, TreeList, Charts, DocumentViewer and CADDrawingViewer are developed by using Microsoft Visual Basic\u00E2\u0080\u0099s graphic classes, while others designed in Microsoft Visual Basic from scratch in order to make them fully suited in the UCPMA system. Their basic functionalities and images are tabulated in Figure 7.15. These graph components are registered and stored in a container. During view configuration, they are rendered to users in a graph button bar, as shown in Figure 7.16. To select a graph component for a view, users need only to click a button on the list, and then an unpopulated graph is created, floating on a view layout window. System Implementation and Evaluation 217 Figure 7.15: Built Graph Components for View Configuration System Implementation and Evaluation 218 Figure 7.15: Built Graph Components for View Configuration (Cont\u00E2\u0080\u0099d) Figure 7.16: Select a Graph Component by Clicking an Icon on the Graph Button Bar 7.2.3.4.2 Views View definition in the data layer is described in Section 5.4.2. The five common views including Context View, Effect View, Reference View, Plan View and Supply View, Graph Button Bar System Implementation and Evaluation 219 proposed for generic project management purposes, are shown in Figure 7.17 (and in Figure 6.18). Each of the graph components in one view presents data in single or two dimensions, while coordination of those graph components forms an integrated, multidimensional view. For example, the Supply view consists of graph components of TreeList, AttributeList and GanttChart. The TreeList displays a tree of resource types used for a particular task, the AttributeList displays the attributes value of each resource type, and the GanttChart presents resource dimension information (e.g. resource name, category) as well as task dimension information (start date, finish date, etc.). By establishing coordinated relationships among three graphs, the Supply view integrates data items from different dimensions into a whole: selecting an item in the TreeList highlights the related bar the GanttChart graph, and displays related attributes and their value in the AttributeList. Figure 7.17: Views Common to Primary Project Management Functions 7.2.3.4.2 Scenes A scene is a presentation of configured views in visualization. In the data layer, it is related to a complicated data model composed of multiple dimensions. On the visualization System Implementation and Evaluation 220 configuring window of the system, the Scenes page is exclusively designed for creating, editing and deleting scenes. Scenes\u00E2\u0080\u0099 attribute information is saved in the system database. Once the user quits the configuring window, the system\u00E2\u0080\u0099s Scene panel will update scene lists within the mainframe (Figure 7.7), provided any scene has been added or removed, or its attributes modified. When a user clicks an item on the panel, the system View Engine will use configuring parameters saved in the database to construct a scene comprising views as shown in Figure 7.17, for example. 7.3 System Evaluation As introduced early in Section 7.1, two types of evaluation processes are presented: a demonstration of the system operation, and series of test PM cases. The evaluation processes are intended to examine the ability of the UCPMA relative to the functional criteria required of an Information Aggregator (Section1.4). These criteria are as follows: \u00E2\u0080\u00A2 Data layer. o It must be able to accommodate the data that is common to the field of construction project management. o In order to combine data from a wide range of sources, it must be compatible with data exchange standards for system interoperability. \u00E2\u0080\u00A2 Logic Layer. o It must be possible to extract data views derived from the central data model. o It must be possible for users to define the data views at configuration time. o It should be possible for end users to work on partial models (data views) through manipulating dimensions and levels for specific analysis purposes. \u00E2\u0080\u00A2 Presentation Layer. o The system should present the PM data through appropriate and consistent user interface elements. o It should be possible for end users to dynamically generate their own custom views. System Implementation and Evaluation 221 o Users should be able to interact with the user interface elements to navigate and explore the data sets. In the following, Section 7.3.1 illustrates how users can operate the system to support change processes. Steps include partially populating the data model, dynamically creating a view and flexibly configuring a change process scene. Section 7.3.2 tests the system using several PM scenarios in order to examine the system\u00E2\u0080\u0099s efficiency in support of integrated PM processes and illustrate what potential it can bring to the current practice. Here, efficiency refers to 1) the ability to present views and scenes created by dragging and dropping view elements, and 2) promptness in explicitly displaying multidimensional view coordination. 7.3.1 Demonstration of Operations 7.3.1.1 Populate Data Model The Central Data Model can store voluminous information on multiple projects. Typically there are many change orders (e.g., sinkhole treatment, brick type replacement, etc.) involved in any medium or large sized project. Each change order may be divided into three phases: Change Initiation, Change Proposal Evaluation, and Change Order Execution. In each phase, there may be several tasks to be performed, and each task involves many information references and resource usages. Also, a change order may influence construction of one or many products in a physical model. Therefore, information including dimensions of Project, Workflow (the change order process is considered as a workflow), Task, Resource, Document, Product, Time, etc., is necessary for presenting the change order process in the UCPMA prototype system. In the system, two separate modules are developed for entering the information items mentioned above. Figure 7.18 demonstrates some (but not all) of the interfaces for entering project data in the dimensions of Task, Workflow, and Project Member, as well as data interrelations. System Implementation and Evaluation 222 In a complete implementation of the UCPMA approach, project data could be obtained from other sources. To illustrate this, Figure 7.19 illustrates how products could be imported from ArchiCAD 7.0. Through the embedded IFC2X Edition2 component, an ArchiCAD drawing can be saved as an IFC formatted file, which is, in turn, saved to an XML based dataset using Visual Basic .Net and IFC Server300. This prototype has not implemented the functionality to incorporate IFC formatted data from an application into the UCPMA\u00E2\u0080\u0099s data model, since it would require extensive programming effort without demonstrating any innovative capabilities. Rather, the research system requires that the project data be entered manually through the user interfaces described. Figure 7.18: Example Interfaces for Entering Project Data System Implementation and Evaluation 223 Figure 7.18: Example Interfaces for Entering Project Data (Cont\u00E2\u0080\u0099d) Figure 7.19: Import Product Data from the ArchiCAD Application System Implementation and Evaluation 224 7.3.1.2 Create a View To create a view, end users should understand first what information items need to be presented, in which data table they are stored, and whether two tables (if chosen), are associated. Procedures to create a view include the following steps: \u00E2\u0080\u00A2 View creation starts by constructing a view object by clicking the \u00E2\u0080\u009CAttributes\u00E2\u0080\u009D menu item on the visualization configuring window menu (Figure 7.20). Basic view attributes that need to be populated currently are ViewName and IconURL. After being defined, the view receives a unique ID in its data table. Figure 7.20: Define a View by Clicking the Attributes Menu Item \u00E2\u0080\u00A2 After a view has been defined, a user can design the view layout by adding graph components and arranging their locations on the screen. Figure 7.21 demonstrates three added graph components for the Supply view. Once these three components have been arranged, their locations and sizes are recorded and saved in the database. In the system, if this view is used in some scene, registered System Implementation and Evaluation 225 components will be presented according to their sizes and locations as the scene is called to show up. \u00E2\u0080\u00A2 Selecting a component in the view layout (for example, right-clicking on the \u00E2\u0080\u009CTableList\u00E2\u0080\u009D component) causes a new window to pop up for specifying attributes of the component. In addition to giving values to Component Name, Dock Style, Graph Border Style, and Show (dimension) Drop Area, a user should also browse available tables in the database and select fields to compose a view (model aspect) in the data layer. After data fields have been selected, the View Engine will translate user selections into required data and refresh graphs with specified data items. Figure 7.21: View Layout Design \u00E2\u0080\u00A2 In the view schema, added graph components are shown as icons (Figure 7.22). The schema window is for end users to link graph components together as an System Implementation and Evaluation 226 integrated multidimensional view (from 1D to nD). Here, users just need to drag an icon and drop it on another icon. It then shows a Relationship Editing window, where users can link two graph components if they have a one-to-one, one-to- many, or many-to-many relationship in the data layer. Users also can choose a \u00E2\u0080\u009Clink action\u00E2\u0080\u009D to specify the link purpose. For example, a \u00E2\u0080\u009CSelect\u00E2\u0080\u009D link action is chosen in this scenario; which means that selecting one item on one graph component can highlight related items on other graph components in the same view. Figure 7.22: View Schema Design In view creation, there is an outstanding issue that limits system flexibility. Compared with a general database management system such as Microsoft Access, the UCPMA system is not transparent enough for to easily allow users to compose views in the data layer. Browsing data tables and selecting fields can lead to mistaken relationships between graph components if end users do not fully understand the related data tables\u00E2\u0080\u0099 associations. This issue requires further investigation in future research. 7.3.1.3 Configure a Scene Like view creation, a scene can also conveniently be created by moving views listed as available into the new scene. Figure 7.23 displays an interface for configuring such a scene. System Implementation and Evaluation 227 At the right side, an embedded window allows users to preview views in order to correctly identify them during selection. Figure 7.23: Create a Scene by Adding Available Views to Its View List Individual views deployed in a scene should not operate separately. They need to be integrated by establishing relations between them. Figure 7.24 demonstrates how two views are related in the scene schema window. Just drag one view icon and drop it on another. A relationship editing window is then displayed. As in Figure 7.22, users define a relation by providing the view relation\u00E2\u0080\u0099s attributes and determine which graph component in one view links to a different graph component in other views. The basic mechanism for establishing a graph component\u00E2\u0080\u0099s relation or a view\u00E2\u0080\u0099s relation is to use primary keys in data tables and to associate graph data objects in the data layer, if applicable. System Implementation and Evaluation 228 Figure 7.24: Edit Relationships between Plan & Supply Views to Compose a Scene In Figure 7.21 and Figure 7.23, there is a box named \u00E2\u0080\u009CDrop Members Here\u00E2\u0080\u009D on the top of some graph components (e.g. the Resource Categories graph). This is an event-based textbox to which end users drag dimension members from the Dimensions panel (as demonstrated in Figure 7.7) and drop them in order to drill information down to different levels. Once it has received a message regarding user interaction, the View Engine (in the back stage) decodes the message into information drilling criteria, filters underlying data items according to these criteria, and refreshes the corresponding graphs with filtered or queried data. 7.3.2 Testing Scenarios This section describes testing scenarios with the UCPMA prototype system. The scenarios from 1- 5 are taken from the change order case used throughout the dissertation (refer to Chapter 1 and Appendix A); scenarios 6 and 7 from risk and quality cases of infrastructure construction for an oil sands project in Canada (Appendix E). These scenarios are typical and important in the construction industry. Through testing, the research presents the capability of the UCPMA framework, and also, analyzes what potential the UCPMA can System Implementation and Evaluation 229 bring to the industry and how different the UCPMA is from Primavera P3E/C, a typical representative of state-of-the-art software systems currently used in construction. 7.3.2.1 Scenario 1 \u00E2\u0080\u0093 Build up a Change Order Process Overview To understand the Sinkhole Earthwork change, a field engineer typically has to collect information from paper or electrical documents on what the change is, what time it requires to respond, how much (material, labor, equipment, etc.) it costs, what its process status is, how it impacts the work schedule, whether it begets other changes, etc. These information aspects involve disciplines such as cost, schedule, budget, scope, material procurement, workflow, etc. Once having gathered sufficient information, the engineer generates a mental model on which he may take several activities (e.g. tracking the change process, instructing to code work for billing, etc.). These activities may have several days or weeks\u00E2\u0080\u0099 interval from one to another, and in between the engineer involves a great number of other construction management tasks. Once he gets back to the Sinkhole change, he usually has to take time to recall most relevant information. The UCPMA system can present a scene reflecting primary information for most changes of a project and assisting to build up a quick overview. See Figure 7.25. The scene is composed of five common views. In this scenario, data items for change information from the dimensions of Document, Task, Workflow, Product, Resource, Time, and other related dimensions are fetched from the database. They are then consistently presented in the Reference View, Plan View, Context View, Effect View, and Supply View respectively, according to visualization strategies formulated previously. To present the scene, the engineer needs only to navigate listed items on the scene panel (Figure 7.7) and click the Change Orders button. Once receiving a user instruction, the system automatically sends a message to the underlying View Engine for visualizing change order processes. Since such a scene has been set up following steps addressed in Section 7.3.1, the View Engine populates a scene instance with change orders\u00E2\u0080\u0099 data and visualization configuration information stored in a database. The database was built upon a Central Data Model and the scene visualization is configured on a VCM. System Implementation and Evaluation 230 To look into the Sinkhole Earthwork process, the engineer selects the \u00E2\u0080\u009CSinkhole Earthwork\u00E2\u0080\u009D process in the Context view. Immediately upon the process being selected, a Gantt Chart bar in the same view is highlighted in red color. This highlighted bar visually stands for the designated process. Meanwhile, a list of the \u00E2\u0080\u009CSinkhole Earthwork\u00E2\u0080\u009D process\u00E2\u0080\u0099 tasks, which form a workflow, is shown in the Plan view; all involved resources listed in the Supply view; all relevant information in documents list in the Reference view. These views, combined together, contribute to the mental model in the engineer\u00E2\u0080\u0099s mind. 231 Figure 7.25: Presentation of a Scene Composed of Five Common Views. System Implementation and Evaluation 232 7.3.2.2 Scenario 2 \u00E2\u0080\u0093 Monitor Potential Impact and Review Resource Usage Following the scenario 1 addressed above, the engineer wants to know what materials, labors and equipment were used on the site for the Sinkhole issue and which construction activities in the schedule may be impacted potentially. The engineer chooses a task named \u00E2\u0080\u009CWork Execution\u00E2\u0080\u009D in the Plan view, triggering the system to search and present resource usages and document references specific to this task in the Supply and Reference view respectively (see Figure 7.25). The \u00E2\u0080\u009CWork Execution\u00E2\u0080\u009D task in the Plan view is highlighted. Meanwhile, thanks to the underlying VCM, building objects (foundation Walls #4 and #10) affected by the change are highlighted in the Effect view. Construction activities on these two objects may be impacted by the specific change issue; the engineer could check other changes whether they are related to these two objects or not, or verify the work schedule if these two objects\u00E2\u0080\u0099 start or finish dates have slipped from the work schedule baseline (the current prototype doesn\u00E2\u0080\u0099t support this ability). Further, the engineer wants to have a look at how excavation equipment was used over time. He just moves the mouse indicator on the screen to the Supply view where resources are listed in a TreeList graph component in three hierarchical layers. By clicking the Excavating category, all uses of this type of resources over a time are highlighted in the view\u00E2\u0080\u0099s Gantt Chart. Meanwhile, detailed information items regarding equipment name (e.g. Backhoe, Bulldozer), unit, quantity, unit price, and cost are displayed in a Table List graph component. In a short, the system is able to link together all of the right information for a specific work task. 7.3.2.3 Scenario 3 \u00E2\u0080\u0093 Acquire Change Information for Updating a Schedule The five views shown in Figure 7.25 contain primary change order process information common to many functional departments such as project control, accounting, engineering, etc. The commonality of information enables these views to act as a \u00E2\u0080\u009Chub\u00E2\u0080\u009D of communication among different departments \u00E2\u0080\u0093 a hub for reducing communication burden during a PM process. For example, the project control department can acquire change-related information from these System Implementation and Evaluation 233 views to update a schedule, while information on changes was usually prepared by the engineering department (e.g., by a field engineer). Once a change issue is identified and a related RFI is prepared, a project control staff wants to know what activity is affected by the change, what resources are assigned to carry out the extra work, how long it will take (duration), etc., in order to update the work schedule. He only needs to click the Change Orders button on the scene panel of the system main frame, select the \u00E2\u0080\u009CSinkhole Earthwork\u00E2\u0080\u009D item in the Context view, and can then obtain information of duration and start and finish dates from the Gantt Chart in the same view in order to incorporate the change in the work schedule (see Figure 7.26); he can obtain resource information through expanding an hierarchical resource tree list in the Supply view in order to load resources on an activity associated with the specific change issue; as mentioned in Scenario 7.3.2.2, he only needs to select the \u00E2\u0080\u009CWork Execution\u00E2\u0080\u009D task in the Plan view and finds what objects may be affected in the Effect view in order to determine activity logic for a new activity in the schedule. These information aspects are multidimensional and are sufficient for updating the work schedule to the change accordingly; moreover, all are presented on one \u00E2\u0080\u009Cpage\u00E2\u0080\u009D to other departments. 234 Figure 7.26: User Interaction on Views to Acquire Change Information System Implementation and Evaluation 235 7.3.2.4 Scenario 4 \u00E2\u0080\u0093 Verify Actual Resource Usage for a Specific Change An accounting staff collects daily time sheets and inputs data into an accounting system. From a time sheet which typically includes an employee number, job code, name, date, regular and actual hours and project number, she cannot figure out on which work item an individual spent time on a particular day since the job code in a time sheet just indicates a category of work, e.g., spoil excavation. Now, the staff wants to know how many direct man-hours the Sinkhole Earthwork change actually consumed. In current industrial practice, paper or electronic document-based daily site reports and staff/worker time sheets are usually handled separately. In the UCPMA system, information from these two documents regarding work task and daily resource usage are integrated in a Central Data Model, stored in a physical server (they can be in many servers at different physical locations). Taking steps similar to those addressed in Scenario 7.3.2.3, the staff creates a Time Sheet view and links it to the Plan view for visualization coordination (Figure 7.27). Figure 7.27: Establish Link between Time Sheet View and Plan View System Implementation and Evaluation 236 After a Time Sheet view is created, she returns to the main system frame and clicks the Change Orders button on the scene panel. Six views (five common views plus the Time Sheet view) come out. Then, she selects the Sinkhole Earthwork item in the Context View and chooses the Work Execution task in the Plan view. As a result shown in Figure 7.28, all rows related to this work task in the Time Sheet view are \u00E2\u0080\u009Cselected\u00E2\u0080\u009D and highlighted in red color. Thanks to the underlying VCM in the prototype system, this result illustrates how two views are coordinated (selecting \u00E2\u0080\u0093 highlighted). Such view coordination actually has been displayed in the scenarios 2 and 3 previously. Meanwhile, here, the interrelationship of a task and associated daily man- hours are explicitly displayed. The staff can then conveniently determine the actual man-hours for the change and compare them with the budget in the change proposal. Figure 7.28: Coordination between Plan View and Time Sheet View System Implementation and Evaluation 237 From scenarios 1 to 4, we can see that multidimensional data for a scene is visually presented in views; these views manifest great efficiency of coordination within the scene, on condition that underlying view information interrelationships are appropriately established. 7.3.2.5 Scenario 5 \u00E2\u0080\u0093 Information Drill-down In this case, the project manager wants to know what activities relating to the \u00E2\u0080\u009CProcess RFI\u00E2\u0080\u009D task of the \u00E2\u0080\u009CSinkhole Earthwork\u00E2\u0080\u009D should be done by the general contractor on a designated day. The manager only needs to drag the Organization dimension from the Dimension panel into the main frame, and drop it on the \u00E2\u0080\u009CDrop Members Here\u00E2\u0080\u009D box in the Plan View\u00E2\u0080\u0099s Daily Note List graph component. Then, an Organization button is created and displayed at the textbox\u00E2\u0080\u0099s location, as shown in Figure 7.29. Clicking the button makes a dimension selection window appear so he can choose required dimensional levels. Once he has checked one of the level members on the tree list of the window and pressed the \u00E2\u0080\u009COK\u00E2\u0080\u009D button, the graph component is refreshed with the required information. In the same way, in the Supply view, end users can gain required information about resource usages contributed by the general contractor. This information drill-down promptness benefits from the underlying Data Winnow functions. Potentially, the Data Winnow, leveraging the OLAP technology, is able to drill down, roll up or slice digital construction data for powerful project control (Nie et al., 2007), yet the current prototype has not fulfilled the function of coordinating external OLAP-applicable interfaces, e.g. Microsoft OLAP services, with internal common views and leaves that for future research. System Implementation and Evaluation 238 Figure 7.29: Information Drill-down Scenario 7.3.2.6 Scenario 6 \u00E2\u0080\u0093 Explore Information on a Risk Management Scene The previous testing scenarios were all based on a hypothetical change-order scenario. The change-order problem is taken to be very appropriate for testing the comprehensive and integrated nature of data that the UCPMA must deal with, since change orders can involve all of the same types of information that full projects must deal with. However, the final two testing scenarios deal with two different problem scenarios and data sets to illustrate that the generality of the proposed solution and to show that the prototype is not specific to the change order scenario. During construction, risk usually refers to the uncertainty of hazard occurrences. In the oil sands infrastructure project (Appendix E), a survey was required to measure the depth of a frozen slough in cold weather. Figure 7.30 shows a scene that presents a risk management overview in the UCPMA system. The scene can be created and presented by an end-user in a way similar to that described for Scenario 1 in Section 7.3.2. System Implementation and Evaluation 239 The scene presents primary information about what risks the existed for the event, who was involved in risk management, how much (material, labor, equipment, etc.) it cost, when risk control was carried out, what the status of the risk event was on a particular day, etc. The scene consists of five common views, which are interconnected with each other based on underlying data interrelationships. These views contribute to the scene as an overview of how risk is managed for an event. To look into the risk event of drilling through a frozen slough to measure depth, a user can click the \u00E2\u0080\u009CDrilling through Frozen Slough\u00E2\u0080\u009D event in the Context view. Then, the event is selected, and a Gantt Chart bar associated to it is highlighted in red color. Meanwhile, activities for this event are filtered by the system and shown on the list in the Plan view. There are 6 activities identified for accomplishing this risk control, which are described in Section E.1 in detail. These activities form a Risk Management workflow in three stages which are: Risk Event Sequencing, Risk Identification, and Risk Control in Procedures. A user can explore relevant risk management information by interacting with the system. For example, clicking the activity of \u00E2\u0080\u009CMonitor Each Step\u00E2\u0080\u009D in the Plan view causes all associated resources to this risk control activity to be displayed in the Supply view; all associated documents in the Reference view, and the slough related to the risk management event (which is drawn on the site plan) is highlighted in red color in the Effect view. 240 Figure 7.30: A Construction Risk Management Scene in Five Common Views System Implementation and Evaluation 241 The five views configured into a scene of Risk Management. As stated before, views are designed to focus on presentation of primary information and data interrelation, not on a full range of project management capabilities. However, views reflecting other information of a PM process can be coordinated with the common views in the UCPMA system. Figure 7.31 shows that the Risk Context View and Plan View are coordinated with a Risk Sequence View, a Response View and a Risk Trigger view. The Risk Sequence View indicates how the \u00E2\u0080\u009CDrilling through Frozen Slough\u00E2\u0080\u009D event was sequenced in steps. Steps for this risk event include \u00E2\u0080\u009CWorking in a cold temperature\u00E2\u0080\u009D, \u00E2\u0080\u009CWalk onto frozen slough\u00E2\u0080\u009D, \u00E2\u0080\u009CDrill holes in the ice\u00E2\u0080\u009D and \u00E2\u0080\u009CMeasure depth of slough\u00E2\u0080\u009D. The Risk Trigger View display factors which may cause risk (loss, damage or other hazards) and the Risk Response View enumerates necessary actions corresponding to those triggers in the Risk Trigger View for each step in the Risk Sequence View (see the figure for detailed information about these three views). Data in these views all reside in the Central Data Model. To explore risk information, a user clicks the \u00E2\u0080\u009CDrilling through Frozen Slough\u00E2\u0080\u009D in the Context View, and selects the \u00E2\u0080\u009CMonitor each step\u00E2\u0080\u009D in the Plan view. Then, all steps sequencing the risk event are presented on the list of the Risk Sequence View. The user clicks the \u00E2\u0080\u009CWalk onto frozen slough\u00E2\u0080\u009D on the list, and then all related risk triggers and risk responding actions are brought to the front end. In this scenario, information items in views are visualized in components according to VCM, and presentation of information items\u00E2\u0080\u0099 association is ascribed to view coordination in visualization. As with the other scenarios presented here, the UCPM does not create (nor require users to create) any new information that would not have been created anyway, but it does capture all of the existing information into a cohesive representation and provides a platform for the user to fully access and explore this data and its many interconnections. System Implementation and Evaluation 242 Figure 7.31: User Interaction to Explore Risk Control Information 7.3.2.7 Scenario 7 \u00E2\u0080\u0093 Present a Quality Control Overview In the oil sands infrastructure project, all bases of manholes and catch basins were inspected and tested; and the bases along pipe lines were checked at designated testing points. This scenario is to present an overview of quality control over base construction of manholes, catch basins and pipelines. The scene was created and presented following the same approach described in Scenario 1 and 6. System Implementation and Evaluation 243 See Figure 7.32. The scene consists of five common views reflecting primary information of Quality Management. Data in all views are from the Quality Aspect of the Central Data Model. Views are coordinated, supporting user interaction to explore data interrelationships. To look into the pipe base quality control event, a user can click \u00E2\u0080\u009CUnderground Pipe Trench Inspection\u00E2\u0080\u009D process in the Context View, then a list of quality control steps corresponding to this event are presented in the Plan View. Section E.2 addresses these steps in detail. The user selects the \u00E2\u0080\u009CInspect and Test\u00E2\u0080\u009D step in the Plan View. All associated information regarding documents, resources, costs, etc. are brought to the user and presented in the Reference, Supply and Effect Views respectively. In addition, a manhole product (MH #84) in the Effect view is highlighted in red color. This highlighting exposes the data relationship between a quality activity and the physical products related to the task. From scenarios 6 and 7, we can see that the UCPMA system can present information from Quality Control and Risk Management scenarios in scenes that are configured with an appropriate series of views Data are consistent in the different views and user-interactions are coordinated across the views. The views are coordinated based on their underlying data interrelationships embedded in the Central Data Model. These basic characteristics are the same across all of the testing scenarios presented here. 244 Figure 7.32: A Construction Quality Control Scene in Five Common Views System Implementation and Evaluation 245 7.3.3 Comparison with Existing Systems Sections 7.3.2.1 to 7.3.2.7 demonstrated UCPMA\u00E2\u0080\u0099s capabilities of integrating PM information within views, bringing the right information to a particular task, customizing and incorporating a user view to a set of common views, exposing information relationships and drawing user attention, and flexibly analyzing data by dragging and dropping dimensions to configure customized data views. Existing state-of-the-art systems such as the Primavera P3E/C \u00E2\u0080\u0093 Project Management tool (simply as \u00E2\u0080\u009CP3E/C\u00E2\u0080\u009D here) have some functionality similar to what was demonstrated in previous sections. Yet they take different approaches, and the results also differ from each other. P3E/C is a very powerful and popular PM tools in the construction industry. It is centered on project scheduling information and tasks, although it brings other project management issues into its scope. The UCPMA prototype focuses on information interrelationships of primary PM functions and presents views mainly for an individual PM task. Since the systems are quite different in nature and objective, a direct comparison for the seven scenarios presented above is difficult. However, the relative capabilities of the two systems are discussed here. Figure 7.33 provides a snapshot from P3E/C version 5. First, a schedule in P3E/C mainly presents information of Task, Resource, Cost and Time dimensions, while the UCPMA system covers a broader scope of objects including, e.g., product information associated with an individual activity. The P3E/C does not provide as wide a range of information of each task or activity, since, as stated, its primary focus is on scheduling; while the UCPMA is intended for eight primary PM functions, focusing on presenting their common information from different perspectives. Second, P3E/C shows an activity and its attributes and resources in one view (with different graphs); while UCPMA uses at least five different views. This allows a user\u00E2\u0080\u0099s focus to progress smoothly from overall (on the Context view) to details (on the Reference, Effect and Supply views). Third, for a schedule, P3E/C provides several views (e.g. WBS, Activities, Assignments, Expenses, etc.). Similar to a UCPMA\u00E2\u0080\u0099s view, each P3E/C view includes one or many graphs (e.g. an activity list, Gantt chart, and System Implementation and Evaluation 246 attribute table list for an \u00E2\u0080\u009CActivities\u00E2\u0080\u009D view). However, each view is encoded into the system; a user cannot customize the view using different graphs for different purposes (e.g., the views are determined by the software developers at design time rather than by users at run- time). In addition, graphs are \u00E2\u0080\u009Ctightly\u00E2\u0080\u009D linked. For example, when clicking on the \u00E2\u0080\u009CGrub and Strip Topsoil\u00E2\u0080\u009D, all related attribute information items are searched from a database and shown in the bottom table list of the figure; while the Gantt chart at the right side does not respond to the user action (the red bars in the figure indicates a critical path, rather than a response). It is up to the user to find which bar among a huge list is for the activity he selected. Fourth, P3E/C designed several views exclusively for a schedule, which are on a panel docked at the left side of the figure. As in the third point, a user cannot configure a specific view as required in Scenario 4 (Section 7.3.2.4). Fifth, those views are not effectively coordinated. For example, clicking on the \u00E2\u0080\u009CGrub and Strip Topsoil\u00E2\u0080\u009D activity in the \u00E2\u0080\u009CActivities\u00E2\u0080\u009D view, the \u00E2\u0080\u009CExpenses\u00E2\u0080\u009D view does not respond. They actually are not displayed concurrently. To find related information in the \u00E2\u0080\u009CExpenses\u00E2\u0080\u009D view, the user has to select the activity again. Apparently, graphs in a view or views for a schedule are not well coordinated. Sixth, to search specific information, P3E/C requires users to build a filter for each query. This way lacks efficiency in data analysis. In summary, P3E/C features rich, multidimensional PM information presentation and visualization, yet it was designed with different objectives from the UCPMA prototype. Moreover, although the Data Winnow and VCM of the UCPMA framework are research prototypes, they offer several functions not found in P3E/C. System Implementation and Evaluation 247 Figure 7.33: A Typical P3E/C Project Schedule Layout 7.4 Results 7.4.1 Achievements The research, through the implementation of the prototype system and the demonstration of user-operations, examined the UCPMA architecture: three integral components leveraging state-of-the-art technologies, functioning in different layers and being presented based on VCM (Chapter 3 and Section 7.2). The result is that, using the system, a user can dynamically create views and scenes through flexible configuration of Data Winnow elements where data are from the Central Data Model. In these respects, the system is successful since no significant technical impediment was found to implementation. The VCM features a four coaxial layers visualization structure which effectively supports view composition and data integration from the model, analysis tool and to interfaces. Such a structure is also validated to be able to facilitate implementation of dynamic user-interaction. System Implementation and Evaluation 248 Moreover, through testing scenarios of PM processes, the research examined the UCPMA capability required by an Information Aggregator to improve the three integration problems (Section 1.2 & 1.4), and illustrated what potential it can bring to the current practice. In particular, it was demonstrated that the UCPMA has the capability as followings: \u00E2\u0080\u00A2 Data layer. o The Central Data Model reliably provides data saving, retrieving, and searching services, supports data sharing, and keeps data consistent from the presentation layer to the data layer. The system consists of a multidimensional data repository, a central data model, which can contain construction project management information for identified primary functions (Scenario 1, 6 & 7, in particular). o The central data model, built upon IFCs, has ability in data exchange (This point did not receive testing in the research, but is based on an assumption that IFC enables system interoperability). \u00E2\u0080\u00A2 Logic Layer. o The Data Winnow offers capability for users to browse data tables derived from the Central Data Model, select fields and attributes, and define dimension levels. o It provides flexibility for users to work on dimensions, establish links between dimensions, and generate partial models (data views) at configuration time, as illustrated in Figure 7.21 and Figure 7.22. o The Data Winnow supports serving specific data analysis through manipulating dimensions and levels. Scenario 5 demonstrated such an operation for illustration. Because of the Data Winnow model\u00E2\u0080\u0099s similarity to OLAP\u00E2\u0080\u0099s data structure, it would be able to incorporate OLAP other analysis functions if coordinating external systems is fulfilled in future. \u00E2\u0080\u00A2 Presentation layer. o Views and scenes in visualization can be dynamically created and flexibly configured to present multidimensional construction data per specific user requirements. System Implementation and Evaluation 249 o UCPMA provides a flexible information visualization environment (e.g., drilling and slicing data using \u00E2\u0080\u009Cdrag-and-drop\u00E2\u0080\u009D operations) with a set of common views that can be instanced and customized into specific views through a view engine. The view coordination model works underneath those configuring operations. By changing view configuration, users can generate new views or update predefined views immediately (Figure 7.23 and 24). o The prototype system presents visualized PM data consistent from one view to another, benefited from the common data model and established integration of elements from the Model, the Data Winnow and to the VCM. In short, the system was proved having its expected basic capabilities. Thus, the framework described throughout the dissertation is shown to be technically feasible. In addition, the prototype system also demonstrated potential of the UCPMA framework in improving integration of the current construction project management practice. As shown in Figures 7.25-7.32, the clear improvements made to the traditional processes are enumerated as follows: \u00E2\u0080\u00A2 Information, previously fragmented, is now integrated to different views. Taking the UCPMA approach, participants still carry out individual tasks, yet through a set of common shared views which are related to a shared project data model. The focus of each work is converged on how to use shared information and contribute the project model. \u00E2\u0080\u00A2 Following the UCPMA approach, each item of project work is designed as a workflow process consisting of tasks that are broken down from an upper level so that participants\u00E2\u0080\u0099 efforts are not independent, but related with each other towards a combined project goal. For example, the \u00E2\u0080\u009CSinkhole Earthwork\u00E2\u0080\u009D process is selected from a collection of change order processes which were carried out during the whole construction process lifecycle. One of the tasks, \u00E2\u0080\u009CProcess RFI\u00E2\u0080\u009D carried out by the construction field engineer, belongs to the Change Initiation phase. It can be broken down further into tasks of \u00E2\u0080\u009CCollect Information\u00E2\u0080\u009D (including the subcontractor\u00E2\u0080\u0099s measurement of the sinkhole size, and the superintendent\u00E2\u0080\u0099s recording the issue to a daily site report) and \u00E2\u0080\u009CPrepare System Implementation and Evaluation 250 RFI.\u00E2\u0080\u009D A complete RFI needs sufficient information to be collected. As these tasks are based on the same time line, a delay in the first may have an effect on the second. Thus, these tasks are centered on the \u00E2\u0080\u009CProcess RFI\u00E2\u0080\u009D task, involved information items remain interdependent, and efforts of the field engineer, superintendent and subcontractor are merged into a finished RFI in order to formulate work directives regarding the found sinkhole issue. \u00E2\u0080\u00A2 Information interdependency turns to be explicit within a view or between views in visualization. Clicking one option (e.g. Sinkhole Earthwork in the Context view) highlights associated information such as the change initiator in the Context view, referenced documents in the Reference view, etc. This greatly enhances users\u00E2\u0080\u0099 mental grasp of voluminous construction data, and saves users\u00E2\u0080\u0099 time in figuring out, for example, cause-effect relationships in project control. \u00E2\u0080\u00A2 Management of some processes, such as change order process, submittal process, etc., becomes efficient when they are designed as workflow processes that promote the delivery of the right information for a particular task to the right person at the right time. UCPMA achieves this by integrating graph components\u00E2\u0080\u0099 interaction in view coordination. For example, as shown in Figure 7.25, clicking the \u00E2\u0080\u009CWork Execution\u00E2\u0080\u009D task on the Schedule Chart graph component of the Plan view automatically brings relevant documents (the contract, the change order, etc. ) in the Reference view to end users\u00E2\u0080\u0099 attention. \u00E2\u0080\u00A2 Communication overload can be reduced, not only because of sharing information, combining work goals, and coordinating views, but also by sharing a set of common views with primary information which people usually communicate for. Working on such a set of views, like working on the same \u00E2\u0080\u009Cpage,\u00E2\u0080\u009D reduces human translation effort from one mental model to another during communication. System Implementation and Evaluation 251 7.4.2 UCPMA Applicability and Limitations 7.4.2.1 Applicability As illustrated in Section 7.3.1 and & 7.3.2, the prototype system employed testing cases of change order, risk management and quality control processes, and demonstrated its potential improvements to the industry. These cases reflect typical and important PM processes in construction; and they involve voluminous information related to scope, cost, risk, quality, and organization, requiring multi-parties cooperation. Yet, the UCPMA framework is not tied to these processes alone, but was designed to be oriented for all primary project management functions identified in Chapter 4, because UCPMA\u00E2\u0080\u0099s Central Data Model was designed incorporating fundamental information of those functions; and the dimensions and levels of the Data Winnow were derived from the Central Data Model. Moreover, UCPMA\u00E2\u0080\u0099s five common views were designed to present inherent construction information regarding different facades of a process, namely what (scope), how (planning and time), who (organization and human resource), how much (cost & resources), and how well (evaluation, resource usage, etc.). Shown in Figure 7.34, eight typical activities corresponding to the eight primary project management functions are selected of typical in construction management: Change Order Process, Cost Tracking and Forecasting, Scheduling, Resource Procurement, Quality Control, Risk Monitoring and Control, Workforce Planning, as well as Document Management. From the table, we can see that these activities can be mapped to the five UCPMA views in functional requirements (addressed in Section 4.2 and 5.4). This conceptual mapping indicates that the proposed UCPMA framework can be applicable to identified eight primary functions of construction project management. Take the resource procurement activity as an example. A Context view can be employed to display a list of material procurement processes in graphs over time, serving as an overview window for project material purchasing control. Each process may be corresponding to one or many types of materials used in construction. A Plan view can detail a material purchase process involving a list of detailed activities such as tracking, confirming and accelerating delivery; System Implementation and Evaluation 252 also, the view can embed sub-processes such as a material submittal process or inventory control. A Reference view is able to display information or documents relevant to a particular material procurement process, which may include purchase orders, drawings and specifications, the project schedule, a submittal log, a material purchase schedule, delivery slips, invoices, etc. An Effect view can display a physical product(s) associated to a specific material, illustrating that where this material is used; moreover, the view may be applied to show work activities associated to a particular material so as to check how a material purchase schedule impacts or is influenced by the project schedule. A Supply view is competent for illustrating information of involved persons, equipments (e.g. for delivery), etc. regarding a particular material purchase process. 253 Figure 7.34: Mapping View Requirements to Project Management Activities System Implementation and Evaluation 254 7.4.2.2 Limitations Per the delimited research scope (Section 1.5), the current UCPMA prototype system is unable to interoperate with other systems. The framework has been designed to explicitly support this (e.g., through the use of the IFC data standards in the common data model), but the additional programming to enable this system interaction has not been implemented. Thus, the current prototype cannot incorporate external views, e.g. a Microsoft Project schedule view, to facilitate integrated multidimensional presentation with commercial applications. Furthermore, the ability to coordinate user interaction between views has implemented only the \u00E2\u0080\u009CSelect\u00E2\u0080\u009D user action. Other types of user interactions should also be added. In addition, the system could be improved by providing an effective interface for users to create views in the data layer (at present, the user must be very familiar with the underlying data model in order to work with the visualization interface). These limitations give directions to future research of UCPMA. 7.5 Conclusions This chapter addresses the implementation of the UCPMA system and its use for testing and validation. The system is a prototype, one of the research contributions, intended to validate the possibility of implementing the framework described throughout the dissertation, and testing its capability as an Information Aggregator. The prototype is composed of a back stage and a front stage, imitating a real theatre structure. The back stage (mainly embodying a database, analysis services, and view engine modules) supports data depository and exchange, and serves in creating views and achieving view coordination in the data layer. The front stage consists mainly of common views and custom scenes in visualization, as well as interfaces for editing views and importing data from sources. It provides access for manipulating project data, configuring graph components, views and scenes, and supporting decision making by allowing users to drill information down to different levels. System Implementation and Evaluation 255 In implementation, components in these two stages are organized into three logic layers. The bottom layer (the data layer) stores project data and visualization configuring data, and provides data input and output services. The middle layer (the business logic layer) provides data exploration and view configuration services. The top layer (the interface layer) presents views and scenes for project control and decision-making. Data modeling, IFC technologies, OLAP technology, visualization strategies, and the Model-View-Control pattern were utilized in all three layers. System programming adopts Visual Basic .Net, and Microsoft SQL Server (including Analysis Services). In evaluation, the research took two major processes which are demonstration of user- operations and testing with PM cases. Through steps of partially populating the data model, dynamically creating a view and flexibly configuring a change process scene, the system was proved having no significant technical impediment in implementation and being technically viable as an Information Aggregator. Also, through testing of seven scenarios of typical and important PM cases, the UCPMA based system demonstrated being able to accommodate common information for primary PM functions in a Central Data Model, for users to flexibly access those data and configure user-customized data views, and support PM information visualization, view coordination and user-interactions on interfaces. In addition, the research demonstrated great potential of the UCPMA in improving integration of construction management. In short, the prototype system is successful and effective in respect to technical feasibility and meeting functional requirements of an Information Aggregator. The UCPMA framework is intended for the eight primary functions of construction project management and the prototype should be able to present typical activities of these functions. However, future research is required to refine views and expand system functionalities in order to suit the system for using in the industry; Section 8.3 will give detailed recommendations to future research work. Conclusions 256 CHAPTER 8: CONCLUSIONS This chapter concludes the dissertation. It describes research deliverables, summarizes the research contributions, and then suggests future work to extend the Unified Construction Project Management Arena framework in order to achieve thorough project management integration. 8.1 Summary 8.1.1 Research Problems and Objectives This dissertation describes research on the UCPMA (Unified Construction Project Management Arena) framework and its technical development. The research was conducted on the premise that the construction industry features information fragmentation, while IT (information technologies) can improve the situation. Recently, emerging IT in the construction industry has contributed the potential for data exchange and system interoperability, but this is still at an early stage. From a technical perspective, a problem with IT applications in the construction industry is that there is no way for users to work with the entire data set as a whole, and there is no significant improvement toward having all users sharing a common view of the project, which would improve coordination and collaboration of the fragmented work tasks. In the dissertation, the problems were addressed and formulated into three main categories corresponding to three basic layers of information systems. 1) Data integration problems. Construction information needs to be integrated from fragmented sources, and IT applications are weak in providing system interoperability. Presumed state-of-the-art solutions lack implementation and testing and are vague on what information is required or suitable for construction project management. 2) Data view configuration problems. Little work has been done to enable users and application to configure construction data views derived from or integrated with Conclusions 257 an overall integrated data model. 3) Information presentation problems. The user interfaces of current software tools for construction management are simple, inconsistent and inflexible information presentation in one or two dimensions. Such interfaces too often fail to yield insights into information relationships, project trends, potential problems, etc. The research performed a comprehensive investigation of available technical solutions to the three issues mentioned above. A general finding is that techniques are available for solving each category of issues independently. Standard data exchange languages, such as the IFCs, are commonly recognized as being able to provide effective solutions for information integration and system interoperability. OLAP turns out to be effective in supporting flexible user-configuration of data views. Visualization theories, such as visualization strategies and view coordination, provide the potential to make project data more meaningful and understandable. However, the investigation also shows that none of these solutions can independently and effectively deal with all those issues. And, little research has been directed to integrate these techniques in improving current construction project management practice. These call for a new class of software environment, here called an Information Aggregator. Enlightened by the research of Froese & Staub-French (2003) and O'Brien et al. (2003), the UCPMA framework, as a vision of Information Aggregator, is proposed as a means to integrate data sources, and provide consistent capabilities of analysis and visualization by utilizing technologies of IFC data standards, OLAP, and information visualization theories. The framework was developed, consisting of three components. The Central Data Model, adopting data modeling and data standard technologies, represents construction project data in a central, conceptual project model. It serves as a communication foundation that fosters data sharing among the various parties involved. Another component, the Data Winnow, is a tool to provide data analysis services, leveraging OLAP technology. Based on construction domain knowledge, the Data Winnow consists of several functional entities: dimensions, levels, views, and member properties. Identified primary common dimensions include Document, Process, Product, Cost, Actor, Resource and Time Dimensions, each of which has one or many levels for breaking down information in a hierarchy. Each level may have Conclusions 258 several members which are specified with properties. Similarly, in this dissertation, a set of common views are identified and addressed in detail. They are Context View, Plan View, Reference View, Effect View and Supply View. The third component is the VCM (Visualization Configuration Model). The VCM is composed of graph elements, graph components, view and scene, organized in coaxial layers. It offers capabilities for dynamically presenting multidimensional data in meaningful ways and facilitates user- interactive interface configuration according to special purposes. The basic mechanism is to maintain integrated relationships between entities in different layers: integrating from attribute and object in a conceptual model, to field and table in a database, to property, level and dimension in a Data Winnow, and then to graph, view and scene in visualized presentations. Implementation of the UCPMA prototype system is one part of the present research. To that end, the system was designed to validate the possibility of the proposed framework described throughout the dissertation. It tested its capability of accessing primary construction project management data in a central data set, dynamically configuring data views based on the central data model, and presenting views in visualization supporting flexible user-interaction. The prototype system is structured with two parts: the front stage and the back stage. The back stage consists of a database, analysis services, and view engine, while the front stage includes data processing interfaces, common views and scenes. These components form a structure within three layers: the data layer, the business layer and the presentation layer. Implementation was achieved using Microsoft SQL server and Analysis Services, and Visual Basic .Net. In this research, scenarios of construction project change, risk and quality management were selected for testing. The prototype system demonstrated that no significant technical obstacle impeded fulfillment of the required functions (Section 1.4). It also showed that end users could, using the VCM, dynamically create views from the data layer to the presentation layer by simply browsing lists, dragging icons and dropping those to related components. The system exhibited considerable power in displaying multi-dimensional data items with flexible view coordination relationships. Coordinated views offer great potential Conclusions 259 in providing insights into construction data relationships. Supported by the Data Winnow, they also facilities drilling data down to different management levels or aggregating data from low levels to an upper level for analytical purposes. In short, the detailed research objectives (Section 1.3) were defined as: 1) developing the UCPMA framework, including integrated components of a Central Data Model, Data Winnow and Visualization Configuration Model, in order to integrate data modeling, data analysis and information visualization against the three categories of problems; 2) designing and implementing the prototype system to examine the UCMPA architecture, test its capabilities of being an Information Aggregator. As summarized in previous paragraphs, the research proved the possibility of the envisioned solution and fulfilled all formulated objectives. 8.1.2 Accomplishments and Exceptions As mentioned above, the UCPMA framework consists of three components. To develop the Central Data Model, the research identified eight primary functions for PM and their functional information, and designed data models for those primary functions; individual models were combined into the Central Data Model. There are forty-five classes used in the model (Section 4.5). Among them, thirty are from the IFC model and the other sixteen defined to supplement the IFC model for PM requirements; most of the newly added classes have been implemented and tested through the prototype (Chapter 7). The Data Winnow used a part of the OLAP technology. The research identified seven common dimensions from functional information of primary PM functions identified in Chapter 5. The research also designed levels for each dimension according to the OmniClass system, and presented five data views as well as their functional requirements (Section 5.6). These views are deemed to be common to eight primary functions. Each person involved in a PM task typically work with aspects of these five views (in addition to other, more individual perspectives). The five views together display a scene for a PM task. In the implementation of the prototype, due to limited research time, analysis services of the Data Winnow are incomplete\u00E2\u0080\u0094it does not address analysis of numerical data since OLAP based Conclusions 260 tools, such as Microsoft OLAP Services, are already very powerful in this regard. It is intended to coordinate visualization of such tools in the system in the future. The VCM offers a unique approach to the pattern or structure for organizing visual components and visualizing PM multi-dimensional data. The model leverages elements and visual techniques, which appear somewhat in previous research but are specifically tailored to fit into the overall UCPMA framework. Further study of visual techniques and coordination theories is beyond the research scope. In the prototype, only one user-action is implemented for visual exploration. As described in above paragraphs, each component is incomplete to some extent, but the missing elements are not central to the core research results. The main research objective is the UCPMA framework itself\u00E2\u0080\u0094formed by creating the three essential components of the Central Data Model, the Data Winnow, and the VCM, and integrating these into the overall UCPMA framework. 8.2 Contributions This research has made contributions as follows: The development of the UCPMA technical framework for an Information Aggregator is considered to be a core contribution including several primary contributions which are distinct from other research and development work. They are: \u00E2\u0080\u00A2 A Central Data Model (Chapter 4). The model makes a valuable contribution to project management domain modeling: identified a comprehensive set of requirements based on specific project management (PM) functions, assessed the IFC data model against these PM requirements, and designed additional classes required to meet the model requirements. \u00E2\u0080\u00A2 A Data Winnow (Chapter 5). Adopting the OLAP technology in the PM domain and designing a specific set of PM data views contributed a beneficial solution for defining and working with derived data views from integrated PM data models and Conclusions 261 facilitating flexible exploration of multidimensional construction data within the UCPMA framework. \u00E2\u0080\u00A2 A Visualization Configuration Model (VCM, Chapter 6). The model was designed in a coaxial layered structure which facilitates dynamically configuring a visualization model from inner layers to outer layers and flexibly establishing correspondence between datasets in the data layer and view components in the presentation layer. Designing a VCM contributed a distinct technology framework for multidimensional PM information visualization. These contributing UCPMA components individually were developed to achieve different functional requirements; yet they are not intended to stand alone. The Central Data Model provides a foundation of PM information integration; the Data Winnow facilitated datasets organization in a structured way for data view configuration; and the VCM provides a front end to work with multidimensional views in visualization. Their seamless incorporation significantly contributed to a unified approach, a whole which was shown to be more powerful than individual components improving IT-supported project management effectively. The approach gives a good indication of the potential for developing completely integrated AEC applications. Besides the contributions mentioned above, the following items are considered to be contributions that are secondary in nature: \u00E2\u0080\u00A2 The research addressed a broad-base review of literature and commercial software (Chapter 2), which contributed a background of knowledge and techniques for Unified Construction Project Management research and integrated multidimensional PM information visualization efforts. \u00E2\u0080\u00A2 The development of the UCPMA prototype system served as a platform for illustrating and exploring the primary contribution and for future multidimensional PM data analysis and visualization research. The present research is believed to have potential to make valuable and significant contributions to future research and development of IT applications which could, in turn, Conclusions 262 improve project management practice. However, these contributions do not constitute a final or definitive solution. To advance the approach, future work must expand the system functions for various construction business requirements, and make the software tool reliable and workable in the industry\u00E2\u0080\u0094recommendations towards these ends are made in the following section. 8.3 Recommendations for Future Work During implementing and testing, some issues were observed and noted for further research. They fall into two groups: framework development and system development. Corresponding future work may include the following: 8.3.1 Advance the UCPMA Framework First, further efforts need to be given to expanding the Central Data Model in order to capture more fundamental information. The model should encompass more detailed information for different levels of construction project management. The current model includes primary information items and for illustrating the proposed framework only. Second, future research should be directed to developing guidelines on how to use visualization strategies for different domain information presentation. In current practice, one or two dimensional visualizations are applied for almost all data types. Consequently, end users struggle to completely understand construction data. Shneiderman (1996) and other research has addressed this situation, yet their contributions are not suitable well for construction data presentation. Detailed future work could go into investigating construction management functions and classifying involved domain data into various types according to the nature of data. For example, data items involved in the change order process may be categorized into numerical (further 1D, 2D, etc.) or non-numerical, comparable or incomparable, temporal or non-temporal, etc.; then guidelines can be provided on what type of visualization is most suitable for non-digital construction data presentation. Conclusions 263 Third, future research could investigate what additional views are needed for specific custom requirements. For example, if users want to oversee work progress by creating a \u00E2\u0080\u009CProject Progress Control\u00E2\u0080\u009D scene, what views in addition to the recommended five common views are required to track work progress based on value analysis? To ensure project quality, what fundamental view(s) other than the common views can give users more insights into construction performance? Ideally, the UCPMA framework would provide various specific views or view templates reflecting all primary construction project management processes. In addition, more functions may need to be defined in the Data Winnow in order to develop a variety of user-computer interactions which work effectively in the UCPMA software system. 8.3.2 Extend System Functions In Chapter 7, the research demonstrated the UCPMA capabilities, yet also exposed several areas that need to be expended and developed in order to fully achieve its goal. \u00E2\u0080\u00A2 Creating a view in the data layer may be a challenge for end users who do not know much about the data model or the underlying system database. Currently, it is assumed that users understand the model structure, tables and their fields, as well as table relations by primary keys, and also know something about how to effectively use SQL JOIN statements. The system should provide more user-friendly interfaces for creating views in the data layer. \u00E2\u0080\u00A2 Inputting data from other sources appears to be tedious and error-prone. For testing purposes, information was entered through various interfaces (Figure 7.18). To make the system more powerful and practical for industrial projects, effort should be devoted to implementing data exchange between different applications. \u00E2\u0080\u00A2 Currently, the system only allows the \u00E2\u0080\u009CSelect\u00E2\u0080\u009D user action. More user interactions, such as \u00E2\u0080\u009CPan\u00E2\u0080\u009D,\u00E2\u0080\u009D Scroll\u00E2\u0080\u009D, etc. (refer to Section 6.6.1), should be designed into the system for advanced analysis purposes. \u00E2\u0080\u00A2 Coordination with external application views (CAD, P3, etc.) remains very limited. Some improvement may be achieved by looking into other research which has experience in incorporating available commercial tools. For example, (Hartmann, et Conclusions 264 al., 2003) proposes an advanced Work Space which was designed to integrate different applications used in civil engineering (introduced in Section 2.5.2). Yet coordination of those applications seems very ad hoc, and the system lacks flexibility in configuring custom views for specific purposes. Future research and development may include finding ways to flexibly configure commercial application views in the UCPMA system in order to form a more practical, integrated \u00E2\u0080\u009Carena.\u00E2\u0080\u009D \u00E2\u0080\u00A2 In addition, the system could be implemented as a distributed system so that views are shared and presented on screens which may be located in different physical places. References 265 REFERENCES C. Ahlberg and B. Shneiderman. (1994). \"Visual information seeking: tight coupling of dynamic filters with starfield display.\" CHI' 94, ACM Press: New York; 313-317. Robert Amor, Martin Betts, Gustav Coetzee, and Martin Sexton.(2002). \"Information Technology for Construction: Recent Work and Future Directions.\" ITcon Vol.7 (2002), pg. 245. ASCE. (1972). \"System Control of Construction Quality.\" Journal of the Construction Division, ASCE, Vol. 98, March 1972. Michelle Q. Wang Baldonado, Allison Woodruff, and Allan Kuchinsky. (2000). \"Guidelines for Using Multiple Views in Information.\" AVI 2000, Palermo, Italy. (http://portal.acm.org/citation.cfm?id=345271) Donald Barrie and Boyd Paulson. (1991). \"Professional Construction Management: Including CM, Design-Construct and General Contracting (Third version). \" Published by McGraw Hill, 1991. Alex Barron and Martin Fischer. (2001). \"Potential Benefits of Internet-based Project Control Systems - A Study on Change Order Processing.\" Technical Report, No. 126, CIFE, Stanford University. J. Bertin. (1983). \"Semiology of Graphics.\" Madison, University of Wisconsin Press, 1983. BLIS. (2002). \"Building Lifecycle Interoperable Software.\" Accessed at http://www.blis- project.org/index2.html in January, 2008. Nadia Boukhelifa and Peter J. Rodgers. (2003). \"A model and software system for coordinated and multiple views in exploratory visualization.\" Information Visualization (2003) 2, 258\u00E2\u0080\u0093269. M. Brautigam. (1996). \"Applying Information Visualization Techniques to Web Navigation.\" Thesis proposal, UC Santa Cruz, USA. buildingSMART. (2008). \"Information Delivery Manual, Guide to Components and Development Methods.\" by buildingSMART, Norway. Accessed at http://idm.buildingsmart.no/ in April, 2008. References 266 CCDC-2. (1994). \"Stipulated Price Contract.\" Standard Construction Document provided by the Canadian Construction Association. K.W. Chau, Ying Cao, M. Ansona, and Jianping Zhang. (2002). \"Application of data warehouse and decision support system in construction management.\" Automation in Construction, Vol. 12, 213-224. Sai On Cheung, Henry C.H. Suenc, and Kevin K.W. Cheung. (2004). \"PPMS: a Web- based construction Project Performance Monitoring System.\" Automation in Construction 13 (2004) 361\u00E2\u0080\u0093 376. Common Point. (2005). \"How It Works: Project 4D in Action.\" Accessed in March, 2005 at http://www.commonpointinc.com/products/project4d.html Robert F. Cox, Raja R. A. Issa, and Dar Ahrens. (2003). \"Management\u00E2\u0080\u0099s Perception of Key Performance Indicators for Construction.\" Journal of Construction Engineering and Management \u00C2\u00A9 ASCE / March/April 2003. W. Curtis, M.I. Kellner, and J. Over. (1992). \"Process Modeling.\" Communications of the ACM 35 9, pp. 75\u00E2\u0080\u009390. Mark D'Aoust. (2002). \"Coordinate User Interface Development with VB.NET and the MVC Pattern.\" http://www.devx.com/dotnet/Article/10186/0/page/1. Nash Dawood, Eknarin Sriprasert, Zaki Mallasi. (2003a). \"Product and Process Integration for 4D Visualisation at Construction Site Level: A Uniclass-Driven Approach.\" International workshop on developing a vision for nD enabled construction, Jan.30-Feb.1, 2003. Salford University, Manchester, UK. Nash Dawood and Eknarin Sriprasert. (2003b). \"Multi-Constraint Information Management and Visualization Collaborative Planning and Control in Construction.\" Itcon Vol. 8 (2003). DCMI. (2003). \"Dublin Core Metadata Element Set, Version 1.1: Reference Description.\" Dublin Core Metadata Initiative, 2003-06-02. http://dublincore.org/documents/dces/ DETR. (2000). \"KPI Report for The Minister for Construction.\" By The KPI Working Group, Department of the Environment, Transport and the Regions, UK, dated January 2000 Charles M. Eastman. (1999). \"Building Product Models: Computer Environments Supporting Design and Construction.\" Published By CRC Press LLC, 1999. References 267 ESPRIT 20408. (1997). \"ESPRIT 20408 - VEGA, A Model of Workflow, Specification of a Model for the Definition of Workflows in Virtual LSE Enterprises.\" VEGA D103b. Thomas Froese. (1995). \"Models of Construction Process Information.\" Journal of Computing in Civil Engineering, American Society of Civil Engineers, March, 1995. Thomas Froese. (1996). \"STEP Data Standards And The Construction Industry.\" 1996 CSCE Annual Conference (Volume I); Proceedings of the 1996 Annual Conference of the Canadian Society for Civil Engineering, Edmonton, Alberta, May 29 to June 1, 1996. CSCE, Montreal, Canada, 1996. Vol. 1, pp. 404-415. Thomas Froese, Jeff Rankin, and Kevin Yu. (1997). \"Project Management Application Models And Computer-Assisted Construction Planning In Total Project Systems.\" International Journal of Construction Information Technology, Special Issues on Integrated Environments, Vol. 5, No. 1, Summer 1997, pp.39-62. Thomas Froese and Kevin Yu. (1999). \"Industry Foundation Class Modeling for Estimating and Scheduling.\" 8th International Conference on Durability of Building, Materials and Components. 1999, Vancouver, Canada. Thomas Froese, Martin Fisher, Fancois Grobler, John Ritzenthaler, K. Yu, S. Sutherland, S. Staub, B. Akinci, R. Akbas, B. Koo, A. Barron, J. kunz. (1999). \"Industry foundation Classes for Project Management - A trial Implementation\". Itcon Vol. 4 (1999), pg.17. Thomas Froese and Sheryl Staub-French. (2003). \"A Unified Approach to Project Management.\" Towards a Vision for Information Technology in Civil Engineering, Fourth Joint International Symposium on Information Technology in Civil Engineering, ASCE, Nashville, TN, USA. Thomas Froese. (2003a). \"Future directions for IFC-based interoperability.\" ITcon Vol. 8, Special Issue IFC - Product models for the AEC arena , pg. 231-246, http://www.itcon.org/2003/17 Thomas Froese. (2003b). \"Integrating nD Modeling with Other Kinds of Stuff: Documents, Workflows, and Project Management.\" \"From 3D to nD modeling.\" International workshop on developing a vision for nD enabled construction, Jan.30- Feb.1, 2003. Salford University, Manchester, UK. James H. Garrett, Ian Flood, Ian F. C. Smith, and Lucio Soibelman. (2004). \"Information Technology in Civil Engineering\u00E2\u0080\u0094Future Trends.\" Journal of Computing in Civil Engineering, ASCE /July 2004/185. GloblePM. (2003). \"Global Performance Based Standards for Project Management Personnel.\" Working Paper No 1: Report from Working Session 24-26 February, 2003, Lille, France. References 268 K. Umut Gokce, Raimar J. Scherer and H. Attila Dikbas. (2007). \"Integrated Construction Project Management System Based On Ifc And Iso9001:2000 \". Published by Springer Boston. Volume 243/2007. Timo Hartmann, Martin Fischer, Ernst Rank, Marcus Schreyer, and Frank Neuberg. (2003). \"Integration of a Three Dimensional CAD Environment into an Interactive Workspace.\" Technical Report, No. 146, CIFE, Stanford University. IAI. (2002). \"IAI Vision, Mission and Goal.\" Accessed in 2002, at http://www.iai- international.org/About/Mission.html IAI. (2006). \"IFC Model View Definition Format.\" Accessed at http://www.blis- project.org/IAI-MVD/. IAI. (2007). \"IFC2x Edition 3 Technical Corrigendum 1\". William H. Inmon. (2005). \"Building the data warehouse.\" 4th Edition. Published by Wiley Publishing, Indianapolis, IN. 2005. ISO. (1994). \"Building Construction Core Model, Project Proposal.\" ISO TC184/SC4/WG3 Document N341, 1994. Chris Johnson. (2009). \u00E2\u0080\u009CWhat is Research in Computing Science?\u00E2\u0080\u009D Available at: http://www.dcs.gla.ac.uk/~johnson/teaching/research_skills/research.html. Accessed Dec. 1, 2009. Calvin Kam and Martin Fischer. (2002). \"Product Model & 4D CAD - Final Report.\" CIFE Technical Report #143, Stanford University, October, 2002. Leen S. Kang and Boyd C. Paulson. (2000). \"Information Classification for Civil Engineering Projects by Uniclass.\" Journal of Construction Engineering and Management, Vol. 126, No. 2, March/April 2000. P. Katranuschkov, J. Wix, A. Gehre, and T. Liebich. (2003). \"Collected End User Requirements and Common Structure Common Structure Part II: Gap Analysis.\" Deliverable D12-2, EU Project IST-2001-33022 ICCI \"Innovation co-ordination, transfer and deployment through networked Co-operation in the Construction Industry.\" D. A. Keim. (2002). \u00E2\u0080\u009CInformation visualization and visual data mining.\u00E2\u0080\u009D IEEE Transaction on Visualization and Computer Graphics, 8(1), 1-8. Tapio J. Koivu. (2001). \"Future of Product Modeling and Knowledge Sharing in the FM/AEC Industry.\" Itcon Vol. 2 (2001); author: Tapio Koivu pg- 139. References 269 Branka Kosovac, Thomas Froese, and Dana Vanier. (1999).\"Integrating Heterogeneous Data Representation in model-based AEC/FM Systems.\" Construction Information Technology 2000, Proceedings of CIT 2000 \u00E2\u0080\u0093 The CIB-W78, IABSE, EG-SEA-AI international Conference on Construction Information Technology, Reykjavik, Iceland, 28-30 June, 2000. Jarmo Laitinen. (1998). \"Model Based Construction Process Management.\" Ph.D. Dissertation. Royal Institute of Technology, Stockholm. Joe Marasco. (2004). \"The project pyramid.\" Accessed in June, 2004 at http://www- 106.ibm.com/developerworks/rational/library/4291.html. William R. Mincks and Hal Johnston. (1998). \"Construction Jobsite Management.\" Delmar Publishers, 1998. MSDN. (2006). \"Analysis Services Object Architecture.\" Accessed in June 2006 at http://msdn.microsoft.com/library/default.asp?url=/library/en- us/olapdmad/agcubesdesign_0o1f.asp Rajehndra Nagappan. (2001). \"A Compositional Model For Multidimensional Data Visualization.\" Proceedings of SPIE -- Volume 4302. Visual Data Exploration and Analysis VIII, May 2001, pp. 156-167. Hao Howard Nie, Sheryl Staub-French, and Thomas Froese. (2007).\"OLAP-Integrated Project Cost Control and Manpower Analysis.\" Journal of Computing in Civil Engineering, Volume 21, Issue 3, pp. 164-174 (May/June 2007). C. North and B. Shneiderman. (1997). \"A Taxonomy of Multiple Window Coordinations.\" Technical Report CS-TR-3854, University of Maryland, Department of Computer Science. C. L. North. (2000). \"A User Interface for Coordinating Visualizations Based on Relational Schemata: Snap-Together Visualization.\" Ph.D. thesis in Computer Science, University of Maryland. May 2000. Chris North, Nathan Conklin, Kiran Indukuri, and Varun Saini. (2002). \"Visualization Schemas and a Web-based Architecture for Custom Multiple-view Visualization of Multiple-table Databases.\" Information Visualization , Volume 1, Issue 3/4 (December 2002) Quinton J. Nottingham, Deborah F. Cook and Christopher W. Zobel. (2001). \"Visualization of multivariate data with radial plots using SAS.\" Computers & Industrial Engineering. Volume 41, Issue 1, October 2001, Pages 17-35. References 270 William O'Brien, Raymond Issa, and Ian Flood. (2003). \"Moving from Information Tunnels to Configurable, User-Model Driven Environments: A Vision for Future Project Information Technologies.\" Towards a Vision for Information Technology in Civil Engineering, Fourth Joint International Symposium on Information Technology in Civil Engineering, ASCE, Nashville, TN, USA. OLAP Council. (1997). \"The APB-1Benchmark.\" Available at http://www.olapcouncil.org/research/bmarkly.htm OCCS. (2004). \"OmniClass \u00E2\u0084\u00A2 Tables - May 2004.\" Accessed in July, 2004 at http://www.omniclass.ca/ T. Pattison and M. Philips. (2001). \"View coordination architecture for information visualization.\" Australian Symposium on Information Visualization (invis.au) (Sydney, Australia, 2001), ACS volume 9; 165\u00E2\u0080\u0093171. PMI. (2008). \"A Guide To The Project Management Body Of Knowledge (Fourth Edition).\" By Project Management Institute. Primavera. (2004). \"Product | P3e/c\". Accessed in June 2004 at http://www.primavera.com/products/p3ec_suite.html Chengzhi Qin, Chenghu Zhou and Tao Pei. (2003). \"Taxonomy of Visualization Techniques and Systems \u00E2\u0080\u0093 Concerns between Users and Developers are Different.\" Accessed in March 2005 at http://www.hku.hk/cupem/asiagis/fall03/Full_Paper/Qin_Chengzhi.pdf Jan Reinhardt, Burcu Akinci, and James H. Garrett Jr. (2004). \"Navigational Models for Computer Supported Project Management Tasks on Construction Sites.\" Journal of Computer in Civil Engineering, Vol. 18, No.4, October, 2004. J. Rumbaugh. (1999). \"The Unified Modeling Language Reference Manual.\" Addison- Wesley Publishing Co. Alan Russell and Nocola Chevallier. (1997). \"Representing a Project's Physical View in Support of Project Management Functions.\" Canada Journal of Civil Engineering, Volume 25, 1998. Alan Russell and Thomas Froese. (1997). \"Challenges and a Vision For Computer- Integrated Management Systems For Medium-Sized Contractors.\" Canadian Journal of Civil Engineering, Vol. 24, No. 2, April 1997, pp.180-190. Alan Russell. (2004). \"Research Thrust I.\" Accessed in June, 2004 at http://www.civil.ubc.ca/faculty/ARussell/ARussell.htm References 271 Salford. (2003). \"3D to nD Modelling Project.\" Webpage of University of Salford at: http://ndmodelling.scpm.salford.ac.uk/, accessed January 17, 2003. S. Syed. (1995). \"Information Management for Construction.\" M.A.Sc. Thesis, University of British Columbia. SDG. (2005). \"The Business Intelligence and Data Warehousing Glossary.\" SDG Computing Inc. Accessed in March, 2005 at http://www.sdgcomputing.com/glossary.htm#DataTransformation Darryl M. Sheath, Hilary Woolley, Rachel Cooper, John Hinks, and Ghassan Aouad. (1995). \"A Process for Change - the development of a generic design and construction process protocol for the UK construction industry.\" Proceedings of inCIT\u00E2\u0080\u009996. B. Shneiderman. (1996). \"The eyes have it: A task by data type taxonomy for information visualizations.\" Proc. 1996 IEEE Conference on Visual Languages (Boulder, CO, Sept.3-6, 1996) 336-343. CS-TR-3665, ISR-TR-96-66. Dan L. Shunk, Joong-In Kim, and Hee Yerl Nam. (2003). \"The application of an integrated enterprise modelling methodology--FIDO: to supply chain integration modeling.\" Computers and Industrial Engineering, Vol. 45, Issues1. Kyuman Song. (2004). \" Project Dashboard: Visual Representation of Project Metrics on 3D Building Models.\" PhD Dissertation, Harvard Design School, 2004. A. D. Songer, B. Hays, and C. North. (2004). \"Multidimensional visualization of project control data.\" Construction Innovation. London: Sep 1, 2004. Vol. 4, Iss. 3; p. 173. Robert Spence. (2001). \"Information Visualization.\" Published by the ACM Press in 2001. Sheryl Staub-French and Martin Fischer. (2001). \"Industrial Case Study of Electronic Design, Cost, & Schedule Integration.\" CIFE Technical Report #122, January, 2001. Stanford University. Chris Stolte, Diane Tang, and Pat Hanrahan. (2002). \"Polaris: A System for Query, Analysis, and Visualization of Multidimensional Relational Databases.\" IEEE Transactions on Visualization and Computer Graphics, Vol. 8, No. 1, January-March 2002. Timberline. (2004). \"Timberline Office.\" Accessed on June 4th, 2004 at http://www.timberline.com/software/default.aspx References 272 VEGA. (1997). \"ESPRIT 20408 - VEGA, A Model of Workflow, Specification of a Model for the Definition of Workflows in Virtual LSE Enterprises.\" VEGA D103b. VTT. (2005). \"ProIT: IFC Aspect Library.\" Access in 2005 at http://www.vtt.fi/rte/cmp/projects/proit_eng/indexe.htm. S. Wehrend and C. Lewis. (1990). \u00E2\u0080\u009CA Problem-Oriented classification of Visualization Techniques.\u00E2\u0080\u009D Proceedings of IEEE Visualization (Vis\u00E2\u0080\u009990), 139-143. Sigrid Wenzel, Jochen Bernhard, and Ulrich Jessen. (2003). \"A Taxonomy of Visualization Techniques for Simulation in Production and Logistics.\" Proceedings of the 2003 Winter Simulation Conference. R. Max Wideman. (2003a). \"Model project Management.\" AEW Service, Vancouver, BC. http://www.maxwideman.com/papers/index.htm Edward M. Willis. (1986). \"Scheduling Construction Projects.\" By Prentice Hall, 1986. Jeffrey Wix and Thomas Liebich. (2001). \"Information Flow Scenario.\" Intelligent Service Tools for Concurrent Engineering, http://www.istforce.com. H. Xie, R.R.A. Issa, and W. O'Brien. (2003). \"User Model and Configurable Visitor for Construction Project Information Retrieval.\" Towards a Vision for Information Technology in Civil Engineering, Fourth Joint International Symposium on Information Technology in Civil Engineering, ASCE, Nashville, TN, USA. Kevin Yu, Thomas Froese, and Francois Grobler. (1998). \u00E2\u0080\u009CInternational Alliance For Interoperability: IFCs.\u00E2\u0080\u009D Computing in Civil Engineering: Proc. of the International Computing Congress, ASCE. Boston, MA. pp. 395-406. Kevin Yu. (2002). \"Computer Integrated Construction Based on Total Project Systems Framework.\" PhD Dissertation, University of British Columbia, 2002. M. Zhou and S. Feiner. (1998). \u00E2\u0080\u009CVisual task characterization for automated visual discourse synthesis.\u00E2\u0080\u009D Proceedings of the ACM Human Factors in Computing Systems Conference (CHI\u00E2\u0080\u009998), 392-399. Appendix A 273 APPENDIX A: A CHANGE ORDER PROCESS CASE In this research, a change order process of a building project was taken as an analytical example case for several reasons. Changes occur in every construction project. A typical medium or large size project may involve more than 1000 changes, which may be as complicated as structural modification or as simple as painting color replacement. A change may result from the owner\u00E2\u0080\u0099s directed change, constructive change, consequential change, differing site change, jobsite discovery of hazardous materials, code revisions, vendor coordination, product substitution (Mincks et al., 1998), etc. Moreover, a change may result in revisions of project scope, drawings, specifications, work methods, budget, schedule, quality, etc. In addition, a change usually involves a change order, which is a special agreement defining changes to the terms of a project contract during construction. A change order is usually settled through a formal change order process, which has an important role in construction project management. In this appendix, a change order process, referred to in (Barron, 2001) (Mincks et al., 1998) (Willis, 1986), is examined to illustrate the UCPMA framework described throughout the dissertation. In Section A.1, the change order process scenario, named \u00E2\u0080\u009CSinkhole Earthwork,\u00E2\u0080\u009D is addressed in detail. Section A.2 dissects the change order process by tabulating information regarding \u00E2\u0080\u009CWhat, Who, When, and How,\u00E2\u0080\u009D and then represents the process in Microsoft Visio UML notation. Section A.3 describes basic information involved in the process. Finally, Section A.4 presents the process\u00E2\u0080\u0099s data model in a UML Class Diagram. Material from these sections are quoted or referred to in dissertation chapters. A.1 Change Order Process Scenario The process consists of three phases: Change Initiation, Change Proposal Evaluation, and Change Order Execution. Appendix A 274 A.1.1 Change Initiation A small office building of size 192\u00E2\u0080\u0099-0\u00E2\u0080\u009D X 49\u00E2\u0080\u0099-10\u00E2\u0080\u009D is being built. During excavation, the excavation subcontractor finds a large sinkhole about 2\u00E2\u0080\u0099-4\u00E2\u0080\u009D below the existing grade at grid 2-A. The subcontractor immediately notifies the contractor\u00E2\u0080\u0099s field engineer about the sinkhole discovery which requires additional work to remove it. The field engineer instructs the subcontractor to keep on working and excavating material surrounding the sinkhole in order to discover its size. Meanwhile, the field engineer looks at the drawings to examine the site, floor and structural foundation plans to find any reference to the discovered sinkhole, but no reference is found. He then looks in the specifications for General Requirements-Site Work, Site Preparation and Demolition, and Earthwork. No specific note regarding the sinkhole is found there either. Next, he goes through the geotechnical report. No mention is made of the sinkhole in the geotechnical report. Figure A.1: Found Sinkhole in Construction Site Upon direction from the superintendent, and having gone through General Provisions (CCDC-2, GC6.4) in the contract package, the field engineer thinks that the extra work is not covered in the contract, and then writes a Request for Information (RFI) to the architect and affected engineers to notify them of the problem. The RFI is transmitted to the architect Appendix A 275 via a fax. The architect then reviews the construction documents and visits the site to verify the situation. After verifying the problem, the architect discusses it with the owner\u00E2\u0080\u0099s representative, who decides to proceed with a change proposal from the contractor. The architect responds to the contractor (correspondence to the RFI). Once the problem is verified, the contractor\u00E2\u0080\u0099s accountant initiates a new Extra Work Cost code to track all costs and documentation related to this issue. Then, as the work progresses, all documents such as time cards, material usage records, letters, etc., associated with the issue are tracked and kept in classified folders. The field engineer refers to the General Provisions for information concerning preparation of a change proposal, and Construction Change Directives (CCDC2, GC6.3.3 and GC6.3.4). He decides to prepare an itemized lump sum proposal and requests the appropriate information (related Time Cards, Daily Site Reports, etc.) from the excavation subcontractor once the full size of the sinkhole has been measured. Then the field engineer prepares a contractor\u00E2\u0080\u0099s change order proposal, which includes a cost breakdown and the estimated total cost of the issue. It also states a summary of the change, the finding of facts, the analysis of entitlement, and the cost and schedule impact discussion. [1][2] A.1.2 Change Proposal Evaluation The architect reviews the change order proposal, and agrees to the cost and time extension. Upon the proposal being approved by the owner\u00E2\u0080\u0099s representative, the architect issues a change order (or a contract change directive, if the processing of a change order would take too long for the contractor to proceed with the work immediately, the owner must sign on the change directive or the change order) in accordance with the General and Supplementary Conditions of the Contract. [3] [1] If a subcontractor causes the problem, the field engineer will issue a back-charge change order against the liable subcontractor to compensate for the damage suffered. [2] When the cost is difficult to estimate or the subcontractor is too busy to make an estimate, the work is done based on the tracking of Time & Materials. The subcontractor has to keep track of the time and materials spent on the extra work; and after the work is finished, documents will be submitted for verifying the amounts billed to be reimbursed through a change order directive. [3] If there is an argument over the change order proposal, a meeting with the affected parties may be held in order to negotiate some terms in it. If agreement is not reached, then the architect may prepare and signs a Appendix A 276 A.1.3 Change Order Execution After the receipt of the change order from the architect, the field engineer then issues a subcontractor\u00E2\u0080\u0099s change directive, in which the price for the work (or a method to determine the price for the work \u00E2\u0080\u0093 in other scenarios) is specified. Next, the subcontractor proceeds with the work according to the subcontractor\u00E2\u0080\u0099s change directive. The field engineer submits an application for payment regarding the particular issue. The architect certifies the payment and the billing and payment are made. A.2 Modeling the Change Order Process A.2.1 Change Order Process Activities Dissection A complicated change order process may have one or several loops if there is disagreement with the change proposal or change order. Moreover, a change order may result in a claim. A typical change order involves most of the activities described above. According to the process progress, these activities can be organized into three phases: Change Initiation, Change Proposal Evaluation, and Change Order Execution. To further analyze the process, the process is dissected as a workflow and tabulated as shown in Figure A.2. In this table, columns \u00E2\u0080\u009CFrom\u00E2\u0080\u009D and \u00E2\u0080\u009CTo\u00E2\u0080\u009D list actors interactively performing process activities in three phases, column \u00E2\u0080\u009CWhat\u00E2\u0080\u009D indicates activity objects, and column \u00E2\u0080\u009CMethod\u00E2\u0080\u009D specifies approaches to fulfill process activities. Column \u00E2\u0080\u009COutput\u00E2\u0080\u009D and \u00E2\u0080\u009CReferred\u00E2\u0080\u009D under the \u00E2\u0080\u009CDocument\u00E2\u0080\u009D caption give lists of relevant documents created or reviewed during the process. Column \u00E2\u0080\u009CDecision\u00E2\u0080\u009D highlights main decisions made during the change order process; this information, associated with activities and actors, also draws people\u00E2\u0080\u0099s attention to the key points in the change order process lifecycle. contract change directive (CCD). The contractor may partially agree to the CCD, and then the issue may become a claim, which will be processed under certain contract section. 277 Figure A.2: Change Order Process Dissection (To Be Continued) 278 Figure A.2 (Continued): Change Order Process Dissection Appendix A 279 A.2.2 Process Model in UML Notations Figure A.3, Figure A.4, and Figure A.5 demonstrate UML activity diagrams for three process phases. Within these figures, actors are assigned to each task, and documents generated, or referred to, are linked with a particular task(s). Figure A.3: UML Activity Diagram - Change Initiation Appendix A 280 Figure A.4: UML Activity Diagram - Change Proposal Evaluation Appendix A 281 Figure A.5: UML Activity Diagram - Change Order Execution A.3 Information Involved in Change Order Process A.3.1 Participants In the described scenario, participants take the roles of Architect, Owner (or his/her representative), Superintendent, Subcontractor, Field Project Engineer, Accountant, Scheduler, and Cost Estimator. They read, explore and generate data throughout the process, yet belong to stakeholders with different business targets. Appendix A 282 A.3.2 Documents Output documents include RFI, change proposal, transmittals log, contract change directive (notice to proceed), change order, meeting minutes, timecards, daily site reports, letters, etc. Some samples are listed in Figures A.6 \u00E2\u0080\u0093 A.8. Besides the above documents generated during the change order process, cross-referenced documents include the contract, schedule, geotechnical report, daily site reports, drawings and specifications, etc. A.3.3 Information Recorded in Documents Of these documents, three main examples - RFI, Change Proposal and Change Order - are presented in Figure A.6, Figure A.7 and Figure A.8 respectively. From them, we can see that the change order process features information extensiveness. Typical information recorded in these documents includes the following: A.3.2.1 RFI \u00E2\u0080\u00A2 Project Name and Number \u00E2\u0080\u00A2 RFI No. and Initiated Date \u00E2\u0080\u00A2 Sent To: Receiver (Organization) Name and Address \u00E2\u0080\u00A2 Sent From: Sender (Organization) Name and Address \u00E2\u0080\u00A2 Sent To: Receiver address \u00E2\u0080\u00A2 Sent From: Sender address \u00E2\u0080\u00A2 Sent Method \u00E2\u0080\u00A2 Number of Copies \u00E2\u0080\u00A2 Person Preparing RFI \u00E2\u0080\u00A2 Detail Request Reasons \u00E2\u0080\u00A2 Response Needed Date \u00E2\u0080\u00A2 Response Content \u00E2\u0080\u00A2 RFI Sent Date \u00E2\u0080\u00A2 Initiator Signature and Date Appendix A 283 A.3.2.2 Change Proposal \u00E2\u0080\u00A2 Project Name and Number \u00E2\u0080\u00A2 Proposal Prepared Date \u00E2\u0080\u00A2 Sent To: Receiver (Organization) Name and Address \u00E2\u0080\u00A2 Sent From: Sender (Organization) Name and Address \u00E2\u0080\u00A2 Change Requirement Description \u00E2\u0080\u00A2 Work Method \u00E2\u0080\u00A2 Cost Breakdown Items \u00E2\u0080\u00A2 Cost Item Unit, Usage, Unit Price \u00E2\u0080\u00A2 Schedule Extension and Reasons \u00E2\u0080\u00A2 Proposal Prepared By \u00E2\u0080\u00A2 Signature A.3.2.3 Change Order \u00E2\u0080\u00A2 Initiation Date \u00E2\u0080\u00A2 Project Name and Location \u00E2\u0080\u00A2 Change Reasons \u00E2\u0080\u00A2 To Contractor Name and Address: to identify the designated contractor (or subcontractor) \u00E2\u0080\u00A2 Change Order No. \u00E2\u0080\u00A2 Project No. \u00E2\u0080\u00A2 Contract For: to identify work scope \u00E2\u0080\u00A2 Contract date \u00E2\u0080\u00A2 Change Order Item No \u00E2\u0080\u00A2 Cost Code \u00E2\u0080\u00A2 Cost Code Description \u00E2\u0080\u00A2 Change Order Item Description \u00E2\u0080\u00A2 Change Order Item Amount \u00E2\u0080\u00A2 Original Contract Amount \u00E2\u0080\u00A2 Original Total Amount for Change Order \u00E2\u0080\u00A2 Revised Total Contract Amount Appendix A 284 \u00E2\u0080\u00A2 Changed Contract Time (decreased by unchanged) \u00E2\u0080\u00A2 Date of Substantial Completion of the Change Order \u00E2\u0080\u00A2 Contractor Manager Signature, Address, Date \u00E2\u0080\u00A2 Architect Signature, Address, Date \u00E2\u0080\u00A2 Owner Signature, Address, Date Appendix A 285 Figure A.6: Request for Information (RFI) Form Sample Appendix A 286 Figure A.7: Change Proposal Form Sample Appendix A 287 Figure A.8: Change Order Sample A.4 Change Order Process Data Model Following the analysis illustrated above, the change order data model can be represented in a UML Class Diagram (see Figure A.9). The model includes Process, Task, Resource, Document, Actor, and Organization classes, which capture fundamental information involved in the process. Among classes, Process generalizes tasks, and Task generalizes Appendix A 288 activities. In addition, Workflow is defined here to distinguish the change order process from the document review process and others. A workflow may include more information items, such as task transition (ESPRIT-20408, 1997), than generic processes (e.g. foundation construction). Modeling workflow in detail remains beyond the scope of this research. Figure A.9: UML Class Diagram \u00E2\u0080\u0093 Change Order Process Data Model Appendix B 289 APPENDIX B: UCPMA DATA MODEL ASPECTS The Central Data Model is one of the integrated components in the UCPMA frame. In the prototype system, it is made up of ten data aspects including: Cost, Document, Organization, Process, Product, Project, Resource, Time, Risk and Quality. Except for the process aspect which has been displayed in Figure 7.5, the following presents several snapshots of the data schema for these aspects implemented with the Microsoft SQL server application (see Figures from B.1 to B.9). Each aspect consists of several data tables. A table can exist in many aspects, e.g. DPROJECT_MEMBERS in the Organization aspect and the Project aspect, serving as an association among those aspects. Figure B.1: Cost Aspect Schema 290 Figure B.2: Document Aspect Schema 291 Figure B.3: Organisation Aspect Schema 292 Figure B.4: Product Aspect Schema 293 Figure B.5: Project Aspect Schema 294 Figure B.6: Resource Aspect Schema 295 Figure B.7: Time Aspect Schema 296 Figure B.8: Risk Aspect Schema 297 Figure B.9: Quality Aspect Schema Appendix C 298 APPENDIX C: SCHEMA OF COMMON DIMENSIONS Section 5.3.3 defines seven common dimensions (Cost, Actor, Documents, Process, Product, Resource, and Time) and presents their conceptual data schema. This appendix presents their implementation in the Microsoft Analysis Services environment (Figures from C.1 to C.7). Per definitions, each dimension consists of several tables from different data aspects which are presented in Appendix B. In each figure, there are two areas displaying a dimension\u00E2\u0080\u0099s levels and its data schema respectively. Figure C.1: Cost Aspect Schema 299 Figure C.2: Actor Aspect Schema Appendix C 300 Figure C.3: Document Aspect Schema Figure C.4: Process Aspect Schema Appendix C 301 Figure C.5: Product Aspect Schema Figure C.6: Resource Aspect Schema Figure C.7: Time Aspect Schema Appendix D 302 APPENDIX D: VIEW ENGINE FUNCTIONS AND INORMATION FLOW SEQUENCE DIAGRAM This appendix introduces primary View Engine functions and presents a sequence diagram of information flow among its components. D.1 View Engine Functions D.1.1 Translate User Instructions This function is fulfilled by the DataTranslator module. When configuring a view, a user selects a PM data table and some of its attributes for presenting, as shown in Figure 7.21; sometimes, more than one PM data table may be selected for populating one view. Such configuring information is encoded in a string in the system. Take the following text string as an example: \u00E2\u0080\u009CDRES_DAILY_TASK_MANPOWEUSAGE.DManpowerUseID/DRES_ DAILY_TASK_MANPOWEUSAGE.dDate/DPROJECT_MEMBERS.Na me/\u00E2\u0080\u009D. This string indicates that a view is intended to present information of manpower user ID and manpower use date from the \u00E2\u0080\u009CDRES_DAILY-TASK_MANPOWERUSAGE\u00E2\u0080\u009D table and project member\u00E2\u0080\u0099s name (it may be a labor, a operator, etc.) from the \u00E2\u0080\u009CDPROJECT_MEMBERS\u00E2\u0080\u009D data table; it is saved in the database. When populating a view, such a string mentioned above is read from the database and fed to the DataTranslator module. The module then splits the string, transforms them into a compound SQL query, retrieve PM data using the query, and send required data to the Adaptor for populating the view. Appendix D 303 D.1.2 Populate and Present Visualization The Adaptor module along with the DataTranslator module fulfills this function. The Adaptor has three concrete subclasses (Figure D.1). The ProjectDataAdaptor is designed to automatically create a specific data table object meeting a configuring requirement which is embedded in a text string. The system gets informed from the string that what table in the database contains data for presenting, but doesn\u00E2\u0080\u0099t know how. The ProjectAdaptor specifies this, for example, in order to access cost data in a database table, the adaptor uses this line \u00E2\u0080\u009CoDataObj = New Cost\u00E2\u0080\u009D to create a Cost object. The ViewGraphAdaptor is to call the DataTranslator to generate a query and retrieve PM data from the database, create graph components, and populate them with retrieved PM data. The ViewSettingAdaptor verifies if a graph component is user-action enabled or not \u00E2\u0080\u0093 a Mediator (mentioned in Section D.1.3 below) registers only user-action enabled graph components for view coordination. Figure D.1: Concrete Adaptor Classes A user wants to present a change order scene which includes five common views, for example; each view consists of several graph components \u00E2\u0080\u0093 which are implemented utilizing Microsoft Basic\u00E2\u0080\u0099s Window Form Controls. Visualization configuring information such as what views forms a scene, what graph components constitute a view, how graph components are deployed in a view, what PM data are required to present in graph components, how views or graph components are related, etc., is registered when configuring a visualization and also stored in the same database in the current prototype system. Appendix D 304 Once receiving a user\u00E2\u0080\u0099s instruction, the system takes it as a message passing to the Adaptor. When invoked, the Adaptor calls a View Template Form subroutine to create instances of various graph components as configured before, invoke the DataTranslator to retrieve required PM data through querying the database, populate those graph component instances with derived PM data, and then create views deployed with those graph components and present them to the front end. D.1.3 Coordinate Views This function is contributed by the Controller module implemented on the simplified view coordination model (Figure 7.12). In the prototype system, the Controller consists of a Mediator class and an Observer control module which implements an Observer interface class and Subject class. Each graph control implements the Subject class which mainly contains a function to notify graph components of a user action. Each view generated from the View Template Form subroutine contains an observer instance. The whole system implements a Mediator class which contains an array of observers (view instances). Once a user interacts with a view, e.g., selects an item on a graph component, the graph component catches the user instruction and creates an Event object containing the user instruction, the name of the hosting graph component and related PM data (e.g. selected item\u00E2\u0080\u0099s ID). This Event object serving as a message is passed to the implemented Subject object in the graph component on which the user acts. The Subject notifies the Mediator object of the user action message. The Mediator checks all view instances (observers) according to configuration registration and sends the message to all affected. Once a view receives a message from the mediator, it searches all graph components and passes the message to those graph components linked with the initial one. A graph component gets a message, and then responds accordingly, e.g. by highlighting items to the selected item within the same graph component or located in a different one. Readers can refer to (D' Aoust, 2002) for programming on how the Subject and Observer work in the system. Figures D.2 and D.3 illustrate information flow among View Engine components, described in Section D.1.2 and D.1.3. Appendix D 305 D.2 Information Flow Sequence Diagram The following diagram in Microsoft Visio UML notation shows how information flows among View Engine\u00E2\u0080\u0099s components. 306 Figure D.2: Visualization Presentation Sequence Diagram 307 Figure D.3: View Coordination Sequence Diagram Appendix E 308 APPENDIX E: RISK MANAGEMENT AND QUALITY CONTROL CASES This appendix introduces risk management and quality control cases of an oil sands upgrading project in the northern Alberta, Canada. Information in figures shown here is quoted from original project documents with minor changes. The project design encompasses infrastructure (mostly under ground), such as oily water pipes, catch basins, manholes, fire water system, drainage pipes, drinking water systems, etc., and aboveground superstructures (modules, instrumentation, electricity, etc.). The project was built on a site comprised of lowland areas which are relatively flat but with a couple of creeks going from a river near to the site, as well as some sloughs, trees, etc. The infrastructure of the project started from early January 2008 and ended in May, 2009. E.1 Risk Management Scenario During construction of the infrastructure, a survey company was assigned to measure the depth of a slough on the site at the beginning of Mar, 2008. The weather on the day was minus 29 degree average; the slough was covered with more then 1.5 foot snow on its frozen surface. The client required the project general contractor to take special actions to control risk and ensuring surveyors\u00E2\u0080\u0099 safety for this requirement. To manage risk of this activity, a safety advisor took the steps of 1) sequencing risk activities; 2) identifying risk triggers, and 3) controlling risk in procedures. In particular, the safety advisor first analyzed all factors impacting the job, decomposed the job in tasks and sequenced them with the project scheduler. Second, the safety advisor determined risk triggers (risk causes, etc.) for each step. Third, he recommended procedures for each step (using equipment, tools, procedures, etc.), documented these in a Job Safety Analysis Report, and monitored each step carried out by the surveyor. See Figure E.1, taking the drilling Appendix E 309 through a frozen slough for example. In the first step, the task was considered in the following sequence: working in cold temperature, walking on frozen slough, drilling holes in the ice with the ice auger every 50 feet, and measuring the depth of slough through the hole drilled by the ice auger. For the \u00E2\u0080\u009Cworking in cold temperature\u00E2\u0080\u009D, the safety advisor identified that generally there are three major causes that may trigger risk of the job. They are hypothermia due to cold temperatures, frost bite due to cold temperatures and windburn/frost bite due to wind chill. To prevent risk triggered by these causes, the safety staff recommended: 1) all workers were to dress appropriately for the temperature; 2) workers were to take breaks to warm up when required; 3) workers were to monitor their co- workers for signs of frost bite/windburn. In a medium or large construction project like this oil sands project, risk is defined as activities involving daily health and safety issues, environmental issues, etc. Some are general, requiring standard risk management measures (for example, everyone is required to wear hardhat, life vest and steel-toe boots when going to the field) and others specific to the situation, as in the case addressed above. Yet the handling of most of these issues roughly follows the three steps described earlier. These risk management routines in construction can be designed as a workflow. In some cases, a risk issue may result in damage or loss of equipment, body injuries, environmental pollution, etc.; actions are required to mitigate occurrences of such situations. E.2 Quality Control and Assurance Scenario The infrastructure for this oil sands project includes more than 2000 feet of oily water pipes buried approximately 9 feet deep under the ground level, as well as 182 precast manholes and 117 precast catch basins. All pipes were designed to be placed on compacted sand beds, and all catch basins and manholes to sit on gravel placed on the dried trench bottom. An inspection company (third party) was contracted by the client to carry out QA/QC (quality control and quality assurance) tasks. Appendix E 310 Typically on the site, inspection and/or testing are common methods to determine whether the constructed facility and its base are qualified or not. Such QA/QC inspection or testing activities are generally routine and repetitive in the oil sands project. The independent inspector treated these activities in a workflow method which typically consists of three phases: 1) Scope and Criteria Determination, 2) Quality Control, and 3) Notice and Response. More specifically, the inspector first defined quality control criteria (according to the client quality requirements and design specifications), determined the job scope and conditions, and determined the quality control methods. Second, the inspector reviewed related QA/QC personnel from the Construction Company and client representatives, checked material handling, receiving and storage, performed inspection or testing, analyzed compliance of the constructed work, assessed non-compliance impact, and proposed actions to correct. Third, he notified the construction contractor of the inspection/test results. The contractor mitigated non-compliance impact (if any), and provided feedback with proposed methods to prevent reoccurrence. Then, both companies prepared QA/QC document for project hand-over. Figure E.2 and E.3 are samples of base inspection and testing reports of Manhole #84, Catch Basin #129, other pipes and facilities. The inspector recorded the construction contractor\u00E2\u0080\u0099s activity on a particular day, indicated activities\u00E2\u0080\u0099 locations, and described methods or equipment used to carry out the task on this day. Then the inspector commented on the work condition and performance by inspection, specified equipment (trawler) used for density testing, and addressed that all inspected areas were \u00E2\u0080\u009Cequal to or greater than required density specifications\u00E2\u0080\u009D. In Figure E.3, the report also indicates the excavated base\u00E2\u0080\u0099s geotechnical conditions and determination whether or not the contractor could proceed. It\u00E2\u0080\u0099s not uncommon that a job/deliverable does not meet design requirements or specifications, as determined by inspection/testing. For such a case, a Non-Compliance Report (NCR) will be issued. Figure E.4 shows a sample of a NCR of the oils sands infrastructure project. As the inspector discovered that the ABC company surveyor set out a wrong MH86 location, he initiated the NCR indicating the problem, the reason and impact to the excavator who had over-excavated due to the incorrect location, and proposed a Appendix E 311 solution for the contractor to solve the issue. After receiving the NCR, the contractor fixed the problem as proposed, and returned the NCR noting that disposition action(s) had been completed, verified, and accepted. Also, the contractor took an action requiring \u00E2\u0080\u009Cthe survey manager to verify all GPS units to ensure correct sets and set procedures for periodically training surveyors and cross-examining survey results by different survey groups\u00E2\u0080\u009D, in order to prevent reoccurrence. 312 Figure E.1: Job Safety Analysis Report for Drilling through Frozen Slough Appendix E 313 Figure E.2: Daily Inspection Report of Undergroundings Construction 314 Figure E.3: Base Inspection Report of Undergroundings Construction Appendix E 315 Figure E.4: Non-Compliance Report Sample "@en . "Thesis/Dissertation"@en . "2009-11"@en . "10.14288/1.0063135"@en . "eng"@en . "Civil Engineering"@en . "Vancouver : University of British Columbia Library"@en . "University of British Columbia"@en . "Attribution-ShareAlike 3.0 Unported"@en . "http://creativecommons.org/licenses/by-sa/3.0/"@en . "Graduate"@en . "Integrating data models, analysis and multidimensional visualizations : a unified construction project management arena"@en . "Text"@en . "http://hdl.handle.net/2429/18030"@en .