Architectural Engineering and Design Management

ISSN: 1745-2007 (Print) 1752-7589 (Online) Journal homepage: https://www.tandfonline.com/loi/taem20

ICT-enabled Collaborative Working Environment

for Concurrent Conceptual Design

Dino Bouchlaghem, Huiping Shang, Chimay J. Anumba, Mei Cen, John Miles
& Mark Taylor

To cite this article: Dino Bouchlaghem, Huiping Shang, Chimay J. Anumba, Mei Cen, John
Miles & Mark Taylor (2005) ICT-enabled Collaborative Working Environment for Concurrent
Conceptual Design, Architectural Engineering and Design Management, 1:4, 261-280, DOI:
10.1080/17452007.2005.9684597

To link to this article: https://doi.org/10.1080/17452007.2005.9684597

Published online: 06 Jun 2011.

Submit your article to this journal

Article views: 109

View related articles

Full Terms & Conditions of access and use can be found at

https://www.tandfonline.com/action/journalInformation?journalCode=taem20
 261

ARTICLE

ICT-enabled Collaborative Working

Environment for Concurrent Conceptual
Design
Dino Bouchlaghem, Huiping Shang, Chimay J. Anumba, Mei Cen, John Miles
and Mark Taylor

Abstract
Effective concurrent conceptual design (CCD) in the architecture, engineering and construction (AEC) industry is
essential for reducing project lead times and improving the quality of the resulting design. Computer-aided
techniques and tools are needed to facilitate concurrent engineering (CE) between geographically distributed
project team members during conceptual design (CD). This paper reports on a research project that has both
designed the system architecture and developed a Web-based CE tool to improve AEC projects during the CD
stage. It describes the applications requirements for construction projects and presents a layered and integrated
approach for the integration of multidisciplinary perspectives in concurrent conceptual design. A prototype
system (INTEGRA) has been developed to encapsulate this approach. Details of the overall system architecture
and software components are included in the paper. The aim of the INTEGRA system is to develop IT-based CE
tools that support AEC professionals’ collaborative work in a conducive and flexible way. The paper concludes
that CCD is an interesting and challenging area, and that many topics remain open for further investigation. In
particular, there is a need to ensure the integration of legacy systems used by AEC professionals into new
collaborative design systems.

■ Keywords – Conceptual design; concurrent engineering;
concurrent conceptual design; client/server architecture;
Web-based systems
INTRODUCTION
The architecture, engineering and construction (AEC)
industry is noted for its fragmentation (Howard et al,
1989; Anumba and Evbuomwan, 1996). For example, the
design of a commercial building typically involves six
separate major disciplines, in addition to the client, all of
whom view the process from different perspectives and
may work for different companies. It is generally
accepted that 80% of product costs are committed by
decisions made in the first 10% of the design process,
so the greatest opportunity for economies occurs at
conceptual design stage. Also, getting it right first time
saves money, so conceptual design (CD) is important.
In recent years, concurrent engineering (CE) has been
regarded as an efficient approach to reduce AEC project
lead times and improve design quality. The manufacturing
and electronics industries have implemented CE largely
by collocation but this is more difficult to achieve in
the AEC industry because of the high degree of
fragmentation. Moreover, current CE research in the AEC
industry has been concentrated on the later stages of the
design process and little work has been done on CD,
although it is becoming increasingly recognized as being
important in the AEC industry because a good CD has the
potential to reduce AEC project lead times and overall
costs (Anumba and Newnham, 1998; Santoyridis et al,

ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280

262 D. BOUCHLAGHEM ET AL
1999; Anumba et al, 2000; Wang et al, 2002). It is
recognized that CD is very demanding and intellectually
challenging. This is because, first, the functional
requirements, operating constraints and evaluation
criteria during conceptual design are usually uncertain and
incomplete and, second, CD issues in AEC projects often
involve different professionals from different disciplines
such as clients, architects, engineers and contractors. The
decisions of all these participants interact with those of
the other disciplines but due to the poor definition of the
design, especially during the early stages of CD, there
tends to be insufficient cooperation or coordination.
Therefore, tools are needed to facilitate CE between
remote participants, especially during the CD phase.
This paper reports on a research project that has
investigated the particular needs of concurrent
conceptual design (CCD) – a challenging area that
requires the development of novel techniques to deal
with designers’ needs to rapidly develop and assess
ideas. It presents the integration of multidisciplinary
perspectives in concurrent conceptual design
(INTEGRA) system architecture and the development of
an advanced prototype IT tool for supporting CCD using
the Internet as a communication medium. Given the
available resources it has been necessary to restrict the
scope of the INTEGRA project and the work has only
dealt with the CD of commercial, beam/slab-type
buildings such as a typical office or hotel.
RELATED WORK
IT support for conceptual design has been an active
research area for some time. Recent examples include
work on the synthesis and simulation of solutions for
mechanical engineering design problems (Yao and
Johnson, 1997) and the Schemebuilder environment for
Mechatronics (Counsell et al, 1998). The latter uses a
knowledge-based approach that has largely been
discredited as an approach to CD. Both of these are
large, sophisticated systems but they are not applicable
to the AEC industry. For the latter, recent work on
conceptual design includes the work of Mathews and
Rafiq (1995), Foley et al (1999), Khajehpour and Grierson
(1999) and Miles et al (1999). None of the above
specifically supports CE.
Although computer-supported co-operative working
has been an active research area since the 1980s and
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
the techniques have been widely investigated for
certain aspects of concurrent engineering (CE) (e.g.
Sriram et al, 1992; Cutcosky et al, 1993), there has been
relatively little work to look at the particular needs of the
AEC industry. Also, there has been very little work on
the particular needs of CE tools for CD where the ability
to rapidly develop and test ideas is vital. The AEC
industry has some unique features that often render
techniques developed for other areas of engineering, at
best, only partially applicable. For instance, the AEC
industry is highly fragmented, almost all of the designs
are bespoke, the client employs the services of the
designers before what is to be designed is properly
defined and the resulting products are highly complex
with many more components than, for example, a car.
Different approaches for collaborative working
software have been used for CD in the AEC industry;
these include evolutionary computation, knowledge-
based computer-aided design (CAD techniques), agent
technology and Web-based concurrent design. CAD
systems have focused on facilitating individual design in
specific domains or supporting the integration of several
different knowledge-based CAD tools. The CAD system
developed by Pohl and Myers (1997) is such an example.
The system aids in developing schematic floor plans
during CD by horizontally integrating a CAD drawing
environment with six knowledge-based systems that
specialize in day lighting, sound control, structural system
selection, thermal behaviour, cost and spatial access. The
system serves as an interactive surface between the
building designer and the various intelligent design tools.
Gero et al (1997) describe an integrated prototype-based
expert CAD environment, which integrates CAD-based
building design using prototype refinement with a
knowledge-based system that verifies building code
conformance. However, despite the above work, it is
generally accepted that CAD is too restrictive and
cumbersome for CD (Bradley and Maropoulos, 1998).
There have also been a number of projects that have
used agent-based approaches to collaborative design.
The ADLIB (Agent-Based Collaborative Design of Light
Industrial Buildings) project investigated the feasibility
of using intelligent agents as tools for collaborative
design within the context of light industrial buildings.
ADLIB focused on the potential for agents to suggest
design alternatives and an appropriate devolution of
 ICT-enabled Collaborative Working Environment for Concurrent Conceptual Design
design responsibility between the designer and the
agents (Ugwu et al, 1999).
For single-user systems, evolutionary computation
approaches to CD have been particularly successful
because they have the ability to search the space of
possible design solutions. However, to date, these
systems have suffered from limited geometrical
reasoning abilities. For instance, all the systems for
building design (e.g. Mathews and Rafiq, 1995;
Khajehpour and Grierson, 1999; Miles et al, 1999) have
been limited to buildings with a rectangular floor plan,
with the exception of the work of Shaw et al (2005). This
more recent work does allow for more irregular shapes.
For Web-based collaborative design, Klein (1997)
presents a system designed to improve the capture of
and access to preliminary and geometric design
rationale within concurrent engineering teams. The
approach supports the viewing and updating of
the information by design team members through the
integration of CAD and World Wide Web technology.
Design decisions and their rationale are stored in a
shared database. These data are accessed and updated
by design team members using graphical user-
interfaces on standard Web browsers. Preliminary (non-
geometric) design decisions and the rationale are
entered directly via the browsers. Geometric data are
defined via CAD systems and translated into 2D or 3D
formats. These images, after being entered into the
shared design database, can be viewed over the Web.
Huang et al (2001) proposed to establish a Web-based
framework that supports engineering change
management procedures and activities. The approach
intends to provide better communication sharing,
simultaneous data access and processing, and more
prompt communication and feedback.
Most of the work on AEC industry CE software has
concentrated on the later stages of the design process
and/or does not focus on configurable user-interfaces and
the provision of adequate mechanisms for version control
and change management (Turk et al, 1997; Anumba and
Newnham, 1998; Santoyridis et al, 1999). CD has special
needs. The main work in this area is the intranet-based
work of Fruchter et al (1993) and Fruchter (1996). The
applicability of Fruchter’s work is limited by her use of a
CAD system. As discussed above, CAD is acknowledged
as being too complex for CD. Also her work contains no
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
263
input from or evaluation by practising designers. Schmitt
(1998) describes a number of systems for the
collaborative creation of graphic representations of
designs. The work is of interest but also does not involve
any input from practising designers during the
development and there has been very little evaluation,
hence its relevance is questionable. The literature on IT
support for design contains descriptions of many
systems that have not been subjected to the rigour of
practical evaluation. The value of such work is debatable.
INTEGRA SYSTEM REQUIREMENT
ANALYSIS
The approach used in the INTEGRA project was to work
closely with practising designers, contractors and
clients. At the start of the project, an extensive
requirements capture process was undertaken to
ensure that the research team fully understood the
processes involved in CD. The information gained was
then used to determine the system architecture and
steer the remainder of the work.
Capturing the system requirements was conducted
through a series of interviews with AEC professionals
using knowledge elicitation (KE) techniques. The KE
results show that ‘actors’ on a typical building project
include a client, an architect, a structural engineer, a
mechanical and electrical (M&E) engineer and a contractor.
A number of activities are identified by actors. Table 1
gives an account of different actors’ roles and their major
functional characteristics established through the KE.
The main aim of the conceptual design team is to
provide the client with the plan layout, general form and
structural layout of the building. A typical CD process is
illustrated in Figure 1.
● First, the client provides initial information such as
the client’s brief and geotechnical report to the
team members.
● The whole team discusses design issues and
constraints through project meetings.
● The architect studies the requirements of the
client’s brief and recent buildings of architectural
significance, proposes initial design options for
critique and comments from the other members,
while the structural engineer presents initial
structural layout to the other members.
264 D. BOUCHLAGHEM ET AL

TABLE 1 Actor roles and their activities

Actors Activities Main Concern
Client Describe users’ requirements and functionality of the proposed building. Construction costs, construction time,
Supply client brief, track design decisions, analyse uncertainty potential profits and project risks
and risk minimization
Architect Leading designer. Form and functionality of the building
Provide alternative design options. Analyse context,
site condition, topography and client brief
Structural Scheme out options and decide which are the most Structure of the building. Column layout,
engineer suitable and present them to other roles. Produce a and column loads
sketch-based structural layout. Identify constraints of the project
M&E engineer Design of environmental conditioning of the building including Shape, orientation and lighting of the
all mechanical, electrical and public health services together with building. Floor-to-floor heights, cladding,
lighting, acoustics and building automation location of the lift shaft
Contractor Contribute ideas on build ability, risk and cost control Construction risk, cost, control strategy,
pitfalls, public utilities and ground
conditions
Project manager Manage the project. Management of the project
While there may be a single designated
project manager, s/he may be several actors that undertake
project management roles at various level and for various purposes

● Through a critical review, discussion and

commentary on the design options including plan
layout and structural layout, the architect and the
structural engineer choose the most acceptable
solutions, and improve them until other members
are satisfied.
● The final design options will be presented in a
formal plan layout, 3D image of design and
structural layout.

Note that one of the more surprising aspects of the KE

is that the geotechnical engineer’s involvement comes
before CD. This is because the major cost variant for any
building is the foundations. Hence the geotechnical
aspects of the design are approximately determined at
the stage when the land purchase is being negotiated.
All subsequent foundation design, etc. at the CD stage
is dealt with by the structural engineer.

LAYERED AND INTEGRATED SYSTEM

ARCHITECTURE
Based on interview results and requirement analysis, the
INTEGRA system has been designed using a layered and
FIGURE 1 The conceptual design process integrated architecture. If construction information such

ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280

 ICT-enabled Collaborative Working Environment for Concurrent Conceptual Design
as building design brief files are to be accessed and
used widely between clients, architects, engineers and
construction managers, networking should be
considered. Since the Internet is an international
network where geographically distributed people are
able to exchange and communicate information, it can
be used to support multidisciplinary activities in the
INTEGRA system. From the perspective of network
communication, the INTEGRA system is organized as a
set of layered components. It has several layers ordered
hierarchically from the most abstract (closest to the
system problem domain) down to the most concrete
(closest to the underlying hardware). The most abstract
layer is the user application layer and the most concrete
layer is the hardware connection and support layer
(Jacobson et al, 1998). On the other hand, activities such
as building constraint checking and risk assessment
cannot be performed within the communication
platform; Web-based software needs to be developed to
enhance the system functionality. From a system
software design point of view, the INTEGRA system is an
integrated set of software components residing on the
system physical model. The building blocks of the
system are processes for designing subsystems,
FIGURE 2 Layered INTEGRA system
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
265
packages, tasks and their interconnections. Therefore,
the system can be viewed as both layered applications
and a set of integrated functions.
LAYERED APPROACH TO THE INTEGRA SYSTEM
A major function of the INTEGRA system is to provide
the abstract tools required for transferring messages
and managing interactions across the Internet. The
system can be logically layered in terms of abstraction
and designed as a series of vertical slices of
functionality that cut through all layers. A four-layer
hierarchy has been used for the INTEGRA system and
contains a set of client/server relationships within the
following layers:
● user agent layer
● application process layer
● communication layer
● lower layer network service and support.
Each layer in the hierarchy uses the next lower layer and
becomes an abstract tool.
In Figure 2, the column on the left represents the
software layers used by the server, whereas the column
266 D. BOUCHLAGHEM ET AL
on the right represents the layers used by the client. The
software layers at the server and the client are the
same. Each layer has its interface called service access
points (SAPs) – a set of classes and objects that may be
externally accessed. The arrows in Figure 2 are the
paths traversed by messages and represent the
dependency relationship, which indicates that software
packages in each layer depend on the tools below
them. For example, a typical message originating in the
application layer is passed down the left column of the
figure as it is prepared for transmission. Finally, it is
transmitted by the lower layer at the server and received
by the lower layer of the client. From there, the
message can be passed up the hierarchy until it reaches
the application layer on the client side.
The user agent layer houses the user agent
component that is an interface between the users, Web
pages and Web applications. This component
implements all functions that are typically associated
with the graphical user interface (GUI). Since the
Internet is used as a communication medium in the
system, the user agent needs to have both Internet-
oriented and multi-platform support. The user agent is
effectively a Java-enabled Web browser such as
Microsoft Internet Explorer or Netscape Communicator.
The browser, together with its extensions and external
applications, allows a user to navigate and
communicate with the interface over the Internet.
The application process layer incorporates a Web-
based application component that implements the
requirements defined by the application within the
context of the domain in which the application
operates. For example, a risk assessment application
will produce a variety of risk actions or initiatives based
on numeric input, fuzzy linguistic terms, calculations
and other considerations. It includes server application
processes (APs) and client APs. In this case, the
application software is partitioned so that some
components reside on the client side, while others
reside on the server side. Client APs may be scripts,
add-ins, applets or external applications. Server APs
may be constructed using server-side technology such
as ASP (Active Server Pages), JSP (Java Server
Pages)/Servlet, PHP (PHP Hypertext Processor,
originally stood for Personal Home Page) or CGI
(Common Gateway Interface).
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
The communication layer involves network
communication protocols used for the INTEGRA system
between the client and the server. HTTP is an
application layer protocol that directly supports Web-
based INTEGRA system applications. SMTP is used to
transfer mail. FTP supports the transfer of files between
the client and the server. HTTP, FTP and SMTP run
over the TCP (Transfer Control Protocol)/IP (Internet
Protocol).
The lower network service and support layer mainly
includes the data link layer and physical layer, and
normally includes the device driver in the operating
system and corresponding network interface card in the
computer. Together they handle all the hardware details
of physically interfacing with the cable (or whatever type
of media is being used) (Stevens, 1994).
The layered approach to the INTEGRA system
makes it possible to build each layer independently and
link them together when they are completed. The more
abstract layers are the clients that invoke the services of
the more concrete layers. This one-way dependency
makes it possible to use the same lower-level server
layers in different contexts because they do not depend
on their clients. Similarly, since the lower layers offer a
well-defined set of interfaces, they can be replaced with
different lower layers making the entire subsystem
easily portable to other physical environments.
INTEGRATED APPROACH TO THE INTEGRA
SYSTEM
The INTEGRA system has been implemented as an
‘integrated’ environment, with multiple applications
rolled into a single coherent system that is accessed via
the Internet. Its main software components are
illustrated in Figure 3. They consist of eight functional
components: (1) user interface, (2) client briefing tool,
(3) cost modelling tool, (4) constraints checking tool, (5)
risk assessment tool, (6) sketching and drawing tool, (7)
3D visualization tool, and (8) synchronous and
asynchronous communication tool. The user interface
resides in the user agent layer; the client briefing, cost
modelling, constraints checking, risk assessment,
sketching and drawing, and 3D visualization tools are
distributed in the application process layer.
Synchronous and asynchronous communication is
implemented in the communication layer.
 ICT-enabled Collaborative Working Environment for Concurrent Conceptual Design
FIGURE 3 Integrated INTEGRA system
User interface
The user-interface of the INTEGRA system is based on
an HTML/XHTML presentation and includes a non-
functional interface and a functional interface. The non-
functional user-interface contains a description of the
INTEGRA system such as contact information and
system status. The functional user-interface contains
tool interface preferences and the corresponding front-
end presentation interfaces for back-end tool
applications. Also, an alternative, 3D interface has been
created as an attempt to develop a more intuitive style
of accessing what is a very complex environment. For
details of this, see Taylor et al (2004).
Client briefing
The client brief must be carefully formulated so as to
provide enough contextual information to ensure a solid
foundation for a construction project. In the INTEGRA
system, the client brief contains the basic requirements
for the building such as requirements for costs,
gross/net areas, car parking, etc. The client briefing tool
is designed to enable clients to input information on the
requirements at the beginning of the project (Cen et al,
2002). The software converts the bulk of the information
in the client brief into constraints which are then used
by the other tools in the environment.
Cost modelling
The cost model was the subject of extensive
discussions between the industrial participants and the
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
267
research team. Further advice was also sought from a
specialist cost consultant. At one stage, it was intended
to use a cost model that has emerged from background
research but, eventually, the industrial participants
swayed the decision in favour of a cost model that is in
everyday use and with which they were familiar. The
cost-modelling tool provides an element-based model
for estimating the cost of a building design. The
reference prices for the elements can be obtained from
a variety of publications and cost indices (Cen et al,
2002).
Constraint checking
Constraints for a building design generally come from
the client brief, Building Regulations and standards or
the design team members. The constraints can be in
either text or numerical formats. The constraint
checking tool within INTEGRA contains facilities for
checking the numerical constraints only. Generally, the
text-based constraints are too vague to be implemented
in a computer system and instead they are kept in the
constraint checking tool and can be browsed as
required.
The constraint checker was developed in the form
of a Java applet that uses a graphical input. The need for
a graphical format is because the designers have to
provide some sort of description of the design for the
system to check. The graphical description is achieved
via an object-oriented sketching tool which allows the
designers to develop a typical floor plan and add
268 D. BOUCHLAGHEM ET AL
features such as walls, cores, columns, windows,
doors, standard rooms, etc. Each design discipline
makes its particular contribution to the sketch. Although
the process sounds involved, in practice, the input only
takes one or two minutes. To give the sketch validity and
a scale, the tool uses a user-provided site plan to a
known scale as the background for the sketch and all
items in the sketch are then automatically added to this
predefined scale (Figure 4).
For the actual constraint checking, constraints such
as the gross area, net area and car parking are checked
directly from the sketch. Constraint checking of other
parameters such as project cost, floor-to-ceiling
FIGURE 4 The constraint checker
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
heights, and building height, requires some additional
user input (Cen et al, 2002). There is one additional
feature in the constraint checker – a search algorithm.
This is the routine that checks the building for
compliance with fire escape legislation by checking
the travel distances to cores and/or fire escapes.
Usually, this is a complex and time-consuming
manual procedure which the checker undertakes in
seconds.
Being able to define an outline design and then
quickly check it for constraint compliance is a huge
advance on the present day manual techniques where
areas, volumes, etc. have to be calculated by hand for
 ICT-enabled Collaborative Working Environment for Concurrent Conceptual Design
each design option. With the INTEGRA constraint
checker, each design option can be quickly defined and
then assessed for compliance.
Risk assessment
The risk assessment tool elicits information from the
design team regarding the risk associated with various
design options and other choices and then uses these
data to rank project option risks using fuzzy logic. The
decision is based on an aggregation of the project team
members’ views. The value and validity of each team
member’s input is assessed in a confidential manner by
the other members of the team. So, for example, if a
decision involved the structure, then one would expect
the team members to place the greatest emphasis on
the input of the structural engineer. This tool is
composed of two parts – project server and project
client. The whole risk assessment process is started on
the server side by the project manager. Team members
can access the client system via the Internet. They get
access to the necessary information and then submit
their inputs to the server. The tool processes them and
FIGURE 5 Sketching and drawing tool
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
269
produces a rank-ordered list of risks that the team
needs to address (Yang, 2001). Based on their
assessment, a final judgement is made. The process is
controlled by one member of the design team who acts
as a chair.
Sketching and drawing
The sketching and drawing tools are integrated within
the Web interface with the aid of legacy systems. These
sketching tools are for visualization purposes, as
opposed to the constraint checking described above,
and are used to assess the appearance of the building’s
elevation and how it fits into the surroundings. The
participants in the CCD can draw these sketches using
four methods, depending on which they prefer –
freehand sketching, Autodesk Architectural Desktop
(ADT), Autodesk AutoSketch and Painter Classic
software (Figure 5). In addition, external hardware (e.g.
WACOM Intuos Graphics Tablet System) is used to
respond to user actions. The Intuos Graphics Tablet
System consists of two elements: a graphics tablet
serves as drawing work area, and the Intuos pen, a
270 D. BOUCHLAGHEM ET AL

pressure-sensitive freehand device is used for image
editing and creating. The WACOM control panel is
designed to be customized and keep track of Intuos
tools settings. Different settings can be customized for
different applications.
3D visualization tool
2D sketches and drawings can be turned into 3D
panoramic views using this tool. It uses the MGI
Photovista software (MGI Software Corp, 2000) within
the Web browser. Figure 6 shows the process of
converting 2D sketches to 3D panoramic views.
Communication tools
The communication tools are needed to facilitate ● Smooth transfer of information (models,
collaborative team interactions. These are based on
NetMeeting (for synchronous communication) and
BSCW (Basic Support for Cooperative Work) (for
asynchronous communication) over the Internet.
NetMeeting allows AEC professionals to exchange
information with each other and to collaborate on
projects. During meetings, they can jointly create and ● An increase in construction project control that is
share documents, without having the software on each
computer. Users can also communicate using text chat,
audio and video; use the whiteboard for sharing
drawing/documents; transfer files; and access remote
computers using Remote Desktop Sharing. The BSCW
system enables collaboration over the Web (OrbiTeam
Software GmbH, 2002). It is based on the notion of a
shared workspace – a joint storage facility that may
contain various kinds of objects such as documents,
tables, graphics, spreadsheets or links to relevant Web
pages. A workspace can be set up and objects stored,
managed, edited or downloaded with any Web browser.
The BSCW system keeps members of a group informed
about each other’s relevant activities in a shared
workspace.
The benefits of the integrated approach include:
programmes, documents, data) from one tool to
another, for example, 2D sketches produced with
sketching and drawing tools can be loaded into the
3D visualization software to produce a 3D
panorama. These 2D and 3D sketches can also be
uploaded to the BSCW system.
achieved through integration of multidisciplinary
perspectives in CCD, this integration leads to better
communication, planning, and monitoring.

FIGURE 6 From 2D drawing to 3D panorama

ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280

 ICT-enabled Collaborative Working Environment for Concurrent Conceptual Design
● Improved coordination among project team
members through synchronous and asynchronous
communication.
THE INTEGRA INTEGRATED PROTOTYPE
SYSTEM
The INTEGRA system prototype was developed to
encapsulate the layered and integrated approaches. It
uses the Internet as a carrier, networking
multidisciplinary team members using client/server
architecture. Multidisciplinary perspectives based on the
different roles in a construction project team such as
client, architect, and engineer are considered. Figure 7
illustrates the structure of the current prototype system.
The system software caters for a Web client/Web
server/application server/database structure. The Web
client can be located or installed on any computer over
the Internet. The client processes run concurrently on
the Web browser and interact with the Web server
through the HTTP. The Web server processes client
requests, controls interaction between client
application and data, and returns the Web page to the
FIGURE 7 INTEGRA prototype system
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
271
Web clients. The application server encapsulates
application-specific processing components. The
BSCW server is a legacy system used for documents,
folders, URL sharing and accessing, while the FTP
server is used for uploading and downloading data files.
The database server handles data-object intensive
tasks.
CONCURRENT CLIENT PROCESS
The client processes are the Web browser and its
extensions including client-side scripts and Java
applets. As collecting and validating users’ inputs is one
focus of the project, Java applets are used to
accomplish this requirement. For example, the client
briefing, cost model and constraint checking tools are
implemented as Java applets. These particular tools are
set up for asynchronous use by single users rather than
being truly collaborative. This is because allowing more
than one user to alter items at a given time can easily
lead to confusion and conflicting operations on the
same design. If two or more users wish to collaborate
in the usage of a particular tool, then this can be
272 D. BOUCHLAGHEM ET AL

uses an Apache Web server that is responsible for

interactions involving the Web client, the application
server and the BSCW server. The application server
consists of server-side applications that run on the Web
server. The current application server has been
developed as PHP applications for implementing
business rules, access control, workflow services and
session tracking. The application server software
components are illustrated below using the risk
assessment tool.

Business rules
The risk assessment process is a series of steps, shown
in Table 2, that are encapsulated in the risk assessment
tool. For example, the CalContr.php in task 6 is to
compute contribution degree between the risks; its
pseudo code is shown below:

Get risk items from the database

Get relative weights of team members from the
database
Get contribution degree between the risks from the
database
Calculate contribution degree and select the used risk
using FSM
{Define the top level set
Define the bottom level set
Define the intermediate level set
Define the isolated level set

TABLE 2 Risk assessment process

STEPS TASKS ACTORS
FIGURE 8 Client briefing and cost model Initialization Collect project information Project manager
Task 1 Generate risk issues Team members
Task 2 Gather and rationalize risks Project manager
achieved by sharing a desktop using NetMeeting or Task 3 Assign weights to team Team members
similar software. The applets are used both as members
sophisticated user-interface elements and for Task 4 Derive absolute weights and Project manager
encapsulating the necessary construction logic. Figure 8 relative weights of team
shows two examples, these being the client briefing members
and cost modelling tools. Task 5 Input contribution degree Team members
between risks
WEB/APPLICATION SERVER Task 6 Determine selected risks using Project manager
The Web server provides the application support fuzzy structural modelling (FSM)
required to respond to transactions and Task 7 Assign risk probability and impact Team members
communications from clients. The prototype system Task 8 Rank risks and input their actions Project manager

ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280

 ICT-enabled Collaborative Working Environment for Concurrent Conceptual Design 273

If (a risk locates the top level || a risk locates the are saved in the database server and used to monitor
isolated level) task completion and sequence for each team member.
Put the risk to selected risk list}
Display contribution degree calculation form Session management
Submit the form and invoke SaveUsedRisk.php Since HTTP has no mechanism to maintain state,
The selected risks are stored to the database. individual requests from the same team member are not
related to one another. The Web server cannot easily
Access control distinguish between team members, but maintaining
The risk assessment tool provides role-based login members’ state is one of the fundamental requirements,
functions including the creation of team member for example, the tool needs to keep track of team
accounts and the validation of login information. The members’ information to avoid external access and
project manager (PM) performs the initialization process unauthorized data input. Thus, the session management
which includes the input of project information, role list mechanism is implemented to enable risk data entered
of team members and access rights. The information is by a member to be associated with that member over the
saved in the database (Figure 7). The PM then notifies period of use and to ensure that only members
the team members of their user names and passwords authenticated by the PM can use the tool. For example,
to login into the system. Only the team members steps 2, 4, 6 and 8 need to apply the following procedure:
authorized by the PM can use the tool.
if (!session_is_registered(‘VALID_ROLE’))
Workflow services You are not logged in, please go to login page......
Workflow control is another important requirement for if ($VALID_ROLE!=’project manager’)
the tool, as the risk assessment process depends on You are not Project Manager, you have no privilege to
team members’ collaborative working over the Internet. do this step......
Figure 9 shows the workflow process model, the
sequence of activities performed by the team members BSCW SERVER
and the PM, and their interdependencies, where: The BSCW server is an extension of the Web server,
which means an HTTP demon that is extended by the
● Cnn – controls and automates the coordination of BSCW functionality which is implemented as CGI scripts
the workflow with Python code. More details of BSCW can be seen at
● Taskn – corresponds to the specific process the BSCW website http://bscw.gmd.de/. Currently, the
activities for roles. INTEGRA prototype uses the BSCW server to establish
security and access rights of information, version and
Each step defines a specific task and provides control configuration management, and event notifications.
structures for following activities. In the tool, stepn_flags BSCW provides the essential information exchange

FIGURE 9 Risk assessment workflow process model

ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280

274 D. BOUCHLAGHEM ET AL
infrastructure required for collaborative design. These
facilities allow the stakeholders to create and manage
the various files that refer to a given scheme in a logical
and sensible manner.
Figure 10 shows the INTEGRA shared workspace
using BSCW. This workspace is used to store different
kinds of information generated by application tools.
Information is stored as objects arranged in a folder
hierarchy including briefing files, sketches and
drawings, reports, etc. Team members can transfer
information from their machines to the workspace and
set access rights to control the visibility of this
information or the operations that can be performed for
others (BSCW 4 Administrator Manual, 2002; BSCW 4
User Manual, 2002).
Access rights
The INTEGRA prototype environment makes use of the
BSCW access rights model, which can define roles for
members and thereby assign differentiated access
rights to a shared workspace. Roles in the BSCW server
are ‘manager’, ‘owner’, ‘member’, ‘restricted member’
and ‘registered user’. Role access rights in BSCW allow,
FIGURE 10 INTEGRA shared workspace
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
for example, that some users (manager, owner,
member) may have complete control over an object in a
workspace whereas others (restricted member) have
only read access or no access at all. Construction
disciplines including project manager, client, architect,
structural engineer, mechanical and electrical engineer,
and contractor can be related to the predefined roles in
BSCW. In the INTEGRA prototype, all disciplines should
be registered users and the project manager should
also be the workspace manager, which has R/W rights
to all objects.
● workspace manager, R/W, execute all actions +
● owner: R/W √
● member: R/W *
● restricted member: read-only Θ
Version management
The INTEGRA information within a workspace can be
subject to version control, which is particularly useful
for joint construction document production. It also can
prevent two people trying to check out and work on the
same design document simultaneously. INTEGRA users
 ICT-enabled Collaborative Working Environment for Concurrent Conceptual Design
can also set a lock to prevent the overwriting of a
document. The version state of a document indicates its
degree of maturity or the pertinent stage in a work
process. BSCW provides a menu with three version
states – ‘experimental’, ‘stable’ and ‘released’ – which
correspond to the ‘transient’, ‘working’ and ‘released’ of
the established versioning terminology (Santoyridis et
al, 1999).
Event services
The INTEGRA prototype makes use of BSCW event
services to provide users with information on the
activities of other users, with respect to the objects
within a shared workspace. Events are triggered
whenever a user performs an action in a workspace,
such as uploading a new document, downloading
(‘reading’) an existing document, renaming a document
and so on. The system records the events and presents
the recent events to each user.
FTP SERVER
The applet tools in the INTEGRA prototype use the FTP
server for temporary file storage. The code for the FTP
function in Java called the Linlyn class is used to
read/write files on the FTP server from the tool applets
such as client briefing, cost modelling and constraints
checking in the INTEGRA system.
To upload a file:
Linlyn ftp = new Linlyn (<servername>, <user>,
<password>);
ftp.upload (<directory>, <filename>, <contents
of file>);
To download a file:
Linlyn ftp = new Linlyn (<servername>, <user>,
<password>);
String contents = ftp.download (<directory>,
<filename>);
EXTERNAL APPLICATIONS
The sketching and drawing tool is a Web-based
application that connects proprietary systems such as
ADT, AutoSketch, Architecture, Painter Classic and
Photovista to the Web. The communication tool is
launched by the Web browser to provide additional
NetMeeting services. These proprietary systems are
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
275
integrated using WSH (Windows Script Host) in
VBScript. For example, the following VBScript
statements use WSH to run Photovista:
● Dim wshShell
● Set wshShell = CreateObject(‘Wscript.Shell’)
● wshShell.run ‘PVISTA’
DATA ACCESS
The database server MySQL is used to provide data-
related services for the INTEGRA environment. These
services include storing and retrieving data, aggregating
results from existing data (for example, summing
values), updating or deleting data, organizing or
reorganizing the logical structure of data and
administering the database management system. It can
bridge the server-side applications and backend
database through database connectivity. In a data
access topology, a data engine would process requests
sent from the client’s side of the system. The language
used in these requests is in a form of SQL (Structured
Query Language).
SYSTEM EVALUATION
Many forms of software are not amenable to testing
and evaluation by using known solutions or
experimental results. In such circumstances, the only
form of evaluation that is possible is to ask potential
users to use the software in as realistic manner as can
be achieved and to pass an opinion on the suitability or
otherwise of the software. It is recognized that the
results obtained from such an exercise are qualitative
rather than quantitative but they are the only possible
indication of fitness for purpose. Also, when the
evaluators are asked to test software which requires
them to work in a way that breaks with their normal
practices, then the validity of the results becomes even
more difficult to establish because unfamiliarity can
produce a negative response.
With the INTEGRA environment, it is not possible to
evaluate it using, for example, closed form solutions and
so it has been necessary to evaluate using potential
users. Throughout the research process to create the
environment, each stage was evaluated by the industrial
participants so the resulting software would tend to
reflect their views. Thus, to ensure that an independent
276 D. BOUCHLAGHEM ET AL
evaluation was obtained, it has been necessary to
establish another group of people to undertake this work.
The initial testing of the environment was undertaken
by undergraduate and graduate engineering students.
The main purpose of this work was to check that the
software worked as intended and to detect any major
bugs. At this stage, the environment was not complete
so only parts of the system (mainly the constraint
checking, sketching and BSCW) were present. 12 people
participated in this testing and as a result of this some
minor modifications were made. Following the above,
further rounds of testing were undertaken again using
students. Again the environment was not in its final
state, but this work was used to assess the impact of
further additions to the software.
The main testing occurred at the end of the
development process and in total involved 10 people,
approximately half of whom were practising engineers
and the other half graduate engineering students or
engineering academics. The testing was based around
a workshop session which was divided into three
stages. The first stage was an introduction to INTEGRA
giving an overview of the environment, its aims and the
available tools. This was followed by a demonstration of
the software. The third stage was a hands-on testing
session where the evaluators were encouraged to use
the system.
FIGURE 11 The effectiveness of INTEGRA in terms of document handling, communication and collaboration
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
At the end of the above process, each evaluator was
given a questionnaire to obtain feedback on their
opinions of INTEGRA and their experience of using the
software. The majority of the questionnaire focused on
eliciting information regarding the appropriateness or
otherwise of INTEGRA for supporting CCD and team
communication.
SUPPORT FOR COMMUNICATION AND
COLLABORATION
The evaluators were asked to rate INTEGRA as a
support tool for AEC industry designers undertaking
CCD. This opinion is based on the above limited
exposure.
The evaluators were asked a series of questions
and the answers were typically given using a scale of
one to five, where 1 = strongly disagree, 2 = disagree,
3 = neutral, 4 = agree and 5 = strongly agree. In
addition, space was left for the evaluators to add further
comments in free text. The first question sought for
responses ‘regarding the creation, storage and retrieval
of documents’, this effectively being the parts controlled
by BSCW. The majority of the evaluators agreed that the
environment is effective in this area (Figure 11). The
second question looked at the ‘exchange of information
such as sketches and other documents’ and again the
response was that it is effective.
 ICT-enabled Collaborative Working Environment for Concurrent Conceptual Design 277

The third question elicited a more mixed set of supporting CCD and would not contribute to the
responses, with the overall response being neutral. The success of a design project’. The result was strongly
next question was framed in the negative – ‘that the against this suggestion. The final question looked at
environment provides no support for achieving the ‘overall integration of the tools within the
individual and joint tasks and goals’. The evaluators environment’ and this obtained a positive response.
were supportive of the software with the bulk Overall for this section, the questionnaire results were
disagreeing with the question. The final question in this supportive of INTEGRA.
section looked at the ‘usefulness of the system for
facilitating collaborative working’ and again the THE PERFORMANCE OF THE ENVIRONMENT
response was largely positive. Therefore, the overall This section of the questionnaire was derived by a
response from this section was supportive. different researcher who preferred to use a scale of
1 to 7 for the answers ranging from 1 = very poor to
SUPPORT FOR CCD 7 = excellent. Again there were four questions in the
The next section in the questionnaire asks a series of section and the results are given in Figure 13.
questions about the software’s support for CCD. The The questions in this section cover the ‘ability of the
first question asks whether the evaluators ‘have been software to increase team productivity, support the
provided with all the technology that is needed to execution of CD, reduce time on document management
support CCD’ (Figure 12). The responses show that and increase stakeholder satisfaction because of
the evaluators were not entirely convinced about the extended information access’. None of the questions in
effectiveness of INTEGRA in this area although this section obtained a response lower than adequate
the free text responses fail to give a reason why. A and most of them were ‘good’ or ‘very good’ with some
question about the ‘user-friendliness of the ‘excellents’. This is an interesting finding. Some of the
environment’ obtained a more positive set of replies. differences may be because the longer scale permits
The third question was again framed in the negative more considered responses but, even so, there does
and stated that the ‘environment was not efficient in seem to be a stronger response to these questions.

FIGURE 12 The effectiveness of INTEGRA for supporting CCD

ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280

278 D. BOUCHLAGHEM ET AL
FIGURE 13 Performance of the environment
THE INDIVIDUAL TOOLS AND TASKS
The evaluators were also given questions about the
individual tools with, as explained below, the exception
of NetMeeting and the risk assessment. To ensure that
they experienced all parts of the environment, they
were also required to complete a set of tasks such as
‘drawing a typical floor plan’, ‘checking the plan for
constraint compliance’, ‘using the cost model’,
‘creating an elevation and 3D view of the design’, etc.
The full set of replies is too lengthy and complex to be
covered here but the responses were all positive. Only
two questions received any replies that were mildly
negative and these were for the ‘creation of the 3D
view’, where two of the users rated this as less than
adequate, and for the ‘fire escape constraint checker’,
which received less than adequate from one
evaluator. However, another evaluator also rated this as
excellent!
The NetMeeting tool was not included in the above
evaluation but was tested using the research team
members. The tests included using text chat,
whiteboard and audiovisual communication on a
network where the slowest line speed is 10 mega bits
per second. The test involved six people trying to
communicate simultaneously and, sadly, it was a failure.
A limited amount of audio communication was possible
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
but the response was not consistent or reliable enough
for everyday use. The visual communication was poor.
The only thing that worked well was the text chat.
Further tests were undertaken with smaller groups of
users but even with just three users, the response times
were poor and the visual communication, in particular,
was very limited. It was concluded that without a much
higher band width being available or the usage of far
more sophisticated tools such as VIC (http://
vrvs.cern.ch/Doc/vic-guide.html) and RAT (http://
www-mice.cs.ucl.ac.uk/multimedia/software/ rat/), the
kind of communication that is required is not possible.
The evaluation of the risk assessment tool was
undertaken as a separate exercise because its usage is
relatively time consuming and it would have made the
main assessment too lengthy. To evaluate this tool, a
risk assessment scenario was created and a group of
four people were then asked to participate in an
evaluation session. The process was initiated by the
project manager who specified the project information.
Three further project team members were then involved
in the risk assessment process – a client, an architect
and an engineer. The tool collated the submission of the
whole team, integrated the specification, chose and
ranked the top five risks. The evaluators were
impressed with the tool and felt it is a useful addition
 ICT-enabled Collaborative Working Environment for Concurrent Conceptual Design 279

to the normal decision-making processes that are used Huiping Shang: Department of Civil and Building Engineering,
in CD. Loughborough University, Loughborough, Leicestershire, LE11 3TU,
UK. Tel: +44 (0) 1509 228745, fax: +44 (0) 1509 223981,
SUMMARY OF THE EVALUATION e-mail: H.Shang@lboro.ac.uk.
The results of the evaluation indicate that the
requirements analysis and the subsequent Chimay J. Anumba: Department of Civil and Building Engineering
development of a system architecture for INTEGRA has Loughborough University, Loughborough, Leicestershire, LE11 3TU,
been a success and that the environment represents UK. Tel: +44 (0) 1509 222615, fax: +44 (0) 1509 223981,
the basis for the development of a more complete e-mail: c.j.anumba@lboro.ac.uk.
commercial product to support CD. It is recognized that
the evaluation procedure is not perfect and that those Mei Cen: School of Engineering, Cardiff University, Cardiff,
doing the evaluation only had limited exposure to the CF10 3FQ, UK. Tel: +44 (0) 2920 875694,
system but, given the restrictions that the commercial fax: +44 (0) 2920 874597, e-mail: CenM@Cardiff.ac.uk.
sector places on people releasing their time, this is
about all that can be achieved. John Miles: School of Engineering, Cardiff University, Cardiff,
CF10 3XQ, UK. Tel: +44 (0) 2920 875694,
CONCLUSIONS fax: +44 (0) 2920 874597, e-mail: milesjc@Cardiff.ac.uk.
To meet the requirements of virtual teams in
construction and CCD processes, the INTEGRA Mark Taylor: School of Engineering, Cardiff University, Cardiff,
environment has been designed using a layered and CF10 3XQ, UK. Tel: +44 (0) 2920 874694,
integrated approach. The approach used has been fax: +44 (0) 2920 874597, e-mail: TaylorM3@cf.ac.uk.
based on an extensive requirements analysis with
practising designers. This has then been used to guide
the development of the software and the format of the REFERENCES
environment. The prototype environment is a usable Anumba, C.J., Baldwin, A.N., Bouchlaghem, D., 2000, ‘Integrating concurrent
implementation of web-based IT tools that enable AEC engineering concepts in a steelwork construction project’, in Concurrent
professionals to work collaboratively and concurrently Engineering: Research and Applications, 8(3), 199–212.
even though they are distributed in time and space. An Anumba, C.J. and Evbuomwan, N.F.O., 1996, ‘A concurrent engineering
evaluation has indicated that this prototype is applicable process model for computer-integrated design and construction’, in B.
for distributed construction team collaborative work and Kumar et al (eds.), IT in Civil and Structural Engineering Design, Edinburgh,
in particular that it could make significant productivity UK, Inverleith Spottiswood, 39–42.
savings in the concurrent conceptual design process. Anumba, C.J. and Newnham, L.N., 1998, ‘Towards the use of distributed
artificial intelligence in collaborative building design’, in E.T. Miresco (ed.),
ACKNOWLEDGEMENTS Proceedings of the 1st International Conference on New IT for Decision
The research team would like to acknowledge the Making in Civil Engineering, Montreal, Canada, October 1998, Montreal,
support of the Engineering and Physical Sciences Ecole de technologie supérieure, 413–424.
Research Council (EPSRC) and the contribution from the Bradley, H.D. and Maropoulos, P.G., 1998, ‘A relation-based product model for
industrial partners – High-Point Rendel, Ove Arup, computer-supported early design assessment’, in Journal of Materials
Grosvenor Waterside (Cardiff Bay) plc, Dale Kennedy Processing Technology, 76(1), 88–95.
Partnership, and Birse Construction Ltd. BSCW 4 Administrator Manual, 2002, Germany, OrbiTeam Software
GmbH.
BSCW 4 User Manual, 2002, Germany, OrbiTeam Software GmbH.
AUTHOR CONTACT DETAILS Cen, M., Miles, J., Taylor, M., Bouchlaghem, D., Anumba, C.J., Chim, Y.M.,
Dino Bouchlaghem: Department of Civil and Building 2002, ‘Requirement capture for concurrent conceptual design’, in M.
Engineering, Loughborough University, Loughborough, Leicestershire, Schnellenbach-Held and H. Denk (eds), Advances in Intelligent Computing
LE11 3TU, UK. Tel: +44 (0) 1509 223775, fax: +44 (0) 1509 223981, in Engineering, Proceedings of the 9th International EG-ICE Workshop,
e-mail: n.m.bouchlaghem@lboro.ac.uk. Darmstadt, August 2002, Dusseldorf, VDI Verlag, 201–211.

ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280

280 D. BOUCHLAGHEM ET AL
Conallen, J., 1999, Building Web Applications with UML, Boston,
Massachusetts, Addison Wesley.
Counsell, J., Porter, I. and Duffy, M., 1998, ‘SchemeBuilder: CACD for
mechanism motion control’, Proceedings of a Workshop on Power
Transmission and Motion Control, University of Bath.
Cutcosky, M.R., Englemore, R.S., Fikes, R.E., Genesereth, M.R., Gruber, T.R.,
Williams, M.S., Tenebaum, J.M. and Weber, J.C., (1993) ‘PACT: An
experiment in integrating concurrent engineering systems’, in Computer,
26(1), 28–37.
Foley, A., Miles, J.C. and Moore, C.J., 1999, ‘Innovative support for bridge
design’, in C. Gold (ed.), Concrete Communication Conference 1999, British
Concreter Association, Crowthorne, July, Crowthorne, UK, BCA, 355–366.
Fruchter, R., Clayton, M., Krawinkler, H., Kunz, J. and Teicholz, P., 1993,
‘Interdisciplinary communication of design critique in the conceptual design
stage’, in L. Cohn (ed.), V-ICCCBE, Proceedings of the fifth International
Conference on Computing in Civil and Building Engineering, Anaheim, CA,
June 1993, New York, American Society of Civil Engineers, 377–384.
Fruchter, R., 1996, ‘Interdisciplinary communication medium in support of
synchronous and asynchronous collaborative design’, in B. Kumar and A.
Retik (eds), Information Representation and Delivery in Civil and Structural
Engineering Design, Edinburgh, UK, Civil Comp Press, 21–28.
Gero, J.S., Balachandran, M.B. and Rosenman, M.A., 1997, ‘Intelligent
expert system and CAD systems for design verification’, in I.D. Tommelein
(ed), Expert Systems for Civil Engineers: Integration Issues, New York, ASCE.
Howard, H.C., Levitt, R.E., Paulson, B.C., Pohl, J.G. and Tatum, C.B., 1989,
‘Computer integration reducing fragmentation in the AEC industry’, in
Journal of Computing in Civil Engineering, ASCE, 3(1), 18–32.
Huang, G.Q., Yee, W.Y. and Mak, K.L., 2001, ‘Development of a Web-based
system for engineering change management’, in Robotics and Computer
Integrated Manufacturing, 17(3), 255–267.
Jacobson, I., Booch, G. and Rumbaugh, J., 1998, The Unified Software
Development Process, Reading, Massachusetts, Addison Wesley.
Khajehpour, S. and Grierson, D.E., 1999, ‘Filtering of pareto-optimal trade off
surfaces for building conceptual design’, in B. Topping and B. Kumar (eds),
Optimization and Control in Civil and Structural Engineering, Edinburgh, UK,
Civil Comp Press, 63–70.
Klein, M., 1997, ‘Capturing geometry rationale for collaborative design’, in
R. Reddy and F. Pena-Mora (eds), Proceedings of 6th IEEE Workshops on
Enabling Technologies: Infrastructure for Collaborative Enterprises, Cambridge,
MA, June 1997, Los Alamitos, California, IEEE Computer Society, 24–28.
Mathews, J.D. and Rafiq, M.Y., 1995, ‘Adaptive search to assist in the
conceptual design of concrete buildings’, in B.H.V. Topping (ed),
Developments in Neural Networks and Evolutionary Computing for Civil and
Structural Engineering, Edinburgh, UK, Civil Comp Press, 179–187.
MGI Software Corp, 2000, Photovista virtual tour reference manual.
Miles, J.C., Sisk, G. and Moore, C.J., 1999, ‘The conceptual design of
commercial buildings using a GA’, in B. Topping and B. Kumar (eds),
ARCHITECTURAL ENGINEERING AND DESIGN MANAGEMENT ■ 2006 ■ VOLUME 1 ■ PAGES 261–280
Optimization and Control in Civil and Structural Engineering, Edinburgh, UK,
Civil Comp Press, 17–24.
OrbiTeam Software GmbH, 2001, BSCW Version 4.0 User Manual.
Pohl, J. and Myers, L., 1997, ‘ICADS: an integrated knowledge-based CAD
system’, in I.D. Tommelein (ed.), Expert Systems for Civil Engineers:
Integration Issues, ASCE, New York.
Santoyridis, I., Carnduff, T.W., Gray, W.A. and Miles, J.C., 1999, ‘Assessing a
versioning system for collaborative engineering design with a bridge design
experiment’, in International Journal of Computer Integrated Design and
Construction, 1(1), 17–28.
Schmitt, G., 1998, ‘A new collaborative design environment for engineers and
architects’, in I. Smith (ed.), AI in Structural Engineering, Berlin Springer-
Verlag, 384–397.
Shaw, D.J., Miles, J.C. and Gray, W.A., 2005, ‘Conceptual design of
orthogonal commercial buildings’, in B.H.V. Topping (ed.), Proceedings of
the 8th International Conference on the Application of AI to Civil,
Structural and Environmental Engineering, Rome, August – September
2005, Stirling, UK, Civil Comp Press.
Sriram, R., Livezey, B.K. and Perkins, W.A., 1992, ‘A distributed shared
database system for concurrent engineering’, in 4th National Symposium
on Concurrent Engineering, CE and CALS conference, Washington DC, June
1992, Society for Computer Aided Engineering, 29–43.
Stevens, W.R., 1994, TCP/IP Illustrated, Volume 1: The Protocols, Reading,
Massachusetts, Addison Wesley.
Taylor, M., Miles, J.C., Bouchlaghem, N.M., Anumba, C.J., Cen, M. and Shang,
H., 2004, ‘VRML virtual worlds – an alternative to the desktop metaphor
for GUIs’, in K. Beucke et al (eds), 10th International Conference on
Computing in Civil and Building Engineering, Weimar, June 2004,
Proceedings on CD-rom, 8.
Turk, Z., Wasserfuhr, R., Katranuschkov, P., Amor, R., Hannus, M. and Scherer,
R.J., 1997, ‘Conceptual modelling of a concurrent engineering
environment’, in C.J. Anumba and N.F.O. Evbuomwan (eds), Concurrent
Engineering in Construction, London, Institution of Structural Engineers,
195–205.
Ugwu, O.O., Anumba, C.J., Newnham, L. and Thorpe, A., 1999, ‘Agent-based
collaborative design of constructed facilities’, in A. Borkowski (ed.),
Proceedings of the 6th EG-SEA-AI Workshop, Artificial Intelligence in
Structural Engineering, Wierzba, Poland, September 1999, Warsaw,
Wydawnicta naukowo techniczne, 199–208.
Wang, L., Shen, W., Xie, H., Neelamkavil, J. and Pardasani, A., 2002,
‘Collaborative conceptual design-state of the art and future trends’, in
Journal of Computer-aided Design, 34(13), 981–996.
Yang, H.M., 2001, ‘A Web-based collaborative decision-making system for
construction project teams using fuzzy logic’, PhD thesis, Loughborough
University.
Yao, Z. and Johnson, A.L., 1997, ‘On estimating the feasible solution space of
design’, in Computer-Aided Design, 29(9), 649–655.