Embed Size (px)
Citation preview
METODOLOGIA PARA PROJETOS DE SISTEMAS MECATRÔNICOS
Paulo Roberto da Silva Fonseca
Rio de Janeiro
Agosto de 2015
Dissertação de Mestrado apresentada
ao Programa de Pós-graduação em
Engenharia Mecânica, COPPE, da
Universidade Federal do Rio de
Janeiro, como parte dos requisitos
necessários à obtenção do título de
Mestre em Engenharia Mecânica.
Orientador: Max Suell Dutra
METODOLOGIA PARA PROJETOS DE SISTEMAS MECATRÔNICOS
Paulo Roberto da Silva Fonseca
DISSERTAÇÃO SUBMETIDA AO CORPO DOCENTE DO INSTITUTO ALBERTO
LUIZ COIMBRA DE PÓS-GRADUAÇÃO E PESQUISA DE ENGENHARIA (COPPE)
DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS
REQUISITOS NECESSÁRIOS PARA A OBTENÇÃO DO GRAU DE MESTRE EM
CIÊNCIAS EM ENGENHARIA MECÂNICA.
Examinada por:
________________________________________________
Prof. Max Suell Dutra, Dr.-Ing.
________________________________________________
Prof. Jules Ghislain Slama, D.Sc.
________________________________________________
Prof. Carlos Alberto Nunes Cosenza, D.Sc.
RIO DE JANEIRO, RJ - BRASIL
AGOSTO DE 2015
iii
Fonseca, Paulo Roberto da Silva
Metodologia para Projetos de Sistemas
Mecatrônicos/ Paulo Roberto da Silva Fonseca. – Rio de
Janeiro: UFRJ/COPPE, 2015.
XV, 109 p.: il.; 29,7 cm.
Orientador: Max Suell Dutra
Dissertação (mestrado) – UFRJ/ COPPE/ Programa
de Engenharia Mecânica, 2015.
Referências Bibliográficas: p. 104-107.
1. Mecatrônica. 2. Projetos Mecatrônicos. 3.
Metodologia. I. Dutra, Max Suell. II. Universidade
Federal do Rio de Janeiro, COPPE, Programa de
Engenharia Mecânica. III. Título.
iv
Dedico essa dissertação aos meus pais pelo apoio incessante de toda a vida,
ao meu avô Orlando pela companhia e pelo afeto quando mais precisei,
aos meus irmãos por me darem suporte e por todo amor,
a minha noiva por todo amor, auxilio e compreensão,
e aos meus amigos pelas palavras encorajadoras.
v
Primeiramente agradeço a Deus pela presença constante e pela ajuda inefável,
guiando-me entre tantos desafios e obstáculos,
provendo-me com a força necessária,
proporcionando meu crescimento e
livrando-me de males da vida;
Agradeço ao Professor Max Suel Dutra por ter me dado essa oportunidade,
pelas palavras motivadoras em momentos difíceis e
por toda paciência dedicada; e
Agradeço a todas pessoas que fizeram parte desse aprendizado,
Muito obrigado!
vi
“Algumas pessoas acham que foco significa dizer sim para a coisa em que
você irá se focar. Mas não é nada disso. Significa dizer não
às centenas de outras boas ideias que existem.
Você precisa selecionar cuidadosamente."
Steve Jobs
“Você podia tirar de mim as minhas fábricas, queimar os meus prédios, mas se
me der o meu pessoal, eu construirei outra vez todos os meus negócios.”
Henry Ford
vii
Resumo da Dissertação apresentada à COPPE/UFRJ como parte dos requisitos
necessários para a obtenção do grau de Mestre em Ciências (M.Sc.)
METODOLOGIA PARA PROJETOS DE SISTEMAS MECATRÔNICOS
Paulo Roberto da Silva Fonseca
Agosto/2015
Orientador: Max Suell Dutra
Programa: Engenharia Mecânica
Essa dissertação apresenta inicialmente conceitos básicos de mecatrônica e
projetos, bem como expõe a importância da utilização de metodologias para
desenvolvimento de projetos de sistemas mecatrônicos e os aspectos metodológicos
utilizados para o seu desenvolvimento. Uma revisão bibliográfica acerca da
mecatrônica trata mais detalhadamente essa área do conhecimento, explicando que
esses sistemas não compreendem somente robôs, cujo objetivo é substituir a mão de
obra humana, mas também sistemas projetados para realizar tarefas tecnicamente
inviáveis para realização humana. Além disso, expõe-se a importância da mecatrônica
frente ao desenvolvimento tecnológico e explica-se a importância de projetos para as
organizações, abordando o Processo de Desenvolvimento de Produtos (PDP).
Posteriormente, projetos de sistemas mecatrônicos são tratados, expondo-se um
conjunto de metodologias e padrões para o desenvolvimento técnico e gerencial
desses projetos. Por fim, uma pesquisa com docentes quanto à participação desses
em projetos de sistemas mecatrônicos é apresentada e explana-se a metodologia
desenvolvida com orientação para organizações de projeto, enfatizando-se as
principais atividades, os processos de decisão e a divisão de responsabilidades.
viii
Abstract of Dissertation presented to COPPE/UFRJ as a partial fulfillment of the
requirements for the degree of Master of Science (M.Sc.)
METHODOLOGY FOR MECHATRONICS SYSTEMS PROJECTS
Paulo Roberto da Silva Fonseca
August/2015
Advisor: Max Suell Dutra
Department: Mechanical Engineering
This dissertation initially presents basic concepts of mechatronics and projects,
as well as exposes the importance of using methodologies for mechatronic systems'
projects and methodological aspects used for their development. A literature review
about the mechatronics approaches more deeply this area of knowledge, explaining
that these systems includes not only robots, which aims to replace human labor, but
also systems designed to perform tasks that are technically impracticable for humans.
In addition, the importance of mechatronics, given the world technological
development, is discussed and the importance of projects for organizations is
explained, covering up the Product Development Process (PDP). Subsequently,
mechatronics systems projects are approached by exposing a set of methodologies
and standards for technical and managerial development of these projects. Finally, a
survey study about professors’ participation on mechatronic systems' projects is
presented and the developed methodology with orientation for projects' organizations is
explained, highlighting the main activities, decisions and the division of responsibilities.
ix
SUMÁRIO
1. INTRODUÇÃO ............................................................................................................. 1
1.1. RELEVÂNCIA DA PESQUISA ................................................................................. 6
1.2. OBJETIVOS DA PESQUISA .................................................................................... 9
1.3. ESTRUTURA DA DISSERTAÇÃO ......................................................................... 10
1.4. CONTEÚDO ENVOLVIDO ..................................................................................... 11
2. REVISÃO TEÓRICA .................................................................................................. 18
2.1. SISTEMAS MECATRÔNICOS ............................................................................... 18
2.1.1. Robótica .......................................................................................................... 20
2.1.2. Importância da Mecatrônica ............................................................................ 23
2.1.3. Outros Aspectos da Mecatrônica ..................................................................... 24
2.2. PROJETOS ............................................................................................................ 26
2.2.1. Programas e Portfólios .................................................................................... 28
2.2.2. Importância dos Projetos ................................................................................. 29
2.2.3. Desenvolvimento de Produtos e Projetos ........................................................ 33
3. ANÁLISE EXPLORATÓRIA ....................................................................................... 38
3.1. PROJETOS DE SISTEMAS MECATRÔNICOS ..................................................... 38
3.1.1. Desafios e Tendências .................................................................................... 38
3.1.2. Boas Práticas .................................................................................................. 41
3.1.3. Metodologia Clássica ...................................................................................... 44
3.1.4. Integração nas Metodologias........................................................................... 45
3.2. MÉTODOS DESCRITOS NA LITERATURA .......................................................... 48
3.2.1. MRM ............................................................................................................... 48
3.2.2. Modelo V ......................................................................................................... 50
3.2.3. Modelo Hierárquico ......................................................................................... 51
3.2.4. Modelo de 3-Ciclos .......................................................................................... 53
x
3.3. PADRÕES E METODOLOGIAS PARA GESTÃO DE PROJETOS ........................ 54
3.3.1. PRINCE2™ ..................................................................................................... 55
3.3.2. Scrum .............................................................................................................. 58
3.3.3. PMBoK ............................................................................................................ 61
3.3.4. ISO 10006 ....................................................................................................... 64
3.4. GERENCIAMENTO DE PROJETOS DE SISTEMAS MECATRÔNICOS ............... 67
4. METODOLOGIA PARA PROJETOS DE SISTEMAS MECATRÔNICOS................... 70
4.1. DIFUSÃO DAS METODOLOGIAS E PRÁTICAS ................................................... 70
4.2. PRINCIPAIS ATIVIDADES E DECISÕES .............................................................. 72
4.2.1. Fase 1 – Captação do Projeto ......................................................................... 73
4.2.2. Fase 2 – Iniciação do Projeto .......................................................................... 78
4.2.3. Fase 3 – Projeto Conceitual ............................................................................ 81
4.2.4. Fase 4 – Projeto Básico .................................................................................. 84
4.2.5. Fase 5 – Projeto Detalhado ............................................................................. 87
4.2.6. Fase 6 – Testes e Validação ........................................................................... 90
4.3. DEFINIÇÃO DOS ENVOLVIDOS E DAS RESPONSABILIDADES ........................ 93
4.4. COMPARAÇÃO COM MODELOS EXISTENTES .................................................. 98
5. CONSIDERAÇÕES FINAIS ..................................................................................... 100
5.1. EXECUÇÃO DOS OBJETIVOS ........................................................................... 100
5.2. CONCLUSÃO ...................................................................................................... 101
5.3. TRABALHOS FUTUROS ..................................................................................... 103
REFERÊNCIAL BIBLIOGRÁFICO .................................................................................... 104
APÊNDICE A..................................................................................................................... 108
APÊNDICE B..................................................................................................................... 109
xi
LISTA DE FIGURAS
Figura 1 – Simplificação de um sistema mecatrônico............................................................. 2
Figura 2 – Matriz FOFA. ........................................................................................................ 3
Figura 3 – Tríplice restrição. .................................................................................................. 5
Figura 4 – Cinco características do ser humano. ................................................................. 18
Figura 5 – Sistema mecatrônico .......................................................................................... 20
Figura 6 – Classificação dos sistemas mecatrônicos por forma de atuação. ........................ 21
Figura 7 – Classificação dos sistemas mecatrônicos por meio em que atuam. .................... 22
Figura 8 – Relação entre projetos, programas e portifólios. ................................................. 28
Figura 9 – Relação de partes interessadas em um projeto. ................................................. 30
Figura 10 – Estruturas organizacionais. ............................................................................... 31
Figura 11 – Estrutura projetizada. ........................................................................................ 32
Figura 12 – Ciclos de vida do produto e do projeto. ............................................................. 35
Figura 13 – Método de Kepner e Tregoe para PDP. ............................................................ 36
Figura 14 – Técnicas para projetar sistemas mecatrônicos. ................................................. 42
Figura 15 – Comparação de metodologias quanto a interação das fases dos projetos. ....... 44
Figura 16 – Integração entre as fases de um projeto. .......................................................... 47
Figura 17 – Resultado do projeto de uma mão robótica. ...................................................... 47
Figura 18 – Fases do desenvolvimento de uma solução. ..................................................... 49
Figura 19 – Modelo V. .......................................................................................................... 51
Figura 20 – Módulo Mecatrônico. ......................................................................................... 52
Figura 21 – Modelo de 3-Ciclos. .......................................................................................... 53
Figura 22 – PRINCE2™. ...................................................................................................... 56
Figura 23 – Papéis, eventos e objetos do Scrum. ................................................................ 59
Figura 24 – Burndown Chart. ............................................................................................... 60
Figura 25 – Áreas de Conhecimento do PMBoK. ................................................................. 62
Figura 26 – Interação de processos de um projeto de sistemas mecatrônicos..................... 68
xii
Figura 27 – Fases da Metodologia. ...................................................................................... 73
Figura 28 – Legenda para os fluxogramas da metodologia. ................................................. 73
Figura 29 – Fluxograma das etapas antecedentes aos projetos. ......................................... 74
Figura 30 – Fluxograma: Captação do projeto. .................................................................... 76
Figura 31 – Fluxograma: Iniciação do projeto. ..................................................................... 79
Figura 32 – Fluxograma: Projeto conceitual. ........................................................................ 83
Figura 33 – Fluxograma: Projeto básico............................................................................... 86
Figura 34 – Fluxograma: Projeto detalhado. ........................................................................ 88
Figura 35 – Fluxograma: Testes e validação. ...................................................................... 91
xiii
LISTA DE QUADROS
Quadro 1 – Revistas para publicações sobre mechatronics pelo índice h5. ......................... 13
Quadro 2 – Processos de gerenciamento de projetos - PMBoK. ......................................... 62
Quadro 3 - Processos de gerenciamento de projetos - ISO 10006. ..................................... 65
Quadro 4 – Formação de envolvidos nos projetos de sistemas mecatrônicos. .................... 72
Quadro 5 – Matriz de responsabilidades para principais atores da metodologia. ................. 93
Quadro 6 – Comparação de Métodos. ................................................................................. 98
xiv
LISTA DE GRÁFICOS
Gráfico 1 – Comparativo entre riscos e custo de mudanças em projetos. .............................. 4
Gráfico 2 – Desafios do desenvolvimento de projetos de sistemas mecatrônicos. ................. 7
Gráfico 3 – Sucesso nos projetos de empresas de engenharia no Brasil. .............................. 8
Gráfico 4 – Empresas de engenharia no Brasil que possuem PMO. ...................................... 9
Gráfico 5 – Resultados para mechatronics design nas últimas décadas. ............................. 12
Gráfico 6 – Distribuição das publicações consultadas ao longo dos anos. ........................... 14
Gráfico 7 – Publicações consultadas de acordo com o portal de consulta ou editora........... 14
Gráfico 8 – Distribuição das publicações consultadas segundo o tema e foco. .................... 15
Gráfico 9 – Publicações consultadas de acordo com tipo e organizadora. ........................... 16
Gráfico 10 – Empresas de engenharia brasileiras por tipo de estrutura funcional. ............... 33
Gráfico 11 – Avanço da alocação de recursos durante fases de um projeto. ....................... 34
Gráfico 12 – Integração entre processos de um projeto. ...................................................... 46
xv
LISTA DE SIGLAS
3D - Três Dimensões
AAF - Análise da Árvore de Falhas
ANSI - American National Standard Institute
CAD - Computer Aided Design
DIP – Documentação de Iniciação do Projeto
FMEA - Failure Mode and Effect Analysis
GAP - Gestão Ágil de Projetos
GL - Graus de Liberdade
IEEE - Instituto de Engenheiros Eletricistas e Eletrônicos
ISO - International Organization for Standardization
MEF – Método dos Elementos Finitos
MRM - Modelo de Referência para o Desenvolvimento de Produtos Mecatrônicos
P – Proporcional
PD – Proporcional Derivativo
PDP - Processo de Desenvolvimento de Produtos
PI – Proporcional Integral
PID – Proporcional integral Derivativo
PMBoK - Project Management Book of Knowledge
PMI - Project Management Institute
PMO - Project Management Office
PRINCE2™ - Project In a Controlled Environment
RCA - Root Cause Analysis
TI - Tecnologia da Informação
VANT - Veículos Aéreos Não Tripulados
1
1. INTRODUÇÃO
O mundo está cada vez mais interconectado. O grande aumento das conexões
entre toda a população mundial, iniciado com a popularização da internet a partir da
década de noventa, deu início a uma nova onda revolucionária para humanidade,
chamada de revolução da informação ou revolução digital. Bem como as revoluções
agrícola e industrial, a digital está modificando a forma de interação do homem com o
ambiente em que vive, tendo como fator principal um progresso severo da tecnosfera.
Entretanto, a principal característica da revolução digital, o que a difere das
passadas, é sua característica integradora no que diz respeito às interfaces homem-
máquina, através da qual se possibilitou redução das distâncias. Além disso, com a
revolução digital a disponibilidade de informações tem aumentado exponencialmente,
de modo que as informações passaram a ser tratadas como matéria prima para
processos.
Bem como ocorreu na revolução industrial, há hoje a facilitação da realização
de tarefas que envolvem muito esforço humano. Entretanto, além dos esforços físicos,
a atual revolução também tem reduzido o envolvimento humano em atividade que
demandam muito esforço psicológico, como atividades muito repetitivas, diminuindo
assim a exposição do homem a atividades de risco a sua saúde. Assim, a tecnologia é
vista como fator facilitador das atividades humanas, estando envolvida em grande
parte das atividades cotidianas das pessoas e tendendo a convergir em sistemas
integrados compartilhados.
O desenvolver dessa onda revolucionária atualmente tende a integrar o mundo
digital com o físico, como apontam alguns especialistas, como o gerente de novas
tecnologias da IBM, Cezar Taurion em seu texto que denomina esse tipo de interação
de “Internet das Coisas”. Segundo Taurion1 a Internet das Coisas adicionará
inteligência à infraestrutura física que molda nossa sociedade, possibilitando que os
objetos físicos, com identidades digitais únicas, comuniquem-se e interajam com
entidades do meio virtual, sejam outros objetos ou pessoas.
No que tange ao trabalho, a necessidade pela integração das informações é
manifesta e grandes empresas já utilizam sistemas integrados de gestão para unificar
os dados de seus subsistemas, gerenciar seus fluxos de informação, e conseguir
1 TAURION, Cezar. A Internet das Coisas. Disponível em: http://www.ibm.com/midmarket/br/pt/pm/internet_coisas.html. Acesso em: 17 ago. 2014.
2
vantagens competitivas. Nesse meio, cada vez mais se valorizam os processos pelos
quais se agrega valor aos insumos. A automação industrial, muito empregada nos dias
atuais, é um exemplo, essa torna possível à produção em massa sem que se
configurem discrepâncias relacionadas à conformidade de seus produtos finais. Além
disso, dados os avanços tecnológicos esperados para as próximas décadas, espera-
se que o nível de automação das indústrias aumente substancialmente nesse período.
Por sua vez, os sistemas mecatrônicos têm papel fundamental nessa revolução
já que representam a união entre mecanismos, eletrônicos e tecnologias da
informação. Um sistema mecatrônico de acordo com autores como Pang et al. (2011),
abrange uma ampla gama de disciplinas técnicas e conhecimentos, sendo altamente
integrado e colaborativo. Um esquema simplificado do funcionamento de um sistema
mecatrônico pode ser visto a seguir na figura 1, podendo-se visualizar a relação
indicada por autores como Buur (1989), Isermann (1996), Barbalho (2006), Paula e
Santos (2008), Roloff, Sá e Bento (2010), Gheorghe et al. (2011), Andreeva e
Topolova (2011) e Chami et al. (2013) entre aspectos mecânicos, eletrônicos e de
Tecnologia da Informação (TI).
Figura 1 – Simplificação de um sistema mecatrônico. Fonte: Adaptado de Isermann et al., 1996.
Assim, grande parte dos objetos interagindo no meio virtual da “Internet das
Coisas” será composta por esses sistemas que farão parte da vida cotidiana da
3
sociedade seja em sua vida pessoal ou profissional. Desse modo, acredita-se que haja
uma demanda crescente e exponencial por novos produtos mecatrônicos nas décadas
que sucedem, sendo primordial que as indústrias estejam atentas a esse novo cenário
e preparadas para lidar com os desafios que estão por vir.
Atualmente o ciclo de vida típico de produção de um sistema mecatrônico, nas
indústrias transformadoras, inicia-se com a determinação das especificações para a
próxima geração de sistemas. Essas especificações são oriundas de atividades
desenvolvidas pelas indústrias para determinar as demandas dos mercados em que
atuam, além de estarem diretamente alinhadas com o planejamento estratégico
dessas. Uma ferramenta comumente empregada para determinação dos objetivos
estratégicos das organizações é a representada na figura 2, a ferramenta que permite
identificação das forças e fraquezas existentes na empresa e os riscos associados às
oportunidades e ameaças para a mesma, denominada matriz FOFA.
Figura 2 – Matriz FOFA. Fonte: Elaborado pelo autor.
Posteriormente a realização da análise de suas forças e fraquezas, associadas
ao planejamento estratégico, e de suas oportunidades e ameaças, associadas aos
dados do mercado, as indústrias reformulam seu planejamento para que esse esteja
em conformidade com o cenário vigente. Dessa forma, novos objetivos são
estabelecidos e com o intuito de atingir esses objetivos empreendem-se esforços que
devem ser planejados, executados e finalizados. Esses esforços, de caráter
temporário, são denominados projetos.
Entretanto, algumas etapas devem ser concluidas entre a identificação dos
novos objetivos e o início de um projeto. Uma dessas atividades é o estudo de
4
viabilidade técnica e econômica do projeto que permitirá a alta administração da
indústria em questão avaliar se o projeto será ou não iniciado, considerando as outras
oportunidades para investimento do capital necessário.
Após a seleção de um projeto para desenvolvimento de um novo sistema
mecatrônico, durante a análise de viabilidade técnica, Pang et al. (2011) destacam que
os requisitos inicialmente gerados para os projetos convertem-se em esforços de
pesquisa que posteriormente serão decompostos em especificações e requisitos
específicos para o sistema. Essa é uma etapa chave, embora conceitual e
imediatamente anteior ao início do projeto, na qual a experiência, a capacidade de
entender os desejos dos interessados - seja o mercado ou a alta admistração da
indústria - e a criatividade dos participantes definirão parte das entradas do escopo do
projeto.
A grande importância que é dada a esta etapa está associada aos riscos e
incertezas naturais ao pouco desenvolvimento desta e aos custos associados a
alterações futuras no escopo do projeto, uma vez que alterações desse tipo podem
mudar completamente o foco dos trabalhos em andamento, tendendo a causar
retrabalho e desperdícios de recursos. O gráfico 1 demonstra como se dá a evolução
dos custos da mudança de escopo em um projeto após seu início, fazendo uma
comparação com o grau de riscos e incertezas associados ao mesmo, desde o início
até o fim do seu ciclo de vida.
Gráfico 1 – Comparativo entre riscos e custo de mudanças em projetos. Fonte: Project Management Institute, 2013.
5
Pode se ter como um exemplo o mencionado por Middendorf et al. (2006) ao
relatar que a maioria das avaliações ambientais e de ciclo de vida de um produto é
feita na fase posterior à de desenvolvimento, dadas às dificuldades de se prever os
impactos ambientais e a confiabilidade na fase conceitual dos projetos, o que dificulta
a realização de ajustes no projeto, uma vez que as limitações existentes de tempo e
orçamento os tornam mais onerosos. Por isso, os autores afirmam que quanto mais
cedo forem detectados riscos ambientais em projetos, maior será a capacidade de
atender as demandas do mercado.
Apesar da comparação entre os custos e riscos de um projeto estabelecida
anteriormente pelo Project Management Institute (PMI), esse mesmo instituto estipula
outras oito áreas de conhecimento a serem consideradas ao se iniciar um projeto,
sendo custo uma das três áreas apontadas como pertencente a tríplice restrição
juntamente as outras duas áreas: escopo e tempo. Essas três áreas, representadas na
figura 3, são consideradas como essenciais a um projeto, seu tratamento como
restrições se deve ao fato de que caso se modifique o que foi inicialmente definido
para uma delas será necessário, também, que se modifique, no mínimo, uma das
outras duas.
Figura 3 – Tríplice restrição. Fonte: Vargas, 2006.
A listagem completa de áreas apontadas pelo PMI contempla: escopo;
stakeholders; custo; tempo; risco; qualidade; pessoas; comunicação; aquisições e;
integração. Portanto, uma gestão integrada de todas as áreas é a recomendada pelo
PMI. Outros autores também defendem a utilização de metodologias integradas, em
contrapartida às tradicionais, individualistas, tidas como inadequadas aos cenários
iterativos da atualidade.
O presente trabalho analisa as propostas de metodologias existentes na
literatura para projetos de sistemas mecatrônicos, comparando-as e apontando as
práticas consideradas como fator de sucesso em cada uma para, em seguida, unifica-
las em uma proposta atual, tendo em vista o atual cenário nacional no que concerne
ao tratamento desses projetos. Espera-se que o trabalho gerado sirva de apoio às
6
indústrias que agregam valor a economia nacional e desenvolvem projetos de
sistemas mecatrônicos de modo a facilitar o atendimento da crescente demanda por
esses.
1.1. RELEVÂNCIA DA PESQUISA
O Brasil é formado por uma complexa rede de subsistemas interligados
constituintes de sua infraestrutura básica. Sabe-se que o desenvolvimento adequado
da infraestrutura de um país é de suma importância para sustentar seu crescimento
econômico. O estudo dos desafios para o desenvolvimento do Brasil, aos quais devem
ser propostas soluções específicas devido às suas características únicas, torna-se
absolutamente complexo para que ocorra de maneira inteligente e próspera. Muitos
desses desafios configuram-se diferentes de acordo com cada região do país, mas de
um modo geral pode-se afirmar que sua infraestrutura apresenta uma oportunidade de
melhoria quando comparada as de outros países desenvolvidos.
Os recentes avanços tecnológicos gerados na revolução digital têm permitido
que se encontrem soluções inovadoras, permitindo uma melhor instrumentação das
infraestruturas. Com isso, o mercado vem demandando a implementação de novas
tecnologias em setores diversos, sendo essas em grande parte sistemas que utilizam
em conjunto sistemas mecânicos, eletrônicos e de informação.
Um exemplo disso está nas redes logísticas do país. Atualmente há demanda
pela rastreabilidade de produtos durante a maior parte de sua cadeia, uma vez que,
principalmente após o advento do e-commerce, os consumidores desejam saber
informações detalhadas do andamento de seus pedidos. O desafio de atender a essa
demanda é grande, pois para que as empresas ofertem esse tipo de serviço elas
precisam ter implantado um sistema logístico integrado e rigorosamente controlado.
Esse tipo de sistema vem sendo melhorado continuamente pelas empresas graças ao
desenvolvimento de equipamentos eletrônicos que quando aplicados aos mecanismos
de transporte de cargas em associação a sistemas de informação permitem o controle
da localização exata dessas cargas.
Os sistemas mecatrônicos têm importante papel no processo de modernização
das empresas, como em projetos de substituição de processos produtivos ineficientes
por sistemas automatizados inteligentes. Além disso, a implantação de empresas de
alta tecnologia em território nacional depende, dentre outros fatores, da disponibilidade
desses sistemas. Outro fator importante, relacionado aos sistemas mecatrônicos, é o
fato desses serem vistos como fundamentais para o aumento do nível de
produtividade e competitividade das pequenas e médias indústrias instaladas no país.
7
A capacidade de desenvolvimento de sistemas mecatrônicos no Brasil depende
da competência dos departamentos de engenharia das indústrias para desenvolverem
esses projetos. Entretanto, os rápidos avanços tecnológicos, proporcionados pelo
compartilhamento global de informações, reduziram drasticamente não só o tempo de
vida dos produtos no que diz respeito a sua obsolescência, como também
configuraram um novo cenário para o projeto dos mesmos no qual veio à tona a
necessidade de redução de prazos dos projetos de novas tecnologias. Por
consequência, essa necessidade se estende aos projetos de sistemas mecatrônicos,
que enfrentam ainda o desafio de integrar, de modo harmônico, três grandes áreas do
conhecimento de modo que as necessidades do mercado sejam supridas.
Sabe-se que qualquer processo de modernização dos meios produtivos
depende principalmente do modo como são projetados. Os projetos de sistemas
mecatrônicos apresentam desafios comuns a qualquer projeto, mas também
particulares devido ao alto nível de integração necessário entre áreas do
conhecimento distintas. Em uma pesquisa realizada por Andreeva e Topalova (2011)
verificaram-se quais são os cinco principais desafios apontados para o
desenvolvimento desses projetos em empresas russas, como pode ser visto no gráfico
2, três dos principais motivos relacionavam-se a integração, enquanto os demais
podem ocorrer em qualquer tipo de projeto.
Gráfico 2 – Desafios do desenvolvimento de projetos de sistemas mecatrônicos. Fonte: Adaptado de Andreeva e Topalova, 2011.
8
Entretanto, com exceção do segundo desafio, ausência de profissionais
especializados, todos os demais desafios apontados na pesquisa de Andreeva e
Topalova (2011) podem ser tratados com a utilização de uma metodologia bem
definida para o gerenciamento e desenvolvimento desses projetos. Além disso, ao se
analisar os resultados obtidos em pesquisa ao site pmsurvey.org2, uma iniciativa do
PMI, com filtro para empresas de engenharia do Brasil, é possível averiguar a
influência da existência de escritórios de gerenciamento de projetos, em inglês Project
Management Office (PMO), na obtenção de sucesso nos projetos desenvolvidos
nessas empresas.
O gráfico 3 demonstra os percentuais de empresas que declararam obter
sucesso em seus projetos em quatro categorias: sempre, na maioria das vezes,
raramente e nunca. É importante notar que as empresas apresentam um retrospecto
positivo, ou seja, obtém sucesso sempre ou na maioria das vezes, representam 57%
do total da amostra.
Gráfico 3 – Sucesso nos projetos de empresas de engenharia no Brasil. Fonte: Adaptado de pmsurvey.org, 2013.
Analisando o gráfico 4 que demonstra a divisão da amostra coletada pelo
pmsurvey.org quanto à presença de PMO nas empresas, nota-se que, igualmente,
57% da mesma possui PMO. Porém, apesar da semelhança dos dados apresentados,
é importante esclarecer que não é possível afirmar categoricamente que a existência
2 Fonte: PMSURVEY.ORG, Project Management Institute Chapters. 2013. Disponível em: http://www.pmsurvey.org. Acesso em: 07 ago. 2014.
9
de um PMO é responsável pelo sucesso dos projetos apenas com os dados em
questão, pois para tal se faz necessária à realização de estudos mais aprofundados.
Gráfico 4 – Empresas de engenharia no Brasil que possuem PMO. Fonte: Adaptado de pmsurvey.org, 2013.
Tendo em vista o exposto, percebe-se que embora a pesquisa indique que
mais da metade das empresas obtém sucesso na maior parte dos projetos que
desenvolvem, observa-se que ainda há um amplo campo para melhorias a ser
explorado. Assim sendo, para cumprir o objetivo desta dissertação, a pretensão desse
trabalho é responder à questão que segue:
Quais são as metodologias existentes na literatura para orientação de
projetos de sistemas mecatrônicos que podem ser adotadas por
organizações de projetos?
1.2. OBJETIVOS DA PESQUISA
Objetivo Geral:
Propor uma metodologia para o desenvolvimento de projetos de sistemas
mecatrônicos aplicável às organizações de projetos.
Objetivos Específicos:
Estudar os principais temas que envolvem o desenvolvimento de
projetos de sistemas mecatrônicos;
Identificar as práticas essenciais para o desenvolvimento de
projetos de sistemas mecatrônicos em organizações de projetos;
10
Pesquisar sobre as metodologias e boas práticas de
desenvolvimento e gerenciamento de projetos cabíveis a
sistemas mecatrônicos propostas pela academia nacional e
internacional; e
Avaliar a capacidade de universidades quanto à disseminação
do conhecimento referente ao desenvolvimento e gerenciamento
desses projetos.
1.3. ESTRUTURA DA DISSERTAÇÃO
Visando atingir o que foi previamente estabelecido como objetivo desse
trabalho, estruturar-se-á o conteúdo textual da dissertação em cinco capítulos:
introdução, revisão teórica, análise exploratória, metodologias para projetos de
sistemas mecatrônicos e considerações finais.
O primeiro desses capítulos, tendo abordado uma contextualização do tema a
ser tratado, apontado os objetivos da dissertação e sua importância perante a
sociedade e a academia, bem como os aspectos metodológicos que serão aplicados,
apresenta nesse subcapítulo a estruturação da dissertação. Logo ao fim do presente
subcapítulo, concluir-se-á esse capítulo com a apresentação do processo para
obtenção do conteúdo utilizado por parte do autor, explanando assim os aspectos
metodológicos envolvidos no desenvolvimento da dissertação e apresentando uma
análise desse conteúdo.
Nos capítulos seguintes, referentes ao desenvolvimento do trabalho, será
abordada a revisão bibliográfica, uma análise exploratória e a metodologia para
projetos de sistemas mecatrônicos desenvolvida. Sendo assim, o capítulo referente à
revisão teórica realizada é o segundo capítulo dessa dissertação e aborda sistemas
mecatrônicos, explicando a diferença entre robótica e mecatrônica, apontando a
importância desses sistemas para o avanço tecnológico da humanidade, entre outros
aspectos.
O terceiro capítulo, denominado análise exploratória, apresenta uma análise
envolvendo as principais temáticas dessa dissertação, contando com quatro
subcapítulos, sendo estes: projetos de sistemas mecatrônicos, que envolve os
desafios e tendências desses projetos, boas práticas, um breve relato sobre a
metodologia clássica, e a integração em metodologias; métodos descritos na literatura,
apontando os quatro principais métodos encontrados; padrões e metodologias para
gestão de projetos, abordando as metodologias Project In a Controlled Environment
(PRINCE2™) e Scrum, além do padrão Project Management Book of Knowledge
11
(PMBoK) e do definido pela International Organization for Standardization (ISO), ISO
10006; e um breve subcapítulo especificamente sobre gerenciamento de projetos de
sistemas mecatrônicos.
No capítulo 4 apresenta-se uma pesquisa realizada junto a docentes de
diversos cursos de engenharia de uma renomada universidade para averiguar a
experiência desses com projetos e sistemas mecatrônicos, e, por consequência,
proporcionar a realização de inferências acerca da transferência de know-how para
profissionais recém-formados. Além disso, expõe-se nesse capítulo a metodologia
para projetos de sistemas mecatrônicos desenvolvida como resultado dos esforços de
pesquisa dessa dissertação, tratando das principais atividades e dos processos de
tomada de decisão da metodologia. Na sequência, trata-se especificamente da divisão
de responsabilidades da metodologia, desde a captação do projeto até o fim de seu
desenvolvimento. No subcapítulo final é realizada uma comparação entre a
metodologia proposta nessa dissertação e as demais presentes na literatura.
Em um último capítulo, considerações finais, realiza-se a discussão de todo
conteúdo apresentado até então, em contraponto com o que se definiu como sendo os
objetivos dessa dissertação, apresentado no subcapítulo anterior. São, ainda,
considerados possíveis trabalhos futuros para aprimoramento do que foi desenvolvido
para que se colabore com o avanço da área em questão. E, por fim, apresentam-se as
conclusões do autor, tendo em vista o que foi estudado e pesquisado durante o
desenrolar da dissertação.
1.4. CONTEÚDO ENVOLVIDO
Esse capítulo destina-se a esclarecer os métodos a serem seguidos nesta
dissertação para proporcionar o cumprimento dos objetivos estabelecidos
previamente. Para cada objetivo específico um grupo de atividades distintas devem
ser realizadas vizando a obtenção do resultado desejado.
A fim de pesquisar as metodologias já propostas pela academia nacional e
internacional, fez-se necessária a realização de buscas por conteúdo em livros,
normas, teses, dissertações, monografias e artigos que tratassem do tema. Para tal,
selecionou-se a ferramenta Google Acadêmico que reúne informações sobre
lançamentos nacionais e internacionais do que é publicado pelo meio científico e
direciona os usuários às páginas em que se podem encontrar os documentos.
Baseado na pesquisa, o gráfico 5 apresenta o percentual encontrado nessa
plataforma de buscas para o termo mechatronics design nas últimas décadas. Nesse
comparativo observa-se que o crescimento de publicações envolvendo o tema vem
12
aumentando década após década, com perspectiva de crescimento contínuo. Apenas
as publicações mais recentes, encontradas do início de 2010 até meados de 2015, já
correspondem a 37% do total de publicações encontradas desde 1980, havendo assim
uma tendência de que até 2019 esse percentual supere o encontrado para a década
anterior.
Gráfico 5 – Resultados para mechatronics design nas últimas décadas. Fonte: Elaborado pelo autor.
Para avaliar a influência dos vários artigos recentes relacionados ao termo
mechatronics em publicações acadêmicas, foi utilizada a ferramenta Google Scholar
Metrics3. Essa ferramenta realiza uma contagem de citações recentes de publicações
relacionadas a um determinado tema e classifica os periódicos de acordo com a sua
relevância, através do índice de Hirsch4, usando apenas os artigos publicados nos
últimos 5 anos completos recentes, sendo então denominado índice h5. Dessa forma,
as buscas realizadas no desenvolvimento de um trabalho acadêmico podem ser
direcionadas para os periódicos mais relevantes dentro da área de pesquisa. O quadro
1 mostra o resultado encontrado para a consulta realizada de acordo com o exposto a
cima.
3 A ferramenta considera somente os artigos postados em sites que seguem uma política de inclusão proposta pelo Google e alguns outros artigos dispersos que sejam indexáveis. Disponível em: http://scholar.google.com/citations?hl=pt-BR&view_op=search_venues&vq=mechatronics. Acesso em: 08 jul. 2014. 4 O uso do índice pelo Google Scholar Metrics é feito atribuindo-se aos periódicos um número h considerando o maior número h de artigos em um periódico que foram citados no mínimo h vezes. Esse mesmo índice pode também ser usado para avaliar a qualidade da produção de pesquisadores.
37%
48%
14%
1%
2010 - 2015 (15/mai)
2000 - 2009
1990 - 1999
1980 - 1989
13
Quadro 1 – Revistas para publicações sobre mechatronics pelo índice h5.
Posição Publicação Índice
h5
1 IEEE/ASME Transactions on Mechatronics 40
2 Mechatronics 30
3 IEEE/ASME International Conference on Advanced Intelligent
Mechatronics 15
4 IEEE International Conference on Mechatronics 14
5 International Conference on Measuring Technology and
Mechatronics Automation 14
6 International Conference on Mechatronics and Automation 14
7 IEEE Conference on Robotics, Automation and Mechatronics 11
8 Journal of Robotics and Mechatronics 11
9 International Conference on Industrial Mechatronics and
Automation (ICIMA) 9
10 International Journal of Advanced Mechatronic Systems 8
Fonte: Google Scholar Metrics, 2014.
Na lista dos dez periódicos mais influentes, presentes no quadro, quatro são
organizados pelo Instituto de Engenheiros Eletricistas e Eletrônicos (IEEE), estando
três destes entre os quatro primeiros dessa listagem. Tendo em vista a importância
das publicações realizadas por esses periódicos, optou-se por concentrar as buscas
por artigos no portal IEEE Xplore5. Além disso, nota-se que as publicações
organizadas pela IEEE/ASME e as da revista Mechatronics, publicada pela Elsevier
são, individualmente as três melhores classificadas pelo ranking.
Dentre as várias publicações encontradas no Google Acadêmico e no IEEE
Xplore, bem como livros, teses, dissertações e normas apontados como altamente
relevantes, 27 referências foram selecionadas, para servir como base para o
desenvolvimento da disertação, sendo outras 14 adicionadas posteriormente para
compor o referncial teórico dessa dissertação. A distribuição ao longo dos anos das 41
referências utilizadas nesse trabalho pode ser vislumbrada no gráfico 6.
5 Esse portal pode ser acessado através do link: http://ieeexplore.ieee.org/Xplore/home.jsp.
14
Gráfico 6 – Distribuição das publicações consultadas ao longo dos anos. Fonte: Elaborado pelo autor.
O gráfico 7 proporciona a avaliação das publicações selecionadas de acordo
com o responsável por sua publicação, seja esse um portal ou uma editora. Uma
análise desse gráfico permite que se note a importância do portal do IEEE no tema da
busca por publicações, pois das vinte e cinco publicações selecionadas, dez foram
encontradas atráves desse portal. Sendo o portal da Elsevier, responsável pela
publicação da revista Mechatronics, o segundo com mais publicações utilizadas,
juntamente com a editora Springer. Fato que em associação ao exposto no quadro 1
valoriza ainda mais as referências utilizadas nessa dissertação.
Gráfico 7 – Publicações consultadas de acordo com o portal de consulta ou editora. Fonte: Elaborado pelo autor.
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
10
11
15
Embora o primeiro classificado na listagem seja o Google Acadêmico, é
importante ressaltar que todas as publicações selecionadas, com exceção dos livros,
podem ser encontradas por meio dessa ferramenta de busca. Porém, para realização
da comparação, utilizou-se os portais nos quais as publicações encontram-se
hospedadas. Pelo fato de algumas das publicações ficarem indexadas fora de um
portal, para facilitar a visualização gráfica da distribuição dessas, prefiriu-se então
consolida-las em um grupo denominado Google Acadêmico.
Estratificando o conjunto de publicações de acordo com seu tema e foco
principal elaborou-se o gráfico 8. Neste, as barras estão classificadas primariamente
de acordo com o tema das publicações e secundariamente de acordo com o foco
notado por esse autor. Para facilitar a visualização dos dados mais relevantes, apenas
os focos que se repetem são apresentados nesse gráfico, tendo sido filtrados os
demais. Então, observa-se que prevalecem as publicações sobre projetos de sistemas
mecatrônicos com foco em metodologia, além de Outros, grupo que compreende focos
encontrados apenas em uma referência. O tema projetos, de um modo geral, com
enfoque em gerenciamento também constitui boa parte das referências.
Gráfico 8 – Distribuição das publicações consultadas segundo o tema e foco. Fonte: Elaborado pelo autor.
0
1
2
3
4
5
6
7
8
9
Metodologia Gerenciamento
Geral Desenvolvimento de Produto
Tomada de Decisão Outros
16
Em uma última estratificação, o gráfico 9 demonstra como se deu a divisão das
publicações utilizadas quanto ao seu tipo: artigo, livro e tese. Além disso, de modo
auxiliar essas foram separadas de acordo com as instituições organizadoras ou
eventos na qual foram expostas. Comparando as origens das publicações, é nítida a
maior quantidade originária do periódico IEEE/ASME Transactions on Mechatronics,
representado abaixo como IEEE/ASME.
Gráfico 9 – Publicações consultadas de acordo com tipo e organizadora. Fonte: Elaborado pelo autor.
O grupo Outros referente aos organizadores, que se destaca dentre os demais,
representa aqueles aos quais apenas um artigo foi utilizado, tendo sido criado para
melhorar a visualização gráfica das informações, reduzindo a quantidade de itens
presentes no eixo horizontal desse gráfico.
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Artigo Livro Tese
Dissertação Monografia Norma
17
O estudo das várias publicações selecionadas possibilitou a identificação e
análise das práticas associadas às metodologias encontradas, sendo fundamental
para composição da metodologia apresentada nessa dissertação.
18
2. REVISÃO TEÓRICA
Esse capítulo apresenta o conteúdo básico necessário para o entendimento
dos assuntos tratados nessa dissertação. Para tal, esse está estruturado em dois
subcapítulos, como pode ser visto a seguir: sistemas mecatrônicos e projetos.
2.1. SISTEMAS MECATRÔNICOS
Grande parte das novas conquistas que vem surgindo na indústria no que se
refere ao aumento da capacidade produtiva foi conseguida por meio do
desenvolvimento de soluções tecnológicas. Essas soluções compõem-se de
conhecimentos em mecânica e eletrônica, integrados por meio da TI, capaz de unir os
sistemas eletromecânicos e a inteligência humana. Para Shetty e Kolk (2011), uma
importante característica de sistemas mecatrônicos é sua inteligência intrínseca.
A integração entre essas três áreas do conhecimento forma uma quarta,
denominada mecatrônica. Os primeiros estudos sobre a mecatrônica foram realizados
na década de 80, sendo a maior parte das aplicações subsequentes realizadas pela
indústria japonesa. Buur (1989), bem como Siciliano et al. (2009), mencionam em seu
livro uma comparação entre sistemas mecatrônicos e seres humanos, demonstrada na
figura 4.
Figura 4 – Cinco características do ser humano. Fonte: Adaptado de Kajitani (1986 apud BUUR, 1989).
Na figura 4, à esquerda, analisa-se o ser humano como um sistema composto
de cinco partes distintas, com o propósito de estabelecer uma comparação com os
sistemas mecatrônicos, representados à direita por uma composição semelhante.
Nessa análise são considerados: as fontes que geram energia para os sistemas; os
meios físicos utilizados para interação com o meio; as estruturas responsáveis pela
19
sustentação física; os meios de captar informações do ambiente; e o sistema capaz de
processar informações e unir todos os demais elementos. As partes similares estão
igualmente posicionadas e coloridas para provocar a comparação.
Quanto ao sistema de controle presente em sistemas mecatrônicos e
comparado com o cérebro humano, Dorf e Bishop (2001 apud BARBALHO, 2006)
explicam que esses interconectam componentes, formando uma configuração de
sistemas que produzirá uma resposta desejada. Eles explicam ainda que as entradas
dos sistemas são convertidas em sinais e processados por um componente que gera
um sinal de saída variável, normalmente amplificado. Além disso, esses autores
classificam esses sistemas em dois, um de malha aberta e outro de malha fechada.
Os sistemas de controle de malha aberta utilizam um dispositivo de atuação para
controlar diretamente um processo. Já um sistema de malha fechada, além de possuir
um dispositivo de atuação, conta com sensores para identificar a eficácia da ação
realizada e faz uso da retroação, sendo capaz de atuar continuamente para manter o
resultado desejado.
Entretanto, considerando todos os aspectos mencionados na comparação
anterior, é importante que se note que esses sistemas não necessariamente são
modelados para parecer com seres humanos, embora isso ocorra no projeto de robôs
humanoides. Há sistemas mecatrônicos inspirados em outros tipos de vida, como há
aqueles que foram desenvolvidos pura e simplesmente para realizar uma determinada
função, sem que se tenha dado tanta importância a aspectos de aparência física.
Tratando de sistemas mecatrônicos projetados especificamente para realizar
funções, Li, Zhang e Chen (2001) explanam que o comportamento desses sistemas,
não se baseia somente na concepção de seus algoritmos de controle, dependendo
também da concepção de suas estruturas mecânicas.
Portanto, os sistemas mecatrônicos podem ser projetados para que se
comportem de diferentes maneiras, dependendo de sua finalidade. Desse modo, a
quantidade de requisitos básicos solicitados para os novos sistemas têm crescido
rapidamente, tornando cada vez mais complexo o processo de integração entre as
áreas.
É importante reconhecer que cada uma das áreas, quando tratadas
individualmente já apresentam certa complexidade em sua composição. Levy,
Lengerke e Dutra (2011) apontam com maior detalhamento os componentes de um
sistema mecatrônico, citando atuadores, sensores, módulos de aquisição de dados,
indicadores, monitores, gravadores e fontes de energia.
A figura 5 apresenta uma simplificação de como se dá o funcionamento
integrado entre mecânica, eletrônica e TI em um sistema mecatrônico para a
20
realização de uma tarefa, considerando-se o fluxo de informações, energia e o
controle. Essa figura mostra ainda todas as entradas e saídas desses sistemas, sejam
essas desejadas ou não, como é o caso dos distúrbios e desperdícios.
Figura 5 – Sistema mecatrônico Fonte: Adaptado de Kajitani (1986 apud BUUR, 1989).
Além da divisão em componentes e áreas da ciência, a mecatrônica pode ser
subdividida de outras maneiras. Em uma dessas divisões, apresenta-se dentre os
sistemas mecatrônicos, um tipo em especial que é comumente tratado pela população
geral, sendo alvo constante de filmes de ficção científica, os robôs.
2.1.1. Robótica
Durante a revolução industrial, a automação visava substituir o ser humano nas
tarefas laborais. Por seu significado usual, automação é, então, a síntese de
tecnologias industriais típicas do processo de fabricação e tecnologias de computação
que permitem o gerenciamento de informações. Avanços na automação deram origem
à robótica, essa compreende sistemas mecatrônicos capazes de substituir os seres
humanos na execução de uma tarefa, podendo ser tanto uma atividade física, quanto
uma tomada de decisão. (SICILIANO et al., 2009)
A robótica, segundo Siciliano et al. (2009), é comumente definida como a
ciência que estuda a conexão inteligente entre percepção e ação. Com referência a
21
esta definição, um sistema robótico é, na realidade, um sistema complexo,
funcionalmente representado por múltiplos subsistemas.
Assim como nos demais sistemas mecatrônicos, nos robôs a capacidade de
exercer uma ação, tanto locomoção quanto manipulação, é assegurada por um
sistema de acionamento que excita os componentes mecânicos do robô, atuadores
que envolvem servomotores, acionamentos e transmissões. Da mesma forma, a
capacidade de percepção é confiada a um sistema sensorial que pode adquirir dados
sobre o estado interno do sistema mecânico e da situação do ambiente externo. De
modo que a capacidade de conectar inteligentemente a percepção e a ação é
fornecida por um sistema de controle capaz de comandar a execução da ação em
relação ao estabelecido, bem como das restrições impostas pelo robô e ambiente.
(SICILIANO et al., 2009)
Siciliano et al. (2009) consideram, ainda, o sistema mecânico como o
componente essencial de um robô, sendo esse, de um modo geral, dotado de um
aparelho de locomoção, ou base fixa, e um aparelho de manipulação. Dessa maneira,
quanto a sua estrutura mecânica, os robôs podem ser classificados como robô
manipulador, os que possuem base fixa, e robôs móveis, aqueles capazes de se
locomover utilizando apenas seus dispositivos integrados.
Na figura 6 pode-se observar como esses sistemas são classificados quanto a
sua forma de atuação, havendo sistemas fixos, mais comumente encontrados nas
indústrias, e móveis.
Figura 6 – Classificação dos sistemas mecatrônicos por forma de atuação. Fonte: Adaptado de Siciliano et al., 2009.
Com relação aos sistemas fixos, de acordo com Siciliano et al. (2009), a
estrutura mecânica de um robô manipulador, consiste de uma sequência de corpos
rígidos, denominados elos, interligados por articulações, chamadas de juntas. Um
manipulador é caracterizado por um braço que assegura a mobilidade, um pulso que
22
confere destreza, e uma extremidade atuante, conhecida como atuador, que realiza a
tarefa exigida do robô.
A estrutura fundamental de um manipulador é a cadeia cinemática de série ou
aberto. De um ponto de vista topológico, a cadeia cinemática é denominada aberta
quando existe apenas uma sequência de ligações entre suas duas extremidades.
Alternativamente, uma cadeia cinemática fechada é uma sequência de ligações que
formam um circuito. (SICILIANO et al,. 2009)
Dentre os sistemas móveis acima mencionados, os mais empregados são os
que se locomovem por meio de rodas, uma vez que os demais costumam apresentar
maiores desafios aos projetistas. Entretanto, recentemente, os sistemas
propulsionados vêm ganhando espaço no mercado para atuação em ambientes nos
quais os movidos por rodas são inviáveis ou pouco práticos, sendo o caso de muitos
sistemas aquáticos e aéreos.
Os sistemas mecatrônicos podem ser também classificados de acordo com o
meio onde atuam, sendo esses os que se demonstram na figura 7.
Figura 7 – Classificação dos sistemas mecatrônicos por meio em que atuam. Fonte: Autor.
Conforme pode ser visto na figura 7, são cinco os tipos de ambiente onde
podem atuar os sistemas mecatrônicos. Desses, uma conquista mais recente diz
respeito ao ambiente aéreo que apresenta um “boom” de aplicações com o
desenvolvimento dos Veículos Aéreos Não Tripulados (VANT), em sigla inglesa UAV e
mundialmente conhecidos como drones.
O “boom” mencionado para os VANTs relaciona-se com o advento da
revolução digital, pois com esse não só as indústrias passaram a apresentar demanda
por produtos de alta tecnologia, como a população também o fez. Desse modo, o
desenvolvimento tecnológico dos sistemas mecatrônicos foi beneficiado. Mas, por
outro lado, novos desafios têm surgido, pois esses clientes têm se mostrado mais
exigentes quanto às funcionalidades e interfaces dos sistemas.
23
2.1.2. Importância da Mecatrônica
Para Shetty e Kolk (2011) o sucesso da mecatrônica pode levar produtos
extremamente atraentes para o consumidor em termos de qualidade e rentabilidade.
Isso se dá graças à capacidade desses sistemas, altamente integrativos, de oferecer
diversas soluções aos problemas cotidianos das pessoas. Esses sistemas podem
tanto substituir o homem em tarefas que exigem esforço físico, como também realizar
tarefas as quais o homem não é capaz.
Com relação aos requisitos ergonômicos, Horikawa et al. (2002) apontam o
estudo da integração entre operadores humanos e robôs em sistemas de trabalho
como vital. Pois, exceto em algumas fábricas totalmente automatizadas, operadores
sempre interagem com robôs em atividades como:
Monitoramento dos sistemas;
Intervenção para inicialização, reconfiguração, manutenção, etc.;
Supervisão, gerenciamento e planejamento;
Inspeção para controle de qualidade; e
Trabalhos em sinergia como em montagem ou controle supervisório de
robôs.
A utilização dos sistemas de produção enxuta, segundo Shetty e Kolk (2011),
criou uma demanda por sistemas autônomos inteligentes de inspeção, fabricação e
tomadas de decisão que executem testes sem intervenção humana direta, como é o
caso da atividade de monitoramento.
Shetty e Kolk (2011) definem o monitoramento como a determinação do estado
ou das condições de sistemas e suas mudanças com o tempo. O monitoramento e
análise das condições de uma máquina constituem uma ferramenta valiosa para
estabelecer um cronograma de manutenção. O monitoramento da qualidade fornece
às plantas industriais a capacidade de tomar ações corretivas rápidas na origem de
seus problemas. Em continuação as afirmações prévias, eles citam que outro nível de
garantia de qualidade se dá através de monitoramento on-line da qualidade,
complementando um projeto robusto e métodos de controle estatístico.
Sistemas de monitoramento mecatrônicos têm sido aplicados em várias
indústrias, como de aviação, automotiva, médica, de bens de consumo, aeroespacial e
sistemas de produção industrial, entre outras. Estes sistemas são projetados para
medir parâmetros da planta, estados de plantas, e estados de produção. (SHETTY;
KOLK, 2011)
24
A tendência em mecatrônica é aperfeiçoar os processos de produção global, do
projeto do produto à inspeção da fabricação, ao integrar todas as informações em um
banco de dados comum, citam Shetty e Kolk (2011). Assim, informações de vários
sensores relacionados ao processo podem ser integradas para melhorar a
confiabilidade e a qualidade dos dados do sensor. Esta informação comum pode ser
usada, por exemplo, na seleção de melhores processos de usinagem, ferramentas e
operações de acabamento.
Shetty e Kolk (2011) afirmam que o sistema global envolvido na combinação do
controle automático de desgaste das ferramentas e da inspeção de qualidade, ajuda a
garantir que os processos de produção atinjam a eficiência e que os produtos tenham
maior qualidade. Segundo eles, isto acaba por reduzir o custo total de produção,
aumentando as possibilidades de obtenção de maiores margens de lucro.
2.1.3. Outros Aspectos da Mecatrônica
Em seu trabalho Ghanghi et al. (2011) trata da importância da mecatrônica em
associação com a nanotecnologia para o desenvolvimento tecnológico. Tendo em
vista o enorme potencial do mercado doméstico para os sistemas mecatrônicos
apontados por Prassler e Kosuge (2008), cerca de centenas de milhões de clientes, o
campo está se desenvolvendo de maneira bastante dinâmica. Sendo comum que
novos produtos e novas empresas surjam e desapareçam com bastante frequência.
Um produto industrial é, de acordo com Roloff, Sá e Bento (2010), um artefato
desenvolvido por projetistas para satisfazer necessidades humanas, ou seja, as
pessoas compram o que atenderá a alguma de suas necessidades, sendo que quanto
maior o número de pessoas que tiverem a mesma necessidade, maior será o mercado
para o produto em questão.
Vale notar que nem sempre uma necessidade é nítida aos consumidores, ela
pode estar sendo parcialmente atendida, ou mascarada com o uso de mais de um
produto, como era o caso anterior ao surgimento dos smartphones. Nesses casos o
mercado não oferta produtos adequados ao seu suprimento da necessidade
específica, identifica uma demanda latente, ou atende-o parcialmente, havendo uma
oportunidade de melhoria, ou seja, espaço para uma inovação. Quando há demanda
latente por um produto e essa é restrita a um determinado grupo de indivíduos, isso
caracteriza um nicho de mercado. Sistemas mecatrônicos podem surgir para
responder a necessidades de alguns desses nichos.
Horikawa et al. (2002) declaram que os sistemas mecatrônicos forçam a
reavaliação do processo produtivo por poderem substituir a mão de obra humana, e
25
proporcionarem as indústrias certa flexibilidade para atender aos picos de demanda do
mercado, por serem reprogramáveis, o que também possibilita a extensão de sua vida
útil dentro do sistema de produção.
De maneira geral, o tempo de implantação desses sistemas deverá ser o
menor possível, uma vez que novos produtos requerem novos requisitos em relação à
automação e esses vêm aparecendo cada vez mais rápido no mercado. (MOORE et
al., 2003 apud PAULA; SANTOS, 2008)
Para Horikawa et al. (2002) a seleção do sistema mecatrônico certo para uma
aplicação específica vem se tornando mais difícil a cada momento devido à grande
variedade de equipamentos existentes nesta área. Além disso, sem experiência
anterior na área, é difícil para os projetistas escolherem e avaliarem os aspectos
relevantes a serem levados em conta na longa lista de dados que acompanham as
especificações de cada sistema mecatrônico. Para facilitar, Horikawa et al. (2002),
Naveiro (2002) e Siciliano et al. (2009) destacam alguns parâmetros a serem levados
em conta durante o projeto de um sistema mecatrônico:
Espaço de Trabalho - O espaço de trabalho representa a parte do
ambiente atingível pelo atuador do manipulador. A forma e volume
desse espaço dependem da estrutura do manipulador e das suas
limitações mecânicas.
Repetibilidade – Capacidade de realizar a repetição das mesmas
operações com o atuador, retornando sempre ao ponto desejado dentro
de uma faixa de tolerância;
Grau de Liberdade - Os Graus de Liberdade (GL), devem ser
adequadamente distribuídos ao longo da estrutura mecânica, a fim de
ter um número suficiente para executar uma dada tarefa. No caso mais
geral de uma tarefa que consiste em posicionar um objeto em Três
Dimensões (3D) do espaço, são necessários seis GLs, três para o
posicionamento e três para orientação. Se houver mais GLs do que
variáveis de tarefas, o manipulador é chamado de redundante;
Atuador - A seleção do atuador deve estar de acordo com a tarefa a ser
realizada;
Sensores - A qualidade de um sistema depende muito dos sensores
que são utilizados;
Velocidade de Trabalho - A velocidade de trabalho deve ser planejada
considerando a taxa de produção requerida e outras restrições quanto à
integração com outros subsistemas;
26
Precisão - Especificação da resolução de posicionamento, trajetória e
força;
Carga - Especificação da carga máxima suportada pela estrutura,
considerando as diversas velocidades de trabalho e amplitudes de
movimento;
Programação - Especificação dos métodos de programação
necessários;
Interface - Especificação dos requisitos de interface com outras
máquinas, pessoas, atividades, redes, etc;
Custo - Especificação do custo máximo aceitável incluindo instalação,
treinamento, manutenção e sucateamento;
Fatores Ambientais - Especificação dos requisitos do ambiente, como
temperatura, limpeza, etc.
Segurança e confiabilidade - Especificação dos requisitos necessários
para garantir determinados níveis de segurança e confiabilidade;
Treinamento - Especificação do treinamento necessário para operação
e manutenção do sistema; e
Infraestrutura - Tipo de linhas de energia elétrica, rede pneumática,
base de montagem, etc. necessários para a operação robotizada.
Além desses princípios gerais para projetos desses sistemas, Nogueira e
Lepikson (2006) afirmam que existem regras específicas de projeto que conduzem a
um melhor produto final.
2.2. PROJETOS
Projetar, para Budynas e Nisbett (2011) é formular um plano para satisfazer
uma necessidade específica ou para resolver um problema.
Define-se um projeto como: “Processo único, consistindo de um grupo de
atividades coordenadas e controladas com datas para início e término, empreendido
para alcance de um objetivo conforme requisitos específicos, incluindo limitações de
tempo, custo e recursos.” Entendendo-se como processo “um conjunto de recursos e
atividades inter-relacionadas que transformam insumos em resultados”.
(ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS, 2000, p. 2)
Hedeman, van Heemst e Fredriksz (2007) descrevem um projeto como sendo
um ambiente de gestão temporária criado com o propósito de entregar um ou mais
produtos de acordo com uma circunstância empresarial especifica.
27
De acordo com o Project Management Institute (2013, p. 3), “projeto é um
esforço temporário empreendido para criar um produto, serviço ou resultado
exclusivo”. Ainda segundo o Project Management Institute (2013), a natureza
temporária de um projeto se dá pelo fato de ter início e término definidos, podendo um
projeto ser encerrado com o cumprimento dos objetivos, por seus objetivos não serem
mais alcançáveis, ou por desejo do cliente.
A exclusividade mencionada na definição do Project Management Institute
(2013) se deve ao fato de cada projeto apresentar um conjunto de fatores distintos
com poder de influência que varia de projeto para projeto, mesmo em projetos de
natureza similares. Um desses fatores, conforme aponta o Project Management
Institute (2013), é o nível de experiência dos membros da equipe de projetos nas
atividades a serem realizadas, o que pode exigir um planejamento mais dedicado para
que o resultado final do projeto não seja comprometido. Se esse resultado consistir na
criação de algo físico, então será gerado através do projeto um produto que segundo
Budynas e Nisbett (2011) deverá ser funcional, seguro, confiável, competitivo,
utilizável, fabricável e comercializável.
Porém, esse resultado, embora seja muitas vezes tratado como tal, não
necessariamente será um produto, podendo ser um serviço, ou outra coisa intangível,
como a melhoria da produtividade de uma indústria. Além disso, ocorrem projetos nos
vários níveis hierárquicos de uma organização, podendo envolver uma única pessoa
ou muitas pessoas, uma única organização ou diversas unidades de negócios de
organizações distintas. (PROJECT MANAGEMENT INSTITUTE, 2013)
Considerando a natureza dos projetos, Vargas (2006) aborda os desafios
inerentes a um projeto, dada a complexidade intrínseca ou o curto prazo ou o baixo
orçamento, concluindo que qualquer projeto requer níveis de gerenciamento e controle
não usuais. Assim, a Associação Brasileira de Normas Técnicas (2000) relata que em
alguns casos, os objetivos de um projeto e as características do produto são
aperfeiçoados e definidos progressivamente, conforme se dá o desenvolvimento do
projeto.
Um conjunto de conhecimentos amplamente reconhecidos como boas práticas
para gerenciamento de projetos é encontrado no Guia PMBoK do Project Management
Institute (2013). Existe um consenso em relação ao valor e a utilidade desse guia, pois
as práticas descritas nele auxiliaram gerentes de projetos passados a obter sucesso.
O que para Hedeman, van Heemst e Fredriksz (2007), ocorre em um projeto se todos
os interessados ficam satisfeitos com seu resultado.
Entretanto, o Project Management Institute (2013) destaca que cabe a cada
organização e equipe de projetos, caso haja uma, determinar quais práticas serão
28
utilizadas em seu portfólio de projetos, definindo-se, então, uma metodologia a ser
seguida em cada projeto. Ainda assim, admite-se que haja variações dentre as
práticas utilizadas para os projetos de um mesmo portfólio, dada a característica de
exclusividade desses.
2.2.1. Programas e Portfólios
Define-se um portfólio como um conjunto de projetos, subprogramas,
programas, subportfólios e operações gerenciados conjuntamente para se atingir
objetivos estratégicos definidos. Os projetos individuais, dentro ou fora de um
programa, são considerados parte de um portfólio. Nesse portfólio, os projetos e
programas, mesmo sendo independentes, estão ligados ao plano estratégico da
organização. (PROJECT MANAGEMENT INSTITUTE, 2013)
A relação descrita entre portfólio, programa e projeto pode ser melhor
apreciada na figura 8.
Figura 8 – Relação entre projetos, programas e portifólios. Fonte: Adaptado de Project Management Institute, 2013.
Portfólios, programas e projetos individuais são vinculados e possuem relações
diretas com as estratégias e prioridades organizacionais, define o Project Management
Institute (2013). Assim, o planejamento organizacional impacta diretamente nos
29
projetos através de priorização baseada em fatores como riscos, custos e outros
igualmente relevantes.
Ainda de acordo com o Project Management Institute (2013), as organizações
gerenciam os portfólios com base em seu plano estratégico, com intuito de maximizar
seu valor através de exame cuidadoso dos programas e projetos integrantes. Desse
modo, componentes com baixa contribuição para os objetivos estratégicos podem ser
excluídos, tornando assim o plano estratégico de uma organização o fator principal de
orientação para investimentos em projetos. Ao mesmo tempo, as necessidades de
recursos dos projetos e programas são reunidas e comunicadas ao nível do portfólio,
auxiliando na determinação e orientação do planejamento organizacional.
A Associação Brasileira de Normas Técnicas (2000) destaca a necessidade de,
também, os projetos estarem alinhados com a estratégia organizacional. Para
Stanleigh (2003) somente os projetos estrategicamente alinhados com a organização
serão tratados com alta prioridade. Portanto, projetos que não estiverem ligados à
estratégia organizacional correm risco de falhar, por serem colocados no final da lista
de prioridades da organização.
2.2.2. Importância dos Projetos
O crescimento, bem como a sobrevivência de qualquer organização está
diretamente atrelada aos seus projetos. Esses traduzem ações organizacionais
visando modificar o posicionamento atual da organização com relação ao mercado e
seus concorrentes, agregando valor e conhecimento através da melhoria de
processos, criação de produtos e desenvolvimento de serviços.
Paula e Santos (2008) relatam que com a globalização e consequente
crescimento da competitividade empresarial, as empresas estão sendo forçadas a
reduzir o tempo entre lançamentos de novos produtos, além de reduzir seus custos
para oferecer preços mais competitivos. Os autores apontam ainda, alguns dos
principais desafios atualmente encarados pelas empresas como as flutuações de
demanda, o curto ciclo de vida dos produtos, a frequente introdução de novas
demandas e o crescimento das expectativas dos clientes. Para superarem tais
desafios e permanecerem competitivas no mercado é preciso que essas empresas
tenham claros seus objetivos e planejem suas estratégias.
No contexto de um plano estratégico, o Project Management Institute (2013) dá
ênfase ao fato de os projetos representarem uma forma de se alcançar as metas e os
objetivos organizacionais, mencionando que a autorização para realização desses,
30
normalmente, se dá como resultado de uma ou mais das considerações estratégicas
listadas a baixo:
Demanda de mercado;
Oportunidade/necessidade estratégica de negócios;
Necessidade de natureza social;
Consideração ambiental;
Solicitação de cliente;
Avanço tecnológico; e
Requisito legal.
Como se pode notar pelo acima descrito, o início de qualquer projeto é
precedido por uma etapa estratégica na qual são tomadas decisões chave para o
futuro. Tendo em vista a importância dessas decisões, devem ser levadas em
consideração todas as partes interessadas, pois essas cercam e interferem
diretamente em qualquer projeto. Na figura 9, podem-se ver as principais partes
interessadas em projetos, de um modo geral.
Figura 9 – Relação de partes interessadas em um projeto. Fonte: Project Management Institute, 2013.
Vale notar que, diferentes importâncias devem ser aplicadas a cada um dos
interessados em cada projeto, de modo a classificá-los e a priorizar o tratamento dos
interesses com maior potencial de impacto no projeto.
31
Além disso, dependendo de fatores como o meio em que o projeto está
inserido e a estrutura organizacional adotada pela empresa, alguns dos interessados
apontados na figura 9 podem não existir, podendo até mesmo o gerente de projetos
ser um desses, o que ocorre em empresas com estrutura organizacional funcional.
Além da estrutura organizacional funcional, outros quatro tipos de estrutura
podem ser encontrados nas empresas e como pode ser notado, esse tipo de
estruturação impactará diretamente na condução dos projetos da empresa.
É importante ressaltar a distinção feita pela Associação Brasileira de Normas
Técnicas (2000) quanto à organização empreendedora e a que executa o projeto,
conhecida como organização do projeto, pois essa pode ser constituída como uma
joint-venture, um consórcio e etc., ou uma parte da organização empreendedora. A
figura 10 demonstra quatro tipos de estruturação empresarial, estando cada uma
representada por uma letra, nas quais se destacam as organizações executoras.
Figura 10 – Estruturas organizacionais. Fonte: Adaptado de Project Management Institute, 2013.
Em a) pode-se identificar a estrutura funcional, previamente comentada, onde
não há o cargo de gerente de projetos. Nesse tipo de estrutura os projetos são
coordenados pelos gerentes funcionais que contam com auxílio de alguns de seus
subordinados.
32
A estrutura apresentada em b) é denominada de matricial fraca. Esse tipo de
estruturação é bem semelhante ao definido anteriormente, com a distinção de que
quem coordena os projetos não são os gerentes funcionais e sim os seus
subordinados.
Uma estrutura matricial balanceada é apresentada em c), a principal
característica dessa estrutura é a presença de um gerente de projetos. Porém, esse
gerente está subordinado a um gerente funcional, de tal modo que não possui
autonomia suficiente para influir efetivamente o gerenciamento do projeto, tendo
muitas vezes que acatar ordens que contrapõem os interesses do projeto
passivamente.
A última das estruturas listadas pode ser observada em d). Esta corresponde a
matricial forte e nela pode-se notar a presença de vários gerentes de projetos que
estão reunidos e subordinados a um chefe dos gerentes de projetos, e não a um
gerente funcional, no que corresponde a um PMO. Desse modo, os gerentes de
projetos têm mais autonomia para trabalhar em prol do desenvolvimento dos projetos,
mas ainda enfrentam dificuldades por utilizar recursos humanos pertencentes aos
departamentos dos gerentes funcionais.
Além das quatro estruturas previamente mencionadas, há uma utilizada pelas
empresas com foco em projetos, essa estrutura denomina-se projetizada e pode ser
vista na figura 11.
Figura 11 – Estrutura projetizada. Fonte: Adaptado de Project Management Institute, 2013.
33
Em uma estrutura organizacional desse tipo não há a divisão convencional na
empresa por departamentos e sim equipes que atuam em diferentes projetos, de modo
que o gerente de projetos possui autonomia quase que completa para coordenar os
projetos junto a uma equipe que se dedica exclusivamente ao projeto em curso.
Apesar de ser a estrutura normalmente indicada para empresas que trabalham
com muitos projetos, nem sempre a estrutura projetizada é adotada por essas. Como
exemplo, pode-se citar o caso das empresas brasileiras de engenharia, na pesquisa,
vista no gráfico 10, realizada pela pmsurvey.com, uma iniciativa do PMI, ao aplicar os
filtros necessários para avaliar apenas os resultados relativos a essas empresas
averígua-se que dentre elas, embora a estrutura mais utilizada seja a projetizada, essa
corresponde a apenas 44% do total da amostra e a segunda estrutura mais utilizada é
a funcional, onde nem mesmo há um gerente de projetos.
Gráfico 10 – Empresas de engenharia brasileiras por tipo de estrutura funcional. Fonte: Adaptado de pmsurvey.org, 2013.
Outro fato nítido na pesquisa é que empresas que utilizam uma estrutura
matricial balanceada não foram representativas. Considerando-se as empresas que
possuem gerenciamento de projetos, com base nesses dados, pode-se deduzir que
essas representem 56% das empresas, valor próximo ao indicado no gráfico 4, na
página 9, para empresas que possuem um escritório dedicado exclusivamente ao
gerenciamento e ao desenvolvimento de projetos.
2.2.3. Desenvolvimento de Produtos e Projetos
De acordo com o apresentado pelo Project Management Institute (2013), o
ciclo de vida do projeto deve levar em consideração a fase atual do ciclo de vida do
34
produto a ser gerado. Isso se deve principalmente à tendência contínua de redução
por obsolescência do ciclo de vida dos produtos. Ainda o Project Management Institute
(2013), aponta a complexidade dos projetos como outro ponto a ser considerado, uma
vez que projetos grandes e complexos podem requerer um nível adicional de controle
para suas entregas principais. De modo que o gerenciamento desses projetos pode
ser beneficiado por uma divisão em fases. Ao demonstrar o avanço da utilização de
recursos financeiros e humanos em projetos, o gráfico 11 demonstra a proposta
apresentada pelo Project Management Institute (2013) de divisão em fases formais de
um projeto.
Gráfico 11 – Avanço da alocação de recursos durante fases de um projeto.
Fonte: Project Management Institute, 2013.
A estruturação do projeto em fases representa a segmentação do trabalho em
subconjuntos lógicos para facilitar o gerenciamento, o planejamento e controle.
Geralmente as fases são sequenciais, mas dependendo de sua natureza essas podem
ser sobrepostas em algumas situações. O número de fases em que se divide um
projeto varia de acordo com a necessidade existente. Sendo uma opção a utilização
da divisão em quatro fases, apontada no gráfico anterior. (PROJECT MANAGEMENT
INSTITUTE, 2013)
Além da divisão em fases, é importante notar a curva de avanço dos custos
quanto aos recursos financeiros e mão de obra empregada nos projetos. O Project
Management Institute (2013) demonstra que geralmente os projetos alocam a maior
35
quantidade desses recursos na etapa de execução, na qual também se investe a
maior parte do tempo de um projeto.
Entretanto, antes mesmo de se iniciar um projeto, são despendidas horas de
mão obra em uma etapa que concentra importantes análises estratégicas para que
sejam tomadas decisões referentes aos projetos que irão compor um portfólio. A figura
12 demonstra, basicamente, quais etapas do desenvolvimento de um produto compõe
efetivamente o ciclo de vida de um projeto, em contraponto ao ciclo de vida de um
produto.
Figura 12 – Ciclos de vida do produto e do projeto.
Fonte: Adaptado de Hedeman, van Heemst e Fredriksz, 2007.
Como pode ser visto, o ciclo de vida de um produto compreende uma maior
quantidade de etapas, sendo o ciclo de vida de um projeto apenas uma parte desse,
tendo início apenas após uma definição do que será produzido. Dependendo do
projeto e da solicitação do cliente, seja ele a alta administração de uma empresa ou
uma empresa a qual se presta um serviço, o encerramento do ciclo de vida do projeto
pode ter como saída a entrega de um protótipo funcional, manuais de uso e a
documentação necessária para produção.
Há um conjunto de fases que diz respeito às atividades e práticas de
desenvolvimento de produtos, também conhecido na literatura como Processo de
Desenvolvimento de Produtos (PDP), que abrange todo o processo e pode ser visto
com maiores detalhes nos trabalhos de Barbalho (2006) e Pahl et al. (2007). Em uma
36
breve síntese, Pang et al. (2011), avaliam o PDP em quatro fases, que são
apresentadas a seguir e podem ser vistas a seguir:
Na fase inicial, relacionada à identificação das necessidades dos
clientes, é fator preponderante a definição do problema, ou seja, o
entendimento do escopo a ser tratado;
Posteriormente devem-se estabelecer métricas para o desempenho das
atividades envolvidas no projeto para que possa ser efetuado o controle
das mesmas quanto a questões relacionadas à realização do escopo, a
qualidade, o custo e o prazo;
Em outra fase é necessário que se realize a análise das funções
objetivadas para o produto final do projeto, e os requisitos existentes
para que seja possível a realização das funções pretendidas; e
Finalmente, uma fase é destinada a análise e melhoria do produto, após
a finalização do projeto.
As fases acima relatadas fornecem informações importantes sobre o PDP,
entretanto a metodologia desenvolvida por Kepner e Tregoe, (1981 apud BUUR, 1989)
permite um maior detalhamento desse processo. Essa metodologia, conforme exposto
na figura 13, contém dez atividades que almejam a obtenção de melhores resultados
no PDP.
Figura 13 – Método de Kepner e Tregoe para PDP. Fonte: Adaptado de Kepner e Tregoe (1981 apud BUUR, 1989).
37
Embora seja de fácil confusão, existem diferenças sutis entre o que se entende
por projeto e por PDP. Projetos não se limitam apenas a produtos, abrangendo
também a área de serviços. Por outro lado, com relação aos processos envolvidos, a
abordagem por PDP é mais abrangente que a por projetos, que só inicia após a
decisão do que será realizado, enquanto a abordagem por PDP engloba esse
processo de decisão.
Outro ponto em que a abordagem do PDP se diferencia da de projetos está no
que se refere ao acompanhamento posterior do que foi desenvolvido. A última fase do
PDP, mencionada por Pang et al. (2011), não está compreendida na abordagem por
projetos, sendo comum que nessa etapa do PDP novos projetos surjam, voltados para
melhoria do produto de um projeto inicial.
É importante expor que as etapas posteriores ao encerramento dos projetos
escapam ao escopo planejado para essa dissertação e não serão abordadas pelo
autor, embora as etapas pré-projeto sejam tratadas.
38
3. ANÁLISE EXPLORATÓRIA
Esse capítulo apresenta em detalhes grande parte do conhecimento utilizado
para basear a metodologia proposta nessa dissertação para projetos de sistemas
mecatrônicos, considerando tanto aspectos técnicos desses projetos, quanto os que
envolvem a gestão desses projetos. Para tal, essa análise exploratória está
estruturada em dois subcapítulos: projetos de sistemas mecatrônicos e; padrões e
metodologias para gestão de projetos.
3.1. PROJETOS DE SISTEMAS MECATRÔNICOS
Sistemas multidisciplinares, segundo Shetty e Kolk (2011), não representam
uma novidade, pois têm sido projetados e utilizados por muitos anos. Os autores
apontam ainda que a principal diferença entre sistemas mecatrônicos e
multidisciplinares não está no que os constitui, mas sim na forma como seus projetos
são conduzidos.
Uma vez que o papel dos projetistas consiste na produção de um sistema
mecatrônico que cumpra todos os requisitos e especificações solicitadas pelos
clientes, Angeles e Park (2008) articulam que os desafios enfrentados pelos
projetistas, consequentes da multidisciplinariedade, se refletirão como incertezas nas
tarefas operacionais a serem executadas pelo sistema.
O projeto de um sistema mecatrônico é considerado por Chami et al. (2013) um
dos desafios mais difíceis na indústria, principalmente devido à natureza
multidisciplinar do processo de desenvolvimento que requer a integração de disciplinas
de gestão de projeto e de negócios, além das várias disciplinas de engenharia
frequentemente citadas por muitos autores. Para assegurar o sucesso em qualquer
projeto é recomendado por Horikawa et al. (2002) e por Pahl et al. (2007) que os
desenvolvimentos desses sejam abordados de forma sistemática, ou seja, que seja
utilizado um conjunto ordenado de práticas.
3.1.1. Desafios e Tendências
Assim como em outros projetos, o primeiro passo no desenvolvimento de
sistemas mecatrônicos é analisar as necessidades dos clientes, conforme apontam
vários autores como Pahl et al. (2007), Budynas e Nisbett (2011) e Shetty e Kolk
(2011). O primeiro afirma que reconhecer a necessidade e descrever a necessidade
39
muitas vezes constitui um ato altamente criativo, porque a necessidade pode ser
apenas um vago descontentamento.
Entretanto, voltando-se aos aspectos técnicos, Nogueira e Lepikson (2006)
assinalam que o projeto de um sistema mecatrônico deve se ater as seguintes
considerações sobre esses sistemas:
Envolvem muitos componentes, exigindo a divisão em módulos ou
subsistemas;
Possui interação funcional e integração espacial;
Seus componentes mecânicos possuem formas complexas e de baixa
tolerância geométrica, exigindo o uso de modelagem em CAD; e
Possui software embarcado, capaz de realizar funções de controle,
adquirir e manipular dados, podendo também apresentar interfaces para
outros sistemas.
Para Shetty e Kolk (2011) outro fator a ser considerado é, ainda, o ambiente
técnico em que o sistema será integrado, já que os sistemas mecatrônicos interagem
diretamente com o meio em que estão inseridos com seus sensores, recolhendo
dados e os processando, e seus atuadores, realizando ações.
Em um contexto voltado a projetos industriais Horikawa et al. (2002) declaram
que a utilização dos sistemas mecatrônicos no setor é geralmente realizada sob uma
de duas possíveis circunstâncias: uma nova instalação física e/ou novo processo
produtivo, sendo os sistemas mecatrônicos incorporados no planejamento inicial,
permitindo maior flexibilidade nas decisões; e uma incorporação a processos já
existentes visando ganho de produtividade e/ou qualidade das tarefas, o que implica
em maior complexidade para os projetos, dado as restrições geradas pelo sistema em
funcionamento.
O aumento do grau de complexidade encontrado no processo de
desenvolvimento dos sistemas mecatrônicos são tratados por Stefanov (2011) como
consequência do crescimento contínuo das expectativas dos clientes. Parte dessa
complexidade é considerada intrínseca aos sistemas mecatrônicos, conforme afirmam
Nogueira e Lepikson (2006) ao apontarem que a interação entre funções e a
integração dos componentes trazem a esses sistemas necessidades como as que
seguem:
Presença de interconexões mecânicas e elétricas entre os sensores, os
atuadores e o sistema computacional;
40
Adensamento espacial como resposta a exigência por portabilidade;
Presença de um chassi, base ou carcaça para abrigar ou suportar as
conexões e os componentes eletrônicos, mecanismos, etc.;
Precisão de movimentos e facilidade de montagem;
Interação efetiva entre subsistemas;
Tolerâncias dimensionais e geométricas tipicamente abaixo de 0,01
mm;
Acabamento externo priorizando a forma e o acesso a controles e
conexões; e
Utilização máxima da simetria, para reduzir os custos nas fases de
projeto, simulação, modelagem, fabricação e montagem.
Para Shetty e Kolk (2011) muitos dos altos custos na fabricação de produtos
são oriundos do próprio estágio de projeto. Assim, Horikawa et al. (2002) enfatizam a
importância da realização da análise de viabilidade econômica e financeira dos
projetos de sistemas mecatrônicos, de forma análoga a de qualquer outro projeto. As
principais etapas para realizar-se uma análise econômica específica de um projeto de
robotização podem ser analisadas em seu trabalho.
Ainda sobre custos, Erbe (2002 apud PAULA; SANTOS, 2008) identifica que
pequenas empresas encontram dificuldades para manter sistemas mecatrônicos em
razão dos custos para eventuais reprogramações, do tempo ocioso de equipamentos e
do alto custo da manutenção especializada. Isso caracteriza um nicho de mercado,
voltado a sistemas mais flexíveis e de baixo custo de manutenção.
Além disso, no que tange aos fatores humanos, o caráter multidisciplinar dos
projetos de sistemas mecatrônicos exige também a formação de uma equipe que
possa planejar e desenvolver o trabalho de forma interdisciplinar e sinérgica.
(NOGUEIRA; LEPIKSON, 2006)
Em seu trabalho Middendorf et al. (2006) apontam três fortes tendências, ainda
atuais, para o desenvolvimento de sistemas mecatrônicos. Uma dessas é a redução
dos ciclos de inovação, o que acaba por comprimir o calendário dos projetos, uma vez
que esses precisam ser desenvolvidos em menor tempo para atender as demandas de
mercado e as estratégias empresariais. Outra tendência concerne à inserção de novas
funcionalidades nos produtos, uma vez que o mercado tem apresentado cada vez
mais necessidade por dispositivos que integrem múltiplas funções, facilitando as
atividades cotidianas da população. Por fim, o aumento da variedade de produtos
também é apontado, tendência que diz respeito à natural segmentação do mercado,
consequente a sua expansão.
41
Gheorghe et al. (2011) apontam ainda desafios quanto à necessidade futura
por uma nova filosofia e metodologia para concepção e desenvolvimento de conceitos
de micro e nano sistemas de alta complexidade e elevado grau de integração
associados à inteligência artificial. Os autores ainda mencionam algumas das áreas as
quais a aplicação desses sistemas pode trazer melhorias como: proteção ambiental,
medicina, dispositivos eletrônicos, automações, telecomunicações, domínio da
metrologia, sistemas de transmissão, tecnologia de produção industrial e etc..
Outros desafios são apontados por Kutz (2007) para o mercado futuro de
produtos, considerando seus impactos ambientais. O autor relata que há muitas
maneiras de minimizar os impactos ambientais de um produto, mas que, no entanto, a
melhor das oportunidades se dá durante a fase conceitual de projeto do produto. Para
ele, o produto ambientalmente ideal é aquele que não causa danos ecológicos durante
sua produção e utilização, converte quaisquer condições precárias existentes em seu
ambiente de utilização e ao fim de sua vida útil se torna matéria útil para a produção
de outro produto sem gerar resíduos.
Dados tais desafios e tendências, Horikawa et al. (2002) consideram que
conceitos de ergonomia podem ser utilizados no projeto conceitual para a correta
introdução de sistemas mecatrônicos em ambientes como os industriais, devendo ser
observado que o planejamento das atividades realizadas por esses sistemas traz
características totalmente distintas quando comparados à ergonomia do trabalho
exclusivamente humano.
3.1.2. Boas Práticas
Dentro da fase de projeto conceitual, Middendorf et al. (2006) propõem a
utilização de um conjunto de técnicas de especificação para projetar os sistemas
mecatrônicos, considerando-se os aspectos que podem ser vistos na figura 14 abaixo:
Requisitos: apresenta um conjunto estruturado de requisitos que
precisam ser cumpridos durante o desenvolvimento do produto;
Ambiente: descreve as condições técnicas do sistema a ser
desenvolvido e sua incorporação no ambiente operacional;
Funções: diz respeito à subdivisão hierárquica da funcionalidade;
Estrutura Ativa: descreve os elementos do sistema, seus atributos e
relações, além de definir a estrutura base do sistema, incluindo todas as
suas configurações;
42
Forma: possibilita as primeiras definições de formato do sistema.
Atualmente utilizam-se sistemas do tipo Computer Aided Design (CAD)
com recursos 3D para realizar a modelagem;
Cenários de aplicação: concretizam o comportamento do sistema em
um estado ou situação específica, caracterizando algum problema; e
Comportamento: modela os estados do sistema e as transições de
estado. Dependendo do projeto, especificam-se fatores como
cinemática, dinâmica e estática.
Figura 14 – Técnicas para projetar sistemas mecatrônicos. Fonte: Adaptado de Middendorf et al., 2006.
Mesmo considerando todos os aspectos destacados acima, é importante
destacar o que menciona Naveiro (2002), pois não se pode desprezar o planejamento
de detalhes, como por exemplo, o posicionamento de cabos de alimentação em
projetos de sistemas mecatrônicos inseridos em um ambiente industrial em que haverá
interação com humanos e outros sistemas.
Como pode ser visto, um sistema mecatrônico abrange uma ampla gama de
componentes, tecnologias de interconexão e software de aplicação específica. Esses
permitem a realização de novas funções ou a substituição de soluções presentes. No
projeto de um sistema mecatrônico exercitam-se domínios envolvendo diversas áreas
da engenharia. No passado, as formas e funcionalidades eram o principal foco do
desenvolvimento desses projetos. Porém, hoje em dia também enfoca-se o
desempenho ambiental e a confiabilidade dos sistemas, a fim de criar um produto
sustentável. (MIDDENDORF et al., 2006)
Frequentemente, os fatores de confiabilidade para mecatrônica estão ligados a
sua estrutura mecânica, como é o caso do estresse térmico e do estresse
termomecânico, apontam Middendorf et al. (2006). Já Angeles e Park (2008) definem
43
seis etapas, no que tange estrutura mecânica, que interagem para o desenvolvimento
de um projeto mecatrônico, como segue:
Determinar a topologia da cadeia cinemática e suas configurações, bem
como os tipos de junta;
Definir as dimensões geométricas dos diversos elos;
Determinar o dimensionamento estrutural dos elos e juntas, para
atender aos requisitos de carga estática;
Dimensionar a estrutura dos elos e juntas, para atender aos requisitos
de carga dinâmica;
Determinar o dimensionamento elastodinâmico da estrutura mecânica
em geral, incluindo a dinâmica dos atuadores; e
Selecionar os atuadores e suas transmissões mecânicas de acordo com
as condições operacionais definidas, considerando as incertezas da
tarefa.
Middendorf et al. (2006) acrescentam que caso haja na organização uma base
de conhecimentos de projetos anteriores, essa deve ser consultada, para aplicação de
cálculos simplificados dimensionais e outros para que se estabeleçam comparações
com estruturas desenvolvidas anteriormente. Recomendam-se ainda métodos como o
Método dos Elementos Finitos (MEF) para que sejam realizadas simulações da
estrutura.
Apesar da grande importância dos aspectos técnicos, durante o projeto de um
sistema mecatrônico não se podem desprezar os fatores humanos envolvidos. Um
erro cometido por projetistas é não considerar o ponto de vista do usuário final quanto
à utilização de um sistema, o que pode acarretar futuramente em solicitações de
mudança do escopo do projeto, ou ainda em seu fracasso. Como, apesar de já
haverem esforços de pesquisa nesse sentido, ainda é difícil determinar o momento
mais adequado para consideração dos fatores humanos no projeto, recomenda-se que
a participação dos usuários no trabalho da equipe do projeto seja considerada nas
etapas iniciais da metodologia empregada nos projetos de sistemas mecatrônicos.
(COELHO et al., 2008)
De acordo com Shetty e Kolk (2011), uma metodologia é um conjunto de
práticas, procedimento e regras utilizadas para realização de um trabalho em
particular. Assim sendo, as práticas acima mencionadas, mesmo não tendo caráter de
obrigatoriedade, devem ser consideradas durante o desenvolvimento dos projetos de
sistemas mecatrônicos, uma vez que tendem a melhorar os resultados gerados.
44
3.1.3. Metodologia Clássica
De acordo com Shetty e Kolk (2011), historicamente, projetos de sistemas
multidisciplinares seguiam uma abordagem sequencial, disciplina por disciplina em
que cada uma delas era tratada como um subprojeto dependente apenas das
informações do anterior. Nessa metodologia, como não há interação entre os
subprojetos durante seus desenvolvimentos, os processos de criação ficam restritos a
um conjunto de fatores indicados pelo subprojeto antecessor sem que seja
considerado se aquela configuração está entre as melhores para o sistema como um
todo, ou seja, conforme Shetty e Kolk (2011) declaram, o problema dessa abordagem
é que ao se fixarem vários subprojetos em sequência, novas restrições são geradas e
passadas aos subprojetos seguintes.
Já Li, Zhang e Chen (2001) explicam mais a fundo porque isso ocorre na
metodologia de concepção clássica. Segundo eles, a estrutura mecânica do sistema
mecatrônico é normalmente determinada separadamente, a partir do controlador, e o
desenho da estrutura está orientado apenas para os aspectos mecânicos como a
cinemática, a dinâmica e a estática. Assim, devido à limitação de hardware, a melhor
ação de controle dificilmente é atingida.
Buur (1989) aponta ainda que a abordagem sequencial, embora favoreça o
gerenciamento de riscos, costuma aumentar a duração total de um projeto, pois a
presença de gargalos em qualquer uma das fazes atrasa o projeto como um todo.
Nogueira e Lepikson (2006) também citam o longo ciclo de vida do projeto como uma
das restrições presentes na metodologia tradicional. A figura 15 ilustra o
desenvolvimento das metodologias em três diferentes fases, uma em que não havia
interações, outra com interações no início e fim de cada etapa e uma última altamente
interativa.
Figura 15 – Comparação de metodologias quanto a interação das fases dos projetos. Fonte: Takeuchi e Nonaka (1988 apud BUUR, 1989).
45
A Associação Brasileira de Normas Técnicas (2000) aborda a divisão em fases
afirmando que essa permite uma melhor supervisão quanto à realização dos objetivos,
bem como uma melhor percepção dos riscos associados ao projeto. A associação
relata ainda que durante o ciclo de vida dos projetos podem ocorrer superposições
entre fases significativas.
Desse modo, com o passar do tempo, a metodologia clássica perdeu força e
passou a ser substituída por outras mais interativas, pois os projetos de sistemas
mecatrônicos precisaram ser conduzidos de forma cada vez mais veloz. As
metodologias mais interativas e, por consequente, mais integradas também podem ser
apontadas como vantajosas por proporcionarem aumento da qualidade do resultado
gerado, além de ganhos de tempo.
3.1.4. Integração nas Metodologias
Nogueira e Lepikson (2006) e Pahl et al. (2007) aludem à complexidade das
várias etapas dos projetos de sistemas mecatrônicos e sua natureza interdisciplinar
concluindo que esses exigem métodos específicos e sistematizados. Pahl et al. (2007)
reiteram, no entanto, que esses devem ser aplicados com flexibilidade, considerando
os conhecimentos e terminologias das diversas disciplinas envolvidas.
Uma metodologia sistematizada e simultânea pode ser observada nos projetos
preliminares de sistemas de engenharia, afirmam Shetty e Kolk (2011), e, de certa
forma, a mecatrônica é uma extensão desses sistemas, complementada com sistemas
de informação, devendo esses serem considerados em todas as fases do projeto, não
apenas na preliminar.
Pil e Asada (1996) já alertavam sobre a necessidade de haver uma maior
integração na concepção dos mecanismos e do controle nos sistemas mecatrônicos.
De acordo com suas pesquisas, existem interações significativas e relações
intrínsecas entre a estrutura mecânica, a dinâmica e o controle desses sistemas,
devendo o desenvolvimento mecânico e do controle ser integrado e executado
simultaneamente, havendo interações entre os dois.
Segundo Pahl et al. (2007) o ideal é que não seja possível distinguir as áreas
de conhecimento envolvidas nos projetos de sistemas mecatrônicos, pois a natureza
integradora desses projetos deve tornar fluidos os limites entre as áreas. Uma
abordagem flexível e iterativa para projetos de sistemas mecatrônicos, avaliada por
Stefanov (2011) proporciona aos sistemas mecânicos, eletrônicos e de controle que
sejam concebidos em conjunto, tendo em conta a influência entre eles, os requisitos
tecnológicos e as necessidades dos clientes.
46
Li, Zhang e Chen (2001), afirmam que a metodologia integrada de projetos tem
o potencial de obter um desempenho ideal do sistema como um todo. Seguindo essa
linha, Shetty e Kolk (2011) explicam que a sinergia da integração entre o sistema
elétrico, o sistema mecânico e o sistema de informação é gerada pela combinação
adequada de parâmetros e possibilita que o produto final seja melhor do que apenas a
soma de suas partes, o que resulta em características de desempenho que antes
eram difíceis de alcançar.
Seguindo essa linha, Coelho et al. (2008) defendem que a integração aconteça
o mais cedo possível no projeto de sistemas mecatrônicos. Para tal, é necessário que
esta seja contemplada pelos processos da metodologia utilizada.
Os grupos de processos de uma metodologia são integrados através da
sobreposição de atividades ao longo de todo o projeto, em que, geralmente, cada fase
foca um subconjunto de atividades. O gráfico 12 mostra como os grupos de processos
interagem e o nível de sobreposição em diversas ocasiões. (PROJECT
MANAGEMENT INSTITUTE, 2013)
Gráfico 12 – Integração entre processos de um projeto. Fonte: Project Management Institute, 2013.
Budynas e Nisbett (2011) enfatizam que o desenvolvimento de um projeto é um
processo interativo em que se procede por várias etapas, se avalia os resultados e,
em seguida, retorna para uma fase anterior do procedimento. Segundo o Project
Management Institute (2013), os grupos de processos de gerenciamento de projetos
estão vinculados pelas saídas que produzem, de modo que a saída de um processo,
em geral, torna-se uma entrada em outro. Além disso, é normal que sejam realizadas
47
verificações na transição entre as fases, o que pode acarretar em loops, como pode
ser visto na figura 16.
Figura 16 – Integração entre as fases de um projeto. Fonte: Project Management Institute, 2013.
Em seu trabalho, Chen (2012) projetou e produziu uma mão robótica utilizando
uma metodologia integrada para o desenvolvimento do modelo mecânico, do
eletrônico, e do sistema de controle. Ao fim de seu trabalho, demonstrado na figura 17,
ele concluiu que o compartilhamento de informações e a reutilização de modelos
construídos em diferentes fases do projeto configuram uma grande vantagem dessa
metodologia, uma vez que poupa tempo e reduz o risco de erros nas transferências de
dados entre as fases.
Figura 17 – Resultado do projeto de uma mão robótica. Fonte: Chen, 2012.
48
Para suprir de forma pontual alguns dos desafios mencionados, uma série de
outras metodologias voltadas para projetos de engenharia foram propostas pela
academia, dentre essas, algumas voltadas para casos específicos como as orientadas
ao custo, à manutenção e ao meio ambiente, estando essas detalhadas em livros
como os de Kutz (2007) e de Pahl et al. (2007).
Entretanto, no que tange especificamente aos projetos de sistemas
mecatrônicos, Chami et al. (2013) discorrem a respeito da variedade de metodologias
que têm sido propostas na literatura e conclui que ainda não há consenso quanto a
uma a ser adotada e que, com isso, na prática as empresas desenvolvem
individualmente suas próprias técnicas. Apesar do relato de Chami, na prática, a maior
parte das metodologias encontradas na literatura são variações de um seleto conjunto
de metodologias, sendo as principais destas mencionadas no subcapítulo a seguir.
3.2. MÉTODOS DESCRITOS NA LITERATURA
De acordo com Pahl et al. (2007), para o efetivo gerenciamento de projetos de
sistemas mecatrônicos é necessária a utilização de modelos e procedimentos
adequados, dada a complexidade exigida para desenvolvê-los com raciocínio
interdisciplinar de forma integrada.
Um fator crucial no desenvolvimento dos sistemas mecatrônicos é a integração
rigorosa das disciplinas envolvidas desde a concepção do sistema. Conforme afirmado
por Gausemeier et al. (2011) e Carrasco (2013) outro importante fator a ser
considerado na concepção de sistemas mecatrônicos é o processo de fabricação,
sendo importante que essa preocupação se dê desde a fase conceitual do projeto.
Tais fatores só aumentam a complexidade do desenvolvimento desses projetos.
Assim, faz-se necessário o uso de um método de desenvolvimento sistematizado.
A seguir são apresentados três métodos presentes na literatura: o Modelo de
Referência para o Desenvolvimento de Produtos Mecatrônicos (MRM), desenvolvido
por Barbalho (2006); o Modelo V, proposto Vasic e Lazarevic (2008); o Modelo
Hierárquico, proposto por Hehenberger et al. (2010); e o Modelo de 3-Ciclos, proposto
por Gausemeier et al. (2011). Tendo todos esses métodos sido também abordados por
Carrasco (2013) e Leite (2014).
3.2.1. MRM
O MRM foi apresentado por Barbalho (2006) em sua tese de doutorado em
engenharia mecânica na Escola de Engenharia de São Carlos e posteriormente
validado em um artigo científico por Barbalho e Rozenfeld (2013). O modelo consiste
49
na reunião de boas práticas encontradas na literatura e trata o desenvolvimento de
produtos mecatrônicos pela abordagem do PDP. Além disso, o MRM tem foco em
empresas produtoras de bens, no caso produtos mecatrônicos.
A figura 18 demonstra as doze etapas nas quais se dividem os esforços
empreendidos por uma empresa que faça uso do MRM, partindo da estratégia
empresarial e finalizando com o monitoramento do produto final junto a seus usuários.
Em seu trabalho, Barbalho (2006) emprega essas fases, entretanto alerta-se nessa
dissertação que apesar de ser utilizado o termo otimização para designar uma dessas
fases, a mesma não necessariamente envolve o uso de algoritmos ou outras técnicas
de otimização. Dessa forma, nesse trabalho tomou-se a liberdade de substituir o
mesmo pelo termo “melhoria”, na descrição das fases propostas por Barbalho (2006),
que podem ser vistas abaixo:
Figura 18 – Fases do desenvolvimento de uma solução. Fonte: Barbalho, 2006.
1. Estratégia – planejamento da estratégia para as linhas de produtos;
2. Portfólio – montagem do portfólio dessas linhas;
3. Especificações – definição das especificações dos produtos;
4. Planejamento do projeto – elaboração do plano dos projetos;
5. Concepção – entendimento dos principais componentes e funções do
produto;
6. Planejamento técnico – detalhamento do plano de projeto;
7. Projeto técnico – detalhamento das soluções técnicas para as funções
definidas;
50
8. Melhoria – realização de testes e análises visando o aumento da
robustez e confiabilidade do produto;
9. Homologação – homologação do resultado do projeto;
10. Validação – recebimento de aceite formal e certificação do resultado
gerado;
11. Lançamento – introdução do produto no mercado; e
12. Monitoramento: acompanhamento dos resultados e gerenciamento das
modificações solicitadas.
O modelo propõe também a utilização de gates entre as fases, decisões ou
entregas, que servem para validar o resultado de uma fase e definir seu encerramento
e o início da posterior, ou o encerramento de todo o processo em alguns casos
especiais. Esses gates são representados pelos losangos ao fim dos cortes verticais
na figura 18.
O tipo de cada gate difere de acordo com a cor de seu respectivo losango,
sendo os das fases estratégia e portfólio relativos a decisões empresariais
estratégicas inerentes ao portfólio da organização. Os gates das fases concepção e
projeto técnico estão relacionados com a viabilidade técnica e atendimento dos
requisitos do produto. O gate da fase lançamento, na realidade se trata de um relatório
final e uma lista de lições aprendidas. Todos demais gates envolvem decisões quanto
à continuidade ou cancelamento dos esforços de desenvolvimento, envolvendo a alta
administração da organização.
É relevante que se note que o MRM foi desenvolvido a partir de boas práticas
presentes na literatura da época e do conhecimento do autor que durante o
desenvolvimento do modelo esteve imerso no ambiente de uma empresa cuja
atividade fim era a produção de produtos mecatrônicos, tendo essa metodologia sido
implementada e validada nessa mesma empresa.
3.2.2. Modelo V
A proposta de Vasic e Lazarevic (2008), também abordada por Stefanov (2011)
e Carrasco (2013), consiste inicialmente em analisar os requisitos do sistema, suas
subfunções, seus subsistemas e seus componentes definindo-os, processo
demonstrado na parte esquerda do Modelo V. O modelo pode ser visto na figura 19 e,
como relata Stefanov (2011), tem como resultado um protótipo virtual do sistema.
Então, as equipes colaborativas desenvolvem simultaneamente os subsistemas
mecânicos, eletrônicos e de TI.
51
Figura 19 – Modelo V. Fonte: Stefanov, 2011.
Já na segunda etapa, lado direito do Modelo V, Stefanov (2011) afirma que
desenvolve-se um protótipo físico do sistema, integrando-se gradativamente os
componentes e subsistemas. Ao término dessa fase, verifica-se o executado
comparando-o com os requisitos esperados e, por fim, busca-se validar o sistema
integrado, verificando se há necessidade de melhoria. Caso alguma melhoria seja
solicitada, repete-se a operação desde a primeira fase.
O Modelo V, concebido como processo iterativo, segundo Carrasco (2013) tem
como objetivo estabelecer um conceito de solução que descreva as principais
características físicas e operacionais do sistema a ser desenvolvido.
3.2.3. Modelo Hierárquico
O Modelo Hierárquico para projetos de sistemas mecatrônicos foi apresentado
por Hehenberger et al. (2010) e mencionado posteriormente no trabalho de Carrasco
(2013) e Leite (2014). Uma representação do modelo pode ser vista na figura 20. O
Modelo Hierárquico é baseado nos três pilares que seguem:
Módulos mecatrônicos – Hehenberger et al. (2010) propõe a
decomposição do sistema mecatrônico através de uma espécie de
estrutura analítica do produto. Assim, representam-se os módulos
separadamente, de acordo com suas áreas de conhecimento, como
52
mecânica, eletrônica e controle. Sendo cada um desses módulos
detalhados em estruturas com vários níveis hierárquicos.
Figura 20 – Módulo Mecatrônico. Fonte: Hehenberger et al., 2010.
Modelos hierárquicos para projeto conceitual – Tanto Carrasco (2013)
quanto Leite (2014), mencionam que o modelo é único e tem o objetivo
específico de servir como ferramenta para que se encontre uma solução
do projeto em questão. Esses modelos são constituídos por um
conjunto de requisitos e um conjunto de relações lógicas entre eles. A
elaboração dos modelos representa um grande desafio, exigindo
trabalho criativo.
Projeto hierárquico de parâmetros – A hierarquia de parâmetros de
projeto, como apresentado por Hehenberger et al. (2010), é estudada
de forma individual para cada área do conhecimento, sendo a fase de
53
concepção feita através de vários estágios do projeto intermediário. Ao
fim dessa fase, obtém-se toda a documentação do sistema
desenvolvido. O Método Hierárquico classifica os requisitos dos projetos
em externos, possibilitam o desenvolvimento do nível hierárquico
superior, e internos, requisitos para o dimensionamento dos
componentes da camada hierárquica inferior.
3.2.4. Modelo de 3-Ciclos
Em seus estudos acerca da Engenharia de Produto, Gausemeier et al. (2011)
apresentam um modelo para o desenvolvimento de produtos mecatrônicos, composto
por três etapas de natureza iterativa, sendo assim denominadas ciclos. Esses ciclos
são focados respectivamente no planejamento estratégico do produto, no
desenvolvimento do produto e no desenvolvimento dos sistemas de produção para
aquele produto. A figura 21, localizada a seguir, sintetiza o modelo.
Figura 21 – Modelo de 3-Ciclos. Fonte: Gausemeier et al., 2011.
Um resumo sobre o funcionamento de cada um desses ciclos está descrito
abaixo:
O ciclo inicial, planejamento estratégico do produto, busca estudar o
potencial de sucesso do sistema a ser desenvolvido e avaliar se o
54
projeto de produto é promissor, representando o que o autor denomina
como princípio de solução. Esse ciclo se baseia em quatro tarefas:
foresight (estudos prospectivos); definição do produto; projeto
conceitual do produto; e planejamento de negócios.
O segundo ciclo, também chamado de desenvolvimento do produto,
compreende três fases: projeto conceitual do produto, etapa em que há
grande interação com o primeiro ciclo; concretização das áreas de
conhecimento específicas, quando desenvolvem-se os sistemas de
cada uma dessas áreas; e integração dos sistemas, ao se unir os
sistemas da fase anterior gera-se uma solução global, sendo essa
consolidada em um protótipo virtual.
O terceiro ciclo, desenvolvimento do sistema de produção, compreende:
o projeto conceitual do sistema de produção, tendo como resultado o
princípio de solução do sistema de produção; a concretização do
domínio-especifico voltada para o planejamento do processo, do local
de trabalho, da logística de produção e do dispositivo de trabalho; e a
fase de integração dos sistemas de produção, combinando os
resultados do planejamento do domínio-especifico para obter uma
solução dos sistemas de produção.
3.3. PADRÕES E METODOLOGIAS PARA GESTÃO DE PROJETOS
O gerenciamento de projetos, para a Associação Brasileira de Normas
Técnicas (2000), deve incluir o planejamento, a organização, a supervisão e o controle
de todos os aspectos de um projeto, de forma contínua, visando garantir o atingimento
de seus objetivos. O Project Management Institute (2013) aponta o gerenciamento de
projetos como uma disciplina estratégica crítica para as organizações.
O elo entre a estratégia adotada por uma organização e a equipe de execução
é o gerente de projetos, de acordo com o Project Management Institute (2013), por ser
a pessoa alocada para liderar a equipe. O instituto afirma ainda que ele é o principal
responsável por alcançar os objetivos do projeto e um dos principais tomadores de
decisão no que tange aos esforços do projeto, devendo conhecer e ser capaz de
adaptar diferentes metodologias de gestão a realidade organizacional. Uma vez que
equipes que não compartilham uma metodologia tendem a ser ineficientes, segundo
Xavier (2009).
Entretanto, ao se implementar novas metodologias em uma organização pode
haver dificuldades relacionadas ao desconforto gerado nos indivíduos que constituem
55
a organização, conforme Varaschim (2009) expõe em seu trabalho. Assim o fator
cultural jamais deve ser desprezado durante a definição da metodologia a ser utilizada.
Xavier (2009) afirma que não existe uma metodologia que possa ser utilizada
em qualquer empresa ou projeto. Dessa forma, de acordo com o Project Management
Institute (2013) é fundamental que essas organizações busquem adaptar os melhores
processos e práticas existentes durante a gestão de seus projetos à cultura interna.
Para Xavier (2009) essa adaptação deve considerar não só a realidade dos projetos
da organização, como também as práticas existentes no mercado, as propostas
presentes na literatura e as experiências vivenciadas por gerentes de projetos,
devendo ela ser criteriosa de forma que compense o esforço de gerenciamento em
relação aos correspondentes resultados esperados.
É muito importante que essa adaptação seja realizada, uma vez que cada
projeto apresenta características únicas e distintas, havendo, por exemplo, projetos de
complexidade muito elevada com longa duração e escopo extenso, bem como projetos
de escopo mediano, mas com prazos de execução inflexíveis e curtíssimos. O
conteúdo de metodologias consagradas pode não ser o mais apropriado para projetos
com características singulares.
Por isso, faz-se necessária a adequação das práticas existentes para distintas
organizações e seus projetos. Comprovam essa necessidade, o surgimento e a
evolução de métodos novos para facilitar a realização de projetos que, por natureza,
exijam maior flexibilidade e baixo encargo burocrático. O Scrum, uma metodologia de
Gestão Ágil de Projetos (GAP), é uma dessas metodologias e vem recentemente
tendo sua aplicação estudada para o gerenciamento de projetos de sistemas
mecatrônicos.
Com o intuito de facilitar o trabalho dos gestores de projetos de sistemas
mecatrônicos, esse capítulo aborda alguns dos principais padrões e metodologias
utilizados atualmente para o gerenciamento de projetos, bem como suas vantagens e
desvantagens.
3.3.1. PRINCE2™
O PRINCE2™ é um método para gerenciamento de projetos que pode ser
adaptado a qualquer tipo ou tamanho de projeto. Esse método foi lançado para o
gerenciamento de projetos pelo governo britânico em 1996 e trata das atividades de
gerenciamento, controle e organização dos projetos.
Visando gerenciar projetos em ambiente de mudanças com base
principalmente nas circunstâncias de negócios, o PRINCE2™ gerencia os processos e
56
busca contemplar todas as partes interessadas. O método ressalta a gestão dos
processos frente aos objetivos iniciais. O PRINCE2™ trabalha com a gestão de riscos
como parte integral de todos seus processos, relacionando o projeto com o ambiente
organizacional, a gestão de riscos é utilizada para controle de incertezas no projeto e
em seu entorno. (HEDEMAN; VAN HEEMST; FREDRIKSZ, 2007)
É mencionado por Siegelaub (2004) que o PRINCE2™ não é composto por um
"núcleo" mais processos "facilitadores", mas possui um conjunto de componentes e
processos integrados em um único fluxo, o que torna clara as relações entre todos
eles. Sendo assim, os processos que compõem essa metodologia, bem como as
áreas abordadas por ela podem ser vistas na figura 22.
Figura 22 – PRINCE2™. Fonte: Hedeman, van Heemst e Fredriksz (2007).
Para que se obtenha maior compreensão desses processos, os mesmos são
abordados abaixo, seguindo o descrito nos trabalhos de Siegelaub (2004) e Hedeman,
van Heemst e Fredriksz (2007).
“Preparando um Projeto” – Permitindo uma partida controlada para o
projeto, esse processo fornece as bases para a gestão de projetos,
supervisão e análise de viabilidade. Para isso, ele cria o Comitê Diretor
57
do Projeto e assegura que os requisitos de recursos são compreendidos
e comprometidos com a fase “Iniciando um projeto”.
“Dirigindo um Projeto” – Opera durante todo o projeto, e define as
responsabilidades do Comitê Diretor do Projeto na sua supervisão, ele
fica acima dos outros processos e interage com muitos desses. Ele
fornece os mecanismos para autorizar o projeto, que aprova a
continuidade após a conclusão de cada etapa, e do encerramento do
projeto (todas baseadas na circunstância empresarial). Este é o único
processo no qual o Comitê Diretor do Projeto está ativo.
“Iniciando um Projeto” – É um processo de ocorrência única durante o
ciclo de vida do projeto, expondo a visão global de como o projeto deve
ser gerenciado, e o define em um “contrato” chamado Documentação
de Iniciação do Projeto (DIP). A intenção do DIP é o de proporcionar
uma compreensão comum dos elementos críticos do projeto. Além
disso, é importante mencionar que durante o primeiro estágio de
desenvolvimento do projeto esse processo precisa fazer uso de
recursos da alta administração da organização.
“Planejando” – Processo comum para vários outros processos em
PRINCE2™, a elaboração dos planos busca identificar as entregas do
projeto, as atividades e os recursos necessários para criá-los, além dos
requisitos de gestão e qualidade em um nível compatível com o descrito
no DIP. Outro ponto importante desse processo é que o uso de um
módulo comum destaca o conceito de uma abordagem consistente e
coerente para todo o planejamento.
“Controlando um Estágio” - Esse é um processo de natureza iterativa,
ele é repetido em cada estágio de desenvolvimento do projeto,
fornecendo orientação ao gestor do projeto na gestão do projeto em seu
dia-a-dia. Inclui: autorização de trabalho e recebimento de trabalho;
emissão e gestão da mudança; coleta de status, análise e elaboração
de relatórios; viabilidade e consideração; ação corretiva; e escalada de
preocupações para a alta administração e outros recursos.
“Gerenciando Entrega do Produto” – É o mecanismo usado, entre
outras coisas, para que se chegue a um acordo com os profissionais da
área técnica sobre o trabalho a ser realizado. Ele ocorre sempre que os
pacotes de trabalho são autorizados e faz parte do sistema de
autorização de trabalho do PRINCE2™.
58
“Gerenciando Limites dos Estágios” – Esse é o processo de
gerenciamento das transições entre as conclusões de estágios de
trabalho e o início dos seguintes, incluindo a garantia de que todo
trabalho definido para o estágio tenha sido concluído conforme
planejado. Por ser um processo de controle, esse fornece informações,
para o Comitê Diretor do Projeto, a serem utilizadas nas avaliações de
viabilidade do projeto, no desenvolvimento de planos de ação, na
avaliação de autorização de continuidade para o estágio seguinte e
para que sejam registradas as lições aprendidas durante o
desenvolvimento do projeto.
“Encerrando um Projeto” – O objetivo desse processo é garantir que: o
trabalho foi concluído garantindo a satisfação do cliente e da alta
administração; todos os produtos esperados foram entregues e aceitos
pelo cliente, e que; os recursos de apoio e operação do projeto foram
desmobilizados. É imprescindível que o processo que encerra o projeto,
seja pela conclusão da obra, ou por rescisão prematura, em qualquer
caso o encerramento deve registrar lições aprendidas e experiências do
projeto para agregar conhecimento à organização.
3.3.2. Scrum
Além das metodologias tradicionais mencionadas anteriormente nessa
dissertação, atualmente as metodologias GAP vem ganhando espaço junto às novas
empresas. Essas surgiram para melhorar a forma com que eram desenvolvidos
softwares, sendo assim originária da área de TI.
De acordo com Varaschim (2009), somente a partir de 2001 houve uma maior
clareza relacionada aos modelos ágeis de desenvolvimento, com a publicação do
Manifesto para o Desenvolvimento Ágil. Esse manifesto valorizava os fatores
humanos, a desburocratização, a maior participação dos clientes e a revisão contínua
do escopo nos projetos de TI.
Pinto (2010) destaca a crescente adoção dos princípios ágeis e menciona os
principais métodos existentes. Dentre os métodos mencionados, a aplicação do Scrum
passou recentemente a ser estudada para o emprego em projetos de sistemas
mecatrônicos, como mencionado nos estudos de Ovesen (2013) e Mulder, Verlinden e
Maruyama (2014).
O Scrum é um framework de base empírica com forma iterativa e incremental
de avaliação contínua, originado da necessidade de práticas de gerenciamento
59
voltadas para projetos mais dinâmicos e flexíveis, com alto índice de incertezas. O
Scrum permite que a equipe de desenvolvimento reveja continuamente a solução
proposta ao longo do projeto. (OVESEN, 2013)
Varaschim (2009) destaca que as práticas do Scrum objetivam manter o
gerenciamento do projeto visível aos usuários do modelo. O autor menciona também
que a metodologia não resolve os problemas da empresa, nem detalha o que deve ser
feito, mas dá visibilidade aos problemas, servindo como guia para a resolução destes.
O Scrum Guide, conforme relata Ovesen (2013), defende a utilização de
equipes interdisciplinares e de uma estrutura hierárquica plana, com equipes auto-
organizadas. Assim o supervisor, denominado Scrum Master, tem papel de facilitador
do processo, devendo apenas orientar a evolução dos comportamentos da equipe,
fornecendo a esses o apoio necessário para a execução das tarefas, chamadas de
Sprints. Ovesen (2013) aponta ainda que na última edição do Scrum Guide, descreve-
se uma série de papéis, objetos e eventos, apresentados na Figura 23.
Figura 23 – Papéis, eventos e objetos do Scrum. Fonte: Ovesen, 2013.
Sintetizando o descrito nos trabalhos de autores como Varaschim (2009) e
Pinto (2010), descreve-se o processo do Scrum nos seis passos a seguir:
Ao início de um Sprint realiza-se uma reunião de planejamento, Sprint
Planning Meeting, na qual define-se o que será desenvolvido com a
participação das principais partes interessadas do projeto, sendo
indispensável a presença dos: Product Owner, cliente; Scrum Master,
gerente do projeto e; Development Team, equipe de desenvolvimento.
Nessa primeira reunião define-se a lista, Sprint Backlog, com todas as
tarefas que a equipe se compromete a realizar durante o próximo
Sprint. Essa lista é gerada a partir da lista, Product Backlog, com todos
os requisitos do produto e falhas a serem corrigidas no sistema,
priorizada pelo Product Owner.
60
Durante o Sprint, são realizadas reuniões diárias com a equipe, Daily
Scrum, com duração média de 15 minutos, para acompanhamento e
controle do progresso do projeto, bem como identificação de possíveis
dificuldades encaradas pela equipe. É comum nessas reuniões que se
utilize a ferramenta gráfica conhecida como Burndown Chart,
representado na figura 24, que facilita a visualização do andamento do
projeto.
Figura 24 – Burndown Chart. Fonte: Varaschim, 2009.
Ao final de cada Sprint, uma entrega deve ser realizada. Por isso, é
recomendado que as atividades do Sprint Backlog não sejam
desenvolvidas paralelamente, evitando que tarefas fiquem quase
prontas, mas não haja nenhuma completamente terminada ao fim de
um Sprint. Qualquer tarefa não concluída em um Sprint deve retornar ao
Product Backlog.
Antes que se inicie outro Sprint é realizada uma reunião, a Sprint
Review Meeting, na qual são apresentados os avanços alcançados no
último Sprint para a avaliação do Product Owner, verificando se o
objetivo do Sprint foi atingido.
Por fim, uma última reunião acontece entre a equipe e o Scrum Master.
Denominada Sprint Retrospective, essa reunião tem por objetivo que os
participantes analisem o Sprint, promovendo a discussão de acertos e
erros para buscar formas de melhorar futuros Sprints.
61
Existem ainda outras práticas como a utilização do Burndown Chart,
consideradas incrementos ao método, mais detalhes sobre essas práticas podem ser
encontradas no trabalho de Varaschim (2009).
Ao fim de sua análise dos métodos do Scrum, Ovesen (2013) diz que o Scrum
traz maior foco e eficiência para a equipe, bem como melhorias significativas na
comunicação interna e na atitude, pois incentiva os participantes a ter um papel mais
ativo durante o projeto.
Além disso, Varaschim (2009) verificou que o Scrum é altamente recomendável
para empresas que tenham no seu ciclo de projetos produtos dinâmicos e que
possuam alta taxa de mudança de requisitos, o que também ocorre com os projetos de
sistemas mecatrônicos.
Mas, por outro lado, ainda Ovesen (2013) relata que alguns gestores podem
avaliar o Scrum negativamente quanto ao planejamento de longo prazo, dependendo
das práticas adotadas. Porém, o autor afirma que a utilização de um Scrum mais
completo pode incluir processos para o planejamento de longo prazo. Ele afirma ainda
que o Scrum pode ser aplicado em diferentes projetos e, em muitos casos ser utilizado
conjuntamente com as ferramentas de gestão tradicionais.
Pensando no Scrum para aplicação em projetos de sistemas físicos, Pinto
(2010) argumenta que como o Scrum é um processo de gestão de projetos de TI, essa
aplicação faz mais sentido quando complementada com outros processos mais ligados
às práticas de engenharia.
3.3.3. PMBoK
O PMBoK é um guia de conhecimentos para o gerenciamento de projetos,
desenvolvido pelo PMI. Sua finalidade é promover o conhecimento e as boas práticas
referentes ao gerenciamento de projetos. Estando presente em 185 países, o PMI
busca difundir esses conhecimentos ao redor do mundo.
O PMI é uma referência na área de gerenciamento de projetos, tendo sido
acreditado como desenvolvedor de padrões pelo American National Standard Institute
(ANSI), em outubro de 1998. Os conhecimentos e práticas descritos no PMBoK,
conforme afirma Stanleigh (2003, p. 2), “aplicam-se à maioria dos projetos, na maioria
das vezes e que há amplo consenso sobre seu valor e aplicabilidade”. Desse modo, o
PMBoK não é uma metodologia para o gerenciamento de projetos e sim um padrão
que identifica e descreve os processos recomendados para tal, sendo utilizado para o
desenvolvimento de metodologias nessa área. O guia distribuído pelo Project
62
Management Institute (2013) propõe a utilização de nove áreas de conhecimento,
conforme pode-se ver na figura 25.
Figura 25 – Áreas de Conhecimento do PMBoK. Fonte: Autor
O conjunto de processos que podem ser utilizados no gerenciamento de um
projeto, apresentados pelo Project Management Institute (2013), são divididos de
acordo com as áreas de conhecimento já demonstradas e estão expostos no quadro 2.
Quadro 2 – Processos de gerenciamento de projetos - PMBoK.
Áreas de Conhecimento
Grupos de processos de gerenciamento de projetos
Grupo de processos
de iniciação
Grupo de processos de planejamento
Grupo de processos de
execução
Grupo de processos de
monitoramento e controle
Grupo de processos de encerramento
Gerenciamento da
integração do projeto
Desenvolver o termo de abertura do projeto.
Desenvolver o plano de gerenciamento do projeto.
Orientar e gerenciar o trabalho do projeto.
Monitorar e controlar o trabalho do projeto; Realizar o controle integrado de mudanças.
Encerrar o projeto ou fase.
Gerenciamento do escopo do projeto
Planejar o gerenciamento do escopo; Coletar os requisitos; Definir o escopo; Criar a estrutura analítica do projeto (EAP).
Validar o escopo; Controlar o escopo.
63
Áreas de
Conhecimento
Grupos de processos de gerenciamento de projetos
Grupo de processos
de iniciação
Grupo de processos de planejamento
Grupo de processos de
execução
Grupo de processos de
monitoramento e controle
Grupo de processos de encerramento
Gerenciamento do tempo do
projeto
Planejar o gerenciamento do cronograma; Definir as atividades; Sequenciar as atividades; Estimar os recursos das atividades; Estimar as durações das atividades; Desenvolver o cronograma.
Controlar o cronograma.
Gerenciamento dos custos
do projeto
Planejar o gerenciamento dos custos; Estimar os custos; Determinar o orçamento.
Controlar os custos.
Gerenciamento da qualidade
do projeto
Planejar o gerenciamento da qualidade.
Realizar a garantia da qualidade.
Controlar a qualidade.
Gerenciamento dos recursos humanos do
projeto
Planejar o gerenciamento dos recursos humanos.
Mobilizar a equipe do projeto; Desenvolver a equipe do projeto; Gerenciar a equipe do projeto.
Gerenciamento dos recursos
de comunicações
do projeto
Planejar o gerenciamento das comunicações.
Gerenciar as comunicações.
Controlar as comunicações.
64
Áreas de
Conhecimento
Grupos de processos de gerenciamento de projetos
Grupo de processos
de iniciação
Grupo de processos de planejamento
Grupo de processos de
execução
Grupo de processos de
monitoramento e controle
Grupo de processos de encerramento
Gerenciamento dos riscos do
projeto
Planejar o gerenciamento dos riscos; Identificar os riscos; Realizar a análise qualitativa dos riscos; Realizar a análise quantitativa dos riscos; Planejar as respostas aos riscos.
Controlar os riscos.
Gerenciamento das
aquisições do projeto
Planejar o gerenciamento das aquisições.
Conduzir as aquisições.
Controlar as aquisições.
Encerrar as aquisições.
Gerenciamento das partes interessadas
no projeto
Identificar as partes interessadas.
Planejar o gerenciamento das partes interessadas.
Gerenciar o engajamento das partes interessadas.
Controlar o engajamento das partes interessadas.
Fonte: Adaptado de Project Management Institute, 2013.
Esse conjunto de 47 atividades é considerado essencial para um pleno
gerenciamento de projetos, sendo a sua adoção reconhecida como boa prática entre
os profissionais que atuam com projetos. A utilização desses processos é
recomendável para qualquer projeto, mas é principalmente recomendado para projetos
que apresentam alto grau de complexidade, como é o caso dos projetos de sistemas
mecatrônicos, tratados por essa dissertação.
3.3.4. ISO 10006
De acordo com Associação Brasileira de Normas Técnicas (2000) e Stanleigh,
(2003), a norma ISO 10006 define como é a relação entre as práticas da gestão da
qualidade e o gerenciamento de projetos, fornecendo diretrizes para ampla aplicação
em projetos acerca de pontos importantes dos mesmos. Podendo essas diretrizes
65
serem aplicadas a projetos, programas ou portfólios, de diversas complexidades,
portes e tamanhos, sejam eles gerenciados por um indivíduo ou por uma equipe.
As diretrizes mencionadas pela Associação Brasileira de Normas Técnicas
(2000) empregam os processos de gerenciamento de projetos para discutir as suas
aplicações. O quadro 3 apresenta uma relação e um resumo dos processos de
gerenciamento de projetos propostos pela ISO 10006.
Quadro 3 - Processos de gerenciamento de projetos - ISO 10006.
ÁREA PROCESSO DESCRIÇÃO
Processo Estratégico
Processo estratégico
Define a direção do Projeto e gerencia a realização de outros processos do Projeto.
Processos de Gerenciamento de Interdependências
Iniciação do Projeto e desenvolvimento do plano de Projeto
Avaliação dos requisitos do cliente e outras partes interessadas, preparando um plano do Projeto e iniciando outros processos.
Gerenciamento das interações
Gerenciamento das interações durante o Projeto.
Gerenciamento das mudanças
Antecipação a mudanças e gerenciamento destas ao longo de todos os processos.
Encerramento Conclusão dos processos e obtenção de retroalimentação (feedback)
Processos Relacionados ao
Escopo
Desenvolvimento conceitual
Definição das linhas gerais sobre o que produto do Projeto irá fazer.
Desenvolvimento e controle do escopo
Documentação das características do produto do Projeto em termos mensuráveis e controle dos mesmos.
Definição das atividades
Identificação e documentação das atividades e etapas necessárias para se alcançarem os objetivos do Projeto.
Controle das atividades
Controle do trabalho efetivo realizado no Projeto.
Processos Relacionados ao
Tempo
Planejamento de dependência das atividades
Identificação das inter-relações, interações lógicas e dependências entre as atividades do Projeto.
Estimativa de duração
Estimativa da duração de cada atividade em conexão com atividades específicas e com os recursos necessários.
Desenvolvimento do cronograma
Inter-relação dos objetivos de prazo do Projeto, dependências das atividades e suas durações como estrutura para o desenvolvimento de cronogramas gerais e detalhados.
Controle do cronograma
Controle da realização das atividades do Projeto, para confirmação do cronograma proposto ou para realizar as ações apropriadas para recuperar atrasos.
Processos Relacionados ao
Estimativa de custos
Desenvolvimento de estimativa de custos para o Projeto.
66
ÁREA PROCESSO DESCRIÇÃO
Custo Orçamento
Utilização de resultados provenientes da estimativa de custos para elaboração do orçamento do Projeto.
Controle de custos
Controle de custos e desvios ao orçamento do Projeto.
Processos Relacionados aos
Recursos
Planejamento de recursos
Identificação, estimativa, cronograma e alocação de todos os recursos principais.
Controle dos recursos
Comparação da utilização real e planejada de recursos corrigindo, se necessário.
Processos Relacionados ao
Pessoal
Definição de estrutura organizacional
Definição de uma estrutura organizacional para o Projeto, baseada no atendimento às necessidades de Projeto, incluindo a identificação das funções e definindo autoridades e responsabilidades.
Alocação da equipe
Seleção e nomeação de pessoal suficiente com a competência apropriada para atender as necessidades do Projeto.
Desenvolvimento da equipe
Desenvolvimento de habilidades individuais e coletivas para aperfeiçoar o desempenho do Projeto.
Processos Relacionados à Comunicação
Planejamento da comunicação
Planejamento dos sistemas de informação e comunicação do Projeto.
Gerenciamento das informações
Tornar disponíveis as informações necessárias da organização do Projeto aos membros e outras partes interessadas
Controle da comunicação
Controle da comunicação de acordo com o sistema de comunicações planejado.
Processos Relacionados ao
Risco
Identificação de riscos
Determinação de riscos no Projeto.
Avaliação de riscos
Avaliação da probabilidade de ocorrência de eventos de risco e o impacto destes sobre o Projeto.
Desenvolvimento de reação ao risco
Desenvolvimento de planos para reação ao risco.
Controle de riscos Implementação e atualização dos planos de risco.
Processos Relacionados a
Suprimentos
Planejamento e controle de suprimentos
Identificação e controle do que deve ser adquirido e quando.
Documentação dos requisitos
Compilação das condições comerciais e requisitos técnicos.
Avaliação dos fornecedores
Avaliação e determinação de quais fornecedores devem ser convidados a fornecer produtos.
Subcontratação Publicação dos convites à proposta, avaliação das propostas, negociação, preparação e assinatura do contrato.
Controle do contrato
Preparação e assinatura do contrato.
Fonte: Adaptado de Associação Brasileira de Normas Técnicas, 2000.
67
Em um projeto particular, não existirão necessariamente todos os processos
discutidos na ISO 10006, porém, dependendo do projeto, pode ser necessária a
utilização de outros processos, esclarece a Associação Brasileira de Normas Técnicas
(2000).
Stanleigh (2003) afirma que a ISO 10006 não deve ser usada para fins de
certificação ou registro por ser um documento de diretrizes, sendo seu objetivo geral o
de criar e manter a qualidade em projetos através da sistematização de processos.
Assim, as diretrizes da ISO 10006 vêm sendo utilizadas para realização de auditorias
em projetos para garantir a aderência das práticas empregadas com o estabelecido
pela norma.
Uma comparação entre o que se apresenta na ISO 10006 e no PMBoK, quanto
a: definição de projeto, características de um projeto, definição de plano de qualidade,
alinhamento estratégico da gestão da qualidade, comprometimento da alta
administração, foco nas partes interessadas, liderança, envolvimento de pessoas,
processos, entre outros, pode ser encontrada em detalhes no trabalho de Stanleigh
(2003).
3.4. GERENCIAMENTO DE PROJETOS DE SISTEMAS MECATRÔNICOS
De acordo com o Project Management Institute (2013), como o trabalho
executado em cada fase é geralmente de caráter diferente das anteriores, as
habilidades exigidas da equipe do projeto podem variar entre essas fases. Assim, para
gerar um sistema eficiente, Chami et al. (2013) afirmam que os projetos de sistemas
mecatrônicos enfrentam um grande desafio no que tange a integração dos fatores
humanos envolvidos quanto a seus procedimentos, linguagens, métodos de
modelagem e habilidades com softwares.
Budynas e Nisbett (2011) destacam a importância das atividades de
comunicação entre os profissionais envolvidos em um projeto, através de palavras e
imagens, e defendem que as organizações empreguem esforços para que essa
comunicação seja o mais eficaz possível, uma vez que o sucesso dos projetos
depende diretamente disso. Além disso, é a comunicação dos integrantes que gera o
fluxo de informações do projeto.
Como Shetty e Kolk (2011) apontam, para um bom desenvolvimento de
projetos é necessário que haja um adequado fluxo coordenado de conhecimentos e
informações importantes entre diferentes grupos de especialistas. Desse modo, a falta
de uma linguagem comum de interface torna difícil essa troca de informações em
processos de engenharia simultânea, dependendo o sucesso desses esforços,
68
também, de como se lida com as barreiras organizacionais para favorecer a
cooperação entre funcionários. Eles apontam ainda que as características da
engenharia simultânea são:
Melhor definição do produto sem alterações de última hora;
Projeto para fabricação e montagem realizadas na fase inicial do
projeto;
Processo de como o desenvolvimento de produtos é bem definida;
Estimativas de custo melhor; e
Decréscimo das barreiras entre design e manufatura.
Para Pahl et al. (2007) as equipes devem ser formadas por profissionais de
engenharia mecânica, eletrônica, controle, software e de outras disciplinas relevantes.
O funcionamento da relação entre as equipes de desenvolvimento dos projetos de
sistemas mecatrônicos e a equipe de manufatura é apontado nos estudos realizados
por Pang et al. (2011), como pode ser visto na figura 26.
Figura 26 – Interação de processos de um projeto de sistemas mecatrônicos. Fonte: Pang et al., 2011.
Para Kutz (2007) essa relação proporciona a troca de informações sobre o
projeto e pode ocorrer diretamente entre os membros das equipes e por meio de um
repositório de dados e informações. Ele relata ainda que, além de facilitar a
comunicação do projeto, os engenheiros de projeto que trabalharem com produtos
similares poderão se beneficiar ao usar as informações do repositório para tomar
melhores decisões, essas informações também são importantes para os projetos das
gerações seguintes de produtos.
De acordo com Associação Brasileira de Normas Técnicas (2000) para que,
dentro das organizações envolvidas em projetos, a qualidade abranja todos os níveis
69
responsáveis por seus processos e produtos, a gerência deve empenhar-se para
assegurar que os projetos estejam de acordo com os padrões de qualidade desejados.
Ao se unir um conjunto de boas práticas, procedimento e regras, como os que
já foram citados nesse capítulo, constituiu-se uma metodologia voltada a projetos
mecatrônicos na dissertação em questão, seguindo a metodologia descrita no capitulo
a seguir.
70
4. METODOLOGIA PARA PROJETOS
DE SISTEMAS MECATRÔNICOS
Sabe-se que há na atual literatura distintos métodos para desenvolvimento de
produtos mecatrônicos, bem como métodos e padrões para o gerenciamento de
projetos, conforme mencionado nos capítulos anteriores dessa dissertação.
Entretanto, não se encontra na literatura uma metodologia que diga respeito
simultaneamente aos aspectos técnicos e gerenciais dos projetos de sistemas
mecatrônicos podendo ser utilizada pelas organizações de projeto especificamente,
como é o caso das empresas de engenharia que trabalham apenas com
desenvolvimento de projetos como prestação de serviço.
Tendo em vista o preenchimento dessa lacuna, após realizar uma extensa
análise das boas práticas contidas na literatura, apresenta-se a seguir uma
metodologia a ser utilizada por profissionais de gerenciamento de projetos e
empreendedores que trabalhem com projetos de sistemas mecatrônicos, a fim de
facilitar o desenvolvimento de seus projetos ou, até mesmo, de suas próprias
metodologias de trabalho.
4.1. DIFUSÃO DAS METODOLOGIAS E PRÁTICAS
Com o intuito de verificar o quanto as metodologias e práticas, presentes no
conteúdo utilizado como referencial teórico dessa dissertação, estão sendo difundidas
na indústria nacional, através da transmissão de conhecimentos para novos
profissionais formados nas universidades, foi realizada uma pesquisa junto aos
docentes de uma universidade federal para averiguar sua experiência com projetos de
sistemas mecatrônicos e metodologias de gerenciamento de projetos. O método de
pesquisa utilizado foi o survey de corte-transversal6 e descritivo, aplicado por meio de
questionários.
6 O método de pesquisa survey corte transversal é um método quantitativo baseado em questionários ou entrevistas que ocorre em determinado momento para que seja averiguado o estado das variáveis sob estudo. Uma pesquisa survey pode ainda, concomitantemente, ser do tipo explanatória, quando pretende-se testar uma teoria e as relações causais aplicadas, e do tipo descritiva, quando se deseja identificar opiniões manifestadas em um grupo de pessoas.
71
O questionário foi elaborado com 11 questões, sendo 1 opcional e 10
obrigatórias, 2 abertas e 9 fechadas, de modo que uma era opcional e aberta e visava
identificação do participante para caso houvesse interesse do mesmo em uma
participação futura na pesquisa. Além disso, o questionário contava com um espaço
aberto para observações e sugestões.
O questionário foi disponibilizado virtualmente como formulário através da
ferramenta Google Drive e distribuído por e-mail para 350 docentes dos diversos
programas de engenharia da universidade em questão no dia 14 de janeiro, coletando-
se resultados até o dia 10 de fevereiro de 2015. Entretanto, de todas as solicitações
enviadas, apenas 50 foram respondidas, dentre as quais 13 respostas foram
negativas. Desse modo 37 docentes participaram da pesquisa respondendo ao
questionário.
Dos questionários respondidos pode-se averiguar, de acordo com o afirmado
pelos participantes, que houve uma média de participação em 3,6 projetos por docente
nos últimos 5 anos. Um fato notório é que dentre os 33 docentes que não afirmaram
terem participado de projetos nos quais foram utilizadas metodologias para o
gerenciamento dos projetos, apenas 3 geraram patente em pelo menos um projeto,
enquanto dentre os 4 que afirmaram ter sido utilizada alguma metodologia, 2 geraram
alguma patente.
Com relação a participação em projetos de sistemas mecatrônicos, porém,
apenas 6 dos participantes afirmaram já ter participado. Dentre esses: 2 alegaram que
a organização do projeto possuía certificação de qualidade; 1 afirmou que foi utilizada
uma metodologia para o gerenciamento do projeto, Scrum; 1 respondeu que já utilizou
engenharia simultânea em algum projeto e; 1 disse que um dos projetos em que
participou gerou uma patente. Destaque-se, então, o fato de que o docente que
utilizou uma metodologia de gerenciamento de projetos, Scrum, e que trabalhou com
uma instituição com certificação de qualidade, ter sido o mesmo que gerou patente.
Além disso, pode-se verificar o envolvimento de profissionais de diferentes
formações nos projetos de sistemas mecatrônicos. O quadro 4 demonstra como se
deu a participação desses profissionais nesses projetos, de acordo com o respondido
na pesquisa.
Dentro da amostra, percebe-se que quatro dos seis docentes com experiência
em projetos de sistemas mecatrônicos, relataram o envolvimento de engenheiros
biomédicos em algum dos projetos que participaram, o que denota um maior know-
how dos docentes quanto ao desenvolvimento de projetos de sistemas mecatrônicos
voltados para a área médica.
72
Quadro 4 – Formação de envolvidos nos projetos de sistemas mecatrônicos.
Engenharia Elétrica
Engenharia Mecânica
Ciências da Computação
Outras Eng.
Técnicos (Mec., Eltr. TI.)
Outros Áreas
Sim - - Biomédica - -
Sim Sim Sim Metalúrgica - Direito
Sim Sim Sim Biomédica - Saúde
Sim Sim - Biomédica - -
Sim - Sim Biomédica Eletrônica Saúde
- Sim - Nuclear - Física
Fonte: Autor.
A pesquisa revelou que são poucos os docentes com plena experiência em
projetos de sistemas mecatrônicos, sendo raros os que simultaneamente possuem
know-how com metodologias de gerenciamento de projetos. Desse modo, é difícil
assumir que os profissionais recém-formados tenham sido expostos, por tempo
suficiente, aos conhecimentos que envolvem projetos de sistema mecatrônicos e as
metodologias que envolvem seu desenvolvimento técnico e gerenciamento. Assim,
cabe aos profissionais que desejarem atuar na área, e até mesmo àqueles que já
atuam, mas que precisam desenvolver mais conhecimento na área, buscar cursos
específicos, ou por conteúdos para consulta e estudo, como o que se apresenta nessa
dissertação.
Para propiciar uma análise mais detalhada dos resultados da pesquisa, o
questionário utilizado para essa pesquisa está exposto no apêndice A dessa
dissertação, enquanto um infográfico com todas as respostas, para as principais
questões do questionário, pode ser visualizado no apêndice B.
4.2. PRINCIPAIS ATIVIDADES E DECISÕES
Os subcapítulos a seguir tratam da metodologia proposta, apresentando
fluxogramas com as atividades da metodologia e suas decisões. Da mesma maneira
que a metodologia se divide em fases, esse subcapítulo está dividido em seis partes
correspondentes. As fases da metodologia estão apresentadas na figura 27 e são as
que seguem: Captação da Projeto; Iniciação do Projeto; Projeto Conceitual; Projeto
Básico; Projeto Detalhado; e Testes e Validação.
73
Figura 27 – Fases da Metodologia. Fonte: Autor.
Antes de introduzir o leitor aos fluxogramas apresentados nos subcapítulos a
seguir, para auxiliar seu entendimento, a figura 28 apresenta uma legenda para o que
será encontrado.
Figura 28 – Legenda para os fluxogramas da metodologia. Fonte: Autor.
Essa legenda serve para os fluxogramas desse subcapítulo, 5.1., que trata das
principais atividades e decisões envolvidas nos processos do projeto de um sistema
mecatrônico seguindo a metodologia proposta.
4.2.1. Fase 1 – Captação do Projeto
Antes do início de qualquer projeto há uma etapa organizacional estratégica.
Em qualquer organização o fluxo dessa etapa começa com uma análise conjunta do
plano estratégico da empresa em associação aos dados do mercado, resultando em
informações como as que se referem às atuais demandas do mercado, capacidade
interna para atendê-las, possíveis nichos de mercado a serem explorados e etc.
Para empresas orientadas a produção de bens de consumo, Barbalho (2006)
demonstrou como se dá o fluxograma dos processos envolvidos nessa etapa inicial, o
que pode ser visualizado na figura 29, na qual se aponta que as entradas para o
processo podem vir tanto do planejamento estratégico da empresa, quanto de dados
do mercado. É importante destacar que as etapas que envolvem projetos, projeto
conceitual e início do planejamento do projeto, são uma adaptação dessa dissertação.
74
Os dados gerados nessa primeira análise servem como diretriz para uma
seguinte, envolvendo as linhas de produtos, conforme pode ser visto no trabalho de
Barbalho (2006), tendo Barbalho e Rozenfeld (2013) reiterado essa posição. Uma
prática comum nessa etapa é que se avaliem as reações do mercado às ofertas
passadas e estudem-se eventuais tendências.
Ainda, uma terceira análise identifica as forças e fraquezas da organização,
nessa etapa costuma-se ainda identificar oportunidades e ameaças em um exercício
em que a alta administração busca se preparar para futuras mudanças de cenário.
Com base em todas as informações geradas, então, definem-se os objetivos
para as linhas de produto. Nessa última etapa pode ser gerado um documento com as
diretrizes para o portfólio da empresa com informações sobre quais produtos serão
continuados, descontinuados, melhorados, desenvolvidos e inseridos no mercado.
Figura 29 – Fluxograma das etapas antecedentes aos projetos. Fonte: Adaptado de Barbalho, 2006.
A partir de então, iniciam os trabalhos para direcionar as estratégias funcionais.
Essa etapa marca o início das atividades conceituais dos projetos, quando, embora as
equipes de projeto ainda não estejam formadas, já há conceituação acerca do produto
final.
Chami et al. (2013) explicam que durante essa fase os engenheiros
transformam os objetivos das partes interessadas em requisitos do sistema, a fim de
começar a analisar a solução conceitual mais adequada. Horikawa et al. (2002)
defendem que essa análise, além de se configurar fator fundamental para comparação
das diversas alternativas, permite a seleção das melhores. Assim, os projetos
75
selecionados ao fim dessa etapa, ou seja, as estratégias que serão adotadas pela
indústria, deverão ser documentadas e continuadas.
Nesse ponto, normalmente, a organização empreendedora decide se executará
o projeto ou se terceirizará sua execução, considerando o risco estratégico associado
ao projeto e sua qualificação com relação aos possíveis prestadores de serviço, entre
outros fatores. Caso a decisão tomada seja pela execução do projeto, o MRM
apresentado por Barbalho (2006) poderá ser empregado pela organização
empreendedora e de projeto, preferencialmente em associação a norma ISO 10006
e/ou ao guia PMBoK. Dependendo das características desse projeto, pode-se ainda
utilizar em paralelo as práticas da metodologia Scrum, bem como o modelo V durante
o desenvolvimento técnico do produto.
Se a decisão da organização empreendedora for por terceirizar o
desenvolvimento do projeto a uma empresa de engenharia, essa terá nessa
dissertação a base de conhecimentos necessária para o desenvolver desse projeto,
sendo recomendável a utilização da norma ISSO 10006 e/ou do guia PMBoK, bem
como da literatura indicada para a metodologia escolhido para o gerenciamento do
projeto, seja essa uma metodologia convencional ou uma GAP.
A figura 30 exibe os processos da primeira fase, denominada Captação do
Projeto da metodologia desenvolvida nessa dissertação, orientada para o
desenvolvimento de projetos de sistemas mecatrônicos pela organização do projeto,
seja essa parte da organização empreendedora ou não. Essa fase recebe esse nome,
por ocorrer antes do início do projeto.
Previamente ao início dos esforços do projeto objetiva-se, principalmente, obter
um entendimento pleno quanto aos requisitos necessários para o desenvolvimento do
sistema, de acordo com as necessidades e os desejos do cliente. Essa etapa tem
como principal entrega uma proposta de serviço que deve conter os requisitos
solicitados pelo cliente, tendo-se o cuidado de especificar o que não será realizado
pela organização do projeto.
O processo de captar as necessidades e desejos do cliente, normalmente
ocorre em reuniões com o cliente nas quais deve-se tomar nota do maior número
possível de percepções sobre o que está sendo exposto. É imprescindível que os
participantes desse processo estejam atentos a todas as expressões do cliente, pois
além do que se diz, a forma com que é dito pode trazer um entendimento melhor sobre
as prioridades do cliente. Ao se avaliar as pretensões do cliente, devem ser
considerados para o sistema não apenas fatores como o serviço a ser realizado, o
custo de desenvolvimento e a produtividade, como também os referentes ao
desempenho energético e ambiental.
76
Figura 30 – Fluxograma: Captação do projeto. Fonte: Autor.
Sempre que possível, é recomendável que antes das reuniões seja acordado
com o cliente a quantidade de pessoas que participará da reunião, buscando-se levar
77
mais de uma pessoa por parte da organização do projeto a fim de se reunir o maior
número de observações possíveis.
Uma vez tendo tomado nota dos desejos e necessidades do cliente, o primeiro
passo a ser tomado é a mobilização dos principais profissionais que participarão do
projeto, caso seja iniciado, sendo esses os membros com mais conhecimento
relacionados às áreas de conhecimento envolvidas no projeto.
Em seguida, devem-se converter essas observações em requisitos para o
sistema. É importante que essas observações sejam escalonadas de acordo com a
percepção de prioridade do cliente, a fim de separá-las em requisitos primários e
secundários. Normalmente, as observações mais prioritárias compõem o grupo de
necessidades do cliente e são convertidas em requisitos primários, de modo que as
demais observações serão transformadas em requisitos secundários.
Nesse momento, os requisitos não são necessariamente tecnicamente
refinados, o mais importante aqui é que haja consenso entre o percebido pela
organização do projeto e o exposto pelo cliente. Para assegurar essa ocorrência é
recomendado que seja realizada uma verificação junto ao cliente dos requisitos
registrados. Caso não haja esse consenso, deve ser feito o alinhamento entre as
partes para evitar descontentamentos futuros.
Após se ter alinhado as necessidades e desejos dos clientes com os requisitos
registrados para o projeto, deve-se avaliar se a execução do projeto estará de acordo
com o planejamento estratégico da organização do projeto. Nesse ponto é importante
que a organização considere além dos riscos associados aos aspectos técnicos e
financeiros, os humanos e políticos e culturais, relativos não só aos envolvidos no
desenvolvimento do projeto, como também a todas demais partes interessadas, ou
seja, aquelas que serão afetadas direta ou indiretamente pelo projeto.
Caso haja algum empecilho que vá de encontro ao interesse estratégico da
organização do projeto, esse ponto deve ser negociado com o cliente em busca de
uma adaptação dos requisitos que viabilize a elaboração da proposta de prestação de
serviço. Se a organização do projeto e o cliente não chegarem a um acordo, os
esforços devem ser suspensos, registrando-se as lições aprendidas. Entretanto, se
houver um consenso deve-se prosseguir para a elaboração da proposta.
A proposta de prestação de serviço deve ser elaborada conforme orientações
dadas pelo cliente, afinal, se o cliente for externo, ou seja, se a organização
empreendedora não compreender a organização o projeto, ele poderá receber
diversas propostas de serviço. Nessa situação, uma proposta que fuja dos padrões de
elaboração adotados por ele pode ser descartada, sem mesmo ser analisada.
78
Após sua elaboração, a proposta deve ser apresentada, entregue e submetida
à análise do cliente, último processo da fase Captação do Projeto. Se a proposta não
for aceita, suspendem-se os esforços e registram-se as lições aprendidas. Para
efetuar esse registro, é importante que se busque um retorno do cliente sobre o motivo
da recusa da proposta, caso possa ser explicado. Uma vez que a proposta seja aceita
pelo cliente, as partes devem formalizar seus compromissos por meio de um contrato
e em seguida iniciar os esforços de projeto, prosseguindo para a fase dois da
metodologia.
4.2.2. Fase 2 – Iniciação do Projeto
A fase de iniciação do projeto é estratégica para a execução do mesmo, é
também, dentre todas outras, a que envolve mais detalhes e tomadas de decisões,
embora não seja uma fase que demande muito trabalho quando comparada as
demais. Isso se dá por essa ser a fase na qual se define o escopo do projeto, bem
como o escopo do sistema mecatrônico a ser desenvolvido por meio da tradução do
que foi percebido na fase anterior para termos técnicos.
Para evitar erros, que se cometidos nessa fase podem ser propagados
despercebidamente através das demais etapas do projeto, gerando desperdícios de
recursos e insatisfações com os resultados finais, essa fase deve ser tratada com o
máximo de cautela por parte da organização do projeto. Sendo altamente
recomendável o envolvimento de profissionais experientes nas tomadas de decisão
contidas na mesma.
O que marca o final bem sucedido dessa fase é a entrega de uma proposta
técnica, contendo o escopo do projeto, o escopo do sistema mecatrônico, o orçamento
e o cronograma base. O escopo do projeto delimita quais esforços serão despendidos
pela organização do projeto, deixando nítido o que será e o que não será realizado. Já
o escopo do sistema trata dos requisitos técnicos do sistema que devem ser
atendidos.
Tendo os esforços do projeto sido iniciados, deve-se realizar um estudo do
estado da arte para o problema em questão, devendo-se averiguar se já são
encontradas soluções tecnológicas no mercado que permitam o desenvolvimento do
sistema proposto e em caso positivo se já foram produzidos sistemas semelhantes. A
figura 31 demonstra o fluxograma de todas as atividades envolvidas na fase da
metodologia proposta pelo autor.
Nessa fase de estudos, buscam-se soluções para todos os requisitos presentes
na proposta, bem como para aqueles que não foram descritos, mas que se fazem
79
necessários para o cumprimento daquilo que foi solicitado, complementando a
proposta.
Figura 31 – Fluxograma: Iniciação do projeto. Fonte: Autor.
80
Essa complementação é realizada tendo como referência os requisitos
primários para o sistema, após a realização de uma análise técnica da proposta.
Embora nem sempre a complementação da proposta faça-se necessária, quando
assim o for, deverá então ser conceitualizada uma nova solução, cabendo então a
solicitação de alteração do escopo.
Ao surgir uma solicitação de alteração de escopo para a proposta, com foco
nos requisitos primários do projeto deve-se arquivar a versão antiga da proposta e
avaliar a viabilidade econômica para a organização do projeto da nova versão da
proposta, com escopo alterado, cabendo a decisão final sobre a continuidade dos
esforços a alta administração da organização do projeto.
Caso os esforços venham a ser descontinuados, nessa ou em qualquer outra
das fases a seguir, deve-se informar os interessados sobre o cancelamento do projeto
e registrar as lições aprendidas.
Assim como a Associação Brasileira de Normas Técnicas (2000) recomenda
para as organizações empreendedoras que essas possuam um sistema capaz de
adquirir, armazenar, atualizar e recuperar informações sobre os diversos projetos,
garantindo que estas informações venham a ser utilizadas.
Recomenda-se aqui que as organizações dos projetos que por acaso não
sejam parte das organizações empreendedoras, dos projetos em questão, também
sigam essa diretriz, registrando o conhecimento gerado durante os projetos
executados e fazendo uso desse material sempre que forem executar novos projetos.
O fato de a proposta do projeto compreender todos os requisitos primários para
que se componha uma solução, não implica na possibilidade de desenvolvimento
dessa solução, tendo em vista que pode haver alguma restrição impeditiva para que a
organização do projeto desenvolva aquele sistema, esteja essa relacionada à
escassez de acesso a recursos materiais ou humanos, ou ainda pelo fato do
desenvolvimento da solução ir de encontro a algum outro compromisso contratual da
organização do projeto, entre outras restrições.
Além disso, algum dos requisitos primários pode ser tecnicamente inviável para
o desenvolvimento da solução. Nesse caso, bem como caso haja uma restrição
impeditiva, a organização do projeto deve negociar junto à organização
empreendedora uma alteração de escopo que possibilite o desenvolvimento do
sistema. Se for solicitada uma alteração, deve-se repetir o processo já mencionado
para conceitualização de uma nova solução e caso contrário, repete-se então o
procedimento para cancelamento do projeto.
81
Estando a proposta de acordo com os requisitos, não havendo restrições
impeditivas e essa sendo tecnicamente viável7, devem-se analisar os requisitos
secundários, os que ainda não foram agregados ao escopo da proposta, e verificar se
há possibilidade de ampliação do escopo para que a proposta atenda a esses
requisitos. Após essa verificação, caso seja possível melhorar a proposta, ampliando o
escopo, deve-se especificar a possibilidade de melhoria e consultar o cliente para
saber se ele tem interesse nas possíveis alterações, informando-lhe que essa
alteração acarretará em alteração do prazo e custo do projeto.
Caso o cliente esteja de acordo, deve-se solicitar a alteração do escopo. Se a
alta administração da organização do projeto não aprovar a melhoria, informa-se o
cliente sobre a inviabilidade econômica da alteração de escopo e prepara-se o
orçamento e o cronograma base para o projeto, com base na versão atual da
proposta, sem melhoria. Sendo a solicitação de alteração aceita, devem-se pular as
atividades previstas no fluxograma até a atividade de preparação do orçamento e do
cronograma base.
Entretanto, se não houver requisito secundário, não for possível atender aos
que restarem, ou se o cliente não possuir interesse na ampliação do escopo da
proposta, devem-se iniciar imediatamente os esforços para elaboração do orçamento
e do cronograma base do projeto. Para tal, pode-se utilizar o Microsoft Excel, o
Microsoft Project e o Primavera Project, três das ferramentas mais utilizadas nessa
área, sendo a primeira mais geral e as duas últimas específicas para projetos. Ao fim
dessa atividade, o orçamento e o cronograma devem ser anexados a última versão da
proposta, com o escopo básico do sistema mecatrônico a ser desenvolvido, devendo
esse conjunto de documentos ser, então, submetido à aprovação do cliente.
Se a documentação não for aprovada, deve-se abrir negociação com o cliente,
passando pelo conjunto de atividades já descritos anteriormente, decorrente dessa
atividade. Porém, quando obtida a aprovação da documentação, parte-se, finalmente,
para a fase seguinte dessa metodologia, o desenvolvimento do projeto conceitual.
4.2.3. Fase 3 – Projeto Conceitual
A terceira fase dessa metodologia, projeto conceitual, concentra atividades
voltadas para o planejamento tático do projeto. Nessa fase toda a equipe que
7 É interessante expressar que embora, o método descrito por essa dissertação destine-se ao projeto do sistema, não abrangendo a sua fabricação, esse ponto deve ser considerado durante as análises de viabilidade técnicas do sistema proposto.
82
participará do projeto deve ser mobilizada, é nela que se define a primeira versão do
conceito físico do sistema e o método de gerenciamento de projetos. Essa opção fica
a critério da organização do projeto uma vez que cada projeto apresenta
características únicas, devendo assim ser gerenciadas de modos distintos. Além do já
mencionado, esclarece-se que essa fase tem como entrega o conjunto de planos do
projeto e o projeto conceitual do sistema mecatrônico.
A primeira ação a ser tomada nessa fase deve ser a mobilização do restante do
pessoal que participará do projeto. A partir de então, deve-se detalhar tecnicamente os
requisitos apresentados na proposta técnica. Dependendo do tipo de sistema
mecatrônico que se pretende desenvolver, um conjunto de diferentes atividades
deverá ser realizado nessa etapa. Fora o fluxograma das atividades dessa fase, a
figura 32 traz uma lista de subatividades que deverão ser realizadas durante o
detalhamento técnico dos requisitos da maior parte dos sistemas, sendo possível que
outras atividades além das descritas sejam necessárias.
Depois do detalhamento técnico dos requisitos deve-se definir uma forma e
corpo conceitual para o sistema em desenvolvimento, tendo em vista os requisitos
técnicos. Existem diversas ferramentas que facilitam esse processo, como o AutoCAD
e o Inventor da Autodesk e o SolidWorks da Dassault Systemes, que permitem o
desenho do sistema e seus componentes em duas e três dimensões. Com exceção do
AutoCAD, essas ferramentas permitem ainda a realização de simulações quanto à
movimentação do sistema, permitindo inclusive que sejam gerados vídeos, o que
potencializa a apresentação do projeto do sistema.
Uma vez que o desenho do sistema esteja pronto, esse deverá ser
apresentado ao cliente. Essa atividade tende a gerar um loop em que ocorrerão
iterações até que o cliente se satisfaça com o desenho apresentado. Portanto, é
recomendável que se apresente o desenho do sistema em reuniões que permitam um
diálogo mais aberto com o cliente.
Logo que se apresente um desenho que o cliente considere aceitável, deve-se
prosseguir para a definição do método de gerenciamento que será utilizado. No
subcapítulo 3.3. dessa dissertação foram apresentadas duas metodologias distintas
que podem ser aplicadas: PRINCE2™; e Scrum. Existem outras metodologias que
podem ser utilizadas, entretanto é recomendável que, independentemente da
metodologia adotada, pelo menos um dos padrões para gerenciamento de projetos,
guia PMBoK e ISO 10006, seja adotado.
Resolvida a questão relacionada ao método de gestão, deve-se elaborar o
cronograma físico-financeiro definitivo do projeto, tomando como base o escopo do
83
projeto e do sistema. É recomendável que se monte anteriormente a EAP do projeto e
que se listem todas as atividades que deverão ser realizadas.
Figura 32 – Fluxograma: Projeto conceitual. Fonte: Autor.
Outro ponto importante, é que se tenha uma relação de recursos que serão
alocados durante o desenvolvimento do projeto, bem como as quantidades de esforço
84
que os recursos humanos precisarão desprender para realização de cada atividade.
Diretrizes mais detalhadas para essa atividade podem ser encontradas na metodologia
escolhida para a gestão do projeto, bem como nas normas aplicáveis.
Após a elaboração do cronograma físico-financeiro do projeto, deve-se
submeter o mesmo a alta administração da organização, bem como ao cliente para
que se verifique se ambos estão de acordo com o conteúdo do mesmo. Se alguma
das partes discordar sobre o que se definiu e for solicitada a alteração do documento,
deve-se então avaliar a viabilidade da alteração. Se a alteração tornar o projeto
inviável, seja econômica ou tecnicamente, as partes envolvidas devem ser informadas
e o processo de encerramento deve ser realizado, registrando-se as lições aprendidas
e desmobilizando-se toda a equipe gerencial e técnica.
As normas e metodologias de gerenciamento de projetos utilizadas também
auxiliarão na definição dos processos a serem tratados nos planos do projeto, sendo
indispensável que se abordem questões como integração, prazo, custo e escopo.
Dependendo do projeto e do ambiente em que estiver inserido, além desses
processos é recomendado que se utilizem os demais processos mencionados nos
subcapítulos 3.3.3. e/ou 3.3.4., bem como se tenha planejado procedimentos
específicos para o tratamento de solicitações de mudança no escopo e para a gestão
de conhecimento.
4.2.4. Fase 4 – Projeto Básico
Iniciando a fase do projeto básico dessa metodologia é recomendável que se
modele a solução conceitualizada para o sistema em algum software de CAD, a
menos que já se tenha elaborado um modelo para apresentação ao cliente na fase
anterior.
Com o sistema modelado em CAD, recomenda-se então que sejam descritos
possíveis cenários de atuação para o sistema. É recomendado, também, que sejam
descritos cenários inadequados para o uso do sistema, sendo interessante que se
aborde o maior número de possibilidades imaginável e suas consequências. A
impossibilidade de operação nesses cenários deve ser claramente explicada ao cliente
e futuramente exposta no manual do sistema e na documentação do projeto.
Também se recomenda que todos esses cenários sejam apresentados ao
cliente, uma vez que ele pode conhecer melhor do que a equipe de desenvolvimento
qual uso será feito do sistema ao fim do projeto, podendo sua colaboração nessa
etapa ser crucial para cessar possibilidades de futuros desentendimentos quanto ao
mau uso do sistema.
85
Até que o cliente esteja de acordo com os cenários apresentados, deve-se
reavaliar a viabilidade do projeto quando forem solicitadas alterações de escopo e
sendo viável, remodelar o sistema e/ou descrever novos cenários de atuação. Caso o
cliente discorde do apresentado e não seja solicitada alteração de escopo, ou a
alteração solicitada torne o projeto inviável, deve-se encerrá-lo, considerando as
atividades mencionadas no fluxograma da figura 33.
Terminado o ciclo, uma série de atividades técnicas deverá ser realizada,
iniciando pela especificação das interfaces entre o sistema e o usuário, ou seja, como
será a interação entre o usuário e o sistema. Essa atividade marca o início do
desenvolvimento do sistema de controle e busca responder, entre outras, questões
como as que seguem:
O sistema será autônomo ou controlado pelo usuário?
Se for controlado, o que os usuários poderão controlar?
Será utilizado uma sistema de controle de malha aberta ou fechada?
Para malhas fechadas, quais tipos de controladores serão utilizados?
Proporcional (P), Proporcional Derivativo (PD), Proporcional Integral (PI)
ou Proporcional Integral Derivativo (PID)?
Será utilizada a lógica booleana, ou a lógica fuzzy?
Se for autônomo, o sistema será programado antes de ser entregue ao
usuário final?
O usuário final poderá modificar a programação do sistema?
A possibilidade de programação para o usuário final será
completamente aberta, ou restrita a algumas possibilidades pré-
programadas?
É recomendável que se dê um foco ao usuário do sistema durante essa
atividade e se for possível, que se envolvam alguns dos futuros usuários em potencial
para que se tenha a noção mais próxima possível do que eles desejam para essa
interface.
Dando continuidade ao projeto, é imprescindível que se façam análises sobre o
comportamento do sistema. Essa análise envolve estudos sobre a cinemática, estática
e dinâmica do sistema, que servirão como base, junto aos requisitos, ao modelo e aos
cenários de atuação para o detalhamento técnico do sistema.
A atividade seguinte envolve o detalhamento do pior cenário de atuação para o
sistema, de modo que embase a definição de seus coeficientes de segurança. A
86
definição desses cenários pode ser facilitada pelo uso de simulações e/ou protótipos
do sistema.
Figura 33 – Fluxograma: Projeto básico. Fonte: Autor.
87
Na melhor das hipóteses, simulações e prototipagens devem ser utilizadas em
associação para se obter resultados mais próximos possíveis da realidade que o
sistema encontrará. Entretanto, como essa atividade será realizada dependerá, entre
alguns fatores, principalmente do que está estabelecido no cronograma físico-
financeiro frente ao avanço do projeto e da quantidade disponível de recursos
financeiros.
Assim, ao se definirem os coeficientes de segurança do sistema encerra-se a
fase 4 do projeto, tendo-se agregado ao projeto quatro importantes informações, os
coeficientes de segurança, o comportamento do sistema, o conceito de interface e o
modelo em CAD atualizado. Caso o gerente do projeto queira definir um marco para o
fim dessa fase, sugere-se a elaboração de um relatório técnico que contenha as
informações mencionadas.
4.2.5. Fase 5 – Projeto Detalhado
A quinta fase dessa metodologia, representada na figura 34, envolve o
detalhamento técnico do sistema, para que esse atinja um nível de desenvolvimento
mínimo capaz de possibilitar a execução com a confiabilidade das tarefas pretendidas
para esse sistema, devendo essas terem sido especificadas na proposta entregue
inicialmente ao cliente, evitando conflitos futuros quanto aos parâmetros de
confiabilidade adequados para o sistema projetado.
Middendorf et al. (2006) trata da importância da confiabilidade ao relatar que
essa é um fator essencial para qualquer sistema, sendo de entendimento geral no que
diz respeito a perspectivas técnicas como tempo de vida útil, qualidade, segurança e
manutenção. Mencionando, ainda, que recentemente a dimensão ambiental da
confiabilidade passou a ser reconhecida por sua contribuição para a eficiência de
recursos dos produtos de vida longa. Com isso em vista, é recomendado que a
confiabilidade do sistema resultante seja considerada.
Ao se iniciar essa fase, é muito importante que se verifique se alguma
alteração de escopo ocorrida na fase anterior deverá acarretar em alterações nos
planos do projeto, pois dependendo da alteração podem haver novas partes
interessadas no projeto, bem como pode ser necessária a utilização de recursos que
não haviam sido previstos, entre outras situações.
Na atividade seguinte, devem-se definir os materiais e componentes que serão
utilizados para a composição do sistema. No fluxo apresentado, são propostas oito
subatividades para essa atividade, ficando a critério do gerente do projeto a definição
da ordem com que serão executadas, bem como se serão executadas
88
simultaneamente ou não. Entretanto, dependendo da natureza do projeto em questão,
outras subatividades podem ser necessárias.
Figura 34 – Fluxograma: Projeto detalhado. Fonte: Autor.
89
Recomenda-se, porém, que as áreas do conhecimento envolvidas não sejam
tratadas isoladamente e que haja o maior grau possível de interatividade entre os
profissionais responsáveis pelo desenvolvimento de cada uma dessas subatividades,
encorajando-se assim a troca de informações sobre as tarefas executadas.
Ainda, sobre essa atividade, recomenda-se ao gerente de projeto que sejam
estabelecidas práticas cautelosas para o controle dos riscos associados a sua
execução. Afinal, essa atividade é crítica para o sucesso do projeto, sendo
normalmente a que mais exigirá horas de trabalho dos recursos humanos.
A ocorrência de falhas não detectadas na atividade de definição dos materiais
e componentes que serão utilizados para a composição do sistema poderá acarretar
na necessidade de realização de muitas horas de retrabalho, o que pode inviabilizar a
continuação do projeto e poderá denegrir a imagem da organização junto ao cliente.
Durante o desenvolvimento dessa atividade é interessante que seja elaborado
parcialmente e disponibilizado para os participantes do projeto, um documento
contendo o conjunto de definições técnicas realizadas, para facilitar o controle do
gerente e a fomentar a interação entre os participantes. Também pode-se utilizar uma
ferramenta como Burndown Chart da metodologia Scrum para esse mesmo fim.
Tendo-se finalizado a atividade anterior, devem-se reavaliar todos os possíveis
cenários de atuação do sistema para garantir que esses estejam de acordo com o
projeto detalhado, bem como a listagem de cenários em que o sistema não poderá
atuar. Assim, se for necessária a atualização do pior cenário definido, deve-se também
revisar os coeficientes de segurança do sistema.
Em seguida, devem ser pensadas soluções para possíveis falhas no sistema,
sendo uma ferramenta útil para realização dessa tarefa a análise dos modos e efeitos
de falhas, conhecida pelo termo Failure Mode and Effect Analysis (FMEA). Essa
atividade tem o objetivo de evitar que essas falhas venham a impossibilitar a
continuação da operação com a substituição do sistema e impeçam seu resgate, além
de reduzir os impactos ambientais gerados, principalmente no caso de um descarte
acidental do sistema. Mesmo que essas situações não sejam esperadas, recomenda-
se que as soluções sejam pensadas inclusive para possíveis situações em que o
sistema for utilizado nos cenários listados como inadequados. Com isso, deve-se
buscar a implantação dessas soluções no sistema.
Posteriormente, deve-se iniciar a programação do software que será utilizado
para o controle do sistema, de acordo com as informações já obtidas. Selecionando-se
em seguida, junto ao mercado, as peças e equipamentos que deverão ser adquiridas
para composição do sistema e com base nos pareceres técnicos da equipe de
desenvolvimento.
90
Com o conjunto de informações gerados nessa fase, poderá, então, ser
preparada uma nova versão do modelo em CAD do sistema, dessa vez com maior
detalhamento. Assim, devem ser elaborados o modelo 3D do sistema e seus
desenhos técnicos, que serão apresentados ao cliente. Essa apresentação deve
conter todos os aspectos conhecidos do sistema, garantindo o entendimento do
cliente, cabendo então uma aprovação formal do trabalho realizado. Além disso, os
desenhos técnicos comporão a entrega final do projeto ao cliente e deverão ser
utilizados no caso de registro de patente.
Caso o cliente não aprove o apresentado, deverá repetir-se o mesmo conjunto
de decisões apresentado na fase anterior que poderá ter como consequência o
encerramento prematuro do projeto, ou o retorno a etapa de definição de materiais e
componentes. Dessa forma, recomenda-se que durante a apresentação do sistema ao
cliente, seja esmiuçada qualquer dúvida do mesmo e que, se for solicitada alguma
alteração, busque-se entender os mínimos detalhes do que causou o incômodo, para
que o mesmo não venha a se repetir e para reduzir o retrabalho necessário e
consequentemente evitar que o projeto torne-se inviável.
4.2.6. Fase 6 – Testes e Validação
Com a provação do cliente, deve-se iniciar a fase de teste e validação do
sistema, última fase dessa metodologia, representada na figura 35. A primeira
atividade dessa fase já consiste na realização de um conjunto de simulações virtuais
do funcionamento do sistema, considerando a sua forma final e todos os componentes
e materiais especificados na fase anterior e aprovados pelo cliente. É recomendável
que se utilize durante as simulações o sistema operacional que será utilizado para o
controle do sistema físico.
Durante as simulações, deve-se avaliar como o sistema reage atuando sob as
condições que enfrentará em diferentes ambientes, considerando-se o pior cenário de
atuação, inclusive. Espera-se que o sistema comporte-se como aguardado e seja
funcional em todas as simulações.
Recomenda-se que sejam avaliadas, também, as situações em que o sistema
for submetido à atuação naqueles cenários listados anteriormente como inadequados,
de modo que possam ser detalhadamente descritas suas consequências.
Se durante as simulações para os cenários em que o sistema deverá atuar,
inclusive o pior cenário, o sistema não for funcional, ou seja, for ineficiente durante a
operação das tarefas solicitadas, deverá ser realizada uma análise de falhas. Dentre
outras ferramentas, podem ser utilizadas a análise da árvore de falhas (AAF) e a
91
análise da causa raiz da falha, em inglês Root Cause Analysis (RCA) e o diagrama de
Ishikawa.
Figura 35 – Fluxograma: Testes e validação. Fonte: Autor.
92
Caso não se identifique um erro de projeto, deve-se repetir a simulação
verificando todas as configurações, os dados inseridos no software utilizado e a
integridade do mesmo, pois provavelmente ocorreu um erro durante o processo.
Porém, havendo um erro de projeto deve-se verificar a possibilidade de correção e sua
viabilidade econômica, se por possível e viável, o projeto deve ser corrigido e as
simulações refeitas. Entretanto, se não for possível, ou se não for viável, deve-se
prosseguir com o processo de encerramento do projeto.
Contudo, se durante as simulações o sistema demonstrar-se funcional até para
atuação no pior cenário, deve-se dar continuidade. As atividades seguintes levam a
implantação do sistema operacional em um protótipo físico do sistema. Em seguida
esse protótipo deverá ser testado quanto a sua funcionalidade. Recomenda-se a
realização de testes em cenários semelhantes aos do pior caso de atuação. Se o
sistema falhar deve-se verificar a origem da falha e se houve erro de projeto e sendo
identificado um erro de projeto, deverão ser repetidas as etapas descritas
anteriormente. Não havendo erro de projeto o protótipo deverá ser desmontado e
remontado minuciosamente, o sistema operacional deverá ser instalado com cautela e
o conjunto deverá ser testado novamente.
Tanto para o ciclo mencionado acima, quanto para o descrito anteriormente,
caso não sejam apontadas falhas de projeto e o sistema volte a falhar nos testes, é
recomendável que o gerente de projetos aloque outros recursos para auxiliar a
realização das atividades e verificar se não está ocorrendo falha humana ou das
ferramentas empregadas nos processos.
Uma vez que o protótipo seja aprovado nos testes, o projeto estará em suas
atividades de encerramento previsto, devendo ser elaborado o manual do sistema
mecatrônico gerado. O manual deve ser anexado a documentação do projeto exigida
pelo cliente e o conjunto entregue ao mesmo. Se o cliente solicitar alguma
documentação extra, ou correção do que foi entregue, deve-se verificar o que cabe ser
feito, tendo em vista o contrato do serviço e/ou as possíveis vantagens de se realizar
uma entrega não planejada.
Sendo a documentação aceita pelo cliente, em seguida, deve-se buscar um
retorno junto ao cliente quanto a sua satisfação com os processos do projeto e o
resultado gerado, registrar as lições aprendidas e desmobilizar toda a equipe do
projeto.
A Associação Brasileira de Normas Técnicas (2000) afirma que anteriormente a
conclusão do projeto, a organização empreendedora documente análises críticas
quanto ao desempenho do projeto, colocando em evidencia aquilo que possa ser
utilizado em projetos futuros, preferencialmente envolvendo o cliente e outras
93
principais partes interessadas. Dessa maneira, recomenda-se, para o caso em que a
organização empreendedora é também o cliente do projeto, que a organização do
projeto siga o indicado.
4.3. DEFINIÇÃO DOS ENVOLVIDOS E DAS RESPONSABILIDADES
No presente subcapítulo são expostas em maiores detalhes as divisões de
responsabilidade das atividades dessa metodologia, apresentadas no subcapítulo
anterior, através de uma matriz de responsabilidades, presente no quadro 5. Essa
matriz apresenta todas as atividades já mencionadas, uma por linha, estando as linhas
agrupadas por fase.
As siglas vistas na matriz indicam o papel dos atores, estando descritas abaixo:
A – Parte responsável por avaliar e aprovar ou reprovar o resultado da
atividade;
R – Ator responsável pela atividade, devendo acompanhar e controlar
seu desenvolvimento para garantir que será realizada de modo
eficiente.
E – Aquele que é responsável por executar a atividade.
P – Um participante da atividade, não é o responsável pela execução,
mas tem o intuito de facilitar o seu desenvolvimento, ou de conhecer
seus resultados enquanto ela é desenvolvida.
I – Responsável por informar os resultados da atividade.
EI – Parte que é informada sobre os resultados gerados.
Vale notar que para uma atividade, é imprescindível que haja ao menos um
responsável, um executor e um avaliador, podendo essas funções serem cumulativas.
Outro fator importante é que, sempre que uma das partes necessitar ser informada
sobre o resultado de uma atividade, coexistirá um responsável pela transmissão desta
informação.
Quadro 5 – Matriz de responsabilidades para principais atores da metodologia.
Fase Atividade Equipe do
projeto PMO
Alta administração
Cliente
Captação do projeto
Captar Necessidades e Desejos do Cliente
- EI R/E/I A
Mobilizar principais membros da equipe
- P R/E/A -
94
Fase Atividade Equipe do
projeto PMO
Alta administração
Cliente
Converter necessidades em requisitos primários e desejos em requisitos secundários
- E R/P A
Verificar requisitos com o cliente
- E R/P A
Negociar possíveis modificações para viabilizar o projeto
- EI R/E/I P/A
Elaborar proposta - E R/P A
Apresentar proposta - P R/E A
Registrar lições aprendidas
- E R/A -
Iniciação do
Projeto
Estudar estado da arte - E R/A -
Estudar proposta - E R/A -
Analisar requisitos secundários
- E R/P A
Preparar orçamento e cronograma base
- E R/P A
Especificar possibilidade de melhoria
- E R A
Negociar alterações - P R/E/A P/A
Conceitualizar nova solução
- E R/A -
Solicitar alteração de escopo
- R/E E/A -
Avaliar viabilidade econômica com alteração
- P R/E/A -
Informar cliente sobre a inviabilidade econômica da alteração
- EI R/E/I/A EI
Informar cliente sobre encerramento do projeto
- EI R/E/I/A EI
Registrar lições aprendidas e desmobilizar equipe
- P R/E/A -
Projeto conceitual
Mobilizar demais membros da equipe
P R/E A -
Detalhar requisitos E R/A - -
Definir forma do corpo e desenhar o sistema
E R/I EI A
Definir método de gerenciamento
P R/E A -
Elaborar cronograma físico-financeiro
EI R/E/I A A
Elaborar planos do projeto
EI R/E/I A -
95
Fase Atividade Equipe do
projeto PMO
Alta administração
Cliente
Informar envolvidos sobre encerramento do projeto
EI P R/E/I/A EI
Registrar lições aprendidas e desmobilizar equipe
EI P R/E/I/A EI
Projeto básico
Elaborar modelo em CAD
E R/A - -
Descrever possíveis cenários de atuação
E R/I EI A
Especificar interfaces entre o sistema e o usuário
E R/A - -
Analisar como o sistema se comporta
E R/A - -
Detalhar pior cenário de atuação
E R/A - -
Definir coeficientes de segurança
E R/A - -
Informar envolvidos sobre encerramento do projeto
EI P R/E/I/A EI
Registrar lições aprendidas e desmobilizar equipe
EI P R/E/I/A EI
Projeto detalhado
Revisar planos do projeto
- R/E A -
Definir materiais e componentes a serem utilizados
E R/A - -
Revisar cenários de atuação e coeficientes de segurança
E R/A - -
Definir soluções para falhas operacionais e descarte
E R/A - -
Programar sistema operacional
E R/A - -
Escolher componentes e equipamentos para aquisição
E R/A - -
Preparar desenho técnico e modelo 3D detalhados
E R/I EI A
Informar envolvidos sobre encerramento do projeto
EI P R/E/I/A EI
Registrar lições aprendidas e desmobilizar equipe
EI P R/E/I/A EI
Testes e validação
Simular funcionamento integrado do sistema
E R/A - -
96
Fase Atividade Equipe do
projeto PMO
Alta administração
Cliente
Preparar protótipo E R/A - -
Implementar sistema operacional
E R/A - -
Testar o protótipo E R/A - -
Verificar origem da falha E R/A - -
Corrigir projeto E R/A - -
Elaborar Manual E R/A - -
Entregar documentação ao cliente
EI EI R/E/I A
Informar envolvidos sobre encerramento do projeto
EI P R/E/I/A EI
Registrar lições aprendidas e desmobilizar equipe
EI P R/E/I/A EI
Fonte: Autor.
Embora não seja recomendado, em alguns casos, pode haver mais de um ator
com o mesmo papel, sendo necessária uma gestão diferenciada para essas atividades
para que não haja conflito que prejudique o resultado desejado durante a realização
dos papeis. Esse é o caso das atividades: Negociar alterações; e Elaborar cronograma
físico-financeiro. Nessas atividades o cliente e a alta administração dividem o papel de
avaliador, de modo que deve haver um consenso entre ambas as partes para que o
resultado da atividade seja aceito. Caso uma das partes se recuse a dar seu aceite,
então o resultado é recusado.
Além dos casos citados acima, na atividade de mobilização dos principais
membros da equipe, realizada na fase de captação do projeto, pode haver a
necessidade de aprovação por parte do cliente, dependendo dos requisitos solicitados
para a execução do projeto. Pode ocorrer de o cliente exigir que profissionais com
determinadas habilidades participem de todo o desenvolvimento do projeto, exigindo
como garantia a presença desses nas reuniões preliminares.
Para um melhor entendimento dos leitores, esclarece-se que as colunas a
direita da lista de atividades compreendendo os principais atores envolvidos nos
projetos, pelo ponto de vista da organização do projeto, consiste no que segue:
Alta administração – também denominada alta gerência e alta direção
por outros autores, sendo representada pelo mais alto nível hierárquico
da organização envolvido com o projeto, ou seja, os profissionais com
97
maior poder de decisão no âmbito do projeto e que também estão
envolvidos com decisões estratégicas da organização;
Equipe do projeto – os recursos humanos envolvidos com o
desenvolvimento técnico do projeto. Muitas vezes essa equipe é
composta por engenheiros de especialidades afins as áreas de
conhecimento envolvidas no projeto. Normalmente essas
especialidades são mecânica, eletrônica, mecatrônica e computação,
mas além dos engenheiros, recomenta-se a participação de outros
profissionais com expertise nessas e em outras áreas compor essa
equipe, dependendo do projeto em questão. Além disso, possíveis
usuários do sistemas a ser projetado também devem ter participações,
mesmo que esporádicas, nessa equipe a fim de reduzir o risco de má
aceitação do sistema gerado ao fim do projeto;
PMO – composto pela média gerência, são os profissionais
responsáveis pela gestão direta do projeto e por fazer a ligação entre a
alta administração e a equipe do projeto, sendo na maior parte das
vezes responsabilizados pelo sucesso ou fracasso do projeto. Assim,
recomenda-se que os profissionais que compuserem o PMO da
organização devem estar sempre em busca de maior entendimento
quanto a boas práticas que podem ser empregadas nos projetos em
que participam; e
Cliente – Seguindo o ponto de vista da organização do projeto, trata-se
por clientes aquelas partes interessadas externas a organização do
projeto que tem poder de decisão quanto à continuidade e ao
cancelamento dos esforços do projeto, podendo assim serem divididos
em dois principais grupos, a organização empreendedora e as demais
partes interessadas que possuam tal poder, como, por exemplo,
eventuais patrocinadores (sponsors) e órgãos regulatórios.
Uma vez tendo-se reunido um conjunto de boas práticas em uma metodologia
e explanado as indicações dessa metodologia quanto às atividades a serem
desenvolvidas, seus fluxos e a distribuição das responsabilidades dentre os atores do
projeto, concluir-se-á os trabalhos dessa dissertação.
98
4.4. COMPARAÇÃO COM MODELOS EXISTENTES
Com o objetivo de comparar as metodologias apresentadas para o
desenvolvimento de sistemas mecatrônicos apresentadas no subcapítulo 3.2. dessa
dissertação, MRM, Modelo V, Modelo Hierárquico e Modelo de 3-Ciclos, com a que foi
proposta nessa dissertação, elaborou-se o quadro 6 abaixo, apontando características
das mesmas.
Quadro 6 – Comparação de Métodos.
Método Características
MRM
Abrange todo o PDP mecatrônico;
Envolve atividades técnicas e gerenciais;
Método validado em uma indústria;
Foco em organizações produtoras de linhas de produtos
mecatrônicos; e
Desenvolvimento linear dos produtos, com interação entre as fases.
Modelo V
Aborda os aspectos técnicos;
Ênfase na integração;
Processo iterativo; e
Desenvolvimento por subsistemas.
Modelo
Hierárquico
Ênfase no projeto conceitual e nos parâmetros de design;
Processo iterativo;
Desenvolvimento de modo integrado ou por subsistemas; e
Utilizado para modelagem de um sistema mecatrônico.
Modelo de
3-Ciclos
Abrange todo o PDP mecatrônico;
Baseado no Modelo V;
Aborda os aspectos técnicos;
Ênfase na integração;
Processo iterativo; e
Desenvolvimento por subsistemas.
Metodologia
proposta
Foco em organizações de projeto;
Orientado ao projeto de sistemas mecatrônicos e não ao PDP;
Não trata de fases posteriores ao fim do projeto;
Aborda os aspectos técnicos e tomadas de decisão;
Desenvolvimento de modo integrado; e
Desenvolvimento linear dos produtos, com etapas iterativas.
Fonte: Autor.
Todos os modelos analisados partem de uma avaliação da ideia do sistema,
com intuito de verificar os requisitos técnicos necessários, para que se obtenha o
sistema desejado, e tem seu desenvolvimento estruturado iniciando-se pelos
99
componentes para futuramente compor o sistema pretendido, havendo a necessidade
de uma ou mais etapas de integração.
O MRM e o Modelo Hierárquico, seguem um desenvolvimento linear com
interações entre as fases, já a metodologia proposta nessa dissertação, apesar de
também seguir um desenvolvimento linear, dependendo das características do projeto
e dos resultados encontrados em cada etapa, pode envolver ciclos de aprimoramento
e/ou retrabalho. Já os demais modelos possuem abordagens iterativas com interações
entre as fases.
Percebeu-se durante a análise que o modelo de 3-Ciclos é baseado no Modelo
V, sendo uma extensão do mesmo. A diferença entre eles está no fato de o Modelo V
ser restrito ao desenvolvimento do produto, iniciando-se na concepção do sistema e
estendendo-se até o projeto detalhado do mesmo, enquanto o modelo de 3-Ciclos
demonstra-se mais amplo, abrangendo além da fase de desenvolvimento do sistema
mecatrônico, o estudo de mercado e seleção de ideias para concepção do sistema,
bem como o projeto das facilidades necessárias para produção.
O MRM apresenta uma abordagem ainda mais completa do PDP mecatrônico
que o Modelo de 3-Ciclos. O grande diferencial do MRM em comparação a esse
modelo é relativo ao tratamento tanto de aspectos técnicos que envolvem o
desenvolvimento dos sistemas, quanto dos gerenciais. Assim, o MRM, diferentemente
do Modelo de 3-Ciclos, aborda aspectos posteriores à produção do sistema. Outro
ponto forte do MRM se constitui do fato do mesmo ter sido validado junto a uma
indústria, por meio de sua implementação com consequentes resultados positivos para
os resultados estratégicos e operacionais da mesma.
Embora não tenha sido implementado em uma indústria, o Modelo Hierárquico
foi utilizado durante o desenvolvimento conceitual de um sistema mecatrônico, sendo
sua eficácia validada com o resultado gerado, o projeto conceitual de uma máquina
síncrona. É importante destacar que dada a sua ênfase no desenvolvimento conceitual
dos projetos, esse modelo é o único que não se aprofunda nas questões técnicas do
desenvolvimento dos sistemas.
De todos os modelos, apenas o MRM e a metodologia proposta abordam as
atividades gerenciais necessárias para o desenvolvimento pleno dos projetos, sendo
que o MRM apresenta mais definições sobre o que deve ser feito, enquanto nessa
dissertação deixa-se essa decisão a cargo dos gerentes de projetos, apenas
orientando-os quanto ao que pode ser feito, tendo em vista que as características
únicas apresentadas em diferentes projetos podem exigir a aplicação de práticas
distintas.
100
5. CONSIDERAÇÕES FINAIS
O último capítulo dessa dissertação é subdividido em quatro subcapítulos. No
primeiro desses, realiza-se a discussão de todo conteúdo apresentado nos capítulos
anteriores, contrapondo-os com os objetivos, geral e específicos, definidos para essa
dissertação, apresentados no capítulo introdutório. O segundo subcapítulo apresenta
uma comparação entre a metodologia proposta no quarto capítulo e as apresentadas
no terceiro capítulo. A possibilidade de trabalhos futuros é levantada no quarto
subcapítulo, visando o aprimoramento do conhecimento desenvolvido de forma a se
colaborar com os avanços da área em questão. Finalizando a dissertação, o quarto
subcapítulo traz as conclusões quanto à realização desse trabalho para tudo o que foi
estudado e pesquisado durante a sua composição.
5.1. EXECUÇÃO DOS OBJETIVOS
Os objetivos específicos são atingidos durante o desenrolar da dissertação,
respectivamente de acordo com o que segue:
Durante a elaboração dos dois primeiros capítulos foi realizado um
estudo referente aos principais temas que envolvem o desenvolvimento
dos projetos de sistemas mecatrônicos, abordando-se mecatrônica,
robótica e projetos;
A identificação de práticas essenciais para o desenvolvimento de
projetos de sistemas mecatrônicos em organizações de projetos ocorre
durante o desenvolvimento dos três primeiros capítulos da dissertação,
havendo maior ênfase durante o desenvolvimento do que se apresenta
no terceiro capítulo;
Uma pesquisa quanto às metodologias e boas práticas aplicáveis ao
desenvolvimento e gerenciamento de projetos de sistemas
mecatrônicos encontradas em literatura nacional e internacional foi
utilizada para a composição do terceiro capítulo; e
No subcapítulo 4.1. é apresentada uma pesquisa, realizada junto a
docentes de engenharia de uma universidade, cujos resultados
permitem que se tenha uma noção da capacidade nacional de
disseminação do conhecimento referente ao desenvolvimento e
gerenciamento dos projetos de sistema mecatrônicos, através de suas
universidades;
101
O apresentado no capítulo quatro dessa dissertação, uma metodologia para o
desenvolvimento de sistemas mecatrônicos com foco nas organizações de projeto
proposta pelo autor, cumpre com o objetivo geral dessa dissertação.
5.2. CONCLUSÃO
O trabalho desenvolvido nessa dissertação teve como principal objetivo propor
uma metodologia para o desenvolvimento de projetos de sistemas mecatrônicos
orientada a organizações de projetos. Metodologias com esse fim específico não
puderam ser encontradas nas pesquisas realizadas para a revisão bibliográfica e
durante o desenvolvimento de toda essa dissertação.
O desenvolvimento dessa metodologia foi motivado pelo fato de existirem
poucas metodologias para desenvolvimento de sistemas mecatrônicos na literatura.
Essas metodologias possuem diferentes orientações, sendo a única detalhada a nível
de atividades, orientada a organizações empreendedoras e voltada para o PDP
mecatrônico. Além disso, grande parte das metodologias existentes é baseada no
Modelo V, apresentando então grandes semelhanças com o mesmo.
Embora a literatura aponte que as metodologias existentes não são utilizadas
pelas organizações e que essas desenvolvem as suas próprias metodologias, não fica
claro se a causa para tal se dá pelo desconhecimento por parte da indústria quanto a
existência dessas metodologias ou pela rejeição das existentes.
Assim, outro fator que destaca a relevância dessa dissertação está no fato da
mesma expor os resultados de uma pesquisa realizada junto a docentes, de uma das
maiores universidades do Brasil, através do qual pode-se creditar o fato da não
empregabilidade das metodologias presentes na literatura à pouca capacidade de
disseminação e desenvolvimento dessas metodologias em cursos universitários,
responsáveis por transmitir indiretamente conhecimentos gerados no meio acadêmico
para o mercado, através de profissionais recém-formados.
Dessa forma, o ideal para essa metodologia, como para quaisquer outras
metodologias é que seja cada vez mais trabalhada e apresentada nas universidades.
De modo que, além de consistir numa importante referência para empresas, essa
metodologia passará a ser efetivamente conhecida pelas organizações de projeto,
como por exemplo, empresas de engenharia que desenvolvam projetos de sistemas
mecatrônicos de forma terceirizada para outras organizações e pretendam implantar
uma metodologia, seja para fins de melhoria de seus processos e resultados, para
poder adequar-se a solicitações de contratantes, ou ainda para buscar uma
certificação em qualidade, como a ISO 9000.
102
A metodologia pode também ser utilizada em departamentos de
desenvolvimento de novos produtos de empresas que não possuam experiência
prévia com o desenvolvimento de sistemas mecatrônicos, facilitando a atuação dos
envolvidos no gerenciamento do projeto, uma vez que contém as atividades básicas a
serem realizadas e um conjunto de decisões e ações a serem tomadas.
É essencial que se tenha em mente que se fará necessária à utilização de uma
metodologia de gerenciamento de projetos em associação a metodologia proposta
para que se tenham maiores chances de sucesso para o projeto a se desenvolver.
Além disso, como já fora mencionado anteriormente nessa dissertação, é
recomendável a utilização de uma norma sobre gerenciamento de projetos, visando
garantir a utilização das melhores práticas no gerenciamento do projeto em questão.
Foram apresentadas duas metodologias de características distintas para o
gerenciamento de projetos no capítulo 3. Sendo a metodologia Scrum, de acordo com
o que se apresenta na literatura, mais recomendada para projetos de menor porte,
facilitando que esses sejam realizados em menor tempo. Embora essa seja uma
metodologia originária da área de desenvolvimento de programas de computador, já
existem estudos sobre sua empregabilidade em pequenos projetos acadêmicos de
sistemas mecatrônicos, havendo relatos de sucesso. Dessa maneira, existe uma
expectativa de que esse método de gerenciamento seja testado para projetos de
sistemas mecatrônicos de maiores portes.
Apesar de ter sido apresentada a metodologia de gerenciamento de projeto
PRINCE2™, não foram encontrados relatos de sua utilização em projetos de sistemas
mecatrônicos. Muito pouco pode ser encontrado na literatura sobre o gerenciamento
desses projetos, mas pelos relatos da ampla utilização dessa metodologia em
projetos, de um modo geral, pode-se assumir que sua utilização em projeto de
sistemas mecatrônicos seja plausível.
É consistente considerar que assim como a utilização de métodos para o
desenvolvimento e gerenciamento desses projetos, o fato das organizações de projeto
contarem com o apoio estratégico da alta administração é essencial para que esses
projetos sejam bem sucedidos. Por isso, a metodologia proposta nessa dissertação
não deixou de considerar a fase anterior ao início dos projetos, na qual a participação
da alta administração é importantíssima e indispensável.
Além disso, a metodologia proposta deixa claro em todas as etapas que pode
ser necessário o cancelamento dos projetos e expõe as principais decisões que
envolvem esse processo, baseadas em análises de viabilidade e negociações diretas
com os clientes. Ainda para esse processo de encerramento abreviado de um projeto,
são consideradas importantes atividades que impactarão outros projetos da
103
organização, como o registro de lições aprendidas, que agrega o conhecimento
adquirido com o executado ao capital intelectual da organização.
Nessa metodologia, a participação dos clientes é solicitada em todas as etapas
do projeto, sempre buscando sua aprovação para o que está sendo desenvolvido, de
modo a evitar desacordos futuros e aumentar o contentamento deles com o resultado
dos projetos.
Outro ponto abordado, já na primeira e mais a fundo na quinta fase da
metodologia, se refere à preocupação com o resíduo gerado pelo sistema projetado ao
fim de sua vida útil. Preocupação essa que se faz muito importante, tendo em vista os
possíveis impactos ambientais gerados, o que vem ganhando cada vez mais escala no
cenário atual no que diz respeito às demandas do mercado.
5.3. TRABALHOS FUTUROS
Como possíveis trabalhos futuros, pode ocorrer a validação da metodologia
proposta através de sua utilização durante o desenvolvimento de projetos de sistemas
mecatrônicos, em associação a uma metodologia de gerenciamento de projetos e
seguindo as diretrizes do PMBoK e/ou da ISO 10006. Podendo assim serem avaliadas
as consequências de sua implantação para os resultados de um projeto real e as
organizações envolvidas.
Além disso, podem-se buscar melhorias para a metodologia desenvolvida ao
submetê-la ao conhecimento tácito de profissionais que possuam experiência como
gerente no desenvolvimento de projetos de sistemas mecatrônicos, aumentando-se o
detalhamento das possíveis atividades técnicas de desenvolvimento para os sistemas.
Ainda considerando esses conhecimentos, pode-se ainda ampliar o
detalhamento ao se propor práticas específicas apontadas como intrínsecas para o
gerenciamento de projetos de sistemas mecatrônicos. Porém, essa proposta mais
detalhada deve ser desenvolvida evitando-se o enrijecimento dos processos, tendo em
vista a necessária flexibilidade decorrente da ampla variabilidade de características
apresentadas pelos projetos de sistemas mecatrônicos.
Uma vez que a metodologia tenha sido validada e lapidada, pode-se também
desenvolver um software focado na gestão e no desenvolvimento de projetos de
sistemas mecatrônicos para atender às organizações de projetos, de modo a facilitar a
comunicação e transferência de dados entre as diferentes áreas da organização
durante o desenvolvimento desses projetos.
104
REFERENCIAL BIBLIOGRÁFICO
ANDREEVA, N.; TOPALOVA, I. Challenges and strategies for mechatronics development. XХ МНТК, p. 458 - 464. 2011.
ANGELES, J. e PARK, F. C. Performance evaluation and design criteria .In. SICILIANO, B.; KHATIB, O. (Org) Springer Handbook of Robotics. New York: Springer, p. 229-242. 2008.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO 10006-2000: Gestão da Qualidade – Diretrizes para a Qualidade no Gerenciamento de Projetos, Rio de Janeiro, 2000.
BARBALHO, S. C. M. Modelo de referência para o processo de desenvolvimento de produtos mecatrônicos (MRM): Proposta e aplicações. São Carlos: USP, 2006.
BARBALHO, S. C. M.; ROZENFELD, H. Modelo de referência para o processo de desenvolvimento de produtos mecatrônicos (MRM): Validação e resultados de uso. Gestão e Produção., v. 20, n. 1, p. 162-179, 2013.
BEHBAHANI, S.; SILVA, C. W. D. Mechatronic design quotient as the basis of a new multicriteria mechatronic design methodology. IEEE/ASME Transactions on Mechatronics, v. 12, n. 2, p. 227 - 232, 2007.
BUDYNAS, R. G.; NISBETT, J. K. Shigley’s Mechanical Engineering Design. New York: McGRAW-HILL, 2011.
BUUR, J. Mechatronics design in japan: A study of Japanese design methods and working practice in Japanese companies. Lyngby: DTH, 1989.
CARRASCO, A. M. Modelo de estimativa de custos para as fases iniciais do projeto de produto mecatrônico. Brasília: UNB, 2013.
CHAMI, M. et al. Swarm-based evaluation of nonparametric SYSML mechatronics system design. IEEE International Conference on Mechatronics (ICM), p. 436 - 441. 2013.
CHEN, C.-H. Mechatronics design of multi-finger robot hand. 12th International Conference on Control, Automation and Systems (ICCAS), p. 1491 - 1496. 2012.
COELHO, M. A. O. et al. A User–Centred Mechatronics Design Method. Proc. Mechatronics, p. 1-6, 2008.
105
GAUSEMEIER, J. et al. Integrative development of product and production system for mechatronic products. Robotics and computer-integrated manufacturing, v. 27, n. 4, p. 772-778, 2011.
GHEORGHE, G. I. et al. "Mechatronics Galaxy", an industrial research support for European sustainable and strategic development. International Conference on Mechatronics (ICM), 2011 IEEE, p. 916 - 921. 2011.
HEDEMAN, B.; VAN HEEMST, G. V.; FREDRIKSZ, H. Project management based on PRINCE2 – PRINCE2 TM Edition 2005 – 3rd edition. VHP, 2007
HEHENBERGER, P. et al. Hierarchical design models in the mechatronic product development process of synchronous machines. Mechatronics, v. 20, n. 8, p. 864-875, 2010.
HORIKAWA, O. et al. Seleção de robôs: alguns aspectos. Em: ROMANO, V. F. (Org.). Robótica Industrial: aplicação na indústria de manufatura e de processos. Rio de Janeiro: Edgar Blücher, p. 126-138. 2002.
ISERMANN, R. Modeling and design methodology for mechatronic systems. IEEE/ASME Transactions on Mechatronics, v. 1, n. 1, p. 16 - 28, 1996.
KUTZ, M. Environmentally conscious mechanical design. Danvers: Wiley, 2007.
LEITE, G. A.. Modelagem conceitual de um biossensor para detecção de aflatoxina em castanha-do-brasil. Brasilia: UNB, 2014.
LEVY, C. R. M.; LENGERKE, O.; DUTRA, M. S. Mechatronics learning with a “plug and play” training platform. 21th International Congress of Mechanical Engineering, 2011.
LI, Q.; ZHANG, W. J.; CHEN, L. Design for Control - a concurrent engineering approach for mechatronic systems design. IEEE/ASME Transactions on Mechatronics, v. 6, n. 2, p. 161 - 169, 2001.
MIDDENDORF, A. et al. Integration of reliability and environmental aspects in early design stages of mechatronics. IEEE International Symposium on Sustainable Systems and Technology, 2009.
MULDER F. , VERLINDEN J., MARUYAMA, T. Adapting scrum development method for the development of cyber-physical systems. In: Proceedings of the 10th international symposium on tools and methods of competitive engineering TMCE. Budapest: May 19-23, 2014.
NAVEIRO, R. M.. Montagem. Em: ROMANO, V. F. (Org.). Robótica Industrial: aplicação na indústria de manufatura e de processos. Rio de Janeiro: Edgar Blücher, p. 156-176. 2002.
106
NOGUEIRA, T. B. R.; LEPIKSON, H. A. Um método de engenharia reversa para projeto de produto mecatrônico aplicado à pequena e média empresa. XXVI ENEGEP. 2006.
OVESEN, N. Facilitating problem-based learning in teams with Scrum. In: The 15th International Conference on Engineering and Product Design Education. 2013.
PAHL, G. et al. Engineering Design: a systematic approach, 3rd English edition. London: Springer, 2007.
PANG, C. K. et al. A systems design approach to manage mechatronics R&D. IEEE 5th International Conference on Cybernetics and Intelligent Systems (CIS), p. 136 - 141. 2011.
PAULA, M. A. B. D.; SANTOS, E. A. P. Uma abordagem metodológica para o desenvolvimento de sistemas automatizados e integrados de manufatura. Produção, v. 18, n. 1, p. 8 – 25. 2008.
PIL, A. C.; ASADA, H. H. Integrated structure/control design of mechatronic systems using a recursive experimental optimization method. IEEE/ASME Transactions on Mechatronics, v. 1, n. 3, p. 191 – 203. 1996.
PINTO, M. A. P.. Gestão de Projectos com Processos Ágeis. Lisboa: UTL, 2010.
PRASSLER, e., KOSUGE, K.. Domestic robotics. In. SICILIANO, B.; KHATIB, O. (Org) Springer Handbook of Robotics. New York: Springer, p. 1253-1281. 2008.
PROJECT MANAGEMENT INSTITUTE. Um guia do conhecimento em gerenciamento de projetos (Guia PMBOK®) — Quinta Edição. Pensilvânia: PMI, 2013.
ROLOFF, M. L.; SÁ, S. R. L. D.; BENTO, D. Á. A metodologia de concepção de sistemas mecatrônicos na graduação tecnológica em Automação Industrial do CEFET-SC. Revista Técnico-Científica do IF-SC, v. 1, n. 1, p. 41-45, 2010.
SHETTY, D.; KOLK, R. A. Mechatronics System Design, 2nd Edition, SI. Stamford: CENGAGE, 2011.
SICILIANO, B. et al. Robotics: Modeling, planning and control. London: Springer, 2009.
SIEGELAUB, J. M. How PRINCE2 can complement PMBOK and your PMP. In: PMI global congress proceedings. 2004.
STANLEIGH, M. (2003). Combining the ISO 10006 and PMBOK to ensure successful projects. Disponível na URL:< http://www. bia. ca/articles/pj-combining-iso-10006-pmbok-to-ensure-successful-projects. htm> Acesso em, 5, 2015.
107
STEFANOV, A. Design approach in the development process of plastic parts from equipment for serial production. XХ МНТК, p. 386 - 390. 2011.
VARASCHIM, J. D.. Implantando o SCRUM em um Ambiente de Desenvolvimento de Produtos para Internet. Rio de Janeiro: PUC, 2009.
VARGAS, R. V.; IPMA-B, P. M. P. Identificando e recuperando projetos problemáticos: Como resgatar seu projeto do fracasso. Mundo PM, p. 42-49, 2006.
VASIĆ, V. S.; LAZAREVIĆ, M. P. Standard industrial guideline for mechatronic product design. FME Transactions, v. 36, n. 3, p. 103-108, 2008.
108
APÊNDICE A
QUESTIONÁRIO – PROJETOS DE SISTEMAS MECATRÔNICOS
1. Qual seu nome e e-mail?
Opcional para quem tiver interesse e disponibilidade para auxiliar futuramente na pesquisa.
2. Atualmente trabalha na:
( ) COPPE ( ) INICIATIVA PRIVADA ( ) INICIATIVA PÚBLICA ( ) OUTRO:____________
3. Qual sua formação acadêmica?
Informar área de graduação, mestrado e/ou doutorado.
4. Participou de algum projeto nos últimos cinco anos? Quantos?
( ) NENHUM ( ) UM ( ) DOIS ( ) TRÈS ( ) QUATRO ( ) MAIS ___________
5. A organização na qual os projetos foram desenvolvidos possuia certificação de qualidade?
( ) SIM ( ) NÃO
6. Foi utilizada alguma metodologia especifica para o gerenciamento dos projetos?
( ) SIM ( ) NÃO ( ) OUTRO:_________________________________________
7. Utilizou-se engenharia simultânea (paralelismo) durante algum dos projetos?
( ) SIM ( ) NÃO ( ) OUTRO:_________________________________________
8. Algum dos projetos desenvolvidos tinha como produto final um sistema mecatrônico?
( ) SIM ( ) NÃO
9. Em caso de resposta afirmativa na questão 8. Houve preocupação com relação aos resíduos gerados ao fim da vida útil do sistema desenvolvido?
( ) SIM ( ) NÃO
10. Algum dos projetos gerou patentes? Quantos?
( ) NENHUM ( ) UM ( ) DOIS ( ) TRÊS ( ) OUTRO: ____________________________
11. O desenvolvimento dos projetos envolveu profissionais de quais áreas do conhecimento?
( ) Administração de Empresas ( ) Ciências da Computação ( ) Design ( ) Engenharia Civil ( ) Engenharia de Produção ( ) Engenharia Elétrica ( ) Engenharia Mecânica ( ) Marketing ( )Outro:_____________________________________________________________________
12. Sugestão?
Caso deseje deixar alguma sugestão para os pesquisadores, por favor, utilize esse espaço.
109
APÊNDICE B
INFOGRÁFICO – RESPOSTAS A PESQUISA SOBRE A EXPERIÊNCIA DE
DOCENTES COM GERENCIAMENTO DE PROJETOS.
Abaixo se apresentam as respostas obtidas através do questionário presente
no apêndice A, demonstrando-as graficamente em círculos cuja área aumenta
conforme a participação em projetos do docente nos últimos cinco anos. Além disso,
na legenda abaixo os itens gerenciamento, patente, mecatrônica, qualidade, resíduo e
paralelismo correspondem respectivamente às respostas das questões 6, 10, 8, 5, 9 e
7 do questionário, de modo que a presença desses símbolos em um círculo representa
uma resposta afirmativa quanto à referida questão.
![[LABORATÓRIO DE SISTEMAS MECATRÔNICOS E ROBÓTICA]](https://img.document.onl/doc/110x75/615c78a9e38c77421b0924ec/laboratrio-de-sistemas-mecatrnicos-e-robtica.jpg)