COMPARAÇÕES DE TIPOS DE METODOLOGIA ÁGIL PARA GERENCIAMENTO DE PROJETOS DE SOFTWARE: Caso Manutenção de Equipamentos Portuários

7/25/2019 COMPARAES DE TIPOS DE METODOLOGIA GIL PARA GERENCIAMENTO DE PROJETOS DE SOFTWARE: Caso Manu

1/43

RAFAEL TAVARES SILVA

COMPARAES DE TIPOS DE METODOLOGIA GILPARA 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


2/43


3/43

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


4/43

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


5/43

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


6/43

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.


7/43

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


8/43

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 projectsphases . 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


9/43

AGRADECIMENTOS

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

e conhecimento compartilhado.


10/43

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 OTERMINAL MARTIMO PONTA DA MADEIRATPPM ............................................... 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


11/43

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 limitaesdas 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, Feature-

driven development (FDD) eAdaptive Software Development(ASD) entre si;


12/43

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.


13/43

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 gilpassou 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 sempreparecia 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);

SegundoSchwaber (2004), Scrumbaseia-se na diviso da organizao em clulas

de equipes pequenas, multidisciplinares e auto-organizveis. Assim, na equipe Scrumno h

nenhum lder de equipe ou gerente de projetos para decidir o qual tarefa um membro vaiexecutar 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.
http://www.agilemanifesto.org/http://www.agilemanifesto.org/http://www.agilemanifesto.org/http://en.wikipedia.org/wiki/Agile_software_developmenthttp://www.livrariacultura.com.br/scripts/cultura/catalogo/busca.asp?parceiro=OIXIIP&nautor=373245&refino=1&sid=8790152671192237500832081&k5=24C564E0&uid=http://www.livrariacultura.com.br/scripts/cultura/catalogo/busca.asp?parceiro=OIXIIP&nautor=373245&refino=1&sid=8790152671192237500832081&k5=24C564E0&uid=http://en.wikipedia.org/wiki/Agile_software_developmenthttp://www.agilemanifesto.org/http://www.agilemanifesto.org/http://www.agilemanifesto.org/


14/43

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 forneamfeedbackque

podem influenciar o prximo Sprint, melhorando-o com as experincias adquiridas no Sprint

anterior. Este processo pode ser visto naFigura 1 a seguir.

Figura 1. Metodologia Scrum.

Fonte: Adaptado de Mike Cohn, 2009.


15/43

14

Silva (2011), ainda continua a afirmar que no final dos anos 90, Kent Beck

desenvolveu com base nesta metodologia o Extreme Programmingo 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 aFigura 2

com o esquema metodolgico simplificado do XP.

Figura 2. Metodologia XP

Fonte: Adaptado de PRESSMAN, 2010.

Planejamento

- User Stories;

- Critrios de Aceitao.

- Plano de Iterao.

Desenvolvimento

- Simplicidade;

- Cartes CRC;

- Prottipos.

Codificao &Programao

- Programao em pares;

Interao contnua;

Feedback

Teste

- Teste individual;

- Teste de aceitao.

Produto

Melhorias
http://en.wikipedia.org/wiki/Kent_Beckhttp://improveit.com.br/xp/praticashttp://improveit.com.br/xp/valoreshttp://improveit.com.br/xp/principioshttp://improveit.com.br/xp/principioshttp://improveit.com.br/xp/valoreshttp://improveit.com.br/xp/praticashttp://en.wikipedia.org/wiki/Kent_Beck


16/43

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 aFigura 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


17/43

16

produto de forma iterativa sendo tolerante a mudanas durante o projeto para satisfazer o

cliente final. Segue a metodologia ASD naFigura 4.

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

Especulao

- Planejamento do ciclo adaptativo ;

- Usa declarao de misso ;

- Restries do projeto;

- Requisitos bsicos ;

- Liberao baseada emTimeBox.

Colaborao

- Coleta de requisitos JAD;

- Mini-especificaes.

Aprendizado

- Componentes implementados e testados;

- Grupos focais para feedback

- Revises tcnicas formais

- Ps-mortem

Produto

- Incrementos do Software;-Ajustes para ciclos subsequentes.


18/43

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 deentrega, 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 RequisitosXP Clientes escrevem as user stories.

Scrum Definio doProduct Backlog

FDD Gerao de artefatos para a documentao dos requisitos

ASD Requisitos definidos durante as sesses JAD

Atribuio dos Requisitos as IteraesXP 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 30dias.

FDD As caractersticas so agrupadas, priorizadas e distribudas aos responsveis peloseu 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 SistemaXP Implementao das user stories que fazem parte da iterao corrente por duplas

de programadores.


19/43

18

Scrum Implementao dos requisitos contemplados no Sprint Backlog para a Sprintcorrente.

FDD Anlise da documentao existente, gerao de Diag. de Seqncia da UML,refinamento do modelo gerado nas atividades anteriores e implementao dascaractersticas que sero desenvolvidas durante a iterao corrente.

ASD Implementao dos requisitos que fazem parte da iterao corrente.

Validar IncrementoXP 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 critriodoProductOwnerdefinir.

FDD Os testes e inspees so executados pelos prprios programadores aps aimplementao.

ASD So verificadas a qualidade tcnica e funcional do sistema.

Integrar IncrementoXP 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 SistemaXP 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


20/43

19

XP Cliente satisfeito com o sistema

Scrum Todos os itens noProduct 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 storiesescritas 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).


21/43

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 Operaoprovocavam 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.


22/43

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).

AFigura 5 apresenta o grfico da evoluo da manuteno.


23/43

22

Figura 5Evoluo da Manuteno

Fonte: Adaptado de Pinto e Xavier (2012).

2.4Tipos 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

0

1

2

3

4

5

6

1920 1930 1940 1950 1960 1970 1980 1990 2000 2010 2020

Gerao

Ano

5a. Gerao :

Confiabilidade +

Gesto de

1a. Gerao :

Manuteno

Corretiva

2a. Gerao :

Manuteno

Preventiva

3a. Gerao :

Manuteno

Preditiva +

Disponibilidade

4a. Gerao :

Confiabilidade +

Disponibilidade +

Eng. Manuteno


24/43

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 noprogramada:

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 ata 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).


25/43

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).


26/43

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 deuma 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).


27/43

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) eshut-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 exaustivamenteinvestigadas. 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. Estefenmeno est ilustrado num exemplo naFigura 6:


28/43

27

Figura 6Custo 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 aFigura 7.

CustoAcumulado($)

Tempo (t)

ProjetoBsico

Detalhamento

Fabricaoe

Comissionamento

Startu

Operao e Manuteno

Moderniz

ao

Descarte


29/43

28

Figura 7Escalada 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.


30/43

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).


31/43

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 integr-los, contamos com uma rede de portos e terminais modernos e eficientes, muitosdeles conectados a nossas minas por meio de ferrovias.

Temos portos com calado profundo, aptos para receber os Valemax os maioresnavios mineraleiros do mundo, com capacidade para 400 mil toneladas de minrio.Para atender os portos menos profundos, instalamos as Estaes de TransfernciaFlutuante, 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, mastambm 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.000toneladas 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:


32/43

31

Figura 8Operaes 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 navios-

tanque. 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


33/43

32

capesizesatracam 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 Sulem 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 9Sistemas de Produo/Logstica da Vale.

Fonte: Vale (2012).


34/43

33

3.2 O Terminal Martimo Ponta da MadeiraTPPM

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 naFigura 10 uma viso geral

do TPPM.

Figura 10Viso 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.


35/43

34

3.3 Melhoria de Gesto utilizando Estratgias de Manuteno.

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

VPSVale 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 naFigura 11 a seguir:

Figura 11Dimenses 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 naFigura 12.


36/43

35

Figura 12VPS Manuteno

Fonte: Vale (2012)

3.3.1 Anlise do Cenrio Atual

Um importante sintoma que um processo est descontrolado a aleatoriedade e ofalta 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.

4. Gesto de Ativos

3. Processos de Confiabilidade

2. Preveno de Falhas 1. Tratamento de Perdas

Estgio

Estgio

Estgio

EstgioMeta:Atingirotopodopirmide.

Pirmide de Excelncia

1

2

3

4


37/43

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 docliente 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


38/43

37

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

de abas e filtros conformeFigura 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, naFigura 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.


39/43

38

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

componente, como pode ser visto naFigura 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.


40/43

39

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

Participao do Usuriovs. Mtodo

FASE XP Scrum FDD ASD

Definio do Esboo de Requisitos +++ ++ +++ ++

Atribuio dos Requisitos s Iteraes + + ++ -

Desenvolver Incremento do Sistema + - + +++

Validar Incremento ++ -- -- ++

Integrar Incremento --- ++ ++ --Validar Sistema ++ + + ---

Entrega do Produto ++ + ++ ++

TOTAL +7 +4 +9 +3

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.


41/43

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 XPe 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.


42/43

41

REFERNCIAS BIBLIOGRFICAS

ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. NBR ISO 5462: Confiabilidadee 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: EntrepriseComponents and Process, Prentice Hall PTR: 1999.

COHN, M.Agile Estimating And Planning, editoraPrentice Hall 1 Edio 304p. 2006.

COHN, M. User Stories Applied: For Agile Software Development, Addison-WesleyProfessional; 1 edio. 2004.

FAGUNDES, P. B.; SANTOS, S. S.; DETERS, J. I. Comparao Entre os Processos DosMtodos geis: XP, Scrum, FDD e ASD em Relao Ao Desenvolvimento IterativoIncremental, Atualidades Tecnolgicas para Competitividade Industrial, Florianpolis, v. 1,n. 1, p. 37-46, 1. sem., 2008.

HEPTAGON. Tecnologia da Informao. Feature Driven Development. Disponvelem:. Acessado em: 04 de setembro de 2014.

HIGHSMITH J., Agile Project Management, Creating innovative Products,AddisonWesley, 2004.

KNIBERG, H., Scrumand XP From the Trenches, InfoQ, 1a Ed., 2007.

MARCONI, Marina de Andrade; LAKATOS, Eva Maria. Fundamentos de metodologiacientfica.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-DrivenDevelopment. New Jersey: Prentice Hall PTR, 2002.

PEREIRA, M. J. Engenharia de manuteno: teoria e prtica. Rio de Janeiro: EditoraCincia 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.


43/43

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 scrumpara gesto de projetosna indstria naval. Trabalho de concluso de curso (Graduao em Engenharia de ProduoMecnica)Universidade Federal do Cear, Fortaleza, 2011.

SILVA, RAFAEL TAVARES.Estratgia de manuteno nos portos: determinar mtodose ferramentas para o aumento da confiabilidade do sistema da descarga do TerminalMartimo Ponta da Madeira. Monografia (Especializao em Porto)Universidade Federaldo Maranho, So Lus, 2012.

SLACK N.; CHAMBERS S.; JOHNSTON R. Administrao da produo. 2. ed. SoPaulo: Atlas, 2002.

SOMMERVILLE, I. Engenharia de Software. So Paulo: Addison-Wesley, 2003.

TAVARES, L. Administrao moderna da manuteno. Rio de Janeiro: Novo PoloPublicaes, 1999.

TAVARES JNIOR, A. de S. Engenharia de confiabilidade: planejamento curto e mdioprazo.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: aplicaoprtica. Rio de Janeiro: Qualitymark, 2007.

VIOSCA, R. R. Up the reliability ladder to world class - disponvel em - 1998, acessado em06/07/2014.

XENOS, H. G. Gerenciando a manuteno produtiva. 1. ed. Rio de Janeiro: INDG, 2004.
http://www.livrariacultura.com.br/scripts/cultura/catalogo/busca.asp?parceiro=OIXIIP&nautor=373245&refino=1&sid=8790152671192237500832081&k5=24C564E0&uid=http://www.livrariacultura.com.br/scripts/cultura/catalogo/busca.asp?parceiro=OIXIIP&tipo_pesq=editora&neditora=2854&refino=2&sid=8790152671192237500832081&k5=24C564E0&uid=http://www.livrariacultura.com.br/scripts/cultura/catalogo/busca.asp?parceiro=OIXIIP&tipo_pesq=editora&neditora=2854&refino=2&sid=8790152671192237500832081&k5=24C564E0&uid=http://www.livrariacultura.com.br/scripts/cultura/catalogo/busca.asp?parceiro=OIXIIP&nautor=373245&refino=1&sid=8790152671192237500832081&k5=24C564E0&uid=

Documents

COMPARAÇÕES DE TIPOS DE METODOLOGIA ÁGIL PARA GERENCIAMENTO DE PROJETOS DE SOFTWARE: Caso Manutenção de Equipamentos Portuários