1

METODOLOGIA DE PROJETO
DE PRODUTO
1. Introduo
O projeto de engenharia entendido de forma muito semelhante pelos autores que estudam
metodologia de projeto. Segundo Back (1983), o projeto de engenharia uma atividade orientada para o
atendimento das necessidades humanas, principalmente aquelas que podem ser satisfeitas por fatores
tecnolgicos de nossa cultura. A abordagem sistemtica da atividade de projeto, comum aos autores
contemporneos, pode ser percebida na prpria definio de projeto apresentada por Roozenburg & Eekels
(1995), que entendem o projeto de um produto como um processo mental orientado, pelo qual problemas so
analisados, objetivos so definidos e ajustados, propostas de soluo so desenvolvidas e a qualidade dessas
solues so medidas.
A abordagem sistemtica do projeto de produtos de engenharia amplamente empregada nas
empresas que encontram-se inseridas com sucesso no competitivo mercado globalizado. Quando trata-se,
porm, de indstria de mquinas agrcolas, no obstante a relevncia da atividade agrcola e desse setor
industrial na economia do pas, observa-se que o projeto de produtos no merece a ateno necessria. Um
levantamento citado por Romano et al. (2001) sobre as indstrias de mquinas agrcolas brasileiras revelou que
apenas 29% das empresas entrevistadas possui um processo formal de desenvolvimento do produto.
Com a abordagem sistemtica, o produto projetado numa evoluo de modelos (Ferreira, 1997).
Assim, um modelo mais detalhado e concreto substitui outro mais simples e abstrato, at a viabilizao fsica do
objeto projetado. Vrios modelos de processo de projeto foram criados a fim de aumentar a qualidade dos
produtos, reduzir o seu custo e o tempo de desenvolvimento. No entanto, as diferenas entre eles so, na sua
maioria, de origem terminolgica (Roozenburg & Eekels, 1995). Esses autores distinguem trs tipos de modelos
de processo de projeto: (a) ciclo emprico (observao-suposio-expectativa-teste-avaliao) ou soluo de
problemas; (b) modelo de fases e; (c) desenvolvimento concntrico (trata o projeto como o desenvolvimento de
uma nova atividade empresarial). Os autores salientam que os trs modelos no se opem, mas se
complementam.
O modelo de fases rene os modelos de projeto preconizados, entre outros, por French, Pahl & Beitz,
Hubka. A semelhana entre esses modelos levou Ferreira (1997) e Ogliari (1999) a denomin-lo de modelo

consensual. O modelo consensual composto de quatro fases: projeto informacional, projeto conceitual, projeto
preliminar e projeto detalhado, conforme pode-se observar na FIGURA 1.1.

FIGURA 1.1 - Modelo de consenso para o projeto sistemtico de produtos (Ogliari, 1999).
Em razo dos constantes avanos na rea de projeto assistido por computador que permitem ao
projetista simulaes na medida em que o projeto desenvolvido, existem autores e, dentre eles, Amaral et al
(2004), que suprimiram a fase de Projeto Preliminar juntando-a fase de Projeto Detalhado o que resulta no
modelo expresso na FIGURA 1.2.

FIGURA 1.2 Modelo para o projeto sistemtico de produtos (Adaptado de Ogliari, 1999).
Uma caracterstica importante dos modelos de fases que ao final de cada uma delas h um ganho de
informao sintetizado num modelo cada vez mais concreto de produto, que ao mesmo tempo em que alimenta
a fase seguinte, melhora o entendimento da fase anterior. Essa caracterstica faz com que o conhecimento, tanto
do problema quanto da soluo, aumente significativamente. Os modelos de produto gerados em cada uma das
fases so por ordem: (a) especificaes de projeto; (b) concepo; (c) leiaute definitivo e documentao.
Dentre os modelos de consenso, o modelo de projeto de produto proposto por Pahl & Beitz (1996) um
dos mais difundidos. A sua utilizao e o seu estudo no NeDIP - Ncleo de Desenvolvimento Integrado de
Produtos - no Departamento de Engenharia Mecnica da UFSC, levou a pequenas, mas significativas,
alteraes no seu formato, principalmente pela adoo de algumas ferramentas no exploradas por Pahl & Beitz
(1996), como por exemplo a matriz da casa da qualidade. Os resultados positivos consistentemente obtidos nos
projetos com as atualizaes que vem sendo constantemente incorporados ao Modelo NeDIP, fazem com que
seja adotado como base metodolgica para a soluo do problema de projeto. No Modelo NeDIP, o projeto
tambm subdividido em quatro fases: (a) projeto informacional; (b) projeto conceitual; (c) projeto preliminar e;
(d) projeto detalhado. Na FIGURA 1.3 pode se observar o fluxo de informao entre as fases, assim como o
resultado obtido em cada uma delas e alguns momentos de tomada de deciso.

O objetivo dessa apostila apresentar detalhadamente a metodologia de projeto a ser empregada no

desenvolvimento das solues fsicas projetuais. Procura-se adequar a metodologia de projeto proposta s
particularidades do domnio de conhecimento em questo, apontando-se os principais problemas metodolgicos
assim como as formas de solucion-los. Pretende-se essa, seja uma ferramenta que auxilie aos estudantes de
projeto de produto da Faculdade Horizontina FAHOR na compreenso e utilizao de uma metodologia para a
consecuo com xito de novos projetos de produto.
Na sequncia, apresentam-se as fases da metodologia de projeto (2 Projeto informacional; 3 Projeto
conceitual; 4 Projeto detalhado) onde, para cada uma delas feita a descrio da fase, do modelo de produto
resultante da fase, so definidos os principais termos, so apresentadas as principais etapas da fase, so
detalhadas as ferramentas empregadas na efetivao das tarefas e os aspectos relevantes do domnio de
conhecimento so considerados.

FIGURA 1.3 Modelo do processo de projeto (adaptado de REIS, 2000).

2. Projeto informacional
O ponto de partida dessa fase do projeto o problema que deu origem necessidade de
desenvolvimento de um novo produto. O projeto informacional consiste na anlise detalhada do problema de
projeto, buscando-se todas as informaes necessrias ao pleno entendimento do problema. O modelo de
produto obtido ao final dessa fase so as especificaes do projeto, que uma lista de objetivos que o produto
a ser projetado deve atender (Roozenburg & Eekels, 1995). A partir disso, so definidas as funes e as
propriedades requeridas do produto e possveis restries com relao a ele e ao prprio processo de projeto
(normas, prazos).
Dentro do processo de projeto as especificaes tm duas funes (Roozenburg & Eekels, 1995): a)
direcionar o processo de gerao de solues; b) fornecer as bases para os critrios de avaliao.
A fim de cumprir adequadamente a essas funes, Roozenburg & Eekels (1995) afirmam que as
especificaes de projeto devem possuir as seguintes propriedades:
a) validade: cada objetivo deve ser vlido, isto pode ser observado se, atravs do entendimento do valor do
atributo, os projetistas tm uma clara compreenso da medida em que a meta associada atingida;
b) completeza: incluso de objetivos vlidos em todas as reas de interesse do problema;
c) operacionalidade: dos objetivos, ou seja, possibilidade de gerao de critrios e avaliaes quantitativas;
d) no redundncia: evitar que determinado aspecto ou propriedade seja considerado mais de uma vez;
e) conciso: reduzido nmero de objetivos na especificao, facilitando avaliaes;
f) praticabilidade: objetivos passveis de serem testados, pois mesmo em objetivos operacionais a predio de
determinadas propriedades pode ser to difcil que o teste , praticamente, impossvel.
Conforme foi visto, nessa fase, evolui-se das necessidades dos clientes at as especificaes do
projeto. No entanto, os meios empregados pelos autores consultados (Pahl & Beitz, 1996; Back & Forcellini,
1997; Ferreira, 1997; Veiga, 1999; Maribondo, 2000) no so idnticos, parecem antes atender s
especificidades de seus prprios problemas de projeto. No obstante, foi possvel identificar uma sequncia
lgica de etapas e de tarefas e um conjunto de ferramentas que forneam uma especificao adequada aos
objetivos do projeto. Um resumo das tarefas e das ferramentas mostrado no fluxograma da FIGURA 2.1.

FIGURA 2.1 Etapas da fase de Projeto Informacional (Adaptado de REIS, 2000).

O sentido como alguns termos importantes como clientes do projeto, necessidade do cliente, requisito
do cliente, requisito do projeto e especificaes do projeto so empregados no texto definido no QUADRO 2.1.
QUADRO 2.1 - Definio de alguns termos pertinentes fase de projeto informacional.

2.1. Etapa 1.1: Pesquisar informaes sobre o tema do projeto

A grande maioria dos produtos so sistemas tcnicos caracterizados pelo emprego de subsistemas e
componentes mecnicos, possvel ento definir a partir do ciclo de vida de outros produtos semelhantes,
fontes de pesquisa para o novo produto a ser projetado. Sinteticamente, tem-se: projeto (em suas trs fases),
teste do prottipo, produo (compras, fabricao, montagem), comercializao (marketing, armazenagem,
distribuio, vendas), uso (operao, manuteno), descarte (desmontagem, reciclagem, desativao).
A pesquisa por informaes tcnicas apoia-se, principalmente, na bibliografia disponvel. Nessa fase do
projeto as informaes tcnicas obtidas so importantes em vrias etapas, desde a identificao de
necessidades, passando pela confeco do questionrio aos clientes, at o estabelecimento final das
especificaes do projeto, quando ser necessrio a fixao de metas quantitativas e a forma de avaliao
destas, fatores importantes para o bom andamento do projeto.

2.2. Etapa 1.2: Identificar as necessidades dos clientes do projeto

A identificao das necessidades dos clientes pode ser feita com o auxlio de pesquisa bibliogrfica,
anlise de sistemas tcnicos similares, consulta a especialistas, simulaes de uso e questionrio aos clientes
do produto. Dentre essas atividades, o desenvolvimento do questionrio aos clientes do produto, deve seguir
diretrizes estabelecidas para orientar o desenvolvimento e a implementao de ferramentas de apoio ao
levantamento e sistematizao das necessidades de projeto. So elas:
a) estabelecer as fases do ciclo de vida do produto como base de categorizao das informaes de
projeto (Tarefa 1.1.1);
b) definir os clientes do projeto de acordo com as fases do ciclo de vida do produto (Tarefa 1.2.1);
c) elaborar questes para cada cliente do projeto de acordo com assuntos relevantes em cada fase do
ciclo de vida do produto.

O levantamento das necessidades dos clientes externos nem sempre muito fcil dependendo do tipo
de produto. Para minimizar o problema, a consulta a especialistas pode ser o indicado.
O ciclo de vida do produto, juntamente com a identificao dos clientes do produto, fundamenta o
desenvolvimento de questionrios de levantamento das necessidades quanto ao seu contedo. No que se refere
a sua formatao e ordenao das perguntas, deve-se utilizar recomendaes. Segundo Sudman & Bradburn

(1982), o projeto do questionrio um elemento crucial na maximizao da validade da pesquisa de campo e

preconizam trs regras bsicas para a criao de um questionrio:
a) No formular perguntas antes de estudar as QUESTES (problemas e objetivos) da pesquisa;
b) Manter as QUESTES da pesquisa sempre em foco;
c) Fazer a pergunta PORQUE EU ESTOU FAZENDO ESSA PERGUNTA? e respond-la na perspectiva da
resoluo do problema central.

O questionrio obtido atravs do processo descrito pode ser aplicado de maneira direta aos clientes do
projeto, ou atravs de outros meio utilizando-se a Internet.

2.3. Etapa 1.3: Estabelecer os requisitos dos clientes

As necessidades dos clientes identificadas na etapa anterior, tanto aquelas provindas da pesquisa
bibliogrfica quanto aquelas levantadas nas questes abertas do questionrio (questes em que os
respondentes podem manifestar livremente a sua opinio), em especial as ltimas, no podem ser empregadas
diretamente no desenvolvimento do produto. Conforme se sabe, as necessidades so expressas de forma
subjetiva, de difcil aproveitamento no projeto, sendo necessrio, portanto, traduzi-las para a linguagem de
engenharia.
O desdobramento das necessidades dos clientes em requisitos dos clientes um trabalho feito em
equipe. Em primeiro lugar as necessidades levantadas so distribudas ao longo do ciclo de vida do produto a
fim de identificar mais facilmente quais delas so claramente redundantes. Posteriormente, cada uma das
necessidades estudada e, se necessrio, decomposta com o intuito de descobrir, em linguagem de
engenharia, o que o cliente realmente quer. Caso necessrio, em alguma necessidade de difcil compreenso,
podero ser utilizadas tcnicas de brainstorming.
Fonseca (2000) apresenta algumas recomendaes quanto forma dos requisitos dos clientes. So
elas: a) frase curta composta pelos verbos ser, estar ou ter, seguidas de um ou mais substantivos; b) frase curta
composta por um verbo que no seja ser, estar ou ter mais um substantivo (nesse caso, possivelmente o
requisito formar uma funo do produto).

2.4. Etapa 1.4: Estabelecer os requisitos do projeto

A converso dos requisitos dos clientes em requisitos do projeto constitui-se na primeira deciso fsica
sobre o produto que est sendo projetado (Fonseca, 2000). Razo pela qual busca-se uma sistematizao dos
procedimentos que levam a tal converso, com o intuito de obter requisitos e, consequentemente, especificaes
que atendam ao problema de projeto que se apresenta. Um dos procedimentos que pode ser adotado pode ser
assim dividido: a) estudar e caracterizar os requisitos dos clientes; b) confrontar os requisitos dos clientes com
uma classificao de requisitos de projeto; e c) verificar se os requisitos de projeto assim obtidos apresentam
propriedades consideradas desejveis.
O estudo dos requisitos dos clientes passa, conforme prope Ogliari (1999), pelo estabelecimento de
uma lista de atributos relacionados a cada um desses requisitos. Sendo assim, para cada um dos requisitos dos
clientes em questo devero ser identificados atributos que os caracterizem e ajudem na sua compreenso, o
que auxilia na obteno de uma primeira lista dos requisitos do projeto.

O uso de listas de verificao para obteno dos requisitos do projeto tem sido preconizada por vrios
autores (Pahl & Beitz, 1996, por exemplo). No entanto, Fonseca (2000) vai alm ao sugerir que os requisitos dos
clientes sejam confrontados com a lista de verificao, que na verdade trata-se de uma classificao abrangente
dos atributos do produto proposta pelo autor. Fonseca (2000) classifica os atributos do produto em duas grandes
famlias: atributos gerais e atributos especficos. Os atributos gerais classificam-se em bsicos (aqueles que
diferenciam os produtos como funcionamento, ergonmicos, econmicos, confiabilidade etc.) e atributos do
ciclo de vida (fabricabilidade, montabilidade, mantenabilidade etc.). Os atributos especficos referem-se ao
sistema tcnico em questo, dividindo-se em atributos materiais, energticos e de controle. Considerando-se
o ltimo nvel da classificao proposta tem-se uma ampla lista de itens para verificao. A confrontao
sistemtica de todos os requisitos dos clientes com cada um dos itens constantes na classificao apresentada
permite a obteno de uma lista ampliada de requisitos do projeto.
Finalmente, a lista assim obtida analisada sob a tica das propriedades desejveis nas especificaes
de projeto (Roozenburg & Eekels, 1995): validade, completeza, operacionalidade, no redundncia, conciso e
praticabilidade. Esta anlise tem o objetivo de obter uma lista de requisitos de projeto enxuta (conciso), pois
poucos requisitos so mais facilmente manipulveis num processo sistemtico de avaliao de alternativas, mas,
ao mesmo tempo, completa, pois, conforme salientam esses autores, trabalhar com uma lista de especificaes
incompleta como resolver o problema errado. Dessa forma, ento, so obtidos os requisitos de projeto que
sero hierarquizados atravs da matriz da casa da qualidade.
2.5. Etapa 1.5: Hierarquizar os requisitos do projeto
Esta etapa consiste na aplicao da matriz da casa da qualidade ou primeira matriz do QFD (Quality
Function Deployment - Desdobramento da Funo Qualidade). O QFD uma ferramenta que auxilia a
transformao das necessidades dos clientes em caractersticas mensurveis, que ao serem incorporadas no
projeto constituem-se nos requisitos de qualidade (requisitos de projeto obtidos visando a qualidade). A FIGURA
2.2 apresenta um esquema de construo da primeira matriz do QFD, explicando cada parte da matriz com
breves comentrios.

FIGURA 2.2 Esquema de construo da Matriz da Casa da Qualidade.

A primeira tarefa dentro dessa etapa valorar os requisitos dos clientes. A valorao, isto , a
classificao dos requisitos dos clientes em ordem de importncia fundamental na aplicao do QFD. Segundo

Mirshawka & Mirshawka (1994), nenhuma outra parte da matriz da casa da qualidade tem mais importncia no
resultado do processo que os valores atribudos aos requisitos dos clientes. Dessa forma, procurou-se tratar o
assunto muito criteriosamente. Ullman (1992), afirma que os requisitos dos clientes devem ser comparados aos
pares a fim de que, ao final da comparao, possa se conhecer a sua importncia relativa. A ferramenta
empregada para implementar essa comparao pode ser o diagrama de Mudge, adaptado de seu uso original,
apresentado por Csillag (1985), que era o de comparar funes de um produto dentro da tcnica de anlise de
valor. O uso do diagrama de Mudge para comparar requisitos de clientes visando o uso da matriz da casa da
qualidade amplamente utilizado.
O diagrama de Mudge consiste de uma matriz onde tanto a primeira coluna como a primeira linha so
compostas pelos itens em comparao (requisitos dos clientes, no caso). Compara-se cada requisito das linhas
com todos os requisitos das colunas, exceto os iguais. Em primeiro lugar, a equipe de projeto decide qual o
requisito do par o mais importante (a clula da matriz assume o nmero desse requisito), aps o que, decidese o nvel de importncia: muito mais importante (valor cinco letra A), mais importante (valor trs letra B) e
pouco mais importante (valor um letra C). Segue ao nmero do requisito, na clula da matriz, a letra
correspondente ao quanto mais importante o requisito. O valor relativo de cada requisito obtido pelo
somatrio dos valores observados em todo o diagrama.
Durante a aplicao do diagrama de Mudge, a deciso sobre qual requisito do par o mais importante e
em que medida, tem por base o conhecimento adquirido dos clientes do projeto atravs dos questionrios
aplicados. Nos casos em que os requisitos no constarem no questionrio, a valorao ter por base o
conhecimento adquirido pela prpria equipe ao longo do processo de projeto.
A segunda tarefa da etapa a aplicao da matriz da casa da qualidade. O uso dessa ferramenta deve
ser feito em equipe e fornece como resultado, conforme j foi mencionado, os requisitos de projeto em ordem de
importncia. Existem softwares que podem ser utilizados para o preenchimento dessa matriz.
Uma das atividades mais importantes na matriz da casa da qualidade estabelecer o grau de
relacionamento entre os requisitos dos clientes (o qu) e os requisitos do projeto (como). A identificao de um
relacionamento e do seu grau ser facilitado para a equipe de projeto se o seguinte procedimento for
formalizado: (a) iniciando pelo primeiro como, fazer as perguntas pode esse como influenciar esse o qu?
Esse o qu afeta esse como? (b) se a equipe responder com um sim a uma das perguntas anteriores, perguntar
a relao fraca, mdia ou forte? (c) passar a anlise do prximo o qu repetindo-se o procedimento anterior,
ao chegar-se no ltimo item, passa-se para o prximo como.
No telhado da casa da qualidade (item 5 da FIGURA 2.2), cada um dos requisitos do projeto
confrontado com todos os demais, procurando-se identificar qual o efeito da obteno individual de cada um
deles em todos os demais. Se a maximizao desejada de um requisito leva a um aumento, tambm desejvel,
em outro requisito diz-se que h uma correlao positiva entre eles. Quando ocorre o contrrio e a maximizao
de um requisito causa um decrscimo no desejado em outro, diz-se que h uma correlao negativa entre eles,
ou seja, so conflitantes. Em ambos os casos, geram-se informaes teis para o projeto.
Quando h correlao positiva, sabe-se que pode haver um ganho de qualidade no produto pela
maximizao dessa classe de requisitos. Nos casos em que h conflitos entre eles, correlao negativa, deve-se
adotar uma soluo de compromisso entre eles ou, conforme ser visto adiante, tentar usar a oposio existente
na busca por solues inventivas que elimine ou atenue o conflito.

10

A informao obtida no telhado da casa da qualidade tambm pode ser utilizada, juntamente com a
pontuao obtida na matriz de relacionamento do QFD (relacionamento entre os requisitos do cliente e os
requisitos de projeto), para hierarquizar os requisitos de projeto. Ogliari (1999) prope os seguintes mecanismos
para a utilizao efetiva dos compromissos entre requisitos do projeto obtidos no telhado do QFD: (a) requisitos
positivamente correlacionados (forte ou mdio) devem ter seus pesos de importncia aumentados; (b) requisitos
negativamente correlacionados (forte ou mdio) devero ter o seu peso de importncia atenuados. O autor
formaliza quantitativamente essa proposta, que encontra-se implementada no programa computacional SISCOI.
Geram-se assim, duas listas de hierarquizao de requisitos de projeto: uma sem a considerao dos
cor-relacionamentos entre os requisitos (sem o telhado) e outra considerando os cor-relacionamentos (com
telhado). Surge ento a questo: qual delas deve-se utilizar? Fonseca (2000) prope uma sistemtica para
abordar essa dificuldade:
a) Dividir ambas as listas de classificao em trs partes, o tero superior, o tero mdio e o tero
inferior (os mais importantes, os importantes e os menos importantes).
b) Comparando-se os conjunto de requisitos com seus similares nas duas listas de hierarquizao,
verifica-se se o trabalho tem consistncia, ou seja, se os requisitos do projeto mantm-se
praticamente os mesmos nos dois primeiros conjuntos (mais importantes e importantes).
c) Nesse caso pode-se tomar para hierarquizao final uma mdia das duas listas, ou decidir a
mesma por consenso da equipe de projeto.
d) Se houver grandes discrepncias na posio hierrquica dos requisitos de projeto, deve-se revisar
o trabalho da casa da qualidade e reiniciar o trabalho de avaliaes.
Tambm pode ser feita, com o auxlio do QFD, a avaliao de produtos similares existentes no mercado.
Dessa forma possvel acessar e contornar os pontos fracos observados nesses projetos e, ao mesmo tempo,
procurar entender de que forma o pleno atendimento de determinado requisito do cliente foi conseguido.

2.6. Etapa 1.6: estabelecer as especificaes do projeto

Os requisitos de projeto obtidos e hierarquizados nas etapas anteriores representam os objetivos do
projeto de forma qualitativa, no permitindo, por si s, a continuidade do trabalho, pois no h metas a serem
atingidas e tambm no se sabe como essas metas sero avaliadas e nem mesmo quais so as restries que
devem ser observadas. Portanto, a tarefa principal dessa etapa aplicar o quadro de especificaes de projeto
aos requisitos, obtendo assim as especificaes do projeto.
O quadro de especificaes de projeto nada mais do que o local onde aos requisitos de projeto so
associadas mais trs informaes, conforme sugere Fonseca (2000): a) meta a ser atingida pelo requisito
expressa quantitativamente; b) forma de avaliao da meta estabelecida a fim de verificar o seu cumprimento; e
c) aspectos que devem ser evitados durante a implementao do requisito.
Adicionalmente, juntam-se ao quadro de especificaes, a fim de melhor compor esse modelo inicial do
produto, os objetivos do projeto, a restries gerais observadas e uma breve descrio do produto a ser
projetado.
Aps terem sido estabelecidas as especificaes do projeto necessrio, conforme pode-se observar
na FIGURA 1.3, verificar se o resultado est adequado ao problema de projeto que se apresenta antes de
prosseguir para a prxima fase de projeto. Essa verificao pode ser feita com o auxlio do questionamento
proposto por Pahl & Beitz (1996), respondendo-se as seguintes perguntas:

11

a) A tarefa foi suficientemente esclarecida para permitir o desenvolvimento de uma soluo na forma
de um projeto?
b) So necessrias mais informaes a respeito da tarefa de projeto?
c) possvel alcanar os objetivos propostos com as restries financeiras que se impem?
d) A elaborao de um conceito realmente necessria, ou solues j conhecidas permitem avanar
diretamente para as fases de projeto preliminar e detalhado?
e) Se a fase conceitual indispensvel, como e com que profundidade deve ser desenvolvida?
A anlise conjunta das respostas suscitadas por essas perguntas devem permitir uma deciso quanto
adequao das especificaes do projeto e o incio da prxima fase de projeto.

12

3. Projeto conceitual
O projeto conceitual tido como a fase mais importante no processo de projeto de um produto, pois as
decises tomadas nessa fase influenciam sobremaneira os resultados das fases subsequentes (Back &
Forcellini, 1997). Segundo Ferreira (1997), o projeto conceitual a fase do processo de projeto que gera, a partir
de uma necessidade detectada e esclarecida, uma concepo para um produto que atenda da melhor maneira
possvel esta necessidade, sujeita s limitaes de recursos e s restries de projeto. O modelo de produto
obtido ao final dessa fase a concepo do produto, que, segundo Pahl & Beitz (1996), a proposta de
soluo fundamental, que satisfaz a funo global e que sustenta a promessa de realizao da tarefa.
Em linhas gerais pode-se dizer que o processo de projeto conceitual encontra-se dividido em duas
partes: anlise (ponto de partida no campo do abstrato, anlise funcional, decomposio) e sntese (composio,
sntese das solues, resultado mais prximo do campo concreto).
No modelo do processo de projeto proposto por Pahl & Beitz (1996), o projeto conceitual dividido num
conjunto de etapas que visam garantir a obteno de uma concepo adequada do produto. A sequncia de
etapas, as tarefas a serem executadas, com exceo das iteraes que devem existir entre as etapas para
permitir o ajuste das solues obtidas, so ilustradas na FIGURA 3.1.

3.1. Etapa 2.1: Verificar o escopo do problema

Esta etapa tem por objetivo fazer um estudo compreensivo do problema num plano abstrato, de forma a
abrir caminho para solues melhores. Nesse sentido, a abstrao, que significa, segundo Pahl & Beitz (1996),
ignorar o que particular ou casual e enfatizar o que geral e essencial, tem um papel preponderante, pois
previne que a experincia do projetista ou da empresa, preconceitos e convenes interponham-se entre as
especificaes do projeto e a melhor soluo para o problema. Segundo os autores, essa generalizao conduz
ao cerne da tarefa, fazendo com que a formulao da funo global e o entendimento das restries essenciais
tornem-se claras sem a considerao prvia de uma soluo.
Uma reformulao do problema feita, de forma mais ampla possvel, em etapas sucessivas. Ou seja,
aspectos bvios do problema no so aceitos primeira vista, mas discutidos sistematicamente. Essa tentativa

13

de reformulao do problema feita atravs de uma anlise das especificaes do projeto (Tarefa 2.1.1). Pahl &
Beitz (1996) sugerem uma srie de passos e alguns questionamentos que podem ser seguidos pelo projetista
com o intuito de verificar o problema, abstraindo o essencial.

FIGURA 3.1 Etapas da fase de Projeto Conceitual (Adaptado de REIS, 2000).

14

Num primeiro momento, procura-se entender a natureza do problema. Para isso deve-se indagar se o
cerne da tarefa de projeto :
a) aperfeioar as funes tcnicas do produto;
b) reduzir peso ou espao;
c) reduzir custos;
d) abreviar prazos de entrega; ou
e) melhorar mtodos de produo.
Uma vez identificada a natureza do problema, tem-se em mos o enfoque sob o qual as especificaes
do projeto devem ser analisadas na busca de uma reformulao proveitosa do problema. Essa anlise
orientada atravs de cinco passos que visam conduzir a abstrao na busca por aspectos gerais do problema e
de seus atributos essenciais (Pahl & Beitz, 1996).
Passo 1: Eliminar preferncias pessoais.
Passo 2: Omitir requisitos sem relao direta com a funo e com as restries essenciais.
Passo 3: Transformar informaes quantitativas em qualitativas e reduzi-las ao essencial.
Passo 4: Generalizar os resultados do passo anterior.
Passo 5: Formular o problema sem a incluso de solues.

Com a formulao do problema obtida no Passo 5 - ou melhor, reformulao, pois o problema j havia
sido estudado e definido com um firme embasamento lgico e fatual deve-se prosseguir com o processo de
abstrao e questionamento (Tarefa 2.1.2) numa tentativa de verificar se uma mudana, ou extenso, da tarefa
original pode levar a uma soluo mais promissora. A abstrao utilizada para verificar se, realmente, a tarefa
que se apresenta depende da realizao de outras funes. A abstrao tambm empregada na tentativa de
identificar restries fictcias, que poderiam limitar o emprego de novas tecnologias, materiais, processos de
fabricao e mesmo novas descobertas cientficas. O resultado desse estudo pode quebrar preconceitos e
conduzir a uma melhor soluo do problema proporcionando um entendimento mais claro da tarefa de projeto, o
que indispensvel para o xito nas etapas subsequentes do projeto conceitual.

3.2. Etapa 2.2: Estabelecer a estrutura funcional

Nessa etapa do modelo de projeto conceitual proposto, a formulao do problema feita de forma ainda
abstrata, atravs das funes que o produto deve realizar, independente de qualquer soluo particular. O ponto
de partida a abstrao feita na etapa anterior, que permite o estabelecimento criterioso da funo global do
sistema, e o resultado, ao final da etapa, a estrutura de funes elementares, ou estrutura de operaes
bsicas, caso se trabalhe com funes de baixa complexidade ou padronizadas. Esse processo ilustrado na
FIGURA 3.2.

FIGURA 3.2 Tarefas e processos envolvidos na anlise funcional (fonte: Ferreira, 1997).

15

A definio formal dos principais termos tcnicos empregados nessa etapa do projeto conceitual feita
no QUADRO 3.1.
QUADRO 3.1 - Principais conceitos na etapa de anlise funcional.

Estabelecer a funo global

Uma vez que tenha sido formulado o cerne do problema, possvel indicar uma funo global que,
baseada no fluxo de material, energia e sinal, possa, com o emprego de um diagrama de bloco, expressar as
relaes entre as entradas e as sadas do sistema independentemente de uma soluo (Pahl & Beitz, 1996).
Portanto, o estabelecimento da funo global tem como base o resultado da anlise do problema feito na etapa
anterior do processo de projeto. As entradas e as sadas de todas as quantidades envolvidas, que no tiverem
sido suficientemente esclarecidas, devem ser estudas em maior profundidades e definidas, para que, por fim,
seja possvel especificar a funo global do sistema.
Estabelecer estruturas funcionais alternativas
A subdiviso da funo global visa facilitar a busca por princpios de soluo. A derivao da estrutura
funcional pode ser feita atravs da anlise de sistemas tcnicos existentes. Segundo Pahl & Beitz (1996), essa
abordagem particularmente til para desenvolvimentos nos quais, pelo menos, uma soluo com a estrutura
funcional apropriada conhecida e o problema principal reside na descoberta de solues melhores. Deve-se
observar as diretrizes sugeridas por Pahl & Beitz (1996) para o desdobramento da funo global.
As seguintes recomendaes podem ser sintetizadas do trabalho de Pahl & Beitz (1996):
Derivar uma estrutura funcional aproximada com os relacionamentos possveis de identificar nos
requisitos de projeto. Aps feito o desdobramento dessa estrutura aproximada passo a passo,
trabalhando-se das fronteiras do sistema para dentro.
Caso no seja encontrado um relacionamento claro entre as funes auxiliares, apenas enumerar as
funes auxiliares principais e iniciar a busca por princpios de soluo.
Estruturas funcionais no esto completas at que os fluxos de material, energia e sinal existentes
ou esperados possam ser especificados. No entanto, deve-se comear pela estrutura do fluxo
principal.
Algumas funes elementares aparecem em quase todas as estruturas funcionais, assim o seu
conhecimento prvio auxilia na sua identificao e facilita a busca por princpios de soluo
(catlogos de projeto).
O estabelecimento de uma estrutura funcional pode ser otimizado atravs do desenvolvimento de
variantes, o que pode ser obtido por: (a) diviso ou combinao de subfunes; (b) mudar a
disposio de subfunes individuais; (c) mudar o tipo de ligao (srie ou paralelo); (d) alterar as
fronteiras do sistema).

16

Manter as estruturas funcionais to simples quanto possvel. Combinaes que levem a solues
integradas geralmente so teis com esse fim.
A representao da estrutura funcional deve ser feita por smbolos simples e informativos,
suplementados por clarificaes verbais especficas para a tarefa.
Estas diretrizes podem ser complementadas por algumas outras sugeridas por Back & Forcellini (1997),
quais sejam:
Na formao da estrutura funcional, num segundo nvel de complexidade, alm de decompor o
bloco, deve-se procurar decompor a declarao da funo global e para isso, as sub-declaraes
devem ser as mais con-densadas, na medida do possvel, limitarem-se ao par de verbo e
substantivo.
Nas declaraes de funes parciais e at o nvel de funes elementares, usar o mnimo possvel
de diferen-tes pares de verbo-substantivo para a declarao das funes.
Outro aspecto que pode orientar o estabelecimento da estrutura funcional so as necessidades dos
clientes nas quais o verbo formador da declarao no for ser, estar ou ter. Para esses casos, Fonseca (2000)
recomenda verificar se tal necessidade no , na verdade, uma funo que deve ser implementada pelo produto.
Por fim, cabe lembrar, conforme apontam Roozenburg & Eekels (1995), que o desenvolvimento de
estruturas funcionais no um fim, mas um meio que deve permitir a descoberta de solues teis para o
problema. Portanto, h que se ter cuidado com o nvel de detalhamento necessrio, para que no haja perda de
tempo.
Selecionar a estrutura funcional
Partindo-se da ideia de que diversas estruturas funcionais devero ser geradas, necessrio
estabelecer os critrios de escolha para selecionar a melhor alternativa. A dificuldade principal estabelecer
critrios de soluo objetivos para um modelo de produto ainda muito abstrato. A especificao do projeto,
segundo Back & Forcellini (1997), continua a ser o critrio principal, no entanto, faz-se necessrio imaginar
princpios de soluo para poder confrontar as estruturas alternativas.
Na escolha da melhor estrutura funcional alternativa para funo global pode-se fazer uso de
informaes sobre sistemas tcnicos semelhantes. Isso possvel acontecer dependendo da caracterstica do
projeto e da existncia de estudos na rea de domnio do projeto em execuo. Independentemente dessas
caractersticas, a escolha da melhor estrutura funcional pode ser feita atravs do emprego da matriz de deciso
proposta por Ferreira (1997). Com a aplicao dessa matriz, a estrutura a ser escolhida a que apresentar uma
maior relao entre o ndice de desempenho tcnico (fornece uma indicao de qual estrutura apresenta um
melhor desempenho tcnico em relao s demais) e o ndice de custos (fornece uma orientao de qual
estrutura apresenta um custo mais baixo em relao s demais).
As tarefas necessrias ao preenchimento da matriz de deciso so, segundo Ferreira (1997):
a) Preenchimento dos requisitos tcnicos: a primeira e a segunda colunas do campo superior da
matriz (FIGURA 3.3) devem ser preenchidos, respectivamente, com os m requisitos tcnicos do
produto (RT) e os seus correspondentes pesos relativos (PRRT), obtidos na casa da qualidade.
b) Avaliao das estruturas em relao aos requisitos tcnicos: preenchimento do primeiro campo da
matriz, sendo avaliado o modo pelo qual cada estrutura funcional se comporta quanto a cada um
dos requisitos tcnicos. A escala de valor empregada verifica se o desempenho tcnico da
estrutura (DTij) fraco (smbolo *, valor 1), satisfatrio ( smbolo , valor 5) ou excelente (smbolo

17

, valor 10). O preenchimento deve ser feito por uma equipe multidisciplinar, observando de que
forma os aspectos de disposio das funes, fluxos de energia, material e sinal, o tipo e o nvel
de complexidade dos possveis princpios de soluo, podem influenciar o desempenho tcnico da
estrutura em questo.
c) Determinao do ndice de desempenho tcnico: somatrio do resultado da multiplicao do valor
do desempenho tcnico de cada um dos m requisitos pelo seu relativo peso.
d) Preenchimento da matriz com as especificaes de custo: as, primeira e a segunda colunas do
campo inferior da matriz devem ser preenchidos, respectivamente, com os n custos-meta do ciclo
de vida do produto (ECK) e com o valor relativo das especificaes de custos (ECR).
e) Avaliao das estruturas em relao s especificaes de custo: preenchimento do segundo campo
da matriz, avaliando se cada custo do ciclo de vida das estruturas funcionais alto (smbolo ,
valor 10), mdio (smbo-lo , valor 5) ou baixo (smbolo , valor 1). So vlidas as mesmas
consideraes feitas no item b.
f) Determinao do ndice de custo: obtido de forma anloga ao ndice de desempenho tcnico (item
c).

FIGURA 3.3 Matriz de deciso para seleo da estrutura funcional do produto (fonte: Ferreira, 1997).
Tambm segundo Ferreira (1997), na maioria dos casos, tem-se como critrio de seleo, o melhor
desempenho tcnico a um custo mais baixo. Nessa situao, a estrutura pode ser selecionada atravs da
anlise do valor dado pela relao entre o ndice de desempenho tcnico e o de custo de cada estrutura
funcional. A estrutura que apresentar o ndice mais elevado deve ser selecionada. Nos casos em que o produto
seja de alta tecnologia ou destinado a um pblico de alto poder aquisitivo, a estrutura selecionada pode ser
aquela que possua o mais elevado nvel de desempenho tcnico, mas no necessariamente de custo baixo.

18

3.3. Etapa 2.3: Pesquisar por princpios de soluo

Nesta etapa da metodologia passa-se do abstrato ao concreto, da funo forma. A cada uma das
subfunes da estrutura funcional escolhida na etapa anterior atribudo um princpio de soluo. Para que isto
seja possvel, necessrio, a partir do correto entendimento da subfuno, a busca de um efeito fsico e de um
portador de efeito fsico que, por meio de determinados comportamentos, realizem o objetivo da subfuno em
questo. Um aspecto importante nessa etapa a inteno de se obter vrios efeitos fsicos e/ou portadores de
efeito variantes para um mesmo efeito fsico. Assim, a possibilidade de se chegar a uma soluo otimizada para
o problema de projeto aumentada.
Como o completo entendimento dos termos efeito fsico, portador de efeito fsico e princpio de soluo,
importante na aplicao da metodologia, estes sero definidos a seguir. Um efeito fsico (ou biolgico ou
qumico) caracterizado por poder ser descrito quantitativamente atravs das leis fsicas que regem as
quantidades envolvidas (Pahl & Beitz, 1996). A escolha do efeito fsico a ser utilizado, entretanto, no
suficiente para definir como a subfuno ser realizada. necessrio idealizar um sistema fsico, com seus
elementos e suas relaes, definido qualitativamente, capaz de realizar o efeito fsico esperado, ou seja, um
portador de efeito fsico (Ferreira, 1997). Ao se definir um portador de efeito fsico, define-se um princpio de
soluo, que conforme Hansen (1976) apud Roozenburg & Eekels (1995), uma representao idealizada
(esquemtica) da estrutura do sistema ou subsistema, na qual as caractersticas dos elementos e suas relaes,
as quais so essenciais para o seu funcionamento, so determinadas qualitativamente.
Na busca por princpios de soluo pode-se fazer uso de diversos mtodos, divididos, por questes
didticas, em convencionais, intuitivos e discursivos. Os principais mtodos so listados no QUADRO 3.2.
QUADRO 3.2 - Mtodos utilizados na busca por princpios de soluo.

Fonte: Pahl & Beitz (1996); Back & Forcellini (1997); Ferreira & Forcellini (2000).
O emprego de todos os mtodos listados no QUADRO 3.2 seria contraproducente. Por essa razo
devem ser escolhidos alguns deles para realizar a busca por princpios de soluo. A escolha baseia-se em
experincia anterior do autor num trabalho acadmico semelhante (Reis et al., 2000), onde foram utilizados a
TRIZ, os mtodos de analogia simblica, anlise de sistemas tcnicos existentes, pesquisa bibliogrfica
(principalmente patentes) e mtodo da matriz morfolgica. A ordem de aplicao desses mtodos a mesma
com que foram citados, pois assim evita-se que, num primeiro momento, as solues j conhecidas (bibliografia
e sistemas tcnicos existentes) restrinjam a criatividade dos membros da equipe de trabalho.
Aplicar mtodos de busca discursivos
Os mtodos a serem aplicados nessa tarefa so a TRIZ e a matriz morfolgica. A matriz morfolgica
utilizada ao final dessa etapa para estruturar e sistematizar a apresentao dos princpios de soluo
encontrados e a gerao de concepes alternativas. Na matriz morfolgica as funes elementares da estrutura

19

funcional do produto so ordenadas nas linhas da primeira coluna da matriz. Nas linhas das colunas
subsequentes so colocados os desenhos representativos dos princpios de soluo correspondentes a cada
uma das funes elementares do produto. Para cada linha (funo elementar) deve haver, pelo menos, um
princpio de soluo, de forma a permitir a gerao de concepes alternativas que expressem de maneira
integral a funo global do sistema tcnico.
A TRIZ foi idealizada pelo engenheiro mecnico sovitico Genrich S. Altshuller na dcada de 1950. O
caminho buscado por Altshuller para resolver os problemas de engenharia passam pelo estudo da tecnologia,
sem confiar totalmente na psicologia, como outros mtodos para a soluo criativa de problemas. Para tanto, o
pesquisador estudou mais de 1.500.000 patentes, quando pde identificar os problemas, as contradies e as
solues desenvolvidas nessas patentes. Esse estudo resultou na teoria que rege a busca por solues de
problemas inventivos, ou seja, a prpria TRIZ. A teoria pode ser modelada atravs da FIGURA 3.4, onde observase que atravs da formulao do problema sob a tica da TRIZ, passa-se por solues intermedirias genricas
at que se chegue a soluo especifica do problema real.

FIGURA 3.4 Modelagem da busca de princpios de soluo atravs da TRIZ (fonte: Ferreira & Forcellini, 2000).
O emprego conjunto do QFD, da TRIZ e da matriz morfolgica e os passos sugeridos por Ferreira &
Forcellini (2000). Quais sejam:
a) Levantar as necessidades dos clientes.
b) Estabelecer os requisitos de projeto do produto.
c) Correlacionar os requisitos de projeto entre si.
d) Identificar os requisitos de projeto a serem otimizados e os respectivos requisitos em contradio.
e) Associar os requisitos em contradio com os parmetros de engenharia da TRIZ.
f) Identificar o princpio inventivo da TRIZ.
g) Gerar as alternativas de concepo do produto.
Os passos a, b e c so feitos num momento anterior do projeto com o auxlio do QFD. A seguir, sero
descritos os procedimentos preconizados nos passos restantes. (d) Identificar os requisitos de projeto a
serem otimizados e os respectivos requisitos em contradio: sero analisados aqueles pares de requisitos
que encontram-se em forte contradio. Em cada par de requisitos, aquele que apresentar maior importncia
entendido como requisito de projeto a ser otimizado e o correspondente o requisito em contradio. (e) Associar
os requisitos em contradio com os parmetros de engenharia da TRIZ: cada requisito do par em

20

contradio dever ser associado a um dos 39 parmetros de engenharia da TRIZ (a descrio dos parmetros
de engenharia da TRIZ, assim como os princpios inventivos a eles associados, podem ser encontrados em
Ferreira & Forcellini, 2000). (f) Identificar o princpio inventivo da TRIZ: esse passo busca uma orientao
para a soluo das contradies entre os requisitos de projeto. Para tanto, emprega-se a Matriz de Contradio
da TRIZ. Na primeira coluna dessa matriz encontram-se os parmetros de engenharia da TRIZ a serem
otimizados. Na primeira linha da matriz encontram os parmetros de engenharia que encontram-se em
contradio. O relacionamento entre esses parmetros constituem as demais clulas da matriz, onde esto os
princpios inventivos preconizados para o par de parmetros em questo. (g) Gerar as alternativas de
concepo do produto: nesse passo deve-se estabelecer quais funes da estrutura funcional esto
relacionadas com os requisitos de projeto a serem otimizados, identificados anteriormente. A partir da possvel
gerar, atravs das orientaes dos princpios inventivos da TRIZ, os princpios de soluo que devero
solucionar as contradies identificadas no projeto do produto. Os princpios de soluo gerados dessa forma
devero, ento, ser reunidos com os demais na matriz morfolgica.
Aplicar mtodos de busca intuitivos
Nessa categoria, o mtodo de busca utilizado o da analogia simblica. Tambm conhecido sob o
nome de palavra-chave, nada mais , segundo Back & Forcellini (1997), do que a procura por um verbo,
declarao ou definio condensada do problema (no caso da tese, as declaraes que definem as funes
parciais ou elementares). Em seguida deve-se substituir a palavra ou declarao por sinnimos ou alternativas
de declaraes que tenham alguma relao com a original. Este procedimento permite ver o problema sob
outros pontos de vistas, suscitando novas solues.
Aplicar mtodos de busca convencionais
Os mtodos de busca convencionais a serem utilizados, conforme j foi citado, so o de anlise de
sistemas tcnicos existentes e a pesquisa bibliogrfica, principalmente patentes. Estudo de material tcnico de
produtos, como catlogos, manuais e as pginas das empresas fabricantes na Internet.

3.4. Etapa 2.4: Combinar princpios de soluo

Uma vez obtidos os princpios de soluo para cada uma das subfunes da estrutura funcional do
produto, necessrio combin-los de forma a atender a funo global do sistema. Com o emprego da matriz
morfolgica so estabelecidas combinaes de princpios de soluo entre as subfunes da estrutura funcional
(linhas da matriz). Como cada uma das linhas pode apresentar inmeros princpios de soluo, gera-se,
rapidamente, um grande nmero de solues alternativas, o que pode tornar a etapa de seleo bastante difcil.
Portanto, necessrio limitar o nmero de combinaes. Pahl & Beitz (1996) sugerem a aplicao de trs
critrios para esse fim: (a) somente combinar subfunes com princpios de soluo compatveis; (b) somente
procurar por solues que atendam a especificao de projeto e s restries de oramento e; (c) concentrar em
combinaes promissoras estabelecendo as razes de tal preferncia.
Roozenburg & Eekels (1995) sugerem que se faa uma anlise das colunas da matriz morfolgica de
forma a posicionar nas primeiras os princpios de soluo mais adequados para a subfuno. O ordenamento
feito com base na parte da especificao do projeto referente subfuno em questo. Com essa tcnica, o
nmero de combinaes reduzido, pois as clulas com princpios de soluo pouco adequados no so
consideradas.

21

3.5. Etapa 2.5: Selecionar combinaes

A profuso de solues alternativas geradas constitui-se ao mesmo tempo, segundo Pahl & Beitz
(1996), no ponto forte (grande nmero de solues consideradas) e no ponto fraco (dificuldade de apreciar todas
as solues) da abordagem sistemtica nessa etapa do projeto conceitual. Para tentar superar essa contradio,
minimizando o risco de eliminar uma soluo promissora, h que se empregar mtodos sistemticos de seleo
que se adaptem pequena quantidade de informaes disponveis nessa etapa. Ullman (1992) apud Back &
Forcellini (1997) apresenta um procedimento que utiliza quatro tcnicas diferentes para reduzir as variantes
geradas a umas poucas, mas promissoras, solues. A sequncia do uso dessas tcnicas mostrada na FIGURA
3.5.

FIGURA 3.5 - Tcnicas para seleo de variantes de soluo (adaptado de Back & Forcellini, 1997).
Na tcnica do Julgamento da viabilidade, verifica-se, com base na experincia dos membros da
equipe, se a soluo enquadra-se numa das seguintes condies: no vivel, condicionalmente vivel, deve ser
considerada (vivel). As solues enquadradas como condicionalmente vivel e deve ser considerada seguem
adiante para a prxima tcnica. Para a soluo no vivel, deve-se saber com clareza as razes que levaram a
esse julgamento.
A tcnica da Disponibilidade de tecnologia, busca respostas para perguntas como: pode a tecnologia
ser produzida atravs de processos conhecidos? Os parmetros funcionais crticos so conhecidos? A
sensibilidade dos parmetros operacionais conhecida? Os modos de falha so conhecidos? E assim por
diante. Caso sejam obtidas muitas respostas negativas para uma determinada soluo, h indicativos de que a
tecnologia proposta no encontra-se suficiente amadurecida para ser empregada no projeto.
Na tcnica do Exame passa/no-passa, as solues so confrontadas com as necessidades dos
clientes de maneira absoluta. As necessidades so transformadas em questes a serem aplicadas a cada uma
das variantes de soluo. As questes devem poder ser respondidas com sim ou possivelmente (passa) ou no

22

(no passa). As solues que obtiverem poucas respostas no passa so as mais promissoras, indicando que a
variante pode ser modificada ao invs de ser eliminada.
Na tcnica da Matriz de avaliao, as variantes de soluo restantes so comparadas entre si com
relao a critrios elaborados a partir das necessidades dos clientes. A variante de soluo preferida da equipe
de projeto usada como referncia. A ideia, nessa tcnica, de gerar um escore baseado no atendimento dos
critrios pelas diversas variantes de soluo em relao variante de referncia. As variantes que obtiverem um
escore total maior que a referncia so desenvolvidas para a escolha final da concepo do projeto.

3.6. Etapa 2.6: Evoluir em variantes de concepo

O nvel de detalhamento de uma concepo deve permitir a continuidade do projeto a partir desse ponto
(projeto preliminar) e a avaliao de sua viabilidade. Para tanto, a concepo deve ser desenvolvida at que os
meios de desempenhar cada uma das funes principais tenham sido fixados, assim como as relaes espaciais
e estruturais dos principais componentes. Um esboo deve ter sido suficientemente detalhado para tornar
possvel o clculo aproximado de custos, pesos e dimenses gerais, e a exequibilidade, na medida do possvel,
possa ser garantida (French, 1985).
Fica claro, portanto, que as combinaes de princpios de soluo obtidas na Etapa 2.4 precisam ser
melhor representadas, antes que se tome a deciso sobre qual delas deve seguir para o projeto preliminar.
Dentre os vrios mtodos preconizados por Pahl & Beitz (1996) para a obteno das informaes necessrias a
uma melhor representao das variantes de concepo, pode-se empregar clculos aproximados baseados em
suposies simplificadoras e desenhos em escala simplificados de possveis leiautes, formas, requisitos
espaciais, compatibilidade entre funes etc.

3.7. Etapa 2.7: Avaliar concepes

Essa nova rodada de avaliao de solues na fase de projeto conceitual d-se de forma bastante
similar quela descrita na Etapa 2.5. No entanto, como agora se dispe de poucas variantes de concepo,
emprega-se apenas a tcnica da Matriz de Avaliao, que nessa etapa, devido ao maior nvel de detalhamento
das solues, utilizar como critrios de avaliao as especificaes de projeto.
A escolha de uma ou mais concepes para o subsequente desenvolvimento na fase de projeto
detalhado no deve ser baseada apenas em um valor numrico. Os resultados das avaliaes das concepes
devem ser comparados entre si na busca por pontos fracos. Conforme afirmam Pahl & Beitz (1996), uma
concepo com um escore alto pode ter um ponto fraco bem definido, tornando o seu perfil de valores de
avaliao dos requisitos muito irregular. Nesse caso, os autores sugerem a escolha de uma concepo com um
escore um pouco menor, mas que tenha um equilbrio entre as avaliaes dos requisitos (ausncia de pontos
fracos pronunciados). De qualquer maneira, deve-se buscar a compreenso de todas as incertezas evidenciadas
durante o processo de avaliao, para que a identificao tardia de pontos fracos no prejudique o
desenvolvimento da concepo no projeto preliminar.

23

4. Projeto Detalhado
Conforme mencionado na introduo dessa apostila, a grande maioria das metodologias projetuais
incluem antes da fase de projeto detalhado uma fase chamada de projeto preliminar. Isso ocorre em razo das
tecnologias de desenho assistido por computador serem uma realidade no to recente. Com o advento da sua
utilizao, muitos dos passos preconizados na fase de projeto preliminar ocorrem em paralelo com a de projeto
detalhado. Por esse motivo adotamos nesta disciplina de Projeto de Produto uma s fase chamada de Fase de
Projeto Detalhado. Para uma melhor compreenso, relacionamos aqui as etapas da fase de projeto preliminar
como etapas de uma s fase (projeto detalhado) que, via de regra, so realizadas
Segundo Pahl & Beitz (1996), o projeto preliminar a fase do processo de projeto na qual, partindo da
concepo de um produto tcnico, o projeto desenvolvido, de acordo com critrios tcnicos e econmicos e
luz de informaes adicionais, at o ponto em que o projeto detalhado subsequente possa conduzir diretamente
produo. Nessa fase do projeto o modelo do produto evolui da concepo ao leiaute definitivo. Tambm
Para Pahl & Beitz (1996), no projeto detalhado a disposio, a forma, as dimenses e as tolerncias de todos os
componentes devem ser finalmente fixadas. Da mesma forma a especificao dos materiais e a viabilidade
tcnica e econmica devem ser reavaliados. O modelo de produto expresso pela documentao completa
necessria produo do produto projetado.
Nessa fase so empregados uma srie de normas e procedimentos padronizados, conforme as
necessidades dos meios de fabricao. Uma sntese das atividades dessa fase do projeto apresentada na
FIGURA 4.1. A metodologia proposta tem por base o trabalhos de Pahl & Beitz, 1996, Mendes et al. (2000) e
Maribondo (2000). Por outro lado, nossa contribuio a de reunir as informaes com o objetivo de simplificar
e, ao mesmo tempo, adequar a metodologia aos tempos atuais respeitando o conhecimento e o trabalho
desenvolvido pelos eminentes estudiosos da rea.

24

FIGURA 4.1 - Etapas da fase de projeto detalhado (adaptado de Pahl & Beitz, 1996).

25

O leiaute definitivo deve ser desenvolvido at o ponto onde uma verificao clara da funo,
durabilidade, produo, montagem, operao e custos, possa ser feita. O nvel de detalhamento a ser alcanado
nessa fase deve incluir, segundo Pahl & Beitz (1996):
a) estabelecimento do leiaute definitivo (arranjo geral e compatibilidade espacial);
b) projeto preliminar das formas (formato de componentes e materiais);
c) procedimentos de produo;
d) estabelecimento de solues para qualquer funo auxiliar.
Pahl & Beitz (1996) afirmam que nem sempre possvel traar um plano estrito para essa fase, porm,
propem passos que podem orientar o projetista. Alm disso, esses autores propem o emprego de listas de
verificao, estabelecem os princpios a serem observados (princpios de transmisso de fora, diviso de
tarefas, etc) e mtodos para atender necessidades especficas (projeto para X - DFX). Porm, acima de tudo,
afirmam que deve-se observar as regras bsicas de clareza, simplicidade e segurana. O detalhamento do
roteiro dessa fase do projeto ser desenvolvido tambm com base nas recomendaes desses autores.
As ferramentas empregadas nessa fase do projeto so aquelas comuns na rea de engenharia como:
CAD, CAE, programas de simulao, construo de modelos, programas de auxlio ao clculo e
dimensionamento das partes.

4.1. Etapa 3.1: Elaborar leiautes preliminares e desenhos de forma

A tarefa inicial dessa etapa a identificao de requisitos determinantes, ou seja, aqueles que
apresentam um significado crucial no projeto, como: requisitos determinantes de tamanho (produo, tamanho
de conectores, produto a ser processado etc); requisitos determinantes de disposio (direo de fluxo,
movimento, posio etc); requisitos determinantes de material (resistncia corroso, vida til, material
normatizado etc). O ponto de partida dessa tarefa a lista de especificaes do projeto.
A prxima tarefa a produo de desenhos em escala, levando-se em considerao as restries de
tamanho, forma e disposio identificados. Alm do dimensionamento prvio dos principais princpios de
soluo, devem ser mostrados itens como folgas, posies de eixos e restries de instalao.
A seguir faz-se a identificao dos portadores de efeito fsico determinantes, que so aqueles
componentes ou conjuntos que desempenham as funes principais do sistema tcnico. Para isso, importante
identificar quais funes, ou princpios de soluo, determinaro o tamanho, a forma e a disposio de
componentes no leiaute. Essas informaes devem ser completadas com uma lista de parmetros
caractersticos dos portadores de efeito fsico em questo, como por exemplo: potncia, velocidade angular,
comprimento, resistncia mecnica, relao de transmisso etc.
Com base nesses portadores de efeito fsico e na concepo do produto desenvolve-se leiautes
preliminares e desenhos de forma. Nesse nvel, o desenvolvimento (ex.: definio provisria de dimenses
mximas e mnimas, relaes de transmisso, espessuras etc.) deve prosseguir at que todas as funes
relevantes estejam contempladas. Caso j exista uma soluo (produto), pode-se analisar os fatores de
perturbao dessa soluo e, com base nos resultados, elaborar uma nova lista de requisitos para o leiaute
preliminar em estudo.

26

Caso haja mais de um leiaute preliminar, h que se selecionar apenas um. Para tanto, pode-se utilizar
variaes do mtodo apresentado na FIGURA 3.5 e a lista de verificao para o projeto preliminar sugerida por
Pahl & Beitz (1996). Uma vez feita essa seleo, parte-se para o desenvolvimento de leiautes preliminares e
desenhos de formas para os demais portadores de efeito fsico.

4.2. Etapa 3.2: Elaborar leiautes detalhados e desenhos de forma

Nessa etapa h o desenvolvimento do leiaute preliminar, com a incorporao das solues para as
funes auxiliares e o seu refinamento, j com todas as funes incorporadas, e a subsequente avaliao, a fim
de verificar a adequao dos resultados aos critrios tcnicos e econmicos.
A primeira tarefa dessa etapa a determinao de quais funes auxiliares essenciais so necessrias
tendo em vista a proposta de leiaute em uso (por exemplo: suportar carga, vedar presso, refrigerar componente
etc). Uma vez identificadas essas funes, h que se buscar solues para elas, preferencialmente, solues j
conhecidas, como peas padronizadas ou de catlogos.
A prxima tarefa a de incorporar no leiaute e nos desenhos de forma as solues para as funes
auxiliares. Para tanto deve-se observar regras bsicas (clareza, simplicidade e segurana) e as diretrizes do
projeto preliminar (dilatao, alongamento, fadiga, ruptura, corroso, projeto para ergonomia, projeto para
esttica, projeto para manufatura, projeto para montagem, projeto para atender normas, projeto para fcil
manuteno, projeto para reciclagem, projeto para o mnimo risco e projeto para padronizao), ambas
sugeridas e abordadas com algum detalhe por Pahl & Beitz (1996). Nessa etapa, portanto, deve-se prestar
ateno nas normas referentes rea de domnio do produto e normas gerais de projeto e produo, deve-se
efetuar clculos detalhados dos parmetros envolvidos, alm de considerar conhecimentos experimentais do
prprio produto ou de semelhantes, ou at mesmo construir prottipos. Uma outra atividade importante dentro
dessa tarefa a compatibilizao das solues encontradas para as funes auxiliares e aquelas j
desenvolvidas para as funes principais do sistema tcnico, incorporando-as no leiaute em desenvolvimento.
Isso pode tornar necessrio o refinamento das partes principais j presentes no leiaute.
A tarefa de completar os leiautes gerais com todas as funes incorporadas visa consolidar as
modificaes feitas com a incorporao das solues para as funes auxiliares, de forma que se tenha todos os
desenhos de forma, leiautes detalhados e gerais coerentes e prontos para avaliao.
A avaliao sob critrios tcnicos e econmicos torna-se necessria para selecionar um leiaute para o
produto, caso tenha-se desenvolvido mais de um ou, caso tenha-se apenas um leiaute, para tentar identificar a
sua adequao para a soluo do problema de projeto. Em ambas situaes, indicado o emprego de um
mtodo sistemtico que considere, se possvel na forma quantitativa, os conhecimentos de ordem tcnica e
econmica obtidos ao longo do processo de projeto. A matriz de deciso apresentada na FIGURA 3.3 pode ser
utilizada com esse fim.

4.3. Etapa 3.3: Finalizar verificaes

Durante o processo de avaliao podem ter sido identificados pontos fracos no leiaute ou surgido
dvidas quanto alguma soluo adotada, tornando necessrio otimizar e completar os desenhos de forma at
ento feitos. Nessa tarefa poder ser necessria a repetio de atividades j realizadas ao longo do projeto

27

preliminar, como a busca por solues para funes auxiliares, desenvolvimento de novos leiautes ou
aproveitamento de solues adotadas em variantes de leiaute no utilizadas.
Com o leiaute otimizado em funo das observaes feitas durante a avaliao, deve-se verificar erros
e fatores de perturbao. Para realizar essa tarefa deve-se fazer o uso diligente da lista de verificao para o
projeto preliminar apresentada no QUADRO 4.1.
Como ltima tarefa do projeto preliminar, prepara-se a lista de partes preliminar e documentos iniciais
para a produo, o que culmina com o estabelecimento do leiaute definitivo e completo (desenhos, lista de
partes e documentao descritiva) do produto.
QUADRO 4.1 Lista de verificao para o projeto preliminar.

FONTE: Pahl & Beitz (1996).

Para Pahl & Beitz (1996), no projeto detalhado a disposio, a forma, as dimenses e as tolerncias de
todos os componentes devem ser finalmente fixadas. Da mesma forma a especificao dos materiais e a
viabilidade tcnica e econmica devem ser reavaliados. O modelo de produto expresso pela documentao
completa necessria produo do produto projetado.
Nessa fase so empregados uma srie de normas e procedimentos padronizados, conforme as
necessidades dos meios de fabricao.

4.4. Etapa 3.4: Detalhar o leiaute definitivo

Durante o esta etapa a preocupao do projetista deve estar focada em apurar os ltimos detalhes do
projeto, efetuar os dimensionamentos finais e ao mesmo tempo produzir os desenhos detalhados se esquecer
informaes que permitem a sua fabricao.

28

4.5. Etapa 3.5: Integrar informaes tcnicas

Durante o esta etapa deve-se promover a integrao de todos os desenhos e outras informaes
necessrias a montagem de partes.

4.6. Etapa 3.6: Revisar o projeto

A preocupao do projetista aqui de verificar se o produto atende as especificaes e as normas
estabelecidas para que possa cumprir a funo para o qual foi projetado.

4.7. Planejamento de prottipos

Mesmo antes do trmino do processo de desenvolvimento do produto j h a necessidade de
construo de prottipos, visando testar algum princpio de soluo ou mesmo acelerar o andamento do projeto.
Esse entendimento defendido por Pahl & Beitz (1996), servindo tambm de justificativa para a ausncia dessa
atividade em locais especficos dos modelos de desenvolvimento de produtos. Sendo assim, sero vistas a
seguir algumas consideraes importantes a respeito do desenvolvimento de prottipos.
De acordo com Ulrich & Eppinger (1995), um prottipo uma aproximao do produto ao longo de uma
ou mais dimenses de interesse. As dimenses as quais se referem os autores dizem respeito ao grau de
realizao fsica do prottipo e ao seu grau de abrangncia. Nessa primeira dimenso, um prottipo fsico, ou
seja, artefatos tangveis criados para se aproximarem das caractersticas do produto, se ope a um prottipo
analtico, que representam o produto de forma no tangvel, muitas vezes matematicamente. Na outra dimenso
encontram-se opostos o prottipo compreensivo aquele que representa todas as caractersticas do produto - e
o prottipo focado que representa apenas um, ou poucos atributos do produto.
A definio sobre qual tipo de prottipo o mais adequado ao desenvolvimento do produto est
relacionado ao propsito do prottipo. Nesse aspecto, Ulrich & Eppinger (1995) distinguem quatro propsitos
para a construo de prottipos: aprendizado (adquirir conhecimento a respeito do funcionamento dos princpios
de soluo e do nvel de atendimento das necessidades dos clientes); comunicao (facilitar a transmisso de
aspectos da ideia do produto a diferentes instncias hierrquicas na empresa e demais clientes); integrao
(verificar a integrao dos diversos subsistemas e componentes que formam o produto); estabelecimento de
marcos no projeto.
Ao mesmo tempo em que a construo de prottipos pode acelerar o desenvolvimento de produtos,
tambm pode, caso haja negligncia no planejamento, comprometer o cronograma de projeto. Sendo assim,
Ulrich & Eppinger (1995) sugerem uma metodologia para o planejamento de prottipos. Os quatro passos
sugeridos so apresentados a seguir:
Passo 1: Definir o propsito do prottipo: ou seja, com que finalidade se est construindo um
prottipo. Para tanto, devem ser listadas as necessidades especficas de aprendizado,
comunicao, integrao e se o prottipo dever ser um dos marcos principais do processo de
projeto.
Passo 2: Estabelecer o nvel de aproximao do prottipo: a equipe de projeto dever fazer
consideraes sobre a necessidade de um prottipo fsico ou analtico, compreensivo ou focado.
Na maioria das vezes, o melhor prottipo o mais simples.
Passo 3: Delinear o experimento: essa etapa necessria pois na maioria das vezes, o uso de
prottipos no desenvolvimento de produtos pode ser pensado como um experimento. Essa etapa

29

inclui: a identificao das variveis experimentais (caso existam), identificao das normas de
testes, identificao das variveis de resposta e um plano para a anlise dos resultados.
Passo 4: Criar um cronograma de execuo: como execuo considera-se a aquisio de partes e
instrumentao, construo propriamente dita e teste. Nesse contexto, trs datas so importantes:
data em que todas as partes estaro prontas para a montagem; data do final da montagem e
primeiro teste; data final dos testes.

4.7. Consideraes finais

Esta apostila tem o intuito de auxiliar o estudante no processo de aprendizagem do componente
curricular de Projeto de Produto da Faculdade Horizontina no sendo permitida a sua reproduo. Trata-se de
material de apoio s aulas e s atividades de projeto do mesmo componente que tambm contou com a
colaborao do estudante do curso de Engenharia Mecnica Cesar dos Santos.
A apostila foi baseada na Tese de Doutorado de ngelo dos Reis (2000) a quem deve ser atribudo o
mrito deste trabalho entretanto, algumas adaptaes foram realizadas para adequao s necessidades do
componente curricular.
Como o prprio autor revela, deve-se atentar para o fato da metodologia proposta neste trabalho no
ser algo acabado e esttico. Constantes aperfeioamentos vem sendo propostos e testados, de forma que as
atividades vem sendo melhor entendidas e executadas com maior eficcia. Assim, embora se tenha tido o
cuidado de fazer uma exposio detalhada das etapas, tarefas e ferramentas, de forma que a metodologia
proposta pudesse ser utilizada como um referencial inicial para projetos semelhantes, especialmente na rea de
mquinas agrcolas onde h carncia de uma abordagem sistemtica do projeto, necessrio a constante
incorporao das novas prticas e a atenta considerao do tipo de projeto em questo.