NVEL DE MATURIDADE DO PROCESSO DE PROJETO: AS

QUATRO INTERFACES
MANZIONE, Leonardo; MELHADO, Silvio;
(1) POLI-USP, 11-2306-8565, e-mail: leonardo@coordenar.com.br (2) POLI-USP, e-mail:
Silvio.melhado@usp.br

RESUMO
O conceito da AIA (American Institute of Architects) de nvel de desenvolvimento de um projeto, descreve
o grau de completude para determinado elemento do modelo BIM em relao a um referencial previamente
definido. Essa proposio contempla os nveis de desenvolvimento dos elementos construtivos organizados
a partir da classificao Uniformat. Embora esse critrio especifique adequadamente os diferentes setores
ou sistemas de um edifcio, ele pode conduzir a vises parciais e compartimentadas do projeto, se entendido
isoladamente. O conceito original de nvel de desenvolvimento, denominado LOD na bibliografia,
contempla dois significados ora tratado como nvel de detalhe, ora tratado como nvel de
desenvolvimento, demonstrando contradies.
O objetivo do artigo propor um novo conceito para resolver essas contradies e ampliar o significado
para o de Nvel de Maturidade, como a medida do desenvolvimento de um projeto em relao s suas metas
previamente definidas. Esse referencial de metas composto pelos objetivos do negcio traduzidos em
requisitos programticos; pelos usos preestabelecidos do BIM traduzidos em conjuntos especficos de
propriedades geomtricas e no geomtricas; pela compatibilidade geomtrica; e pelo sistema de
planejamento e controle.
Palavras-chave: Processo de Projeto, Nvel de detalhe, Nvel de desenvolvimento, Maturidade

ABSTRACT
AIAs level of development concept describes the completeness degree for a given element of the BIM model
towards a previously defined reference. This proposition contemplates the levels of development of
constructive elements organized from the Uniformat classification. Although this criterion properly
specifies different sectors or systems of a building, it may lead to incomplete, compartmentalized views on
the design, if understood separately. The original concept of level of development, called LOD in the
literature, addresses two meanings it is treated as level of detail, as well as level of development, which
shows contradictions.
The papers objective is to propose a new concept to resolve these contradictions and expand the meaning
to the concept of Maturity Level, as a measure of the developing a design against to its previously set
targets. This goal reference comprises business objectives translated into programmatic requirements;
BIM pre-defined uses translated into specific sets of geometric and non-geometric properties; by
geometric compatibility; and by the planning and control system.
Keywords: Design Process, Level of Detail, Level of Development, Maturity

INTRODUO

O surgimento dos sistemas em BIM mostra que um novo paradigma para o trabalho
colaborativo precisa ser criado. Porm, em um estgio inicial, observado ainda no Brasil,

percebe-se que as equipes de projeto continuam a trabalhar de maneira individual e com

trocas de informao somente nos momentos de eventos-chave de compatibilizao. Na
prtica continua-se trabalhando de forma convencional, sem o aproveitamento dos
benefcios possveis da tecnologia BIM.
Eventuais justificativas para essa situao poderiam ser baseadas em argumentos dos
profissionais que talvez argumentem que sejam obrigados a adotar mtodos de trabalho
particulares em virtude das limitaes dos processos implantados em seus escritrios,
concebidos para funcionar sem o apoio efetivo da TIC e do Processo Colaborativo,
justificando com isso a manuteno de velhos hbitos no colaborativos, fortemente
arraigados na cultura da AEC.
Consequentemente, a colaborao imaginada para o processo em BIM ser muito difcil
de ser conseguida com a utilizao das metodologias de trabalho atualmente utilizadas.
Dessa maneira, muitas empresas falharo em alcanar a eficincia e os benefcios que o
BIM pode trazer para o trabalho colaborativo entre elas e seus clientes.
Baseado nessas condies foi desenvolvida a Tese de Doutorado do primeiro autor, que
se baseou no desenvolvimento de uma Estrutura Conceitual para a Gesto do Processo de
Projeto Colaborativo com o uso do BIM. O objetivo desse artigo apresentar alguns dos
novos conceitos que foram desenvolvidos nessa Tese.
Objetivamente o processo de projeto em BIM pode ter uma amplitude muito maior que o
projeto convencional sendo possvel e necessrio que sejam desenvolvidos Indicadores
Chave de Desempenho que possibilitem a medio de aspectos relacionados a eficincia
ou a eficcia do processo de projeto.
Dentro do raciocnio de serem criados os indicadores (ICD), a Tese propem que seja
ampliado o conceito atualmente vigente no mundo BIM de nvel de detalhe para
outro, mais amplo, que entende, qualifica e quantifica o processo de projeto pelo seu grau
de maturidade.
O artigo definir os componentes do grau de maturidade e focalizar com maior ateno
ao clculo de dois deles: o nvel de desenvolvimento (ND) e a densidade de interferncias
(DI). Os outros dois domnios, descritos no artigo, sero abordados conceitualmente.
2

NVEL DE MATURIDADE

Nvel de maturidade a medida do desenvolvimento de um projeto em relao s suas

metas previamente definidas. Esse referencial de metas composto pelos objetivos do
negcio traduzidos em requisitos programticos; pelos usos preestabelecidos do BIM
traduzidos em conjuntos especficos de propriedades geomtricas e no geomtricas; pela
compatibilidade geomtrica; e pelo sistema de planejamento e controle (Figura 1).

Figura 1: Nvel de maturidade

Fonte: Autor

Sero detalhados a seguir os quatros referenciais que iro determinar o nvel de

maturidade: usos do BIM e propriedades, compatibilidade geomtrica, objetivos do
empreendimento e planejamento e controle.
2.1

Objetivos do empreendimento e requisitos programticos

A elaborao do programa de necessidades o ponto de partida para o desenvolvimento

do empreendimento e de seus projetos.
Em nosso entendimento, as questes-chave mencionadas acima necessitam ser
consideradas em toda implantao de projetos em BIM, devendo ser entendidas como
recomendaes e alertas. Trata-se de uma fase conceitual, pois, ao se definir o programa,
dispe-se de poucos elementos concretos, alm de o projeto ainda no ter sido iniciado
na prtica.
Pouca ateno dada ao problema
Pouca ateno tem sido dada pelas entidades profissionais elaborao do programa. A
Associao de Gestores e Coordenadores de Projetos (2003) segundo seu Manual de
Escopo, considera a elaborao do programa como um servio opcional, observando que
esta atividade mais comumente aplicada em empreendimentos mais complexos, ou que
incorporem atividades variadas [...].
A pouca ateno concedida ao tema pode justificar em parte os problemas encontrados
na prtica, como a desorganizao do fluxo de informaes e a falta de dados para o
planejamento do processo de projeto, problemas estes que resultam em retrabalhos,
atrasos e aumentos nos custos dos projetos.
O que se denomina programa do edifcio constitui, na prtica, um conjunto de
necessidades e requisitos do cliente, envolvendo vrios aspectos: espaciais, funcionais,
estticos, desempenho, uso de sistemas construtivos e novas tecnologias, especificaes
de materiais, etc. Por outro lado, em paralelo s definies do programa h que se lidar
com restries de vrias espcies que limitaro o universo das solues e atuaro como
filtros. So restries de vrias naturezas, como: forma e geologia do terreno,

regulamentaes das diferentes instncias pblicas, normas, disponibilidade de verbas,

entre outras.
A complexidade, a natureza dinmica e a relao com o todo do projeto
Normalmente, o registro da elaborao do programa feito por meio de documentos
textuais e planilhas, sendo completado por atas de reunies que ocorrero ao longo do
processo. Porm, medida que o projeto evolui so feitas mudanas incrementais que
alteraro o programa inicial, levando a solues que no atendem necessariamente ao
programa original.
O cliente relata seus requisitos, relacionando-os, de modo geral, com o programa do
espao do edifcio. Contudo, esses requisitos se estendem indiretamente para os
elementos delimitadores do espao, como paredes, portas, janelas, lajes e outros. Os
sistemas tcnicos, como ar condicionado, instalaes eltricas e hidrulicas, tambm so
afetados indiretamente, pois seu detalhamento ocorre em fases avanadas, sendo feito por
profissionais que no participaram dos estgios iniciais. Esses requisitos indiretos,
decorrentes dos requisitos principais definidos pelo cliente, nem sempre so percebidos
de imediato e podem surgir como problemas em momentos avanados do projeto,
ocasionando retrocessos; ou, em muitos casos, so esquecidos, resultando em solues
incompletas de projeto.
Outro fator importante a natureza interativa do processo de projeto, pois a evoluo das
solues pode afetar e estimular o cliente a mudar os seus requisitos, aspecto que,
combinado com as interaes tcnicas entre os projetistas, pode ocasionar mudanas,
resultando em solues descoladas dos objetivos iniciais (Figura 2).
Figura 2: Mudanas e descolamento do objetivo inicial

Fonte: Adaptado de Kiviniemi (2005)

Observa-se na prtica que, embora conceitualmente o programa de necessidades pertena

fase de planejamento, a mudana dos requisitos do programa ocorre continuamente em
ciclos de interaes, justificando o monitoramento e o ajuste contnuo das solues e do
prprio programa. Deve-se buscar um ponto de convergncia entre as solues propostas
e o atendimento dos requisitos, quer ajustando a soluo de projeto (Figura 2) quer
ajustando os requisitos (Figura 3).

Figura 3: Ajuste dos requisitos

Fonte: Adaptado de Kiviniemi (2005)

2.2

Nvel de desenvolvimento propriedades geomtricas e no geomtricas

Apesar das definies de fases de desenvolvimento de um projeto no processo

convencional serem conhecidas na prtica pelos profissionais, existem problemas que
limitam a verificao do atendimento dos requisitos de cada uma dessas fases.
Uma razo que tanto nas normas vigentes, ABNT NBR 13531 (1995), quanto nos
manuais de escopo de projeto, Associao de Gestores e Coordenadores de Projetos
(2003), a delimitao das fases no especifica critrios objetivos e sim conceitos. A outra
razo se deve ao fato do processo de verificao ser manual e por esse motivo impreciso,
dando margem para verificaes incompletas e para a subjetividade.
Problemas semelhantes ocorrem tambm no universo do BIM: o conceito adotado pela
American Institute of Architects (2007) para classificar os nveis de desenvolvimento
enfatiza a evoluo geomtrica do modelo e d importncia relativamente menor para as
propriedades no geomtricas.
Essa conceituao pode reforar nos usurios a ideia que o BIM apenas um modelo
geomtrico o que reafirma o ponto de vista de Owen et al. (2010), que observam que a
tendncia corrente de muitos utilizar o BIM mais como uma tecnologia, o que
denominam simples BIM (sBim), e menos como um processo integrado ou inteligente
(iBIM) [...].
A Figura 4 ilustra a ideia adotada na estrutura conceitual: os nveis de desenvolvimento
variando de 100 at 500 sendo associados aos diferentes tipos de propriedades que podem
ser criados pelo usurio em funo do tipo de uso pretendido para o BIM e aplicados aos
objetos do edifcio que sero categorizados conforme o sistema Uniformat.

Figura 42: Nvel de desenvolvimento e conjuntos de propriedades

Fonte: Autor

2.3

Metodologia de clculo para o ND

O clculo efetuado atravs de uma planilha Excel e o software Solibri podendo ser
utilizados outros que faam as mesmas operaes.
Os passos para o clculo sero fornecidos a seguir a partir de um exemplo.
Passo 1: contar o nmero de objetos do modelo BIM, com o Solibri, classificando-os
conforme o critrio da Uniformat nesse passo importante verificar se o modelo possui
objetos no classificados e se for o caso fazer as correes, pois uma modelagem sem
levar em conta essa questo pode induzir a erros.
Passo 2: gerar no Solibri um relatrio analtico que classifique os objetos em funo do
tipo da propriedade que est sendo pesquisada. Com esse relatrio teremos a condio de
identificar os objetos que tm e os que no tm valores atribudos para a propriedade
Passo 3: lanar os dados na planilha Excel que efetuar todos os clculos (Figura 5).
A Figura 5 apresentada com as frmulas utilizadas possibilitando assim que possa ser
criada e aproveitada por outros pesquisadores. Nela se destacam campos numerados que
sero identificados e explicados a seguir.

Figura 5: Planilha de clculo do ND

Fonte: Autor

Campo 1: preencher com o nmero total de objetos da classe Uniformat que est sendo
analisada. No exemplo da figura foi utilizada a planilha para a classe C1010 paredes.
Campo 2: preencher com os dados obtidos no relatrio analtico do Solibri conforme a
Figura 67. Nesse campo so colocados todos os objetos que possuem valores atribudos
para o conjunto de propriedade em estudo independentemente se esses valores esto ou
no validados de acordo com o programa de necessidades.
Campo 3: analisar os resultados obtidos no relatrio do Solibri da Figura 67 e verificar
se eles esto de acordo com o programa de necessidades. Na ausncia do programa de
necessidades ou se este se encontrar desatualizado, os dados podem ser inseridos somente
aps passarem por um processo de anlise crtica e validao feita pela coordenao do
projeto, pelo proprietrio e pelo profissional responsvel pelo projeto especfico.
Campo 4: esse campo calculado automaticamente. Ele conta o nmero de tipos de
propriedades que esto sendo consideradas no conjunto de propriedades escolhida. O
nmero de propriedades para o conjunto escolhido servir como o peso a ser atribudo
para o item.
Campo 5: esse campo calculado automaticamente. Ele calcula a mdia aritmtica entre
o nmero de objetos dividido pelo nmero de tipos de propriedade que foram calculados
no campo 4. A mdia obtida dos objetos relativos ao campo 2 calculada somente para
servir de referencial. O valor que ser adotado o que foi descrito no campo 3.

Campo 6: esse campo calcula automaticamente a nota obtida no item, demonstrando o

quanto do item foi atendido. Esse dado obtido atravs da diviso do nmero mdio
de propriedades que atendem aos requisitos calculado no campo 5 pelo nmero total
de objetos.
Campo 7: esse campo calculado automaticamente. Nele calculada a somatria dos
pesos que so calculados no campo 4.
Campo 8: esse campo calculado automaticamente. Nesse campo calculada a mdia
ponderada entre as notas dos itens multiplicada por seus pesos e dividida pela somatria
dos pesos.
Campo 9: esse campo calcula automaticamente o valor do ND atravs da mdia
ponderada calculada no campo 8, transformada em percentual e multiplicada pelo valor
do ND terico da fase (no exemplo igual a 100, porm, esse valor pode ser 200, 300, 400
ou 500, dependendo da fase em estudo).
LIMITAES
O clculo do ND tem algumas limitaes e ressalvas comentadas a seguir.
Propriedades pr-existentes na biblioteca de objetos do projetista (default).
Normalmente, a biblioteca de objetos dos projetistas encontra-se desenvolvida e o seu
reaproveitamento deve ser feito de forma criteriosa, uma vez que poderemos ter conjuntos
de propriedades no especificados para existir; propriedades com valores atribudos a
priori e objetos com detalhes geomtricos incorretos ou desnecessrios so fatores que
podem levar a medidas enganosas do ND. Portanto se recomenda que inicialmente ao
processo de projeto todos os integrantes revejam suas bibliotecas e faam as adequaes
necessrias.
Inexistncia, incompletude ou desatualizao do programa de necessidades.
No frequente, na prtica de trabalho, o cliente preencher formalmente os requisitos do
programa, pois comum que isso ocorra de maneira informal e em diversas fases do
processo. Por outro lado necessrio diferenciar os requisitos do cliente por natureza
requisitos de desempenho daqueles eminentemente tcnicos, prprios das
especialidades de projeto envolvidas. Portanto, o preenchimento prvio de uma tabela
com todos os requisitos especificados parece ser impraticvel, recomendando-se que a
avaliao dos resultados obtidos se baseie tambm em anlises crticas qualitativas e no
somente numricas.
Retrabalho
O indicador ND no tem como objetivo medir o retrabalho, porm ele existe na prtica e
a sua ocorrncia pode alterar os valores do ND, portanto o retrabalho influencia o nvel
de desenvolvimento do projeto.
O retrabalho pode ocorrer a partir de uma combinao de diversos fatores: os objetos
podem ser eliminados ou alterados nas propriedades geomtricas e no geomtricas,
podem ser criados novos objetos e novos requisitos de programa podem ser criados ou
alternados. Uma mudana que combine esses fatores no deve ser considerada retrabalho
sem que suas causas sejam analisadas. As mudanas ocorrem tanto para a melhoria do
processo quanto para a sua piora. Porm como isso pode ser avaliado? Simplesmente
contabilizar o nmero e o tipo de mudanas no leva a uma concluso, mas apenas a
evidncias de mudanas.

Entendemos que o retrabalho somente possa ser avaliado atravs da interpretao do

coordenador de projetos em conjunto com sua equipe, analisando e avaliando os impactos
e a natureza das mudanas.
Preciso da geometria
Os termos geometria aproximada e geometria precisa, embora usuais nas definies
correntes do LOD, so pouco precisos na avaliao do desenvolvimento do modelo. Caso
o objetivo do modelo seja o da pr-fabricao de estruturas de concreto, metlicas ou
mesmo de componentes como kits hidrulicos ou banheiros, a preciso requerida para
os processos industriais da ordem de milmetros. A preciso requerida para a construo
convencional da ordem de centmetros para a maioria dos casos. Outro ponto a ser
considerado a confirmao de medidas, pois em um ND 200 os objetos podem ser
inseridos apenas para a sua macrodefinio como solues ou partidos; porm, em um
estgio superior de desenvolvimento ser necessria a confirmao de medidas, pois os
objetos sero compatibilizados e detalhados. Em todos os casos, a preciso deve ser
entendida dentro do contexto onde est inserida e sua avaliao deve ser feita com essas
consideraes em mente.
2.4

Compatibilidade geomtrica

A compatibilidade geomtrica um requisito de qualidade do processo de modelagem.

Conforme referenciado na reviso bibliogrfica, diversos tipos de problemas decorrentes
de falta de compatibilidade podero ocorrer durante o processo de modelagem. Mas esses
problemas podem ser detectados com softwares especficos, como o Solibri ou o
Navisworks. O processo de verificao da compatibilidade geomtrica parametrizvel,
podendo ser escolhidos os objetos a serem comparados e tambm predefinir o valor das
tolerncias.
DENSIDADE DE INTERFERNCIAS
Definimos DI (densidade de interferncias) como a razo entre o nmero de interferncias
verificadas atravs de softwares de anlises de modelos BIM, categorizadas segundo
critrios de criticidade e o volume da envoltria do edifcio.
CLCULO
Variveis
ni: nmero de interferncias, valor calculado pelo software sendo funo do tipo de
parametrizao adotada;
ve: volume total do edifcio, valor definido pelo clculo do volume da superfcie
envoltria do edifcio.
ve /1.000 m3: volume anteriormente calculado dividido por 1.000 m3.
FRMULA
=

Unidade de medida: nmero de interferncias / 1.000 m3

10

FOCO
Objetivo: avaliar a qualidade do processo de modelagem das disciplinas e da
coordenao do projeto como um todo, visando garantir a qualidade do processo de
projeto.
Tipo de medida: quantitativa.
Estgio de maior impacto: projetos executivos.
PERFIL DOS DADOS
Perodo de coleta dos dados: a cada atualizao feita no modelo BIM.
Frequncia de emisso de relatrios: devem ser emitidos relatrios a cada atualizao
do modelo e antes das reunies de coordenao de projetos.
ALVOS
Tendncia: ao analisar a frmula, verificamos que para um dado volume a DI varia em
funo direta do ni, ou seja, a DI aumenta na razo direta do nmero das interferncias;
portanto, sua tendncia boa quando seu valor diminui, tendendo a zero ao longo do
tempo.
PARAMETRIZAO
Uma caracterstica importante no clculo da DI que as interferncias podem ser
parametrizadas, sendo a DI, portanto, funo do grau de liberdade arbitrado no projeto,
no se tratando, pois, de um ICD absoluto, mas relativo ao ambiente do projeto. So
relacionadas a seguir as variveis que podem ser parametrizadas.
Escolha do tipo de componentes
Essa opo permite selecionar quais tipos de objetos sero verificados, possibilitando
filtrar dentre todos os objetos do edifcio aqueles que forem essenciais para garantir a
qualidade do modelo, como, por exemplo: paredes, componentes da estrutura, fachada.
Escolha do tipo de disciplinas
Alm do filtro de componentes, podem ser tambm escolhidas as disciplinas que sero
interfaceadas no teste, podendo ser configuradas diversas situaes: arquitetura x
estrutura, estrutura x instalaes, etc.
Escolha do tipo de interferncias
O tipo de interferncia a ser verificado pode ser escolhido a partir de trs possibilidades:

Objetos duplicados

Essa categoria lista todas as instncias de interseces onde os componentes foram

duplicados, o que significa a existncia de um ou mais componentes com forma e
localizao idnticas. Esse tipo de problema de grau crtico, uma vez que representa
redundncias no modelo

Objetos dentro de outros

Esta categoria lista todas as instncias de interseces nas quais os componentes estejam
embutidos dentro de outros

Objetos sobrepostos

11

Esta categoria lista todas as instncias de interseces nas quais os componentes estejam
sobrepostos a outros, normalmente ocorrem cruzamentos entre vigas e paredes, objetos
da estrutura e objetos de instalaes, etc.
2.5

Planejamento e controle do processo de projeto

O processo de planejamento e controle formulado para a estrutura conceitual aborda tanto

o processo de gesto quanto o processo de modelagem.
Portanto a principal questo a ser resolvida pela estrutura conceitual como relacionar
ambos os processos. A proposio trabalhar com trs nveis de planejamento
hierarquicamente organizados: estratgico, ttico e operacional (Figura 6) e com uma
estrutura integrada, composta pela estrutura analtica do projeto (EAP) e a estrutura
analtica do modelo (EAM).
Figura 6: Relacionamento entre a gesto do projeto e a gesto do modelo

Fonte: Autor

3. Concluses
As concluses deste trabalho enfatizam que, muito mais que solues pragmticas e de
curto prazo, torna-se necessria uma nova estrutura conceitual para guiar-nos no caminho
da evoluo do processo de projeto e de sua gesto, pois no se pode esperar que solues
trazidas diretamente por softwares viessem a nos mostrar esse caminho.
REFERNCIAS
AIA, AMERICAN INSTITUTE OF ARCHITECTS. Integrated Project Delivery: A
Guide. 2007, 62 p.
ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. ABNT-NBR-13531:
Elaborao de projetos de edificaes - Atividades tcnicas. 1995. 22 p.
ASSOCIAO DE GESTORES E COORDENADORES DE PROJETOS. Manual de
escopo de servios de Arquitetura e Urbanismo. 132 p.
KIVINIEMI, A. Requirements management interface to building product models.
2005. 343 p. Tese (Doutorado) - Stanford University, 2005.
OWEN, R., et al. Challenges for Integrated Design and Delivery Solutions. Architectural
Engineering and Design Management, v.6, p.232-240, 2010.