2. LITERATURE REVIEW
2.5 Object-Oriented System Development (OOSD)
Object-oriented system development (OOSD) stems from the Simula programming language in the 1960s (Dahl and Nygaard 1966). Simula was used to create computer simulations using objects such as ships, buoys, and tides in fords (Satzinger et al 2000).
Objects are the abstractions of physical and conceptual things that have relations, attributes, and behaviors. Object orientation (OO) is the concept that treats every physical and
conceptual thing as the objects (Booch 1994). The OOSD views a system as a collection of interacting objects that work together to accomplish tasks (Satzinger et al 2000). This approach is an entirely different approach to traditional methods such as structured approach and information engineering approach. It develops the software applications in terms of component objects, classes of related objects, and frameworks of related objects and classes.
The OOSD approach views a system as a set of interacting objects. In addition, these objects are described in an abstract manner. Therefore, an incremental and iterative method is suitable for implementing OOSD (Pittman 1993). A system development life cycle generally includes six phases: plan, analysis, design, implement, test, and maintenance. Developing incrementally means to refine systems in steps, whereas, iterative development denotes to grow up systems with looping processes (Firesmith 1993).
The schematic diagram of the incremental and iterative method is shown in Figure 2.5.
Unlike the waterfall approach, the incremental and iterative method delivers the whole system using several iterations. Each iteration builds one portion of the system (incremental) on previous delivery. Since the method accomplishes a portion of the whole system at a time and each development cycle recovers software errors occurring in previous delivery, development risks and complexity are reduced effectively (Caspers 1994;
Satzinger et al 2000). This method also cuts down the overall costs and the development time.
Analysis
Design Test
Plan
… Maintenance
Implement
…
Data flow Legend
Process Division Cycles
…
Data flow Legend
Process Division Cycles
Figure 2.5 Incremental and Iterative Method (Ko, 2002)
For communicating with system participants and modeling and documenting OO software systems, proper notation is required in OO system development life cycle (Vadaparty 2000). The Unified Modeling Language (UML) has been adopted as a standard OO specification language by the Object Management Group (OMG) for specifying, visualizing, understanding, constructing, and documenting OO software using OO concepts (Systä 2000). The OMG is a consortium that develops and propagates uniformity in OO systems. The UML provides several robust models including use case, class, object, component, deployment, sequence, collaboration, statechart, and activity diagrams for users to describe applications for different purposes (Booch et al. 1999). It has also received de facto approval by system developers for modeling software under various OO system development processes (Larman 1999). Therefore, the UML standardized notation is an appropriate notation system for modeling OO systems (Coleman et al. 1997).
Based on the OOSD approach, this study applies the UML to develop the Design-Build Process Collaboration system (DBPCS) to facilitate the fast-track construction.
CHAPTER 3
INTEGRATED DESIGN-BUILD FRAMEWORK (IDBF)
3.1 Problem Description of Integrated Design-Build Framework
This study aims to create an Integrated Design-Build Framework (IDBF) as the architecture to execute a design-build project by combining a fast-tracking mechanism and design-build delivery method with the processes reengineering philosophy. Therefore, to develop the IDBF, the primary concerns about facilitating the fast-tracking construction by process integration are necessary to determined.
Fast-tracking network is the target of the IDBF
The purpose of cross-organization process re-engineering in this research is to facilitate the fast-track construction in the D/B projects. To achieve this purpose, a fast-tracking network needs to be schemed preliminarily so that the re-engineered cross-organizational processes of A/E and GC can then be designed for implementing the fast-tracking network. Therefore, how to determine the fast-tracking phases and their overlapping relationships is the first concern for developing the IDBF. To overcome this problem, dividing a D/B project into several design-build packages and identifying their sequential relations are two essential tasks. As the fast-tracking phases and overlapping relationships are determined, a fast-tracking model depicting the network of fast-tracking construction can be created subsequently.
Collaborative process model of A/E and GC is essential for fast-tracking
Because design and construction activities respectively executed by A/E and GC are both included in the fast-tracking phases, how to cooperate between A/E and GC is the
second concern in the IDBF. Accordingly, aiming at the collaboration between A/E and GC’s processes, this study applies business process re-engineering (BPR) philosophy to generate the collaborative process model of A/E and GC. For this purpose, some problems and constrains for creating the collaborative process, inherited from the natures of BPR philosophy and design-build projects, are necessary defined preliminarily.
First, the created collaborative process is project-oriented one, due to the different constitution of different design-build project allies; i.e., the collaborative mechanism may differ from projects due to different processes within alliances’ organizations. Moreover, for both GC and A/E, since a design-build team is a temporary alliance, and several design-build projects may possibly concur, the collaborative process model is properly created based on the original processes without changes or modifications for the existing processes so that design professional and GC can perform their collaborative process model under the usual processes. Accordingly, recognizing the collaboration links and potential information flows between design professional and GC’s processes is the core for creating a collaborative process model. Interoperability of process is the main focus of the cross-organization process reengineering. The processes of A/E and of GC can be integrated from an information processing viewpoint based on the input-operation-output paradigm.
Second, to reengineer the processes across the boundary between design professional and GC, an abstract process model providing formal representation of process characteristics is necessary at the beginning of process reengineering (Scheer, 2000; Irani et al., 2001). However, under circumstances addressed by Cheng (2003), it is often difficult if not impossible for managers to accurately describe by category the operational processes of a construction company and of a design professional. Generally, ISO specifications are
useful references for process modeling due to the details they provide on management processes and activities; therefore, this study refers to the ISO specifications and applies the eEPC diagram of the ARIS modeling language (Scheer, 2000) to depict graphic process models providing a visual view of the abstract process model. When process models are generated, two processes can then be compared with similarity measures to determine the possible collaboration links and information flows between them.
An information system for managing the execution of the fast-tracking and the collaborative process model is the significant infrastructure in the IDBF.
Unlike the traditional linear design and construction procedure, complexities of project execution and potential risks may increase with the overlapping activities in the fast-track construction. Besides, the activities within the collaborative process model are distributed over A/E and GC’s organizations. Thus, how to manage the execution of the collaborative process model to facilitate the fast-tracking is the final concern in the IDBF.
To overcome this problem, a process management system is significant for executing the collaborative processes. The process management system needs not only the capability to manage the execution the collaborative processes, but also the function to manage the execution of fast-track phases in a D/B project.
Summarily, to develop the IDBF, the fast-tracking model, the collaborative process of A/E and GC, and a process execution management information system are the three primary components needed to create. Following this idea, the architecture of the IDBF is developed.
3.2 Architecture of Integrated Design-Build Framework
The three models encompassed by the IDBF include the (1) fast-tracking model, (2)
collaborative process model, and (3) Design-Build Process Collaboration System (DBPCS), as shown in Figure 3.1. The fast-tracking model is the constitution of design-build modules (DBMs) as derived from an analysis of the axiomatic design (AD) method. Each DBM is assigned a project sub-goal, to be achieved by the collaborative design and construction processes within the collaborative process model (CPM). The fast-tracking phases of a Design-Build (D/B) project can be determined based on DBM overlapping relationships.
Moreover, the collaborative process model is composed of collaborative design and collaborative construction processes, both of which are generated using the Cross-Organizational Process Re-engineering Method (COPReM). The COPReM is used to identify areas of overlap between A/E and GC processes to determine activities that are common to both. The bottom layer of the IDBF is addressed as the Design-Build Process Collaboration System (DBPCS), which serves as the IDBF implementation infrastructure.
The fast-tracking and collaborative process models created, respectively, in the first and middle layers, are both conceptual models that are difficult to implement due to their complexity. To overcome this problem, the DBPCS must be designed to implement fast-tracking and integrated process models automatically.
Figure 3.1 Architecture of Integrated Design-Build Framework (IDBF)
To develop three layers in the IDBF, this study first applied the axiomatic design (AD) methodology to map a D/B project into customer, functional, physical and process domains by zigzagging decomposition and creating dependency matrices. Figure 3.2 shows AD mapping relationships. Each associated domain consists of specific characteristic vectors such as customer need {CN}, functional requirement {FR}, design proposal {DP} and construction process variable {CPV}. Concurrently, the design matrix [A] between {FR}
and {DP} vectors and the construction matrix [B] between {DP} and {CPV} vectors can be evaluated to present DPs and CPVs execution sequences. Further, the concurrent matrix, the product of design and construction matrices, can be applied to reveal the overlapping relationships among all DBMs. The final fast-tracking model for a design-build project can be generated by summarizing the DBMs and their overlapping relationships.
Figure 3.2 Four Domains of Axiomatic Design in This Study
However, as coordination between design and construction processes are critical to DBM implementation, details regarding these processes must be determined in order to achieve further process integration. Therefore, this study also develops a Cross-Organizational Process Re-engineering Method (COPReM) to create the Collaborative Process Model (CPM), which was used as the foundation for design-build module implementation. The CPM comprises collaborative design and construction processes that cross organizational boundaries, as shown in Figure 3.1. In other words, the generated CPM provides a cooperative mechanism that satisfies all DBMs within the
fast-tracking model. The collaborative design process delivers design results for DBMs and collaborative construction processes realize the design results generated by collaborative design processes. Each collaborative process within the CPM encompasses the following three components: A/E processes, GC processes and collaborative links. A/E and GC processes represent the processes originally in operation in their respective organizations.
Collaborative links represent areas of shared activity between the two processes.
To generate the CPM for a D/B project team, this study applies a semantic similarity analysis to evaluate data and functional similarities between A/E and GC processes to identify overlapping activities and duplicated data exchange flows. By applying process reengineering philosophy, collaboration links in the CPM can thus be generated using process mergence and activity collaboration methodologies.
The collaborative processes embedded in all DBMs serve to increase complexity and decrease feasibility of the fast-tracking model. Therefore, the DBPCS, the bottom layer of the IDBF, is designed to implement fast-tracking and collaborative process model automatically. However, as CPM collaborative processes span two independent organizations, collaborative process information is distributed over a heterogeneous information environment. Consequently, the DBPCS requires the capability to exchange data between legacy systems without interfering with original system functions.
Accordingly, the DBPCS must (1) proceed with the fast-tracking model and manage DBM execution procedures, (2) make CPM executable in the DBPCS, and (3) dispatch activities to corresponding actors and acquire information from the original information system in order to deliver consistent data to actors. To accomplish these three objectives, this research combines a Microsoft BizTalk framework and the Multi-Agent System (MAS) philosophy to develop the DBPCS.
In summary, the IDBF offers a process-oriented, fast-tracking execution mechanism for D/B projects, in which the collaborative process model provides design-and-build processes for DBMs in the fast-tracking model, and the fast-tracking model expresses the overlapping relationships between DBMs. With regard to creating the fast-tracking model and CPM, a fast-tracking model creation method and the cross-organizational process reengineering method (COPReM) are addressed in the following two sections.
Furthermore, a DBPCS is developed based on the MAS philosophy to implement and manage automatically the collaborative processes in the created fast-tracking model to increase IDBF feasibility.
Finally, to demonstrate IDBF feasibility, a real D/B project case “A” involving an integrated residence is illustrated. The design-builder in this example is a GC and A/E team, with the GC designated as team leader. Figure 3.3 shows the organizational structure of the D/B team in case “A”. The case study aimed to create a fast-tracking model and integrated process model for the initially independent cases of GC “A” and DP “A”.
Design-Builder
General Constructor
“A＂
Architecture/Engineer
“A＂
Financial analysis Purchasing Division
Construction management Construction Department
Subcontractors
Architecture design Subcontractors
Figure 3.3 The Design-Builder’s Organization Structure of Case “A”
Chapter 4
Fast-Tracking Model Creation Method
The fast-tracking model represents the first step in creating an IDBF as it represents the goal of D/B team integrated processes. The collaborative process model can then be determined based on the fast-tracking model. The purpose of the latter is to create a scheme for fast-tracking design-build modules (DBMs) and for delineating their overlapping relationships. Generally, a DBM clusters the execution of both design and construction activities. Using the axiomatic design (AD) methodology, the development procedure of fast-tracking model as shown in Figure 4.1 is discussed in the following.
5. Produce the concurrent matrix [C]
Is [A] or [B] changed？
7. Create fast-tracking model 4. Evaluate the construction process
design matrix [B]
6. Rearrange both matrixes [A] and [B]
Yes
No
2. Decompose FRs and DPs
3. Generate construction process variables (CPVs)
1. Define the first level FRs Start
End Determine the design proposals and
concurrent relationships of them.
Determine the construction process variables and concurrent
relationships of them.
Generate the design-build modules and determine the overlapping relationships of each modules to create the fast-tracking model.
DP Analysis:
CPV analysis:
Fast-tracking model analysis:
Figure 4.1 Procedure for creating a fast-tracking model
4.1 Define the First Level FRs
The 1st level function requirements (FRs) are the basic functional requirements of a D/B project that the construction must satisfy. The 1st level FRs are defined as the minimum sets of independent functional requirements that describe project design goals.
Generally, the FRs in the lst level are derived from customer needs (CNs), which can be determined from the request for proposal. In the example of the integrated residence project, the following seven CNs were identified.
1. Land use optimization;
2. Environmental protection;
3. Incorporation of basic functions (e.g., “fire safety”, “privacy protection”, “lighting &
ventilation”, “water & power supply”, “rational utilization of space”, “clear and simple emergency evacuation pathways”;
4. Building safety;
5. Incorporation of open spaces;
6. Barrier free environment design; and 7. Parking space maximization.
Based on the above CNs, four corresponding 1st level FRs were initially determined as shown in Figure 4.2.
Figure 4.2 The lst level FRs of Case “A”
4.2 Decompose FRs and Design Proposals (DPs)
Because 1st level FRs can express only abstract D/B project requirements, with a level of detail inadequate to describe design goals, decompositions of 1st level FRs are required. Furthermore, because design proposals (DPs) must be generated simultaneously
procedure shown in Figure 4.3 (Suh, 2001). To reduce interrelationships between individual DPs, FRs and DPs were required to satisfy the Independence Axiom (Suh, 2001) of axiomatic design methodology during the mapping process. Procedure details are described below.
Figure 4.3 The Zigzagging Procedure of Decomposing FRs and DPs
1. Mapping FRs to DPs at the current level
The aim of this step is to determine the most proper design proposals for fulfilling current level FRs. Figure 4.4 shows 1st level DPs mapped from the FRs in Figure 4.2.
Integrated Residence
Environment Protection
Facilities Layout: DP1 Landscape Design: DP4
Water/Power supply and air condition system design: DP3 Master Design: DP2
Figure 4.4 The lst Level DPs of Case Study (corresponding to Figure 4.2)
2. Evaluating the design matrix [A]
The level of concurrency in the relationship between two design proposals can now be evaluated based on the evaluated design matrix [A]. The process of mapping between functional requirements and design proposals allows the dependency relationships between functional requirements to be expressed mathematically in terms of characteristic vectors defining the functional contribution value of design proposals to each FR. Accordingly, at a given level in the FR and DP hierarchies, the set of functional requirements in the functional domain constitutes the FR vector, denoted as {FR}. Similarly, the corresponding set of design proposals in the physical domain constitutes the DP vector, denoted as {DP}.
The relationship between {FR} and {DP} can be written as:
} ]{
[ }
{ FR = A DP ………(4.1)
In Equation 4.1, [A] is called the building design matrix which expresses the functional contribution values of design proposals to each FR. After referencing the contribution relationships within this matrix [A], dependency relationships between FRs can be determined by clustering their related DPs. Taking Figure 4.4 as an example, because FR1 and FR2 are both fulfilled by DP1, therefore, FR1 and FR2 are not independent of one another.
Moreover, to make overlapping possible, the relationship between functional requirements must satisfy the Independence Axiom. That is, the design matrix [A] must either be a diagonal or triangular matrix (as shown in Figure 4.5(2) and 4.5(3)). When the design matrix [A] is diagonal, each functional requirement can be satisfied independently by means of one DP, with such a design described as “uncoupled”. When the matrix is triangular, the independence of FRs can be guaranteed if and only if the DPs are
determined in a proper sequence. Such a design is described as “decoupled”. Any other matrix types (as shown in Figure 4.5(1)) are called full matrices and result in coupled designs which violate the Independence Axiom.
X
Figure 4.5 Three Types of Design Matrices of Axiomatic Design Method (Peña-Mora, 2001)
The 1st level design matrix [A], as derived from 1st level functional requirements and design proposals, is shown in Table 4.1. The design matrix [A] shown in the Table 4.1 represents the original matrix; that is, there is no consideration given to obeying the Independent Axiom. If the original matrix is satisfied with the Independence Axiom, either the subsequent decomposition level can proceed sequentially or the functional requirements and design proposals in the matrix must be modified. Therefore, the matrix shown in Table 4.1 should be modified in the next step.
Table 4.1 The 1st Level Design Matrix [A] (Original)
Environment Protection Facilities Layout Master Design Water/Power supply and air condition system design Landscape Design
DP1 DP2 DP3 DP4
3. Modifying FRs and DPs
As design matrix [A] is a full matrix, functional requirements and design proposals must be modified to satisfy the Independence Axiom. Achieving such must take the following into consideration: Firstly, if no coupling exists between the two entities, the full matrix can be decoupled by switching the order of entities in the matrix. Secondly, if coupling does exist between entities, either the functional requirements or design proposals must be regenerated. In the design matrix example illustrated in Table 4.1 which has no coupling entity, the full matrix can be decoupled by switching the order of “Environmental protection requirements (FR1)”, and “General functions of building (FR2)”. Table 4.2 shows the decoupled matrix modified from the full matrix in the Table 4.1.
Table 4.2 The 1st Level Design Matrix [A] (Modified)
Master Design Environment Protection Facilities Layout Water/Power supply and air condition system design Landscape Design
DP2 DP1 DP3 DP4
General Functions of
Building: FR2 X 0 0 0
Environmental Protection
Requirements: FR1 X X 0 0
Water/power supply and air
condition: FR3 X 0 X 0
Landscape: FR4 X 0 0 X
Functional Requirements (FRs)
Design Proposals (DPs)
3. Zigzagging DPs to next level FRs
As current level functional requirements satisfy the Independence Axiom, the
requirements at the next level. As next level functional requirements are generated, their corresponding design proposals can be determined and the design matrix evaluated to ensure elements within the level satisfy the Independence Axiom. FR and DP hierarchies
requirements at the next level. As next level functional requirements are generated, their corresponding design proposals can be determined and the design matrix evaluated to ensure elements within the level satisfy the Independence Axiom. FR and DP hierarchies