Vous êtes sur la page 1sur 43

RAFAEL TAVARES SILVA

COMPARAES DE TIPOS DE METODOLOGIA GIL


PARA GERENCIAMENTO DE PROJETOS DE SOFTWARE:
Caso Manuteno de Equipamentos Porturios.
Trabalho apresentado ao curso MBA em
Gerenciamento de Projetos, Ps-Graduao lato
sensu, Nvel de Especializao, do Programa
FGV

Management

da

Fundao

Getlio

Vargas, como pr-requisito para a obteno do


Titulo de Especialista.

Edmarson Bacelar Mota


Coordenador Acadmico Executivo

Jos Tenrio Barreto Jr.


Orientador

So Lus MA
2014

FUNDAO GETULIO VARGAS


PROGRAMA FGV MANAGEMENT
MBA EM GERENCIAMENTO DE PROJETOS

O Trabalho de Concluso de Curso


Comparaes de tipos de metodologia gil para gerenciamento de projetos de software:
caso manuteno de equipamentos porturios.
Elaborado por Rafael Tavares Silva e aprovado pela Coordenao Acadmica, foi aceito
como pr-requisito para a obteno do certificado do Curso de Ps-Graduao lato sensu
MBA em Gerenciamento de Projetos, Nvel de Especializao, do Programa FGV
Management.

Data da Aprovao: So Lus, 01 de Novembro de 2014.

Edmarson Bacelar Mota


Coordenador Acadmico Executivo

Jos Tenrio Barreto Jr.


Orientador

DECLARAO

A empresa Vale S/A representada neste documento pelo Sr. Ronaldo Ramos Jnior
(Supervisor), autoriza a divulgao das informaes e dados coletados em sua organizao, na
elaborao do Trabalho de Concluso de Curso intitulado Comparaes de tipos de
metodologia gil para gerenciamento de projetos de software: caso manuteno de
equipamentos porturios, realizados pelo aluno Rafael Tavares Silva, do curso de MBA em
Gerenciamento de Projetos, do Programa FGV Management, com o objetivo de publicao e/
ou divulgao em veculos acadmicos.

So Lus, 10 de Novembro de 2014

Ronaldo Ramos Jnior


Supervisor
Vale S/A

TERMO DE COMPROMISSO

O aluno Rafael Tavares Silva, abaixo assinado, do curso de MBA em Gerenciamento de


Projetos, Turma GP19-So Lus do Programa FGV Management, realizado nas dependncias
da instituio conveniada ISAN, no perodo de 09/08/2012 a 27/06/2014, declara que o
contedo do Trabalho de Concluso de Curso intitulado Comparaes de tipos de
metodologia gil para gerenciamento de projetos de software: caso manuteno de
equipamentos porturios, autntico e original.

So Lus, 02 Setembro de 2014

Rafael Tavares Silva

Ao meu av Alberto Tavares Silva (in memoriam), Engenheiro Mecnico, Civil e Eletricista,
msico, ex-prefeito, ex-deputado estadual, ex-deputado federal, ex-senador, ex-governador,
Conselheiro da Repblica e tantos outros cargos de engenharia por ele exercidos, um
exemplo de marido, de av e de poltico, sempre um entusiasta que me inspirou com
honestidade e justia na conduo da vida.

A minha me Ana Maria, meu primo Joo Almeida, minhas avs Raimunda e Florisa, pela
amizade, carinho e por todo o apoio dado em minha vida, em especial nos estudos.

RESUMO
O Desenvolvimento de Produto, bem como o Gerenciamento de Projetos so fatores
fundamentais para o sucesso de um empreendimento. A busca por metodologias mais simples
e mais eficazes um desafio constante. Neste cenrio, as metodologias baseadas no
Desenvolvimento gil de Software, que est sendo cada vez mais adaptada e utilizada em
processos produtivos, em especial no desenvolvimento de Softwares. A manuteno de
equipamentos porturios pode ser favorecida com a utilizao de programas computacionais
de gesto de ativos. Para o desenvolvimento de melhorias deste sistema, verificou-se qual o
mtodo gil mais indicado, por se tratar de um projeto simples e de pequeno porte,
inviabilizando assim o uso de mtodos de gerenciamento de projetos complexos, como o
PMBOK. Chegou-se a concluso que cada um dos mtodos geis tem suas vantagens e
desvantagens, devendo a escolha ser feita pela adequao e o conhecimento da ferramenta
para o propsito. No caso de melhorias de um software j existente, pelo fato do usurio
conhecer as funcionalidades, o mtodo mais eficiente deve ser aquele que priorize a
participao o usurio final em todas as etapas do projeto. Neste quesito o mtodo XP
(extreme programming) e FDD (Featured Driven Development) foram os que melhor
reuniram caractersticas individuais para tal fim.
Palavras Chave: Mtodo gil; Porto; Gerenciamento de Projetos; Manuteno

ABSTRACT
The Product Development and Project Management are key factors for the success of a
company. The search for simpler and more effective methodologies is a constant challenge. In
this scenario, the methodologies based on Agile Software Development, which is being
increasingly adapted and used in production processes, especially in the development of
software. The maintenance of port equipment (spare parts) can be facilitated with the use of
computer programs for managing assets. To develop improvements of this software, it was
found that the most appropriate agile method, because it is a non-complex and small system,
thus precluding the use of methods of managing complex projects, such as the PMBOK. The
conclusion that each of agile methods has its advantages and disadvantages, the choice must
be made for the suitability and knowledge of the tool for the purpose came up. In case of
improvement of an existing software, as the user learn about the features, the most efficient
method should be one that prioritizes the end user participation in all the projects phases . In
this aspect XP (extreme programming) and FDD (Featured Driven Development) were the
methods that best met individual characteristics for this purpose.

Key Words: Agile Development, Port, Project Management, Maintenance

AGRADECIMENTOS

Aos professores do Curso de Gerenciamento de Projetos da FGV pela dedicao, experincia


e conhecimento compartilhado.

SUMRIO

1. INTRODUO ................................................................................................................ 10
2. DESENVOLVIMENTO .................................................................................................. 12
2.1 METODOLOGIAS GEIS DE DESENVOLVIMENTO DE SOFTWARE ................................... 12
2.2 COMPARATIVO ENTRE OS MTODOS GEIS................................................................... 16
2.3 MANUTENO ................................................................................................................. 19
2.4 TIPOS DE MANUTENO ................................................................................................. 22
2.4.1 MANUTENO CORRETIVA ............................................................................................ 23
2.4.2 MANUTENO PREVENTIVA .......................................................................................... 24
2.4.3 MANUTENO PREDITIVA ............................................................................................. 25
2.4.4 MANUTENO DETECTIVA ............................................................................................ 26
2.4.5 ENGENHARIA DA MANUTENO .................................................................................... 26
3. ESTUDO DE CASO ........................................................................................................ 29
3.1 LOGSTICA DA VALE S/A ................................................................................................ 29
3.2 O TERMINAL MARTIMO PONTA DA MADEIRA TPPM ............................................... 33
3.3 MELHORIA DE GESTO UTILIZANDO ESTRATGIAS DE MANUTENO. ....................... 34
3.3.1 ANLISE DO CENRIO ATUAL ....................................................................................... 35
3.3.2 MELHORIAS DO SISTEMA ATUAL ................................................................................... 36
4. CONCLUSES ................................................................................................................ 40
REFERNCIAS BIBLIOGRFICAS ................................................................................. 41

10

1. INTRODUO
Uma das maiores queixas para a implementao da metodologia do PMBOK a
complexidade e o excesso de processos associados, que torna necessrio pessoal qualificado e
familiarizado com a metodologia para que esta seja posta em prtica. Muitas empresas no
tm requisitos suficientes nem a maturidade elevada no tema para implantar o PMBOK
como ferramenta de gerenciamento de projetos.
A possibilidade de utilizar metodologias geis, que foram originalmente
desenvolvidas para o desenvolvimento de softwares, pode ser uma soluo eficaz para
gerenciar projetos de baixa complexidade e riscos, que tenham o escopo bem definido.
Com base nisto, surge o seguinte questionamento: Qual Mtodo gil utilizar para
gerenciar projetos de desenvolvimento de software, baseado nas vantagens e desvantagens de
cada um deles?
A relevncia deste trabalho est em utilizar metodologia geis para
Gerenciamento de Projetos de forma a minimizar o tempo com burocracias e excessos de
processos, tornando o gerenciamento mais simples e tendo mais chances de sucesso ao
projeto.
Para chegar a uma concluso sobre os mtodos geis, as seguintes suposies
foram levantadas:
i. Utilizao de Mtodos geis em Projetos de Desenvolvimento de Softwares
como ferramentas para aumentar as chances de sucesso do Projeto.
ii. A escolha e adaptao do Mtodo gil so relevantes para o sucesso do projeto.
Portanto, como objetivo geral do trabalho ser avaliar as vantagens e limitaes
das Metodologias geis mais apropriadas para o Gerenciamento de Projetos de
Desenvolvimento de Software de Manuteno de Componentes. Para isso ter como objetivos
especficos:
i. Apresentar as principais Metodologias geis;
ii. Apresentar as principais vantagens e desvantagens dos Mtodos geis.
iii. Comparar os mtodos geis eXtreme Programming (XP), Scrum,
driven development (FDD) e Adaptive Software Development (ASD) entre si;

Feature-

11

iv. - Identificar o Mtodo gil mais apropriado para o desenvolvimento de um


software de controle de manuteno de componentes porturios.
Quanto s tcnicas de pesquisa empregadas, esta pesquisa pode ser classificada
como uma pesquisa de campo. Uma pesquisa de campo aquela utilizada com o objetivo de
conseguir informaes e/ou conhecimentos acerca de um problema, para o qual se procura
uma resposta, ou de uma hiptese, que se queira comprovar, ou ainda, descobrir novos
fenmenos ou as relaes entre eles. Consiste na observao de fatos e fenmenos tal como
ocorrem espontaneamente, na coleta de dados a eles referentes e no registro de variveis que
se presumem relevantes, para analis-los. O que principalmente caracteriza esta pesquisa
como uma pesquisa de campo a comparao das metodologias geis aplicadas na gesto de
projetos em construes. (MARCONI, 2003) (VERGARA, 1997).
Pode-se ter pesquisas de campo do tipo: Exploratrias, Experimentais ou
Quantitativo-descritivo. Neste caso, ser utilizada a pesquisa quantitativo-descritiva. A
pesquisa de campo quantitativo-descritiva consiste em investigaes empricas, que objetivam
o delineamento ou anlise das caractersticas principais ou decisivas de um fenmeno, a
avaliao de programas ou ainda o isolamento de variveis principais ou chave. (MARCONI,
2003) (VERGARA, 1997).
O propsito deste estudo apresentar o Mtodo gil mais indicado para um
Projeto de Desenvolvimento de Software para Controle da Manuteno de Componentes
Porturios, baseado nas vantagens e desvantagens de cada um dos mtodos apresentados.
A estrutura do trabalho inicialmente conter a fundamentao terica e reviso
bibliogrfica a respeito das Metodologias geis e suas aplicaes em Projeto de
Desenvolvimento de Software e uma comparao da utilizao das Metodologias geis, com
suas vantagens e desvantagens. Ser feito uma comparao dos mtodos: eXtreme
Programming (XP), Scrum, Feature-driven development (FDD) e Adaptive Software
Development (ASD). Tambm ser feito uma explanao sobre a manuteno e qual a
importncia de um software para controle de componentes. No captulo final sero abordados
os dados de pesquisa em campo, demonstrao e anlises dos dados coletados e os resultados
da utilizao em campo da metodologia. Como uma concluso para avaliar a viabilidade e as
vantagens de aplicar as Metodologias geis.

12

2. DESENVOLVIMENTO
2.1

Metodologias geis de Desenvolvimento de Software

Segundo Silva (2011), criou-se em 2001 o Manifesto para o Desenvolvimento


gil de Software, comumente chamado apenas de Manifesto gil, e desde ento o termo
Desenvolvimento gil passou a descrever abordagens de desenvolvimento que seguissem os
princpios definidos neste manifesto para desenvolvimento de software. Apesar de os
membros da equipe envolvida ter suas prprias prticas e teorias individuais sobre como fazer
um projeto de software ter sucesso, todos concordavam que fundamentos comuns sempre
parecia ter sido respeitado quando os projetos davam certo.
Para Silva (2011), os principais Mtodos geis de Desenvolvimento de Produtos
so:

Scrum;

eXtreme Programming (XP);

Feature-Driven Development (FDD);

Lean Software Development;

DSDM (Dynamic System Development Method);

Crystal Family of Processes, (exemplo: Crystal Clear);

Adaptive Software Development (ASD);

Segundo Schwaber (2004), Scrum baseia-se na diviso da organizao em clulas


de equipes pequenas, multidisciplinares e auto-organizveis. Assim, na equipe Scrum no h
nenhum lder de equipe ou gerente de projetos para decidir o qual tarefa um membro vai
executar ou o problema que ser resolvido, sendo estas questes decididas pela equipe como
um todo. A equipe multifuncional para que todos tenham a possibilidade de trocar idias e
emitir opinies a cerca da caracterstica de implementao ou da tarefa a ser executada. Estas
equipes so apoiadas por dois indivduos especficos: um ScrumMaster e Proprietrio do
Produto. O ScrumMaster uma espcie de consultor ou treinador da equipe, ajudando os
membros da equipe utilizar o framework Scrum(quadro de resultados) da forma mais
eficiente. O proprietrio do produto representa a empresa, clientes ou usurios e orienta a
equipe para construir o produto correto.

13

Segundo Cohn (2006) e Silva (2011), Projetos Scrum avanam a medida que se
desenvolvem uma srie de Sprints (metas), que so atribudas em intervalos de tempo entre
duas a quatro semanas. Pode ser feito uma analogia ao ciclo PDCA, que gira para resolver
uma srie de medidas identificadas no planejamento. As funes ou tarefas necessrias para a
entrega do produto (Product Backlog) so divididas em fraes menores (Sprint Backlog).
No incio de um Sprint, os membros da equipe se comprometem a entregar estes determinados
nmeros de caractersticas ou atividades que foram listadas na carteira do projeto do produto.
No final do Sprint, com esses recursos prontos ou atividades executadas, realizada uma
reviso durante o qual a equipe demonstra a nova funcionalidade ou a atividade para o
proprietrio do produto e outras partes interessadas (stakeholders) que forneam feedback que
podem influenciar o prximo Sprint, melhorando-o com as experincias adquiridas no Sprint
anterior. Este processo pode ser visto na Figura 1 a seguir.

Figura 1. Metodologia Scrum.


Fonte: Adaptado de Mike Cohn, 2009.

14

Silva (2011), ainda continua a afirmar que no final dos anos 90, Kent Beck
desenvolveu com base nesta metodologia o Extreme Programming o qual mais conhecido
como XP. Este se caracteriza por um pequeno conjunto de prticas, que giram em torno de
alguns valores bsicos que ajudam a criar sistemas mais confiveis, com melhor escopo,
produzidos em menos tempo e com menor custo que as prticas normais. Os objetivos so
alcanados atravs de princpios e mtodos diferentes da forma tradicional de
desenvolvimento de software.
Segundo Beck (2005) essa metodologia destaca a agilidade no desenvolvimento
dos projetos e busca a satisfao do cliente, alm de favorecer o cumprimento das estimativas.
O XP proporciona ambiente de desenvolvimento de software, e est fundamentado
principalmente nos pilares: comunicao, simplicidade, feedback. O princpio de
comunicao est no bom relacionamento entre clientes e desenvolvedores, substituindo
meios de comunicao por conversas pessoais. A simplicidade permite a criao de cdigos
simples, ou seja, visa programar o software com o menor nmero possvel de classes e
mtodos. J o uso de feedback significa que o programador e cliente ter informaes
constantes do cdigo e as respectivas funcionalidades do programa. Abaixo segue a Figura 2
com o esquema metodolgico simplificado do XP.
Planejamento
- User Stories;
- Critrios de Aceitao.

- Plano de Iterao.

Produto

Desenvolvimento
Teste

- Simplicidade;

- Teste individual;
- Teste de aceitao.

Melhorias

Codificao &
Programao
- Programao em pares;
Interao contnua;
Feedback

Figura 2. Metodologia XP
Fonte: Adaptado de PRESSMAN, 2010.

- Cartes CRC;
- Prottipos.

15

Segundo Coad e Luca (1999) e Palmer (2002), O FDD (Feature-Driven


Development ) iniciou-se a partir dos conceitos de modelagem orientadas por objetos de Peter
Coad, e de gerenciamento de projetos de Jeff De Luca, sendo criada em 1997 para o
desenvolvimento de um programa bancrio em Cingapura. uma metodologia voltada para
priorizar as funcionalidades requeridas pelos clientes, independentemente das complexidades
dela. Embora o cliente no se envolva no processo de validao e testes, este mtodo se
prope a entregar o produto final de acordo com as expectativas iniciais e sem falhas. O valor
do cliente expressado de forma simples no formato: ao, resultado e objeto (p.e.: Somar
total de item em estoque). A seguir a Figura 3 com o esquema metodolgico do FDD.

Figura 3. Metodologia FDD.


Fonte: HEPTAGON (Online, 2014)

Segundo Highsmith, 2004, O ASD (Adaptive Software Development) foi a


metodologia proposta por Jim Highsmith e tem por base ser focada um uma meta ou misso
especfica. Utiliza caixas de tempo (Time Boxes), ou seja, o projeto fracionado em perodos
de tempo fechados, menores e definidos, para facilitar o planejamento e execuo. Neste
tempo so definidos oramentos, marcos e entregveis. Este mtodo julga necessrio avaliar
os riscos continuamente, num desenvolvimento em espiral, devendo-se focar na evoluo do

16

produto de forma iterativa sendo tolerante a mudanas durante o projeto para satisfazer o
cliente final. Segue a metodologia ASD na Figura 4.
Especulao
- Planejamento do ciclo adaptativo ;
- Usa declarao de misso ;

- Restries do projeto;

Produto

- Requisitos bsicos ;
- Liberao baseada em TimeBox.

- Incrementos do Software;
-Ajustes para ciclos subsequentes.

Aprendizado
- Componentes implementados e testados;
- Grupos focais para feedback

Colaborao
- Coleta de requisitos JAD;
- Mini-especificaes.

- Revises tcnicas formais


- Ps-mortem

Figura 4. Metodologia ASD.


Fonte: Adaptado de PRESSMAN, 2010.

2.2

Comparativo entre os Mtodos geis

Cada um dos mtodos geis apresenta um conjunto de atividades a serem adotadas


durante o processo de desenvolvimento do sistema. com base nestas atividades que
realizada a comparao. os mtodos geis que sero comparados so:

eXtreme Programming (XP);

Scrum;

Feature-driven development (FDD);

Adaptive Software Development (ASD).


Fagundes et al (2008) apud Sommerville (2003) afirma que:
os mtodos geis so fundamentados no Desenvolvimento Incremental. As
atividades sugeridas durante o seu processo de desenvolvimento so bastante

17

semelhantes aos Princpios geis. No Desenvolvimento Incremental, os clientes


inicialmente identificam, em um esboo, os requisitos do sistema e selecionam quais
so os mais e os menos importantes. Em seguida definida uma srie de iteraes de
entrega, onde em cada uma fornecido um subconjunto de funcionalidades
executveis, dependendo das suas prioridades.

A tabela 1 abaixo mostra o comparativo entre diversos mtodos de


desenvolvimento gil, baseado no Desenvolvimento Incremental, feito por Fagundes et al
(2008).
Tabela 1. Comparativo entre os Mtodos geis Baseado no Desenvolvimento Incremental.
Mtodo

Especificao da Atividade

Definio do Esboo dos Requisitos


XP
Clientes escrevem as user stories.
Scrum

Definio do Product Backlog

FDD

Gerao de artefatos para a documentao dos requisitos

ASD

Requisitos definidos durante as sesses JAD

Atribuio dos Requisitos as Iteraes


XP
Equipe tcnica e clientes definem as user stories que sero desenvolvidas nas
iteraes. As iteraes duram de 1 a 4 semanas
Scrum

Definio do Sprint Backlog. As Sprints (iteraes) duram no mximo 30


dias.

FDD

As caractersticas so agrupadas, priorizadas e distribudas aos responsveis pelo


seu desenvolvimento. As iteraes duram no mximo 2 semanas.

ASD

Definio do nmero de iteraes. As iteraes duram de 4 a 8 semanas.

Desenvolver Incremento do Sistema


XP
Implementao das user stories que fazem parte da iterao corrente por duplas
de programadores.

18

Scrum

Implementao dos requisitos contemplados no Sprint Backlog para a Sprint


corrente.

FDD

Anlise da documentao existente, gerao de Diag. de Seqncia da UML,


refinamento do modelo gerado nas atividades anteriores e implementao das
caractersticas que sero desenvolvidas durante a iterao corrente.

ASD

Implementao dos requisitos que fazem parte da iterao corrente.

Validar Incremento
XP
Os programadores executam os testes de unidade e os clientes executam os testes
de aceitao.
Scrum

O Scrum no adota nenhum processo de validao pr-definindo. Fica a critrio


do Product Owner definir.

FDD

Os testes e inspees so executados pelos prprios programadores aps a


implementao.

ASD

So verificadas a qualidade tcnica e funcional do sistema.

Integrar Incremento
XP
A integrao acontece paralelamente ao desenvolvimento das user stories.
Scrum

Atividade realizada ao final de cada Sprint.

FDD

Atividade realizada aps os testes no incremento.

ASD

N/D

Validar Sistema
XP
O sistema disponibilizado ao cliente para que o mesmo realize validaes.
Scrum

O cliente valida o sistema integrado em uma reunio no ltimo dia da Sprint.

FDD

Esta atividade ocorre atravs das inspees e dos testes de integrao

ASD

N/D

Entrega do Produto

19

XP

Cliente satisfeito com o sistema

Scrum

Todos os itens no Product Backlog desenvolvidos

FDD

O sistema entregue aps todos os conjuntos de caractersticas implementados

ASD

Todos os requisitos desenvolvidos.


Fonte: Fagundes et al, 2008.

Para Fagundes at al (2008), pode-se concluir que:


os mtodos geis selecionados para fazerem parte deste estudo apresentam
atividades bastante semelhantes em relao aos seus processos de desenvolvimento.
Porm, algumas atividades apresentam particularidades, como por exemplo: a
programao em dupla, as user stories escritas pelos clientes e a escrita dos testes
antes da implementao do XP; as reunies de planejamento, dirias e de reviso
adotadas pelo Scrum; as inspees de cdigo de FDD; e as sesses JAD sugeridas
pelo ASD.

2.3

Manuteno

A manuteno passou por mudanas nos ltimos 70 anos, segundo Pinto e Xavier
(2012), devido:
Ao aumento da complexibilidade e variabilidade dos equipamentos,
componentes, projetos e seus respectivos sistemas de monitoramento;
Novas tcnicas de manuteno;
E principalmente devido ao novo enfoque estratgico da manuteno como
fator para alcanar os resultado e altas produtividades.
A evoluo da manuteno foi classificada por Pinto e Xavier (2012) como:
a) Primeira Gerao: Do incio da revoluo industrial at a Segunda Guerra
Mundial a indstria era pouca mecanizada ou equipamentos eram simples e bastante robustos
(superdimensionados). A produtividade ainda no era fator-chave na competitividade e a
manuteno se limitava a limpeza, lubrificao e em casos de falhas, eram feitos os reparos
dos equipamentos. As equipes eram treinadas em cima das falhas e no de como preveni-las.
(PINTO; XAVIER, 2012).

20

b) Segunda Gerao: Ocorre a partir dos anos 50 at meados dos anos 70, no
perodo do ps-guerra quando as presses por produtos aumentaram e a mo de obra havia
diminudo sensivelmente. A mecanizao cresceu significadamente e a produtividade e
disponibilidade se fez necessrio, pois a indstria era dependente das mquinas. Surgiu o
conceito da manuteno preventiva, em que reparos sistemticos em intervalos fixos
evitariam a quebra dos equipamentos, pois havia a ideia que todas as falhas seguiam a curva
da banheira. Os custos de manuteno se elevaram e inicio dos sistemas de planejamento e
controle da manuteno (PCM) rudimentares, ainda sem o uso de softwares. (PINTO;
XAVIER, 2012).
c) Terceira Gerao: A partir da dcada de 70 os processos de mudana na
indstria aceleraram bastante. Paradas para manuteno impactavam no volume, no custo e na
qualidade da produo, tornando-se um problema de preocupao generalizada. A tendncia
da produo de adotar a filosofia Lean e Just-in-time causava um nvel de estoque bastante
reduzido e podia paralisar uma linha de produo em caso de falhas longas. Associado ao
crescimento da automao e da mecanizao, a confiabilidade e disponibilidade se tornam
fatores-chave no sucesso da organizao. Neste nvel de automao, as falhas tambm
interferem no nvel de qualidade e servio, cada vez mais provocando consequncias srias.
So caractersticas da 3. Gerao:
i. Reforo da manuteno preditiva;
ii. Uso de Softwares de Planejamento e Controle da Manuteno;
iii. Conceito de confiabilidade aplicado pela engenharia de manuteno;
iv. Utilizao do RCM (Manuteno Centrada na Confiabilidade) advindos da
indstria aeronutica;
v. Falhas de interao entre as reas de Engenharia, Manuteno e Operao
provocavam falhas prematuras;
vi. Incio de tercerizao por Servio. (PINTO; XAVIER, 2012).
d) Quarta Gerao: Tem, basicamente, as mesmas expectativas da terceira
gerao, porm o enfoque em disponibilidade bem mais alto e a confiabilidade passa ser o
alvo da manuteno. A engenharia da manuteno tem como razo de existncia a
Disponibilidade, Confiabilidade e Mantenabilidade. E a anlise de falhas se faz presente. O
monitoramento em tempo real dos equipamentos e a manuteno preditiva so cada vez mais
utilizados, e, com isso, a manuteno preventiva sistemtica cai em desuso. E as intervenes
no planejadas comeam a serem utilizadas como indicador de ineficcia da manuteno.

21

Tem incio a anlise do custo do ciclo de vida (Life Cicle Cost ( LCC)) e a engenharia da
manuteno aproximam e interagem a produo, engenharia (projeto) e a manuteno.
Segurana e meio ambiente so fatores importantes para o processo. No processo de
terceirizao, as contratadas so tratadas como empresas parceiras, com contratos longos e
baseados em indicadores de desempenho (KPIs). (PINTO; XAVIER, 2012);
e) Quinta Gerao: As prticas adotadas pela quarta gerao so mantidas, mas
o enfoque comea a ser voltado para os resultados empresariais, necessrios sobrevivncia
da empresa, pela da sistemtica da Gesto de Ativos (Asset Management). Os ativos devem
produzir na sua capacidade mxima, sem falhas no previstas, de forma que seja obtido o
melhor Retorno Sobre Ativos (Return on Assets (ROA)) ou Retorno Sobre Investimento
(Return on Investment (ROI)). Portanto os ativos devem ser acompanhados desde a fase
conceitual de projeto at o fim da vida (til e/ou econmica), visando diminuir as falhas.
Outras caractersticas da quinta gerao:
i. Aumento de preditivas e monitoramento on-line;
ii. Domnio de todo o ciclo de vida do ativo (concepo/projeto, aquisio,
instalao, comissionamento, operao, manuteno e descarte);
iii. Maximizao e Monitoramento de desempenho e produtividade;
iv. Melhoria contnua (Kaizen) em busca de diminuir falhas;
v. Excelncia na Engenharia de Manuteno;
vi. Terceirizao por resultados. (PINTO; XAVIER, 2012).
A Figura 5 apresenta o grfico da evoluo da manuteno.

22

5a. Gerao :
Confiabilidade +
Gesto de

4a. Gerao :
Confiabilidade +
Disponibilidade +
Eng. Manuteno

Gerao

3a. Gerao :
Manuteno
Preditiva +
Disponibilidade

2a. Gerao :
Manuteno
Preventiva

1a. Gerao :
Manuteno
Corretiva

0
1920

1930

1940

1950

1960

1970
Ano

1980

1990

2000

2010

2020

Figura 5 Evoluo da Manuteno


Fonte: Adaptado de Pinto e Xavier (2012).

2.4 Tipos de Manuteno

A classificao dos tipos de manuteno um pouco divergente entre os autores.


Para ABNT (1994) e Pereira (2009), existem a manuteno corretiva, preventiva e preditiva.
Porm para Xenos (2004) alm destas, citado: a melhoria de equipamentos, preveno de
manuteno e a manuteno produtiva. Entretanto Pinto e Xavier (2012), alm de descrever as
trs

propostas pela a associao brasileira de normas tcnicas (ABNT), acrescentou a

23

manuteno detectiva e engenharia de manuteno. Esta ltima similar a melhoria de


equipamentos proposta por Xenos (2004). Apresenta-se a seguir a classificao de Pinto e
Xavier (2012), adotada no presente trabalho.

2.4.1

Manuteno Corretiva

Segundo a ABNT (1994), a manuteno corretiva (MC) a manuteno efetuada


aps a ocorrncia de uma pane destinada a recolocar um item em condies de executar uma
funo requerida. Ou seja, feita sempre depois que a falha ocorreu. Para Xenos (2004), a
opo por este mtodo deve levar em conta aspectos econmicos, e as perdas de produo. A
deciso de levar o equipamento at a quebra pode, segundo Mobley et al. (2008), levar a
danos srios ao ativo ou a outros equipamentos adjacentes que operam normalmente,
principalmente em plantas que atuam de forma contnua, com elevadas cargas (presso, peso,
temperatura, corrente etc.). Portanto estes danos potenciais precisam ser avaliados.
As causas da manuteno corretiva podem vir de falhas (inutilizao do
equipamento) ou de defeitos (desempenho ineficiente) quem desviam as caractersticas de um
item em relao a seus requisitos. Portanto, a manuteno pode ser programada ou no
programada:

2.4.1.1

Manuteno Corretiva Programada

Manuteno Corretiva Programada ocorre quando um defeito que diminui a


produtividade do componente ou coloca em risco sua operao detectado, neste ponto feita
uma preparao e programao para ser realizado o reparo ou tomada a deciso de rodar at
a quebra (breakdown). Ento realizada de forma planejada. So importantes as inspees e o
monitoramento sensorial para que estes defeitos sejam percebidos antes que a falha ocorra.

2.4.1.2

Manuteno Corretiva No Programada

Manuteno Corretiva No Programada o tipo de reparo emergencial que feito


quando a falha ocorre de forma inesperada e aleatria e em condies que no podem ser
monitoradas (ex.: queima do filamento de uma lmpada incandescente ou falha de um circuito
integrado).

24

Tambm pode ser utilizada em partes menos crticas no equipamento, em que a


falha no ir impactar a produo ou quando se tem outro equipamento sobressalente
instalado pronto para operar.
importante lembrar que este tipo de manuteno requer um estoque sempre
disponvel, porque a falha pode ocorrer a qualquer momento, muitas vezes sem uma indicao
prvia.

2.4.2

Manuteno Preventiva

De acordo com a ABNT (1994), a manuteno preventiva (MP) aquela efetuada


em intervalos predeterminados, ou de acordo com critrios prescritos, destinada a reduzir a
probabilidade de falha ou a degradao do funcionamento de um item.
Existem dois tipos bsicos de manuteno preventiva, de acordo com Xenos
(2004, p. 139): a Baseada no Tempo e a Baseada na Condio (ou Preditiva, para alguns
autores).
A MP baseada no tempo realizada quando os componentes apresentam
cronodependncia e

vida til bem definida e/ou quando no podem ser monitorados

constantemente. A desvantagem deste tipo de manuteno que ela no utiliza os


componentes at o limite de sua vida-til e no h garantias que o componente no ir falhar
neste intervalo entre as manutenes, portanto ineficiente.
Nem sempre os prazos para troca de componentes so confiveis para Pinto e
Xavier (2012), portanto, ela deve ser feita sempre que:
- No for possvel a manuteno preditiva;
- Quando existirem riscos de acidente e segurana;
- Por oportunidade, em equipamentos de difcil liberao operacional;
- Em sistemas contnuos, que possuem alto valor de produtividade ou valor
agregado (ex.: petroqumicas, mineradoras, siderrgica, automobilstica).

25

2.4.3

Manuteno Preditiva

Manuteno preditiva definida pela ABNT (1994), como a manuteno que


permite garantir uma qualidade de servio desejada, com base na aplicao sistemtica de
tcnicas de anlise, utilizando-se de meios de superviso centralizados ou de amostragem,
para reduzir ao mnimo a manuteno preventiva e diminuir a manuteno corretiva.
considerada como uma forma de manuteno preventiva baseada na condio,
que mais eficiente, pois h um monitoramento frequente dos componentes atravs de
inspees, muitas vezes sensores online, maximizado a utilizao do elemento at o fim da
vida til. Porm nem todos os componentes so possveis este tipo de monitoramento em
alguns casos:
- No tem como acessar o componente sem desmonte;
- O parmetro ou condio no pode ser tecnicamente monitorado no local;
- Quando invivel a anlise do parmetro (Ex.: valor do ensaio alto ou muito
demorado);
- A falha ocorre de forma instantnea e aleatria (Ex.: Queima do filamento de
uma lmpada incandescente).
O objetivo da manuteno preditiva , para Pinto e Xavier (2012), reduzir ao
mnimo a manuteno preventiva, pelo uso do elemento at o limite do fim real de sua vida
til, assim como reduzir a manuteno corretiva no planejada, identificando e predizendo
com antecipao a falha, para que possa ser corrigida programadamente. Permite dessa forma
a operao contnua do equipamento pelo maior tempo possvel.
Devido aos equipamentos e tecnologia de predio ser bastante especfica,
comum ela ser tratada de forma diferenciada e existirem uma equipe dedicada a manuteno
preditiva. (XENOS, 2004).

26

2.4.4

Manuteno Detectiva

A manuteno detectiva , segundo Pinto e Xavier (2012), a atuao em


sistemas de proteo, comandos ou controles, buscando falhas ocultas. Seria a manuteno
dos sistemas de deteco.
Ela fundamental para a confiabilidade, que os sistemas de predio, controle,
monitoramento, intertravamento e proteo dos equipamentos estejam funcionando
corretamente. muito comum em plantas industriais o uso de sistemas de proteo do tipo
trip (protees eltricas) e shut-down (desligamento), porm eles tm que ser verificados para
detectar falhas e atuaes indevidas.

2.4.5

Engenharia da Manuteno

A engenharia da manuteno , de acordo com Xenos (2004), a melhoria contnua (kaizen)


dos equipamentos fundamental para o sucesso em longo prazo das organizaes. Alm
disso, os fabricantes dos equipamentos devem receber esta retroalimentao, de modo a
melhorar o projeto de seus produtos, para quando estes forem sendo substitudos. Para que a
engenharia de manuteno funcione, fundamental que as causas raiz sejam exaustivamente
investigadas. No apenas retomando as condies originais do equipamento sem buscar o que
causou a falha.
Alm disso o custo do equipamento avaliado durante todo seu ciclo de vida, desde a
concepo at o descarte. Os custos de operao, manuteno e descarte, segundo Pinto e
Xavier (2012), excedem os custos iniciais de aquisio de duas a 20 vezes, dependendo do
equipamento, portanto a fase de operao (onde ocorrem as manutenes) dever ser vistas
com a mesma preocupao econmica quando poca que o item foi adquirido. Este
fenmeno est ilustrado num exemplo na Figura 6:

27

Descarte

Modernizao

Start up

Fabricao e
Comissionamento

Detalhamento

Projeto Bsico

Custo Acumulado ($)

Operao e Manuteno

Tempo (t)

Figura 6 Custo Acumulado Durante o Ciclo de Vida (LCC).


Fonte: Adaptado de Pinto e Xavier (2012).

Para Viosca (1998), as empresas devem seguir degraus em uma escada virtual no
sentido da excelncia, porm no necessariamente deve ser seguido na ordem e os processos
(pode-se optar por no adotar alguns dos passos), a escada virtual pode ser descrita em trs
sees: manuteno bsica, computacional (softwares e ERPs) engenharia de confiabilidade
conforme a Figura 7.

28

Figura 7 Escalada da Manuteno.


Fonte: Adaptado de Viosca (1998)

Para se atingir a excelncia em manuteno, necessrio conhecer todo o ciclo de


vida do equipamento e ter tecnologia para o gerenciamento dos equipamentos. A
rastreabilidade de componentes e a correta identificao e apropriao dos custos de
manuteno, significam ter informaes importantes que iro definir as estratgias de
manuteno.

29

3. ESTUDO DE CASO
A Vale S/A uma empresa brasileira que tem negcios no ramo da minerao,
siderurgia, logstica e energia. Com sede no Brasil e presente em 37 pases. Foi criada por
decreto-lei, em 1 de junho de 1942 originalmente com o nome de Companhia Vale do Rio
Doce (CVRD), nesta poca as operaes eram concentradas em Minas Gerais e em seu
primeiro ano, produziu 40 mil toneladas de minrio de ferro, quantidade equivalente a que
embarcada por hora atualmente. Foi privatizada em 6 de maio de 1997. E em novembro de
2007, adotou-se o nome Vale, que veio a substituir Companhia Vale do Rio Doce
CVRD. (VALE, 2012).
a terceira maior empresa de metais e minerao do mundo e a maior das
Amricas, com base na capitalizao de mercado. a maior produtor mundial de minrio de
ferro e pelotas de minrio de ferro e o segundo maior produtor mundial de nquel. Um dos
maiores produtores mundiais de minrio de mangans e ferro ligas. Tambm produz cobre,
carvo trmico e metalrgico, fosfatos, potssio, cobalto e metais do grupo da platina
("PGMs"). Como estratgia de crescimento, participa ativamente da explorao mineral em
27 pases em todo o mundo. Opera um grande sistema de logstica no Brasil e em outras
regies do mundo, incluindo ferrovias, terminais e portos martimos, o qual est integrado as
operaes de minerao. Alm disso, tem um portflio de frete martimo para o transporte de
minrio de ferro. Diretamente e por intermdio de afiliadas e joint ventures, temo
investimentos nos setores de energia e siderrgico. A Vale uma empresa global com
escritrios, operaes, exploraes e joint ventures espalhados pelos cinco continentes.
(VALE, 2012).

3.1

Logstica da Vale S/A

Segundo Alleluia (2008), a distribuio dos portos como instrumento para o


crescimento econmico do pas uma constatao consagrada, pois 90% exportao para o
comrcio exterior realizado pelo transporte martimo. Os portos so os elos entre a parte
terrestre e martima de um sistema logsticos, segundo os quais a eficincia na transferncia
de carga e seus custos operacionais esto estritamente relacionados com a operao porturia.
(ALLELUIA, 2000).

30

Os portos da Vale servem para integrar verticalmente a cadeia logstica e


diminuir custos de frete, que impacta negativamente no preo final do produto no mercado
internacional. Segundo a Vale (2012), em seu stio eletrnico:

Nossos clientes e operaes esto localizados nos cinco continentes. Para integrlos, contamos com uma rede de portos e terminais modernos e eficientes, muitos
deles conectados a nossas minas por meio de ferrovias.
Temos portos com calado profundo, aptos para receber os Valemax os maiores
navios mineraleiros do mundo, com capacidade para 400 mil toneladas de minrio.
Para atender os portos menos profundos, instalamos as Estaes de Transferncia
Flutuante, onde o minrio passado dos navios Valemax para navios menores.
Essa cadeia de logstica integrada permite reduzir o nmero de viagens realizadas,
principalmente entre Brasil e sia, diminuindo no apenas custos e tempo, mas
tambm emisso de gases poluentes.

Para isto, possuem grandes recursos em ativos ferrovirios e porturios e a ampla


experincia como operadores de ferrovias e de servios porturios, associados falta de
transporte eficiente para carga geral no Brasil, possibilitando ocupar a posio de lderes no
segmento de logstica no Brasil. Atualmente est expandindo a capacidade das ferrovias e
portos principalmente para atender s necessidades de nossos negcios de minrio de ferro.
Para apoiar a estratgia comercial no segmento de minrio de ferro, est investindo no servio
de transporte martimo dedicado entre Brasil e sia e no desenvolvimento de centros de
distribuio na sia e no Oriente Mdio para minimizar os custos do frete e maximizar a
flexibilidade para melhorar a competitividade de minrio de ferro nessas regies. Estes
principais investimentos so: encomenda de uma frota de 35 navios da Classe VALEMAX,
entre prprios e contratados, feita a estaleiros da China e da Coreia do Sul, que sero
entregues at 2015, com operao exclusiva para a empresa, com capacidade de 400.000
toneladas de porte bruto, bem como o complexo porturio de Om e da Malsia. (VALE,
2012).
A Vale atua no mundo com diversos projetos logsticos e porturios conforme
Figura 8 a seguir:

31

Figura 8 Operaes Logsticas da Vale S/A.


Fonte: Vale (2012).

I. Paraguai: Atua no transporte hidrovirio no Corredor Corumb, atravs da


hidrovia Paran-Paraguai;
II. Argentina, Ferrovia para atender o projeto Rio Colorado e porto de San Nicols
no rio Paran;
III. Libria: Projeto Simandou (Guin), ser escoado por ferrovia e porto no Guin
(em fase de projeto);
IV. Om: Complexo Industrial do Porto do Sohar;
V. Moambique: Porto de Beira (arrendado) e Nacala Velha para escoar a
produo de carvo de Moatize (Tete);
VI. Malau: Logstica ferroviria (concesso);
VII. Indonsia: Porto de Harapan Tanjung Mangkasa, um porto especial com boias
de amarrao para acomodar navios e tambm um terminal que pode acomodar naviostanque. Atua em parceria com a Sumitomo;
VIII. Malsia: Terminal martimo (porto e ptio) no projeto Teluk Rubiah, capaz de
atracar navios de 400.000 dwt (Valemax).
IX. Filipinas: Atua com o floating transfer station (FTS) fazendo o papel de porto
offshore, ou seja, uma operao de transhipment em que navios da classe Valemax ou

32

capesizes atracam a contrabordo de um outro navio que transfere (ou armazena) carga para
navios de tamanhos menores.

No Brasil, o sistema logstico da Vale divide-se em: Sistema Sul-Sudeste,


composto pela Estrada de Ferro Vitria a Minas (EFVM), Ferrovia Centro Atlntica (FCA),
Portos Sul em Vitria (ES), o Terminal de Produtos Diversos (TPD), o Terminal de Granis
Lquidos (TGL) e o Terminal de Praia Mole (TPM) e em Barra dos Coqueiros (SE), o
Terminal Martimo Incio Barbosa (TMIB), alm da MRS Logistica, Terminal de Ilha Guaiba
- TIG e Terminal de Itagua, bem como as respectivas minas; e, o Sistema Norte, composto
da Estrada de Ferro Carajs (EFC), Ferrovia Norte Sul (FNS), Terminal Martimo de Ponta da
Madeira (TMPM), bem como as respectivas minas, conforme Figura 9 que segue. (VALE,
2012).

Figura 9 Sistemas de Produo/Logstica da Vale.


Fonte: Vale (2012).

33

3.2

O Terminal Martimo Ponta da Madeira TPPM

No caso do estudo, ser limitado ao Terminal Porturio Ponta da Madeira, que


segundo Vale (2012, p.3), tem o seguinte histrico: No ano de 1967, foram descobertas
jazidas de ferro em Carajs no Par, dando seguimento a construo do Sistema Norte que no
ano de 1984 foi marcado pelo fim da construo da ferrovia de Carajs, e, no ano de 1985
com o incio do Projeto Carajs e das operaes no Per 1 de Ponta da Madeira. Em 1994
comearam as operaes no Per 2, de carga geral, e em 2003, com o aumento da demanda
por minrio de ferro, o comeo das operaes no Per 3. Segue na Figura 10 uma viso geral
do TPPM.

Figura 10 Viso Geral do TPPM


Fonte: Vale (2012)

O Sistema do Terminal Martimo Ponta da Madeira TPPM composto


basicamente por Viradores de Vago, Sistemas de Transporte (Correias Transportadoras) e
Empilhadeiras e/ou Recuperadores e Carregadores de Navios.

34

3.3

Melhoria de Gesto utilizando Estratgias de Manuteno.

Segundo Silva (2012), a Vale iniciou em 2009 um sistema de gesto chamado de


VPS Vale Production System, que uma adaptao e adequao do STP (Sistema Toyota) e
TPM (Manuteno Preventiva total), que foi adotado pela Vale S/A, como modelo padro de
gesto, de modo a garantir a performance da empresa. No geral, tm como objetivo a reduo
de custos, reduzir tempos e aumentar a produtividade. Ou seja, produzir mais com menos
recursos atravs da excelncia em gesto.
O VPS composto por seis Dimenses, que abrangem os macroprocessos
mostrados na Figura 11 a seguir:

Figura 11 Dimenses do VPS


Fonte: Vale (2012)

Cada uma destas dimenses representada por uma pirmide que representa a
evoluo dos processos de gesto, onde na base da pirmide est o estgio bsico de gesto e
vai evoluindo medida que se vai em direo ao topo da mesma, chegando a excelncia ao
utilizar na plenitude a ferramenta de gesto de ativos. Para que o sistema de gesto atinja o
topo da pirmide, necessrio que a melhoria contnua seja implementada no setor de
manuteno, assim como importante que as melhorias sejam mantidas (padronizadas). Estes
processos esto representados pela que segue na Figura 12.

35

Pirmide de Excelncia

Meta: Atingir o topo do pirmide.

Estgio

Estgio

Estgio

Estgio

4. Gesto de Ativos 3. Processos de Confiabilidade


2. Preveno de Falhas 1. Tratamento de Perdas
Figura 12 VPS Manuteno
Fonte: Vale (2012)

3.3.1

Anlise do Cenrio Atual

Um importante sintoma que um processo est descontrolado a aleatoriedade e o


falta de uniformidade dos indicadores. Conforme Pinto e Xavier (2012) e Verri (2007) quanto
menor for a proporo de manuteno corretiva executada numa planta, em relao aos
demais tipos de manuteno, mais indica que esta unidade est sob controle.
O Terminal Porturio Ponta da Madeira possui um sistema informatizado de
gesto de manuteno comercial que est atualmente em troca por sistema concorrente. O
programa utilizado at o ano de 2014 no atendia de forma eficaz as informaes necessrias
para a manuteno eficiente de componentes porturios.

36

As principais falhas eram relacionadas ao controle da carteira de componentes que


estavam a recuperar, em recuperao e que estavam j recuperados em estoque. Outras falhas
como o tempo mximo que o item est em recuperao (pois existem questes fiscais
envolvidas), e a gesto de garantia (se o item falhou dentro de um perodo de garantia)
tambm no eram gerenciados pelo software de gesto da manuteno. Estes fatos, deixavam
o sistema porturio sob constante risco de falha, pois os controles sempre dependiam de
planilhas paralelas e do sentimento intuitivo de tcnicos e gestores.
Com base nas necessidades existentes, surgiu o desenvolvimento de um sistema
gerencial, chamado de SGC - Sistema de Gesto de Componentes, que foi feito customizado
para atender as necessidades do cliente na gesto da manuteno. Trata-se de um sistema
baseado nas nuvens, ou seja, funciona diretamente num servidor WEB e pode ser acessado
por todos os usurios, de qualquer dispositivo com acesso a rede mundial de computadores
(Internet).
O SGC foi desenvolvido utilizando mtodos tradicionais, baseado em
especificaes tcnicas e necessidades relatadas por meio de um documento escrito. O
resultado foi um programa com um grande potencial de uso, porm com muitos ajustes
necessrios, principalmente no que se referem a filtros de busca, funcionalidades e interfaces,
pois a participao do usurio foi mais efetiva os testes do que no planejamento,
especificaes e desenvolvimento do mesmo.

3.3.2

Melhorias do Sistema Atual

Para corrigir os problemas que no foram tratados no desenvolvimento do Sistema


de Gesto de Componentes original, seria necessria uma contratao adicional por parte do
cliente para aplicar todos os pontos de melhoria que foram apontadas e registradas pelos
usurios do sistema, ou seja, necessrio que seja feita uma atualizao de sistema. Porm,
para evitar novas falhas recomendvel utilizar tcnicas modernas de desenvolvimento de
softwares. As principais queixas do usurio, esto relacionadas a falta e despadronizao de
filtros para pesquisa, relatrios e outras funcionalidades menores que iriam melhorar e
facilitar o uso do sistema.
No mercado, como abordado em captulos anteriores, existem diversas tcnicas de
abordagem para o desenvolvimento de software, ento sero apresentadas quais as mais

37

indicadas para a melhoria de um sistema pr-existente, baseado na WEB e utilizando interface


de abas e filtros conforme Figura 13 a seguir.

Figura 13. Tela Inicial do Sistema de Gesto de Componentes.


Fonte: Autor, 2014.

Como relatado, o sistema atual no permite que o usurio busque uma informao
atravs de um mesmo requisito de filtro em telas similares, o que dificulta a busca por
informaes. Por exemplo, na Figura 14 abaixo, estamos na aba Geral do mdulo manuteno
de componentes, pode-se filtrar por TAG do componente, status de recuperao, gestor, fase e
nmero de Nota fiscal.

Figura 14. SGC - Mdulo Manuteno de Componentes - Aba Geral.


Fonte: Autor, 2014.

38

J na aba Aguardando Envio, no conseguimos pesquisar pelo TAG do


componente, como pode ser visto na Figura 15 a seguir.

Figura 15. SGC - Mdulo Manuteno de Componentes - Aba Aguardando Envio.


Fonte: Autor, 2014.

Como a programao da atualizao do sistema ser baseada em falhas relatadas


pelo usurio, so de extrema importncia que sejam utilizadas tcnicas que priorizem o
usurio final e que o mesmo tenha uma participao ativa no desenvolvimento, pois se trata
de um programa em que o usurio j domina, sendo necessrio implementar as melhorias
observadas pelos mesmos.
Com base nas caractersticas descritas dos mtodos geis de desenvolvimento de
software, o autor montou o quadro a seguir, que faz uma ponderao da participao do
usurio final em cada etapa e em cada mtodo.

39

Quadro 1. Participao do Usurio Final no Desenvolvimento da Fase.


Participao do Usurio vs. Mtodo
FASE

XP

Scrum

FDD

ASD

+++

++

+++

++

Atribuio dos Requisitos s Iteraes

++

Desenvolver Incremento do Sistema

+++

Validar Incremento

++

--

--

++

Integrar Incremento

---

++

++

--

Validar Sistema

++

---

Entrega do Produto

++

++

++

TOTAL

+7

+4

+9

+3

Definio do Esboo de Requisitos

Fonte: Autor, 2014.

No quesito de participao do usurio no desenvolvimento, o mtodo FDD e XP


reuniram melhores caractersticas individuais para tal fim. Entre estas, para ser a metodologia
escolhida para a etapa de melhoria no Sistema de Gesto de Componentes, deveria se fazer
reunies com a empresa terceirizada e verificar qual a mesma teria maior maturidade e
conforto para desenvolver as suas atividades.

40

4. CONCLUSES
O objetivo deste trabalho buscava definir qual a melhor Metodologia gil para
desenvolver um software de gerenciamento de componentes para manuteno porturia.
Mesmo com tantos tipos mtodos geis para desenvolvimento de softwares de manuteno,
no existe um tipo nico que v determinar sucesso no desempenho do sistema para os
usurios de uma empresa. A escolha uma questo econmica, cultural e que melhor se
adapte as condies necessrias para os usurios. Vimos que as metodologias geis possuem
vantagens em relao ao PMBOK por serem mais simples e menos burocrtica, tornando-as
mais aplicveis a projetos de pequeno porte.
Com este software ser capaz de conhecer o histrico do equipamento
(confiabilidade), evitar a falha (disponibilidade), prolongar a vida do equipamento
(engenharia da manuteno) e controlar os custos (gesto de ativos).
A investigao, conforme os objetivos especficos, identificou-se algumas prticas
importantes no desenvolvimento de um software de manuteno, como a participao direta
de usurios no desenvolvimento trs menores retrabalhos e resulta em clientes finais mais
satisfeitos. O mtodo XP e FDD possuem vantagens em relao aos demais mtodos geis,
pois o mesmo est mais focado na participao do usurio final.
Como possveis desdobramentos, pode-se aprofundar atravs de uma pesquisa
entre usurios de vrios mtodos geis, qual o grau de importncia que cada membro da
equipe no desenvolvimento, para que esta confirmao seja feita de forma estatstica, por
pesquisa de opinio.

41

REFERNCIAS BIBLIOGRFICAS
ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. NBR ISO 5462: Confiabilidade
e mantenabilidade. Rio de Janeiro, 1994.
BECK K., Extreme Programming Explained: Embrace Change, Addison-Wesley, 2a Ed ,
2005.
BECK, K.; GRENNING, J.; AT AL, Agile Manifesto, Disponvel na internet em:
http://agilemanifesto.org/. Acessado em 02 de Agosto de 2014.
COAD, P., FEBVRE, E., LUCA, J. Java Modeling in Color with UML: Entreprise
Components and Process, Prentice Hall PTR: 1999.
COHN, M. Agile Estimating And Planning, editora Prentice Hall 1 Edio 304p. 2006.
COHN, M. User Stories Applied: For Agile Software Development, Addison-Wesley
Professional; 1 edio. 2004.
FAGUNDES, P. B.; SANTOS, S. S.; DETERS, J. I. Comparao Entre os Processos Dos
Mtodos geis: XP, Scrum, FDD e ASD em Relao Ao Desenvolvimento Iterativo
Incremental, Atualidades Tecnolgicas para Competitividade Industrial, Florianpolis, v. 1,
n. 1, p. 37-46, 1. sem., 2008.
HEPTAGON. Tecnologia da Informao. Feature Driven Development. Disponvel
em:<http://www.heptagon.com.br/fdd>. Acessado em: 04 de setembro de 2014.
HIGHSMITH J., Agile
AddisonWesley, 2004.

Project

Management,

Creating

innovative

Products,

KNIBERG, H., Scrum and XP From the Trenches, InfoQ, 1a Ed., 2007.
MARCONI, Marina de Andrade; LAKATOS, Eva Maria. Fundamentos de metodologia
cientfica. 5. ed. So Paulo: Atlas, 2003.
MOBLEY, K. R.; HIGGINS L. R.; WIKOFF, D. J. Maintenance engineering handbook.
Nova York: 7. ed. Ed. McGraw-Hill, 2008.
PALMER, Stephen R.; FELSING, John M. A Practical Guide to Feature-Driven
Development. New Jersey: Prentice Hall PTR, 2002.
PEREIRA, M. J. Engenharia de manuteno: teoria e prtica. Rio de Janeiro: Editora
Cincia Moderna Ltda, 2009.
PINTO A. K.; XAVIER J. A. N. Manuteno: funo estratgica. 4. ed. Rio de Janeiro:
Qualitymark Editora, 2012.
PRESSMAN, R. Software Engineering: A Practitioner's Approach. 7a. Ed. Nova York:
McGraw-Hill, 2010.

42

RIBEIRO, A. R. C. Produtividade na manuteno porturia. 2011. Monografia


(Especializao em Porto) Universidade Federal do Maranho, So Lus, 2011.
SCHWABER, K. Agile Project Management with Scrum, editora Microsoft Press;
1 Edio; 192 p; 2004.
SILVA, RAFAEL TAVARES. Aplicao da metodologia scrum para gesto de projetos
na indstria naval. Trabalho de concluso de curso (Graduao em Engenharia de Produo
Mecnica) Universidade Federal do Cear, Fortaleza, 2011.
SILVA, RAFAEL TAVARES. Estratgia de manuteno nos portos: determinar mtodos
e ferramentas para o aumento da confiabilidade do sistema da descarga do Terminal
Martimo Ponta da Madeira. Monografia (Especializao em Porto) Universidade Federal
do Maranho, So Lus, 2012.
SLACK N.; CHAMBERS S.; JOHNSTON R. Administrao da produo. 2. ed. So
Paulo: Atlas, 2002.
SOMMERVILLE, I. Engenharia de Software. So Paulo: Addison-Wesley, 2003.
TAVARES, L. Administrao moderna da manuteno. Rio de Janeiro: Novo Polo
Publicaes, 1999.
TAVARES JNIOR, A. de S. Engenharia de confiabilidade: planejamento curto e mdio
prazo. So Lus: Vale, 2012.
VERGARA, S. Projetos e relatrios de pesquisa em administrao. So Paulo: Atlas,
1997.
VERRI, L. A. Gerenciamento pela qualidade total na manuteno industrial: aplicao
prtica. Rio de Janeiro: Qualitymark, 2007.
VIOSCA, R. R. Up the reliability ladder to world class - disponvel em < www.mtonline.com/june1998/up-the-reliability-ladder-to-world-class> - 1998, acessado em
06/07/2014.
XENOS, H. G. Gerenciando a manuteno produtiva. 1. ed. Rio de Janeiro: INDG, 2004.

Vous aimerez peut-être aussi