integrated building design for production management ... fileintegrated building design for...

INTEGRATED BUILDING DESIGN FOR PRODUCTION MANAGEMENT SYSTEM

Research and Development and Innovation

RITA CRISTINA FERREIRA

1. INTRODUCTION

This work presents the results of a research, development and innovation (R&D&I)

project that aimed at creating a Web Information System to support the development

of integrated building design for production. This project has been coordinated by the

director of a small building design firm, DWG Arquitetura e Sistemas, and has been

granted by the largest research council in Brazil (FAPESP - The State of São Paulo

Research Foundation), under a special program for technological innovation in small

businesses.

DWG was founded in March of 1994 and it was the first independent design office in

Brazil to specialise in masonry design for production using 3D models. The challenge

was to break with the traditional methods of producing drawings by linking product

information with the especification of production process at early stages of design

development. It was evident that the development of masonry production system

design plays a key role due to its myriad interfaces with other subsystems.

Additionally, the elaboration of masonry design required intense coordination across

the detail design phase and design coordination was incorporated within the scope of

the R&D&I project. Initial results of integrating masonry design and design

Integrated Building Design for Production Management System

2

coordination demonstrated increased efficiency in identifying and solving problems

related to interoperability, modularisation and technology.

Despite considerable gains from this integrated process were obtained, problems

related to the remote collaboration and coordination of the different design disciplines

emmerged. For example, a problem identified was concerned to communication

between independent firms responsible for each discipline causing lack of

information for decision making.. These problems were identified at earlier stages of

the R&D&I project causing the re-scope of the project. Addiotinaly, the development

of the design for production of a real construction project throughout the specification

and development of the system prototype led to the identification of unforseen

requirements (e.g. “following up construction”) that were incorporated within the final

scope.

The final system (namely Sistema π) was developed aiming at supporting the

management of design for production, adding automation processes to perform

remote (via web) collaborative work between multidisciplinary teams using 3D CAD.

The development process had four requirements validation processes and consisted

of consulting with different stakeholders groups.

The concept of the Integrated Building Design for Production Management System

(IBDPMS) was developed involving thirteen major construction companies. The

conceptualisation and development phases had a total duration of four years. The

development of the system took the advantage of a desacelaration of the brazilian

construction market and the lack of construction projects to get the attention of


3

potential clients. At the same time, the constant emergence of new technologies for

design, provided stimulus to the development of the management system. Currently,

the results include a complete software specification and 40% of the functional

prototype.

2. RESEARCH AND DEVELOPMENT (R&D)

The research and development of the IBDPMS had three stages, consisting of:

idealisation, planning and conceptualisation (research) and development.

The first stage refered to the idealisation of the product and its presentation to

FAPESP (the research council). The idealisation evolved over years simultaneously

with the DWG business strategy focused on exploring this new market opportunity.

At a second stage, the conceptualisation consisted of identifying throughout

construction the emergence of design-related problems and propose ideas to

mitigate those problems. This conceptualisation was formalised in a business and

research plan that was focused on identifying the main market demands and

research and commercial opportunities for the Building Integrated Design for

Production.

The third stage was concentrated on the development and implementation of the

software prototype. This stage follwed guidance from the Rational Unified Process

(RUP) model for engineering software process managing, as well Unified Modeling

Language 2.1 (UML 2.1) (Booch, Rumbaugh and Jacobson, 2005) and Business


4

Process Modeling Notation (BPMN) (White, 2004; Owen & Raj, 2003). The software

documentation was developed using Enterprise Architect® 7.0.

The RUP model is divided into 4 phases (Rational, 1998): inception, elaboration,

construction and transition. Troughout these phases, the process and activities are

oganised upon 8 disciplines: business modelling, requirements, analysis and design,

implementation test, deployment, configuration and change management, project

management and environment. In addition to phases and disciplines (two-

dimensional processes), RUP model considers time as a third dimension that reflects

the dynamic organisation of the process along time, called iteractions. Due to the

complexity of the RUP model its implmentation was partial and in conjunction with the

software agile development approach (Wikimedia, 2008; Rational, 1998).

In addition to these approaches for software engineering, investigations were

conducted about new information models for construction, such as Building

Information Modeling (BIM) (Autodesk, 2005; Howard & Björk, 2007). The

investigations were focused on identifying trends in construction related to software

development. The investigation led to the realisation of a series of workshops with IT

and constructions experts (e.g. the AIA group, DWG clients). These workshops

resulted in the formation of the BIM research group at the University of São Paulo.

Furthermore, the research and development was carried out in a concurrent

engineerging (CE) fashion (Prasad, 1996; Laufer, 1997).

In regards to the IBDPMS, the second stage included the inception phase and the

elaboration and construction phases of RUP model. To increase the iteractions,

stakeholders were involved throughout four requirements validations. The


5

stakeholders involved were: a customer (investor and constructor contractor);

Architectural, Engineering and Construction (AEC) professionals; IT professionals as

independent consultants and suppliers - namely, from software development firms;

Independent AEC consultants; and academic researchers. The R&D team was also

supported by external consultants/advisors for information technology, civil law,

construction production, construction management, knowledge management,

construction safety and health management in construction, human resourch

management and economy.

The first validation occurred in a workshop day with customer’s representatives, the

consultants, researchers and other invited professionals. This workshop included an

extensive discussion about the Information System and an application of a JAD (Joint

Application Development) session. Thourghout the workshop, the scope of the

management system was clarified and the IT team began to align it to the business

modeling. Also the initial requirement analysis was performed.

The other three validations considered the participation of different stakeholders’

representatives and they happened as requirements and solution were getting

mature. Surveys with AEC and IT professionals and academic researchers were

used as a complementary method for requirements capture. The outputs of the

inception phase included the final software specifications, the definition of a clear

technological and business strategy (including a risk analysis), and a development

programme considering the constraints related to to the development of the software

in a short-term basis (as per the business strategy).


6

3. THE MANAGEMENT SYSTEM - SISTEMA pppp

The proposed management system, namely “Sistema p”, was designed to manage

distributed design for production knowledge, involving product designers (architects

and engineers responsible for product conception), contractors and sub-constractors

and specialist designers for production that are part of the DWG Arquitetura e

Systemas team. Figure 3.1 shows a diagram of the Sistema p and the different

stakeholders (actors).

Figure 3.1 – View of Sistema PI

This system was conceptualised to manage those decisions that can be seen

through the utilisation of 3D models, such as how the scaffolding would be

strategically positioned, considering the walls and the structure, for external


7

rendering. The system has functionalities to capture the communication between

designers, contractors and constructors.

It was critical to this system to design an attractive interface for stimulating actors

participation and increasing the management system effectiveness. During the

system development, part of the research was dedicated to investigate web systems

usability. In this respect, technologies such as Silverlight® from Microsoft© were

tested. Testing such technologies included their application with stakeholders and

potential clients and users.

Figure 3.2 shows an example of the time management functionality. The schedule is

obtained from the interactive process model. A set of different colours and symbology

were tryied aiming to improve the system interface. The green circles indicate

finished activities; the grey circles indicate activitivies that have not been done yet,

and the major circle in yellow and red indicate the activity currently been undertaken.

Below the circles, the date for completion and a short description of the activity been

undertaken are shown. At the upper left corner, the name of the responsible for

completing each activity is highlighted.


8

Figure 3.2 – An example of time management functionality using Silverlight®.

4. R&D RESULTS

The second phase of the R&D program was concluded in August 2008. The main

output of this phase was the software prototype. Additional outputs of this phase

include a pilot integrated building design for production; an information hierarquical

classification; a process map for the Integrated Building Design for Production; and

proofs of concept for the management system. These are futher described in the

following sections.


9

4.1. Pilot integrated building design for production

Simultaneously to the system development, a pilot integrated building design for

production was developed. The pilot study included masonry design, external

rendering and pumbling systems. All building systems and subsystems were

modelled using 3D CAD, that allowed the R&D team collect information for mapping

the management system.

The pilot design was contracted by the main contractor (one of the largest

construction company in the country - Construtora Cyrela SA). During the design

development, 30 professionals of design firms, contractors and constructors were

interviewed. These interviews were used to identify requirements that would increase

the added value of the system (for example, the willing to pay price for offering the

management and design service). Further details about these interviews can be

found at Ferreira (2007).

The selected pilot project is located in a high density urban area of São Paulo, Brazil

occupied high rise residential buildings. The pilot project consisted of a residential

building, with 32 floors above ground level and two basement floors. The building has

54 standard apartments (Figure 4.1), 2 duplex apartments and approximately 17.500

m2 of constructed area.


10

Figure 4.1 – Standard apartment.

Figure 4.2 represents part of 3D model with masonry, struture and pumpling kits.

Figure 4.3 and Figure 4.4 show details of a pumbling kits set and part of

documentation of pumbling kit for assembly, including items identification according

to industry supplier. Finally, Figure 4.5 represents a view of the structure, masonry

and scaffolding for external rendering in a single 3D model.


11

Figure 4.2 – 3D model detail shows masonry, part of structure and pumbling kits.

Figure 4.3 – Detail of a pumbling kits set for assembly.


12

Figure 4.4 – Documentation of pumbling kit for assembly, including items identification

according to industry supplier.


13

Figure 4.5 – A view of structure, masonry and scaffolding for external rendering execution.

4.2. Information hierarchical classification

Throughout the R&D a hierarquical classification to identify the level of detailing of

the building was proposed. This classification was tested in the integrated building

design for masonry production with 3D CAD. This classification and practical

examples of its implementation was tested through a workshp with a steering group

formed by academics and practitioners.


14

Figure 4.6 shows the hierarquical classification according to the main knowledge

areas (i.e. space organization, stability and utilities), followed by disciplines, systems,

subsystems, components and elements. This classification provided to R&D team a

clear vision about the level of detailing for production.

Figure 4.6 – Building information hierarquical classification.

In this hierarchical framework, three knowledge areas were considered: spacial

organisation, stability and utility. These knowledge areas supports the organisation of

the different levels of detail and divides design according to product design and

desing for production.

This hierarquical model can be compared to that used in Systems Engineering

described by Laudeur, Bocquet e Auzet (2003), resulting from the Simon concepts


15

(1981 apud Lauder; Bocquet; Auzet, 2003). The use of this taxonomy allowed to

model with precision and flexibility the building subsystems and its interfaces.

The management system uses this hierarquical classification for many functions,

including those related to communication, decision making, import/export from/to 3D

CAD models etc.

4.3. Process mapping

The process mapping for each subsystem was obtained using a table containing

entry data and its outputs (Tzortzopoulos, 1999). This table was implemented into the

IBDMS and allowed to identify the interfaces between systems/subsystems and its

components/elements. The process is also divided in phases, that will be used to

control the design evolution by the management system. Table 4.1 presents an

example of the process mapping table for masonry design for production and Table

4.2 for masonry and external rendering integrated design for production.

Table 4.1 - Entry-Process-Output table for masonry design for production

PHASE DATA ENTRY PROCESS OUTPUT

Init

ial

Technological selection for masonry

Architecture studies

Structure studies

MEP studies

Horizontal and vertical masonry modulation

Compatibility analysis between architecture, structure and MEP designs

Delivery documentation

Structural dimensioning directives

Architectural dimensioning directives

MEP directives for designing

Compatibility report


16

PHASE DATA ENTRY PROCESS OUTPUT D

evelo

pm

en

t Previous phase approval

Architectural design

Structural design

MEP design

MEP 3D models (if available)

Wall 3D modelling

MEP 3D models (if not available from designer)

Interference analysis



Walls 3D models

Walls location and distribution plans

Masonry vertical distribution scheme

Walls front views

Fin

ish

Previous phase approval

Coordination analysis

Architectural design reviewed

Structural design reviewed

MEP design reviewed

MEP 3D models reviewed

Critical analysis

Masonry production design revision

Delivery documentation closing

Walls 3D models reviewed

MEP location plans on structure



Walls front views

Quantity report

Table 4.2 - Entry-Process-Output table for masonry and cladding integrated design for

production.


17

PHASE DATA ENTRT PROCESS OUTPUT

Init

ial

Technological selection for masonry and external rendering

Architecture studies

Structure studies

MEP studies

Horizontal and vertical masonry modulation

Compatibility analysis between architecture, structure and MEP designs

Technological analysis for integrating masonry and external rendering



Structural dimensioning directives

MEP directives for designing

Architectural dimensioning directives

Develo

pm

en

t


Architectural design

Structural design

MEP design

MEP 3D models (if available)

Wall 3D modelling

External rendering 3D modelling

MEP 3D models (if not available from designer)

Interference analysis



Walls 3D models

External rendering 3D models



Walls front views

External rendering execution plans

Fin

ish


Coordination analysis

Architectural design reviewed

Structural design reviewed

MEP design reviewed

MEP 3D models reviewed

Critical analysis

Masonry design for production revision

External rendering design for production revision

Delivery documentation closing

Walls 3D models reviewed

MEP location plans on structure


Walls location and distribution plans reviewed

Walls front views reviewed

External rendering execution plans reviewed

Quantity report


18

4.4. System requirements identification from a pilot design

The identification of requirements for the development of the integrated bulding

design for production was done by several means including a real case where the

R&D team participated throughout the design development and coordination and

followed the use of the design for production on site.

An example of requirement identified by this mean occurred when it was necessary

to make a decision about the technology for the provision of hot water whilst the

plumbing design for production was been elaborated. An earlier decision (perfectly

registred in quality documentation) was made towards the adoption of copper for the

hot water system. However the construction management team decided to change

the material and the information did not immediately reached to the design for

production team.

This event had enabled R&D team to identify the functionality details for “Technology

selection”. This functionality was designed to support decisions approvals by the

contractor and or subcontractor throughout many short cycles, specificated in the

business process diagram (Figure 4.7).

When a decision is registred (what), many other data are included, as when it was

decided and who decided and if the decion maked have authority for making

decisions. The system automaticaly prevents changes to be made by non autorised

groups. To change a decision, the system will start an automatic notification for all

involved with it. A decision has a time to occur. It can not be later or earlier. So the


19

Sistema p can be configured to control the time for decisions and to notify all that

need to know about it.

The process for “Solution Search and Decision Making” is the most important and

was considered by the R&D team the core of the management system. It is possible

to see that all complementary processes (Figure 4.7) are driven by the “Solution

Search and Decision Making” process. This assumption was validated through the

real design for production. Wrong decisions have generated additional costs and/or

time for project.


20

BPMN Integrated Building Design for Production Management Syst...

So

luti

on

an

d d

ec

isio

n m

ak

ing

«L

an

e»

Ph

.4 -

Sit

e i

mp

lan

tati

on

«L

an

e»

Ph

.3 -

De

ve

lop

me

nt

«L

an

e»

Ph

.2 -

Se

tup

an

d s

pe

cif

ica

tio

n

«L

an

e»

Ph

.1 -

In

itia

lis

ati

on

«L

an

e»

«BusinessProcess»Ph1.1 Systeminitialisation

«BusinessProcess»Ph.2.1- Env ironment

setting up

«BusinessProcess»Ph.2.2 Design planning

«BusinessProcess»Ph.3.2 Documentation

«BusinessProcess»Ph.4.1 Construction

follow-up

«BusinessProcess»Ph.2.3 Technological

selection

END

«BusinessProcess»Ph.3.1 Collaborativ e

prototyping

START

«BusinessProcess»Solution search and

decision making

Are there

problems?

Are there

problems? Are there

problems?

Is it necessary to review

technological selection

and or standards?

N

Y

N

Y

N

Y

N

Y

Figure 4.7 – Business process diagram for Integrated Building Design for Production

Management System.


21

5. SOFTWARE (SYSTEM) DEVELOPMENT

The software development was based on an iteractive approach that considered a

dynamic requirements identification process. At very early stages of the

development, usability tests were conducted and the visual identity for the systems

and a prototype were developed simultaneously with systems specification.

The results were used throughout the second validation that involved AEC designers,

IT professionals and academic researchers. This procedure was repeated three

times with an IT consultant and the outputs were:

� a navigable prototype system, containg a mock up web site that expressed the

information workflow;

� an executable prototype system for some selected funcionalities;

� a second executable prototype system for a group of functionalities.

5.1. Business Process Model

Business process management is considered critical for developing sucessful new

products and services (Miers, 2007), creating a business commitement to the project.

During software development and using a Computer Aided Software Engineering

(CASE) tool, it is possible to create a model of business process.


22

The business process for the IBDPMS was modeled based on Business Process

Modeling Notation (BPMN) standard, using Enterprise Architect® 7.0. The business

was divided into 5 process groups as follow:

� Initialization – includes some processes to configure the system;

� Setup and Specification – includes “Environment settings and standards” for

design, “Design planning” and “Technology selection” for modelling and

detailing contracted systems;

� Development – includes control tools for “Collaborative prototyping” (3D

modeling) and “Documentation” for using at the construction site;

� Construction site implantation – includes processes for “Construction site

follow-up”;

� Solution and decision making – includes processes for “Solution searching and

decision making” to identified problems during design.

5.2. Actors

The development of the Integrated Building Design for Production led to the

identificaton of new “actors”. These actors were called “Integrated Design for

Production Manager”, “Integrator” and “Design Integrator”. Two other types of

actors were also identified from business model and requirements. There were

grouped into external and internal actors. External actors were “Constructor’s

Design Coordinator”, “Product Designer” and “Construction Manager”. From the


23

DWG side, the internal actors were “Integrated Design for Production Manager”,

“Integrator” and “Design Integrator”.

By using UML (Unified Modeling Language), it was possible to identify generic

relationships between the actors (Figure 5.1). In this respect, all actors were

generalised as “User”. “Technical Specialist” is the generalisation of “Constructor’s

Design Coordinator”, “Product Designer” and “Internal Specialist”. Likewise,

“Internal Specialist” is the generalisation of “Integrator” and “Design Integrator”.

The definition of each category of actors and their roles and responsibilities as

presented in the following (Figure 5.1):


24

uc Actors

EXTERNAL

Constructor's Design

CoordinatorInternal Specialist

Technical Specialist

Integrated Design for

Production Manager

Construction Manager

Integrator

Product Designer

User

Design Integrator

Figure 5.1 - Building Integrated Design for Production Management System’s actors.

The “Constructor’s Design Coordinator” and the “Product Designer” roles refer to

traditional professionals in the design team of building construction, such as the

architect, the electrical designer and structural designer. The “Integrated Design for

Production Manager” is responsible for the system’s general administration. The

“Integrator” acts as the technical coordinator for the integrated design and is

responsible for promoting integration between the product design (conceptual

design) and the design for production (construction).


25

5.3. Requirements

Requirements in the integrated building design for production system are divided into

functional and non-functional. The non-functional requirements refer to system’s

quality involving some constraints, quality attributes and goals and quality of service

requirements and non-behavioral requirements (such as usability, testability,

maintainability, extensibility and scalability).. The functional requirements are those

related to general funcionalities identified from business process and reviewed by

use cases detailing (such as technical details, data manipulation and processing and

other specific functionality). In total, 14 functional requirements were identified and

organised in five groups, as shown in Erro! Fonte de referência não encontrada..

Table 5.1 – Groups and functional requirements of Sistema p.

Group Function requirements

1. Initialization Begining integrated design

2. Setup Setting up design environment

Defining technology scope

Planning and controling design

3. Development Disposing initial information

Detailing integrated design

Searching for solution and decision making

Validating evolutional stages

Generating documentation

Getting final validation


26

4. Implantation Following up construction

Evaluating design changes

5. Mobile device access Accessing system using mobile devices

5.4. Use Cases

In parallel to the business process modelling and requirements specification, it was

identified and detailed the use cases for developing the system. The use cases were

grouped into five packages:

1. Managing Design and Standards

2. Developing design

3. Searching and communicating

4. Integrating CAD with Management System

5. Accessing system by mobile devices.

In total, 89 use cases were identified for the management system and those were

detailed throughout software development, using concurrent engineering and

software agile development approaches. One example of a use case is the markup

function implemented into AutoCAD® as a command (Figure 5.2). Figure 5.3 shows

the use cases from “Integrating CAD with Management System” package for markup

functions implementation.


27

Figure 5.2 – Example of markup command into AutoCAD®.

The above example of a markup command in AutoCAD® displays a screen for the

designer to describe the problem identified during the design process. The data is

exported afterward to the IBDPMS and disseminated to others for discussion and

decision making.


28

Figure 5.3 – Use cases from “Integrating CAD with Management System” package, for

markup functions implementation.

6. FINAL REMARKS

The integrated design for production was identified as a building construction market

demand. In Brazil, this demand has considerably increased as investments in the

construction sector are constinuously rising. The applies to the demand for more

effective and efficient production quality control.

Throughout the development of the system, it was identified that there is professional

gap to support the decisions that involves architectural design, construction

technology and the management of construction on site. The Integrated Building

Design for Production Management System was design to aid decision making


29

during designing for production. Simultaneously, it pulls key decisions from product

designs at early stages, because these are entry data to the elaboration of the design

for production.

The emergence of new design technologies, such as BIM, were considered at earlier

stages of this R&D programme and the Sistema π is been adapted/integrated with

such technologies, therefore. setting an upgrade for the system.

Finaly, additional issues emerged throughout the the development process. Firstly, it

was identifyied that the system brings transparency to the decision making process.

However, in some circumstances transparency is not desied. For instance, the fact

that the software registers all the transaction can inhibit the use of the system. Some

of the designers prefer not having the problems and mistakes registered in a data

base. Finaly, in regards to the role of the integrator: although the system

communicates with all designers, there is a need for a mediator when the solution for

a trade-off is not obvious. That means a third part is necessary to bring a more

holistic view of the design to support decision making. It is the same when it comes to

establish deadlines for the delivery of the decisions.

ACKNOWLEDGEMENTS

The author thanks to FAPESP – Fundação de Amparo à Pesquisa do Estado de São

Paulo for supporting this research through grant n. 01/13304-0 and to the design

offices and contractor, Construtora Cyrela SA, which participated on the integrated

building pilot design for production.


30

REFERENCES

Autodesk (2005). Parametric Building Modeling: BIM's Foundation. Available at:

<http://images.autodesk.com/adsk/files/Revit_BIM_Parametric_Building_Modeling_J

un05.pdf>. Accessed in 27 set.2005.

Booch, G.; Rumbaugh, J. Jacobson, I. (2005) UML: guia do usuário. Rio de Janeiro:

Elsevier.

Ferreira, R. C. (2007) Uso do CAD 3D na compatibilização espacial em projetos

de produção de vedações verticais em edificações. 161 p. Master Degree

Dissertation, Civil Engineering, Escola Politécnica, Universidade de São Paulo.

Howard, R.; Björk, B.-C. Building information modelling – Experts’ views on

standardisation and industry deployment. Advanced Engineering Informatics,

2007.

Laudeur, E.; Bocquet, J.-C.; Auzet, C. (2003) Using Systems Engineering to enhance

Concurrent Engineering environment through modelling problematic. In:

INTERNATIONAL CONFERENCE OF CONCURRENT ENTERPRISING, 9., Espoo.

Proceedings. Espoo, Finland. Available at: <http://www.lgi.ecp.fr/publidata/20-05-

2003_04:07:29/ICE2003(provisoire).pdf>. Accessed in Feb. 08, 2007.

Laufer, A. (1997) Simultaneos Management. USA: AMACOM. 313 p.


31

Miers, D. (2007). BPM – Driving Business Performance. Available at:

<http://www.bpmfocus.org/membership/document.aspx>. Accessed in Oct. 21, 2008.

Owen, M.; Raj, J. (2003) BPMN and Business Process Management: Introduction

to the New Business Process Modeling Standard. Popkin Software, 2003. Available

at: <http://www.bpmn.org/>. Accessed in 10 ago. 2007.

Prasad, B. (1996) Concurrent Engineering Fundamentals: integrated product and

process organisation. New Jersey: Prentice Hall.

Rational (1998). Rational Unified Process: Best Practices for Software Development

Teams. In <http://www.ibm.com/developerworks/rational/library/content/03July/

1000/1251/1251_bestpractices_TP026B.pdf >. Rational Software, USA. 21p.

Tzortzopoulos, P. (1999) Contribuições para o desenvolvimento de um modelo do

processo de projeto de edificações em empresas construtoras incorporadoras de

pequeno porte. 163p. Master Degree Dissertation, Civil Engineering, Universidade do

Rio Grande do Sul, Porto Alegre.

White, S. (2004) Introduction to BPMN. IBM Corporation. Available at:

<http://www.bpmn.org/>. Accessed in Aug. 10, 2007.

Wikimedia (2008) Agile software development. Available at:

<http://en.wikipedia.org/wiki/Agile_ software_ development>. Accessed in 13 ago.

2008.


32

TRADEMARKS

Enterprise Architect® is trademark of Sparx Systems. AutoCAD® is trademark of

Autodesk, Inc. Silverlight is trademark of Microsoft Corporation.

integrated building design for production management ... fileintegrated building design for...

Documents