Condicionantes do processo decisório na terceirização da manutenção de software: um estudo de caso em empresa pública

(1)

UNIVERSIDADE

CATÓLICA DE

BRASÍLIA

PRÓ-REITORIA DE PÓS-GRADUAÇÃO

STRICTO SENSU EM GESTÃO DO CONHECIMENTO E

TECNOLOGIA DA INFORMAÇÃO

Mestrado

CONDICIONANTES DO PROCESSO DECISÓRIO NA

TERCEIRIZAÇÃO DA MANUTENÇÃO DE SOFTWARE: UM

ESTUDO DE CASO EM EMPRESA PÚBLICA.

Autor: Odalis Jodoé Allievi

Orientadora: Profª Dra. Rejane Maria da Costa Figueiredo

(2)

ODALIS JODOÉ ALLIEVI

CONDICIONANTES DO PROCESSO DECISÓRIO NA

TERCEIRIZAÇÃO DA MANUTENÇÃO DE SOFTWARE: UM

ESTUDO DE CASO EM EMPRESA PÚBLICA.

Dissertação apresentada ao Programa de Pós-Graduação Stricto Sensu em Gestão do Conhecimento e da Tecnologia da Informação da Universidade Católica de Brasília, como requisito para obtenção do título de Mestre em Gestão do Conhecimento e da Tecnologia da Informação.

Orientadora: Rejane Maria.da Costa Figueiredo

(3)

Ficha elaborada pela Coordenação de Processamento do Acervo do SIBI – UCB.

A436c Allievi, Odalis Jodoé.

Condicionantes do processo decisório na terceirização da manutenção de software: um estudo de caso em empresa pública / Odalis Jodoé Allievi. – 2008.

211 f. ; 30 cm.

Dissertação (mestrado) – Universidade Católica de Brasília, 2008.

Orientação: Rejane Maria da Costa Figueiredo.

1. Software – Manutenção. 2. Tecnologia da informação. 3.

Terceirização – Processo decisório. 4. Gestão do conhecimento – Estudo de casos. I. Figueiredo, Rejane Maria da Costa, orient. II. Título.

(4)

DEDICATÓRIA

Aos nossos filhos, Miguel e Daniel.

Que também este trabalho lhes sirva de inspiração.

Que cumpram o dever de superar minha geração

e deixar mais valor no mundo.

(5)

AGRADECIMENTOS

A Deus por permitir a realização deste trabalho.

A minha esposa e filhos todo carinho e, principalmente, por me proporcionar um lar onde encontro paz, amor e força para continuar.

Aos meus pais Vilson e Albani e à minha irmã Lauria, por todo amor e pelo contínuo apoio e incentivo durante toda a minha vida.

Aos professores Rildo Ribeiro, Nicolas Anquetil e Rejane Figueiredo pela dedicação com que orientaram este trabalho.

Aos meu professores Gentil, Wander, Julia, Eunice Alencar, Fresneda, Rildo, Moresi pela dedicação, paciência e amizade

A todos meus colegas de curso, em especial aos que formaram grupos comigo, Alex, Odilon, Andrea, Rogério, Maristela, André, Kellen, Edgar, Osiris, pela convivência e lições gratuitas de responsabilidade, educação, compromisso e companheirismo.

Aos meus colegas de profissão Moles, Aristides, Kalb, Luiz Henrique, Erilson, Tonyson, Nacif, Luciana, Eurico, Edson, Piquet, Elisa, Glória, Foschini, Sérgio, por terem, cada um à sua maneira, colaborado para esta realização.

(6)

EPÍGRAFE

“Quem sabe tomar decisões nunca parte da premissa de que

determinado caminho é o correto e todos os demais errados.”

Peter Ferdinand Drucker

“O maior problema do mundo poderia ter sido resolvido

facilmente quando ainda era pequeno.”

(7)

RESUMO

A manutenção de software é a atividade que mais consome recursos no ciclo de vida de um software. Muitas empresas têm buscado na terceirização a força de trabalho de que precisam para fazer frente ao esforço demandado por esse serviço. Porém, a decisão em adotar, ou não, a terceirização é um processo crítico que influencia no sucesso ou fracasso do processo de terceirização. Este trabalho definiu um conjunto de condicionantes para auxiliar decisores no processo decisório na terceirização da manutenção de software, com base em modelos de gestão de Tecnologia da Informação. Adotou-se pesquisa bibliográfica e estudo de caso com procedimentos de pesquisa documental, observação participante e entrevistas. Como resultados foram definidas dez condicionantes que foram confirmadas por profissionais que vivenciaram o processo de terceirização da manutenção de software em uma grande empresa pública. A observação destas condicionantes, reveladas no estudo de caso, podem ser utilizadas como subsídios no processo decisório de futuras terceirizações da manutenção de software dessa e de outras empresas.

Palavras-chave: Terceirização de Tecnologia da Informação. Manutenção de software.

(8)

ABSTRACT

Software maintenance is the task that most requires resources in a software life cycle. Lots of companies have been in pursuit of outsourcing human resources to attend the demand of this service. However, the decision to outsourcing is a delicate process that interferes in the success or failure of outsourcing process. This study highlighted factors that can support managers in the decision making process to outsourcing software maintenance tasks, based in Information Technology management models. This research was conducted through a case study, bibliographic research, participant observation and interviews. The results listed ten influencing factors that were confirmed by professionals that experienced outsourcing process in software maintenance in a huge public institution. The observance of such factors, revealed during this study, can be used as subsidy in future outsourcing decision making process for software maintenance in the institution studied and in other companies.

(9)

Figura 1: Estrutura de tópicos para Manutenção de Software. 10 Figura 2: Processos da IEEE 1219 e ISO/IEC 14764. 26

Figura 3: As três dimensões do eSCM. 53

Figura 4: Atividades de Aquisição do MPS.BR 58

Figura 5: O ciclo de vida de fornecimento do eSCM-CL. 67

Figura 6: As áreas de capacidade do eSCM-CL. 68

Figura 7: Planejamento da pesquisa 98

Figura 8: Procedimento de coleta de dados 101

Figura 9: Pesquisa bibliográfica 103

(10)

Quadro 1: Quadro resumo da pesquisa. 2 Quadro 2: Evolução dos custos da manutenção de software 14

Quadro 3: Problemas técnicos da MS 18

Quadro 4: Problemas gerenciais da MS 19

Quadro 5: Tipos de terceirização 31

Quadro 6: Manutenção e Desenvolvimento de Software

terceirizados 32

Quadro 7: Motivos para terceirizar TI em 1990 e 2000 34 Quadro 8: Alguns exemplos de normas que algumas organizações

públicas devem seguir 40

Quadro 9: Modelos de processo decisório 45

Quadro 10: Visão geral dos modelos 61

Quadro 11: Contribuições dos modelos para tomada de decisão 62 Quadro 12: Práticas do eSCM-CL Área de Capacidade 71 Quadro 13: Relacionamento entre práticas do eSCM-CL 79 Quadro 14: Histórico de contratações de desenvolvimento e

manutenção de software do BANCO 107

Quadro 15: Situação atual de contratação do BANCO 110 Quadro 16: Composição do significado de Condicionante 111

Quadro 17: Lista de condicionantes 112

Quadro 18: Condicionantes e práticas da fase de Análise do

eSCM-CL 118

Quadro 19: Tabulação da confirmação de importância das

(11)

ABNT - Associação Brasileira de Normas Técnicas

ANS - Acordo de Nível de Serviço ou SLA - Service Level Agreement

CMM - Capability Maturity Model

CMMI - Capability Maturity Model -Integration

CMMI-AM - Capability Maturity Model -Integration - Acquisition Model

CMU - Carneggie Mellon University

COBIT - Control Objectives for Information and related Technology ESCM - e-Sourcing Capability Model

ESCM-CL - e-Sourcing Capability Model – for Clients

ESCM-SP - e-Sourcing Capability Model – for Service Providers

IEC - International Electrotechnical Commission

IEEE - Institute of Electrical and Electronics Engineers

IN - Instrução Normativa

ISACA - Information Systems Audit and Control Association

ISO - International Organization for Standardization

IT - Information Technology

ITSqc - Information Technology Services Qualification Center

MPS.Br - Melhoria de processo do Software Brasileiro

MPS.Br-GA - Melhoria de processo do Software Brasileiro -Guia de Aquisição PF – Pontos por Função

PMBoK - Project Management Book of Knowledge

RUP - Rational Unified Process

(12)

Sumário

1 INTRODUÇÃO...1

1.1Contexto...1

1.2Revisão Bibliográfica...2

1.3Problema...6

1.4Objetivos...7

1.5Organização do trabalho...7

2 MANUTENÇÃO DE SOFTWARE...9

2.1Considerações Iniciais...9

2.2Fundamentos da manutenção de software...10

2.2.1Definições e Terminologias...10

2.2.2Natureza da manutenção...11

2.2.3Necessidade de manutenção...12

2.2.3.1Sistemas legados...12

2.2.4Maioria dos custos em manutenção...13

2.2.5Evolução de software...15

2.2.6Categorias de manutenção...16

2.3Questões-chave da Manutenção de Software...17

2.3.1Questões técnicas...17

2.3.2Questões gerenciais...19

2.3.3Estimativa de custos de manutenção...21

2.3.4Métricas para manutenção de software...22

2.4Processos de manutenção...23

2.4.1Processos de manutenção...23

2.4.2Atividades de manutenção...27

2.5Técnicas de manutenção...28

2.5.1Compreensão de programas...28

2.5.2Reengenharia...28

2.5.3Engenharia reversa...29

2.6Considerações finais...29

3 TERCEIRIZAÇÃO DE TI...30

3.2Terceirização...30

3.3Terceirização de TI ...31

3.3.1Motivos e benefícios para terceirizar a TI...34

3.3.2Motivos ou riscos para não terceirizar a TI...36

3.4Terceirização de TI em empresas públicas ...39

(13)

4.2Tomada de decisão...41

4.2.1Questões para terceirização de Tecnologia da Informação ...46

4.2.2Ciclo de vida do processo de tomada de decisão de terceirização...47

4.3Questões na terceirização da manutenção de software...48

4.4Modelos para gestão em Tecnologia da Informação e Terceirização...51

4.4.1eSCM (The eSourcing Capability Model)...52

4.4.1.1 eSCM-CL (The eSourcing Capability Model for Client Organizations)...54

4.4.2COBIT (Control Objectives for information and Related Technology)...55

4.4.3CMMI (Capability Maturity Model Integration)...56

4.4.4PMI (Project Management Institute)...57

4.4.5MPS.BR (Melhoria do Processo de Software Brasileiro)...57

4.4.6Modelo proposto por Alfredo C. Saad...58

4.4.7Modelo proposto por Franceschini, Galetto, Varetto e Pignatelli...59

4.4.8Resumo compativo dos modelos...60

5 O MODELO ESCM-CL E AS PRÁTICAS DE ANÁLISE...64

5.1Considerações iniciais...64

5.2O modelo eSCM-CL...64

5.2.1Propósito...65

5.2.2A Estrutura do Modelo...65

5.2.3Ciclo de Vida de Fornecimento...66

5.2.4Áreas de Capacidade...67

5.2.5Níveis de Capacidade...69

5.2.6Práticas por área de Capacidade...70

5.3As Práticas da Fase de Análise ...78

5.3.1As práticas da área de capacidade Análise de Oportunidade de Fornecimento (Sourcing Opportunity Analysis - OPA)...80

5.3.1.1Definir o estado atual (opa01)...80

5.3.1.2Definir critérios para identificar oportunidades de terceirização (opa02)...82

5.3.1.3Identificar potenciais oportunidades de terceirização (opa03)...85

5.3.1.4Analisar opções de terceirização para potenciais oportunidades de terceirização (opa04)...86

5.3.2As práticas da área de capacidade Modo de Terceirização (Sourcing Approach - APP)87 5.3.2.1Identificar e documentar o modo de terceirização para as ações de terceirização propostas (app01)...88

5.3.2.2Estabelecer e implementar procedimentos para desenvolver e validar o plano de negócio para a terceirização (app02)...89

5.3.2.3Identificar e documentar o modelo de governança para a ação de terceirização proposta (app03)...91

5.3.2.4Realizar análise de risco e impacto da ação de terceirização proposta (app04)...93

5.3.2.5Decidir iniciar a ação de terceirização proposta (app05)...95

(14)

6.2Metodologia de pesquisa...97

6.2.1Planejamento...99

6.2.2Coleta de dados...100

6.2.2.1 Pesquisa Bibliográfica...102

6.2.2.2 Estudo de Caso...103

6.2.3Análise dos resultados...105

6.2.4Redação dos resultados...106

6.3Objeto do estudo de caso...106

6.3.1Experiências do BANCO com situações de terceirização de Tecnologia da Informação pregressas...106

6.3.2Situação atual...108

7 CONDICIONANTES PARA TERCEIRIZAÇÃO DA MANUTENÇÃO DE SOFTWARE – PRIMEIRA PARTE...110

7.2Condicionantes...110

7.2.1Aderência...113

7.2.2Fornecedores ...114

7.2.3Indicadores ...116

7.2.4Legislação...117

7.2.5Objeto (o que terceirizar?)...118

7.2.6Pessoas...120

7.2.7Processo...122

7.2.8Riscos...125

7.2.9Tempo...127

7.2.10Valores financeiros...128

7.3Considerações finais...131

8 CONDICIONANTES PARA TERCEIRIZAÇÃO DA MS – SEGUNDA PARTE...132

8.1Considerações iniciais...132

8.2Processo decisório ocorrido na organização para a terceirização da MS...132

8.3Utilização e importância das condicionantes...134

8.4Relato sobre as condicionantes ...135

8.4.1Aderência...135

8.4.2Fornecedores...135

8.4.3Indicadores...136

8.4.4Legislação...136

8.4.5Objeto...136

8.4.6Pessoas...137

8.4.7Processo...138

(15)

8.4.10Valores financeiros...140

8.4.11Condicionantes complementares ...141

9 CONCLUSÕES E TRABALHOS FUTUROS...142

9.1Visão geral...142

9.2Conclusões...143

9.3Contribuições...145

9.4Trabalhos Futuros...145

10 REFERÊNCIAS BIBLIOGRÁFICAS...147

11 APÊNDICES...151

11.1Termo de consentimento livre e esclarecido...151

11.2Apêndice II – roteiro de entrevistas...152

11.3APÊNDICE III – Categorização do eSCM-CL e referencial teórico...154

11.3.1ADERÊNCIA...154

11.3.1.1eSCM...154

11.3.2FORNECEDORES...155

11.3.2.1eSCM...155

11.3.2.2Terceirização...155

11.3.2.3Processo Decisório...157

11.3.3INDICADORES...157

11.3.3.1eSCM-CL...157

11.3.3.2Manutenção de Software...158

11.3.4LEGISLAÇÃO...160

11.3.4.1eSCM-CL...160

11.3.5OBJETO...160

11.3.5.1eSCM-CL...161

11.3.6PESSOAS...162

11.3.6.1eSCM-CL...162

11.3.7PROCESSO...166

11.3.7.1eSCM-CL...166

(16)

11.3.8RISCOS...168

11.3.8.1eSCM-CL...169

11.3.9TEMPO...171

11.3.9.1eSCM-CL...172

11.3.10VALORES FINANCEIROS...172

11.3.10.1eSCM...172

11.4APÊNDICE IV – Categorização da análise documental e observação participante...175

11.4.1ADERÊNCIA...175

11.4.1.1Edital Sustentação de Software...175

11.4.1.2Observação Participante...175

11.4.2FORNECEDORES...175

11.4.3INDICADORES...175

11.4.4LEGISLAÇÃO...180

11.4.5OBJETO...180

11.4.5.2Obervação Participante...184

11.4.6PESSOAS...184

11.4.7PROCESSO...185

11.4.7.2Guia de Referência Técnica...186

11.4.8RISCOS...189

11.4.9TEMPO...190

(17)

(18)

1 INTRODUÇÃO

1.1 Contexto

A dependência por software atinge diversas áreas das atividades econômicas, financeiras e sociais da humanidade. Criar e manter programas de computador são tarefas que influenciam ou interferem em diversos aspectos das economias nacionais e internacionais (SOMMERVILLE, 2007). Além disso, o esforço e o custo de manutenção de software têm aumentado, consumindo cada vez mais recursos das organizações.

Esses recursos podem vir a ser fornecidos por meio da terceirização de serviços, que também permite que as empresas concentrem-se em sua atividade-fim e, quando usada adequadamente, pode incrementar a produtividade, agilidade, competitividade e lucratividade das organizações (SAAD, 2006).

Sendo a terceirização da manutenção de software uma alternativa, incorre-se em um processo de tomada de decisão que ocorre sempre que seja necessário agir diante de um problema. Mesmo existindo apenas uma alternativa, agir ou não, é uma decisão com efeitos distintos (GOMES, 2006).

Cada vez mais empresas proprietárias de sistemas de informação encontram-se diante da questão se devem ficar com a manutenção dos mesmos sob sua inteira responsabilidade ou se contratam terceiros para auxiliá-los nessa tarefa. Percebe-se que há vantagens, oportunidades, desvantagens e riscos na terceirização das atividades de Tecnologia da Informação (TI).

O alto crescimento da terceirização e as recorrentes falhas nos serviços de TI atentam para uma necessidade latente: tanto clientes quanto fornecedores de serviços precisam estar aptos a atender aos fatores críticos da terceirização de TI a fim de aumentar a probabilidade de sucesso deste tipo de relacionamento (HYDER et al., 2006a).

(19)

Por essas considerações, com base nos fatores específicos da atividade de manutenção de software, nas vantagens e desvantagens da terceirização de serviços de TI e no relato de atividades do processo decisório, propõem-se condicionantes a serem seguidas nas contratações de manutenção de software, com mais ênfase nas especificidades de empresas públicas. Assim, contribui-se para um processo decisório que busque a melhor alternativa capaz de identificar e dar respostas às questões mais relevantes.

1.2 Revisão Bibliográfica

Para a revisão bibliográfica deste trabalho foram realizadas pesquisas nas principais bases como: IEEE [http://www.ieee.org], Web of Science [http://isiknowledge.com] e Google Acadêmico [http://www.googlescholar.com]. As palavras-chave definidas foram: Software Maintenance, Decision, Outsourcing, Information Technology buscando possíveis associações entre elas. O Quadro 1 demonstra a quantidade de ocorrências em cada fonte de pesquisa.

Quadro 1: Pesquisa nas bases científicas

Termos IEEE Web of

Science

Google

Acadêmico

“Software Maintenance” 4.066 373 33.500 “Software Maintenance” and Decision 179 32 11.900

“Software Maintenance” and Outsourcing 21 9 1.490

“Software Maintenance” and Outsourcing and Decision 2 - 1.140 “Information Technology” and Outsourcing 98 42 39.800

“Information Technology” and Outsourcing and Decision

17 3 20.300

(20)

Há o reconhecimento de que a terceirização da manutenção de software tornou-se uma grande indústria e há preocupações por parte de pesquisadores e profissionais em questões como: que sistemas terceirizar, como manter o controle estratégico, delimitar o que é manutenção e como detalhar em contratos, como será a transição do sistema para a empresa contratada, entre outras (SWEBOK, 2004, cap. 6, p. 5).

Misra et al. (2006) pesquisaram fatores e co-relacionamentos na terceirização da manutenção de software. Dentre estes fatores relacionados ao esforço (tempo, quantidade de profissionais, custos, entre outros) para manutenção, encontram-se: características do sistema, atitudes do cliente, clima organizacional e equipe de manutenção. Como resultado de sua pesquisa, concluíram que os fatores e aspectos da manutenção de software independem dos serviços a serem fornecidos por terceirizados (manutenção outsourcing) ou feitos na empresa cliente (manutenção insourcing).

Ahmed (2006) apresenta e justifica algumas recomendações para que a terceirização da manutenção seja confiável e de custo compatível. Essas recomendações são divididas em estratégias e de riscos. As estratégias gerais se referem, em primeiro lugar, à decisão do escopo. Assim, terceirizar o help desk é muito diferente da terceirização da manutenção de código. Os riscos da manutenção terceirizada são similares aos do desenvolvimento, no entanto, há riscos específicos da manutenção terceirizada, como custos e prazos fora de controle.

Park e Kim (2003) examinaram a efetividade dos tipos de manutenção (insourcing e

outsourcing) na perspectiva da qualidade e do esforço. Utilizaram 107 entrevistas, das quais 52 foram respondidas por profissionais trabalhadores em bancos, em um total de 28 organizações. Uma das conclusões é de que o grau de esforço para os tipos insourcing e

outsourcing mudam dependendo da idade do sistema. Tanto para sistemas de apoio a decisão como transacionais, o tipo outsourcing emprega maior esforço que o insourcing. O número de mantenedores decresce no tipo insourcing em sistemas com mais de 3 anos. Nos transacionais, o tipo outsourcing emprega muito mais mantenedores nos primeiros anos, enquanto o insourcing mantém o mesmo número (PARK e KIM, 2003).

São comuns problemas complexos de decisão quando há diversas possibilidades de ação em uma infinidade de áreas em várias atividades públicas e privadas. Após estabelecidos os critérios para a decisão, pode-se aplicar métodos matemáticos para atribuição de pesos, como: SMART (Simple Attribute Rating Technique), Ordinal (Ranking Methods), AHP (Analytic Hierarchy Process), Atribuição Direta de Peso ou Pontuação Direta (Direct Rating),

(21)

No uso dessas metodologias matemáticas enfrenta-se o problema dos critérios (fatores, restrições, relaxações, atributos, alternativas ou conseqüências das alternativas) não estarem claramente definidos (GOMES, 2006, p. 29). Para Drucker (2006, p. 16-18), ao especificar a resposta ao problema, deve-se estabelecer os objetivos, as metas mínimas, as condições que deverão ser satisfeitas, ou seja, há de se definir as “condições-limite”. Decisões que não satisfazem às condições-limite são piores que aquelas que erram na definição do problema.

Neste trabalho, utiliza-se o termo condicionantes para o conjunto de significados das palavras: restrição, fator, critério, aspecto, premissa, argumento, dedução, preferência, atributo, diretrizes, observação, regras e imposição.

Ferreira, Shimizu e Laurindo (2007) utilizaram o método Analytic Network Process

(ANP), similar ao AHP, para explicar a decisão de terceirização das atividades de TI. A metodologia AHP é baseada na comparação paritária de critérios e atribuição de peso do mais até o menos importante (GOMES, 2006, p.100-103) e a ANP melhora as interações entre os níveis de tomada de decisão. Foram analisados três casos em uma empresa brasileira e como base para a análise fizeram revisão de literatura para considerarem seis aspectos relativos à terceirização: estratégico, custos, contratos e gestão dos fornecedores, riscos, exemplos de terceirização da TI (benchmarking) e novas formas de gestão. Os autores concluíram que o uso do ANP pode explicar o contexto de uma decisão de terceirização de TI. Porém, sugerem que o mesmo modelo seja aplicado em mais casos e situações diferentes, tanto para explicar decisões passadas como para auxiliar em decisões futuras.

Drucker (2006) e Bazerman (2004) consideram o processo decisório, com suas etapas, se possível evitar heurísticas e vieses, suficientes para se chegar a decisões “racionais” corretas. Mesmo assim, Overby (2007) informa que o índice de fracasso das relações de

outsourcing está entre 40 e 70%, sendo que o cerne do problema está no conflito de interesses entre fornecedor e cliente. O primeiro quer lucrar mais e o segundo quer gastar menos.

Segundo Bergamaschi (2004), há empresas que conseguem obter melhores resultados na administração da terceirização de TI por estarem mais focadas nos objetivos da terceirização. Assim, para essas empresas, há maior satisfação com os serviços prestados e percebem redução de custos, aumento da eficiência, foco nas atividades essenciais e melhora no desempenho dos processos de TI. As empresas menos “preocupadas” com os objetivos têm menor crença nesses resultados.

(22)

opiniões opostas entre as duas classificações de empresa quanto a ser mais barato manter a TI interna e ao esforço para seleção do fornecedor, por exemplo.

Diante de tantos aspectos relativos a TI, os decisores podem recorrer a diversos modelos de gestão para a TI. Fernandes e Abreu (2006) resumiram 20 deles, dentre os quais se encontram o eSCM-SP (The eSourcing Capability Model – Service Provider) e o eSCM-CL (CL -for Client Organizations), da Carnegie Mellon University (CMU), e focam terceirização de serviços suportados por TI (HEFLEY e LOESCHE, 2007), o COBIT (Control Objectives for Information and Related Technology), apresentado pelo Information Systems Audit and Control Foundation (ISACA) com foco em governança de TI, o CMMI (Capability Maturity Model Integration), criado pelo Software Engineering Institute (SEI), também da CMU, com foco em processos de software, o PMBOK (Project Management Body of Knowledge), do

Project Management Institute (PMI), com foco em gestão de projetos, e o MPS.BR (Melhoria do Processo de Software Brasileiro).

O eSCM-CL propõe um conjunto de “boas práticas” de gestão desenvolvidas para fornecer, às empresas clientes de serviços de terceirização, um guia visando ao sucesso de suas iniciativas. O eSCM-CL preocupa-se com o conjunto de tarefas voltadas àquele que é o comprador de serviços suportado por TI, desde o ato de desenvolver a estratégia do sourcing

da organização, o seu planejamento e a seleção do fornecedor de serviço, o início do contrato, o controle da entrega do serviço e o término do contrato. Tem a intenção de ser um modelo associado para o eSCM-SP, focalizando-se nos aspectos mais voltados ao cliente nos relacionamentos de provimento de serviços bem-sucedidos (HEFLEY e LOESCHE, 2006).

Segundo Fernandes e Abreu (2006), “o principal objetivo das práticas do COBIT é contribuir para o sucesso da entrega de produtos e serviços de TI, a partir da perspectiva das necessidades do negócio, com um foco mais acentuado no controle que na execução”. Dentre os 34 processos distribuídos nas quatro perspectivas do COBIT, dois tratam de terceirização: AI2 – Aquisição e Manutenção de Software Aplicativo (sistema) e DS2 – Gestão de Serviços de Terceiros.

O PMBOK tem como objetivo identificar o subconjunto do conjunto de conhecimento em gerenciamento de projetos que é amplamente reconhecido como boa prática. O modelo prevê uma área de conhecimento denominada “Gerenciamento de Aquisições do Projeto” que também trata de terceirização (PMBOK, 2004).

(23)

apresenta um processo de aquisição de Software e Serviços Correlatos (S&SC) e está ajustado para aquisição de produtos de prateleira (pacotes de software), entre outros; porém, não é indicado para a modalidade de contratação de mão-de-obra (SOFTEX, 2007, p. 7).

A terceirização tem sido preocupação recorrente por parte das empresas que a adotam e também no serviço público. Para o segundo, quatro Instruções Normativas foram publicadas para regulamentação do tema, sendo que duas dispõem sobre questões referentes à Tecnologia da Informação.

Com isso, observa-se a existência de modelos que se propõem a melhorar o processo de software, como por exemplo o Melhoria do Processo de Software Brasileiro (MPS.BR), e outros que se propõe a conduzir o processo de terceirização como, por exemplo, o eSourcing Capability Model (eSCM). Também existem muitos modelos para auxiliar o processo decisório, como por exemplo o Analytic Network Process (ANP). Porém, há carência de pesquisas sobre a terceirização da manutenção de software utilizando processos decisórios e modelos para gestão de terceirização em conjunto.

1.3 Problema

Terceirizar, ou não, é uma questão complexa que deve considerar diversos riscos e aspectos para o negócio. A terceirização da manutenção de software é distinta de outras funções da área de TI. A manutenção insourcing de software traz resultados diferentes das resultantes da manutenção outsourcing. Na manutenção outsourcing há mais riscos, fatores e questões para serem resolvidas do que na insourcing.

Há muitos modelos de gestão que prescrevem atividades e auxiliam o decisor no processo de terceirização, alguns em aspectos gerais, outros em aspectos de TI, e poucos lidam com as questões da área de software. Porém, não se encontram modelos que abordem especificidades da manutenção de software.

É necessário aumentar os subsídios do decisor para uma decisão “esclarecida”, diminuindo a possibilidade de que ela se revele na fase de execução ou de apresentação de seus resultados “incorreta” ou imprópria.

(24)

Dado o contexto, a pergunta desta pesquisa é: que condicionantes devem ser observadas para a decisão de terceirização da manutenção de software?

1.4 Objetivos

Dada a relevância do tema, o objetivo principal deste trabalho foi definir condicionantes que devem ser observadas no processo de decisão em terceirizar a manutenção de software.

Para se chegar a esse objetivo principal, os seguintes objetivos específicos foram definidos:

● caracterizar o processo de manutenção software;

● caracterizar o processo de terceirização da manutenção de software;

● caracterizar o processo decisório da terceirização da manutenção de software; ● identificar condicionantes para o processo decisório da terceirização da

manutenção de software.

1.5 Organização do trabalho

Este trabalho está organizado em oito capítulos. Neste capítulo – Introdução, apresenta-se o contexto, a revisão bibliográfica e justificativas, o problema e objetivos deste trabalho.

No capítulo 2 – Manutenção de software, apresenta-se as principais questões concernentes à manutenção de software, seus fundamentos, questões-chave, seus processos e técnicas.

No capítulo 3 – Terceirização de TI, apresenta-se a redação de um dos resultados desta pesquisa, o referencial – Terceirização de TI. Apresenta-se motivos e benefícios para terceirizar a TI e motivos e riscos para não terceirizá-la.

(25)

No capítulo 5 – Modelo eSCM-CL e as Práticas de Análise, apresenta-se o modelo eSCM-CL que foi utilizado como referência para este trabalho, ressaltando-se a fase de análise.

No capítulo 6 – Metodologia, apresenta-se a metodologia de pesquisa adotada, detalhes sobre seu planejamento, procedimentos e coleta de dados, descrição do estudo de caso, entre outros.

No capítulo 7 – Condicionantes para Terceirização da MS – Primeira Parte, apresenta-se o contexto da pesquisa com informações sobre a organização escolhida para o estudo de caso e as condicionantes resultantes da pesquisa bibliográfica, documental e observação participante.

No capítulo 8 – Condicionantes para Terceirização da MS – Segunda Parte, apresenta-se os resultados das entrevistas para confirmar apresenta-se as condicionantes apreapresenta-sentadas no capítulo anterior foram utilizadas e com que importância. Também, foi possível entender melhor o processo decisório ocorrido na organização.

No capítulo 9 – Conclusões e trabalhos futuros, apresenta-se as conclusões, contribuições e trabalhos futuros..

Encontra-se, ainda, quatro apêndices:

Apêndice I – Termo de consentimento livre e esclarecido; Apêndice II – Roteiro de entrevistas;

Apêndice III – Categorização do eSCM-CL e referencial teórico;

(26)

2 MANUTENÇÃO DE SOFTWARE

2.1 Considerações Iniciais

Este capítulo apresenta o resultado de pesquisa bibliográfica na literatura de Manutenção de Software, Engenharia de Software, Tecnologia da Informação (TI) e Administração destacando-se os principais problemas e aspectos recorrentes em trabalhos publicados concernentes Manutenção de Software (MS).

O Guide to the Software Engineering Body of Knowledge (SWEBOK) é usado como linha mestra nos assuntos abordados. No entanto, mesmo sendo o Guia orientado para várias audiências com diversos objetivos no intuito de fornecer uma visão consistente em engenharia de software, publicações bastante conhecidas de autores como Sommerville, Pressman e Pigosky são usadas em conjunto. Além disso, padrões da International Organization for Standardization (ISO), normas do Institute of Electrical and Electronics Engineers (IEEE) e diversos trabalhos acadêmicos se juntam para melhor esclarecer alguns tópicos.

Conforme a Figura 1, para o SWEBOK (2004, cap.6, p.91) há o entendimento que tanto o processo de MS, quanto questões referentes à manutenção possam ser organizadas em forma de seções e tópicos. Assim, este capítulo adota a organização proposta pelo SWEBOK:

• Fundamentos de Manutenção de Software - definições e terminologias, natureza da manutenção, necessidade de manutenção, maioria dos custos de manutenção, evolução de software e categorias de manutenção;

• Questões Chave em Manutenção de Software - questões técnicas, questões gerenciais, estimativa de custos de manutenção, métricas para manutenção de software;

• Processos de Manutenção de Software - processos de manutenção e atividades de manutenção;

(27)

Figura 1: Estrutura de tópicos para Manutenção de Software. Fonte: SWEBOK (2004, cap.6, p.2)

2.2 Fundamentos da manutenção de software

Esta seção provê uma base de entendimento sobre MS com definições e ênfases nos seguintes assuntos: definições e terminologias, natureza da manutenção, necessidade de manutenção, maioria dos custos de manutenção, evolução de software e categorias de manutenção

2.2.1 Definições e Terminologias

(28)

Sommerville (2007, p.326) entende que MS é toda mudança em um sistema após a sua entrega e identifica três tipos diferentes:

• Manutenção para reparos de defeitos de software – são correções em programas, em projetos e em requisitos;

• Manutenção para adaptar o software a um ambiente operacional diferente – necessária quando da mudança de hardware, sistema operacional ou outro elemento do ambiente;

• Manutenção para adicionar funcionalidade ao sistema ou modificá-lo – para atender novos requisitos de negócio.

Sommerville (2007, p.326) também reconhece os termos manutenção corretiva e adaptativa, mas usa o termo evolutiva para as demais e afirma que há uma variação de nomenclatura e, por isso, prefere não utilizar as demais.

As normas, ou padrões, ISO/EIC 14764 e IEEE/EIA 12207 definem MS como “modificações no código e na documentação associada devido a um problema ou necessidade de melhoria. O objetivo é modificar um produto de software preservando sua integridade”, sendo que a primeira também enfatiza os aspectos da pré-entrega SWEBOK (2004, cap.6 p.1). O SWEBOK (2004, cap. 6, p.1) define como manutenção de software (MS) todas as atividades antes e depois da entrega que objetivam um efetivo controle de custos ( cost-effective) para suporte ao software. Atividades de pré-entrega incluem o planejamento para as operações de entrega: manutenibilidade e atividades de transição. Atividades de pós-entrega incluem modificações no software, treinamento, operação e help-desk.

Neste projeto usa-se a definição do SWEBOK por ser a que representa a comunidade internacional de engenharia de software.

2.2.2 Natureza da manutenção

Pfleeger (apud SWEBOK, 2004, cap. 6-1) argumenta que “na manutenção há um escopo bastante grande, muito em acompanhamento e controle” além do desenvolvimento.

(29)

A IEEE/EIA 12207 identifica as atividades primárias da manutenção de software como: processo de implementação; análise do problema e da modificação; execução da modificação; revisão/aceite da modificação, e; desativação (SWEBOK, 2004, cap. 6, p.1). Atividades e processos são detalhados em seções específicas.

A manutenção pode ter seu esforço reduzido se o mantenedor puder ter contato com o desenvolvedor e, muitas vezes, a manutenção começa imediatamente após o desenvolvimento (SWEBOK, 2004, cap. 6, p.1).

2.2.3 Necessidade de manutenção

A manutenção em um software é necessária para adaptar o sistema a novas necessidades do usuário, corrigir erros, melhorar sua constituição, migrar sistemas legados, interagir com outros sistemas, hardwares, telecomunicações e redes, desativar o software, entre outros (PIGOSKY, 1996, p.14) (SWEBOK, 2004, cap.6, p.2-3).

2.2.3.1Sistemas legados

Sommerville (2007, p.25-26) e Pressman (2006, p.8-9) sugerem, definem e distinguem os sistemas legados com uma série de atributos como:

• Foram desenvolvidos há décadas - com tecnologias obsoletas e têm sido modificados continuamente para se adaptarem a novas funcionalidades e regras de negócios; podem ser de má qualidade e algumas vezes apresentam código complicado, documentação insuficiente e houve má gestão de suas modificações; • São sistemas críticos de negócios – sendo muito arriscado substituí-los, pois,

podem mudar procedimentos operacionais afetando a auditoria e a área comercial da empresa;

• Não deveriam ser “modificados” – deveriam ser “reengenheirados”, pois, a mudança é inevitável pelas seguintes razões:

o _{Necessidades de adaptação a novos ambientes;} o _{Novos requisitos de negócio são solicitados;}

(30)

• Hardware não disponível – pode ter sido descontinuado ou deixado de fazer parte da política de aquisições da empresa;

• Software de apoio e de aplicação não disponíveis ou desatualizados – os sistemas que atuam em conjunto com o sistema legado podem ser outros sistemas legados ou sistemas cujo fornecedor não oferece mais suporte;

• Dados inconsistentes ou duplicados – devido ao acúmulo ao longo da vida do sistema;

• Regras de negócios embutidas no sistema – fazendo com que as regras e políticas sejam seguidas ou operacionalizadas pela organização.

Seacord (2003, apud RAMOS, 2004, p.9) “um sistema legado não é definido pela sua idade, linguagem, plataforma ou tipo de estrutura de dados. Se um sistema está funcionando em

um ambiente de produção de uma organização, ele pode ser considerado um sistema legado”.

Neste trabalho é usada esta definição.

2.2.4 Maioria dos custos em manutenção

Para alguns pesquisadores a atividade de MS absorve atualmente mais pessoas e recursos do que o desenvolvimento de novos sistemas (PRESSMAN, 2006. p.8).

Segundo Sommerville (2007, p.26), manter sistemas evita riscos de substituição, no entanto alterar um software existente torna-se mais dispendioso à medida que o sistema se torna mais velho.

Segundo o SWEBOK (2004, cap.6, p.2) há uma percepção generalizada de que MS seria apenas correção de erros, porém, estudos têm demonstrado que 80% do trabalho se concentra em outros tipos de manutenção e, com isso, a manutenção é a que consome a maior parte dos recursos financeiros de todo o ciclo de vida do software.

Segundo Pigoski (1996), embora não haja consenso sobre os custos atuais da manutenção de software, há dados suficientes para indicar que essa atividade consome grande parte dos custos totais que envolvem o desenvolvimento de software. Ainda, os maiores gastos com manutenção são atribuídos às grandes empresas que mantém uma grande quantidade de softwares (JONES, 1994 apud PIGOSKI, 1996).

(31)

Quadro 2: Evolução dos custos da manutenção de software

Referência Data/época % para manutenção

Pressman 1970 -> 35% - 40%

Leinz e Swanson 1976 60%

Pigoski 1980 – 1984 55%

Pressman 1980 -> 60%

Schach 1987 67%

Pigoski 1985 – 1989 75%

Frazer 1990 80%

Pigoski 1990 -> 90%

Fonte: Piattini et al. apud MISRA et al., 2006

Para Sommerville (2007, p.334) em se tratando de sistemas legados é importante saber seu valor de mercado. Para proceder essa avaliação algumas questões básicas devem ser formuladas à stakeholders, usuários finais e gerentes, como:

• Se o sistema ainda é usado, por quantas pessoas e para que; • Que processos de negócios são apoiados;

• O sistema é confiável e não causa problemas aos clientes;

• Se das saídas do sistema depende o bom funcionamento da empresa, e se, • As saídas do sistema são utilizadas.

Com respostas a essa e outras questões pode-se classificar os sistemas em: baixa qualidade / baixo valor de mercado; baixa qualidade / alto valor de mercado; alta qualidade / baixo valor de mercado; alta qualidade / alto valor de mercado (SOMMERVILLE, 2007, p.334).

É mais caro adicionar novas funcionalidades depois que o sistema está em funcionamento do que se isso tivesse sido previsto durante o desenvolvimento, a razão para estes custos maiores são:

• Estabilidade da equipe – a equipe que dera manutenção não é a mesma que fez o sistema, assim, mais esforço é gasto com o entendimento do sistema;

• Responsabilidade contratual – a equipe contratada para o desenvolvimento preferirá simplificações mesmo que isso torna a manutenção mais difícil;

(32)

• Idade e estrutura dos sistemas - a estrutura do sistema pode se tornar difícil de ser compreendida e se degradar com as modificações, e estas, cada vez mais difíceis de serem executadas (SOMMERVILLE, 2007, p.327).

2.2.5 Evolução de software

A evolução do software é necessária, porém, há discussões se ela é pontual ou um desenvolvimento contínuo do software (SWEBOK, 2004, cap. 6, p.2).

Sommerville (2007, p.323) entende que o desenvolvimento de um software não finaliza depois que o mesmo é entregue. Segundo o autor, devido a grande dependência de sistemas pelas organizações, os sistemas têm de evoluir, ou seja, devem ser adaptados ou mudados para preservarem sua utilidade e valor.

Pressman (2006) e Sommerville (2007) relatam que Lehman, Belady e sua equipe conduziram a maioria dos estudos sobre mudanças em sistemas. Dos estudos surgiu a proposta de “leis”, batizada de “Leis de Lehman” que estabelecem:

• Lei da mudança contínua (1974) – sistemas devem ser continuamente modificados ou torna-se cada vez menos útil;

• Lei da complexidade crescente (1974) – medida que um sistema muda, sua complexidade aumenta, a menos que esforços sejam realizados para mantê-la ou reduzi-la;

• Lei da regulação (1974) – o processo de evolução do sistema é auto-regulável. O tamanho do sistema, tempo entre versões e número de erros é pouco variável entre versões;

• Lei da estabilidade organizacional (1980) – A taxa de desenvolvimento é quase constante ao logo do ciclo de vida do sistema e independente da quantidade de recursos alocados;

• Lei da conservação da familiaridade (1980) – mudanças incrementais em cada versão são quase constantes e os envolvidos devem manter o domínio do sistema, porém, a medida que este cresce o domínio pode diminuir e o crescimento se mantém estável;

(33)

• Lei da qualidade declinante (1996) – a menos que o sistema seja modificado e adaptado ao ambiente, sua qualidade entrará em declínio;

• Lei do sistema de feedback (1996) – deve haver feedback em multiníveis, multicíclos e multiagentes para conseguir qualidade e aperfeiçoamento significativo do sistema.

Segundo Sommerville (2007, p.325), as Leis de Lehman geralmente são aceitas, porém, por necessidades do negócio, algumas vezes não são levadas em consideração no planejamento da manutenção. Já para Pressman (2006, p.10), os modelos de processos, métodos e técnicas de engenharia visam manter a qualidade à medida que o software evolui.

2.2.6 Categorias de manutenção

Atualmente a norma ISO/International Electrotechnical Commission (IEC) 14764 (2006, p.3-4) classifica, ou subdivide, a MS em quatro categorias:

• Manutenção Corretiva – é reativa e refere-se à atividade de correção de erros; • Manutenção Adaptativa – relativa às alterações para adequar o sistema às

mudanças no ambiente em que está operando;

• Manutenção Perfectiva – contempla as alterações para atender necessidades de melhoria requeridas pelo usuário, ganhos de desempenho e manutenibilidade ou modificação de outros atributos;

• Manutenção Preventiva – para corrigir erros antes que eles se manifestem.

As categorias Corretiva e Adaptativa são classificadas como Reativas e as categorias Perfectiva e Preventiva são classificadas como Pró-ativas. Há, também, a definição de manutenção emergencial que é feita para manter um sistema em funcionamento até que se faça uma manutenção corretiva (ISO/IEC 14764, 2006, p.3-4).

Segundo Pressman (2006, p.583) na comunidade de engenharia de software erros, defeitos, falhas e bugs, são sinônimos, porém, ele prefere distinguir erros de defeitos. Erros são problemas de qualidade encontrados antes que o software seja entregue e defeito são problemas encontrados depois da entrega.

(34)

evolutiva” para denominar as manutenções Adaptativa, Perfectiva e Preventiva quando solucionam problemas, ou “defeitos”, não emergenciais.

2.3 Questões-chave da Manutenção de Software

São chamadas questões-chave por lidarem e assegurarem uma manutenção de software efetiva. A manutenção de software tem técnicas e desafios gerenciais únicos, ou exclusivos, como exemplo, a tarefa de encontrar um erro, que pode estar em uma linha de código de um software com mais de 500.000. Assim, as questões-chave foram agrupadas em quatro seções: questões técnicas, questões gerenciais, estimativas de custos de manutenção e métricas para manutenção de software (SWEBOK, 2004, cap. 6, p.3-4).

2.3.1 Questões técnicas

Para o SWEBOK (2004, cap.6, p.5) são quatro as principais questões técnicas relacionadas à MS: compreensão do sistema, teste, análise de impacto e manutenibilidade.

Entende-se por compreensão do sistema o tempo necessário para o profissional de MS saber em que parte do sistema deverá efetuar a mudança. Algumas pesquisas indicam que entre 40% e 60% do esforço é gasto nessa tarefa (SWEBOK 2004, cap.6, p.5).

Para efetuar testes em partes que foram modificadas o mantenedor, muitas vezes, deve testar o sistema inteiro, ou boa parte dele. Assim, tempo, coordenação da equipe se várias modificações estão sendo conduzidas ao mesmo tempo e dispor do sistema para os testes podem consumir muitos recursos (SWEBOK 2004, cap.6, p.5).

A análise de impacto estabelece como conduzir os custos de maneira efetiva na modificação de um software. Alguns objetivos da análise de impacto são: determinar a dimensão da mudança para o planejamento e execução do trabalho, estimar com precisão os recursos necessários para o trabalho, analisar o custo/benefício da mudança e comunicar a outros o quanto é complexa a mudança (SWEBOK 2004, cap.6, p.5).

(35)

Porém, o amadurecimento de técnicas e processos e o uso de ferramentas ajudam a melhorar a manutenibilidade de um sistema (SWEBOK 2004, cap.6, p.5-6).

Para manter um sistema operacional, os mantenedores deparam-se com várias dificuldades:

• Muitas vezes é excepcionalmente difícil entender o programa “de outra pessoa”; • Os programas são mal documentados;

• Os algoritmos são mal escritos; • A documentação não existe ou é ruim;

• A documentação não é consistente com o código fonte;

• Freqüentemente o software não é projetado e nem está preparado para sofrer mudanças (RAMOS, 2004).

Padueli (2007, p. 68-70.) em seu estudo de caso em uma empresa produtora de software com o objetivo de verificar os problemas de manutenção existentes oferece o Quadro 3. Neste Quadro há uma lista geral, não só dos problemas desta empresa, mas de um apanhado na literatura que ele acredita ser uma lista representativa das dificuldades mais importantes em manutenção de software. Além disso, os problemas foram classificados em fatores onde ocorrem. Os fatores gerenciais são citados na próxima seção.

Quadro 3: Problemas técnicos da MS

Problema Referência

Fatores de infra-estrutura

Necessidade de suporte automatizado à gerência de configuração de software

Dart et al. (2001) Ferramentas para manutenção precisam ser diferentes

daquelas de desenvolvimento

Dart et al. (2001)

Falta de recursos tecnológicos adequados Dart et al. (2001), Estudo de Caso Estagnação tecnológica no ambiente de trabalho Dart et al. (2001)

Fatores humanos – clientes

Necessidade constante dos usuários por melhorias e novas funcionalidades

Lientz e Swanson (1980); Estudo de Caso

Falta de compreensão dos usuários a respeito de suas reais necessidades de software

Estudo de Caso Mudanças freqüentes de prioridade (clientes) Dekleva (1992) Fatores de software

Baixa qualidade da documentação dos sistemas (software original)

Lientz e Swanson (1980); Dekleva (1992); Dart et al. (2001); Estudo de Caso

(36)

incompatíveis

Plataformas heterogêneas dificultam a definição de ferramentas adequadas

Dart et al. (2001)

Fonte: Padueli (2004)

2.3.2 Questões gerenciais

Para o SWEBOK (2004, cap.6, p.6) são cinco os problemas gerenciais mais comuns: alinhamento aos objetivos organizacionais, pessoal, processos, aspectos organizacionais da manutenção e terceirização.

Os sistemas costumam ser desenvolvidos como projetos, com prazo e custos definidos, para atender necessidades de usuários. Ao contrário, a MS procura estender a vida útil do sistema ao máximo possível atendendo a novas necessidades. Em ambos os casos, o retorno sobre o investimento não é muito claro e as atenções da gerência sênior recai sobre as atividades que mais consomem recursos sem benefícios claros (SWEBOK 2004, cap.6, p.6).

Basicamente, os problemas relacionados ao pessoal são relativos à como atrair e manter profissionais para a manutenção devido à atividade não ser considerada “prestigiosa” (SWEBOK 2004, cap.6, p.6). No Quadro 4 há uma lista elaborada por Padueli (2007, p. 68-70) com os problemas, ou fatores, gerenciais e de pessoal.

Quadro 4: Problemas gerenciais da MS

Fatores Gerenciais

Falta de comprometimento com cronogramas Lientz e Swanson (1980); Estudo de caso

Treinamento inadequado da equipe de manutenção Lientz e Swanson (1980);Dekleva (1992); Dart et al. (2001); Estudo de caso

Ausência de um profissional responsável exclusivamente ao controle de configuração de software

Dart et al. (2001)

Visão organizacional diferenciada para a equipe de desenvolvimento e para a equipe de manutenção

Dart et al. (2001) Dificuldades de comunicação entre a equipe de

manutenção e a própria organização

Dart et al. (2001) Software desenvolvido é visto pela gerência como não

construído para a manutenção

(37)

Mantenedores desconhecem planos da organização com relação à equipe de manutenção

Dart et al. (2001) Contratação de temporários para auxílio na

manutenção leva ao menor controle sobre a atividade

Dart et al. (2001) Experiências com manutenções anteriores não são

disseminadas dentro da própria organização e entre novos membros da equipe

Dart et al. (2001), Estudo de Caso

Dificuldades na medição do desempenho da equipe de manutenção

Dekleva (1992) Ausência de adoção de padrões, metodologias e

procedimentos de manutenção

Dekleva (1992); Estudo de Caso

Falta de suporte da gerência Dekleva (1992)

Sobrecarga de tarefas Estudo de Caso

Ausência de manutenção preventiva Estudo de Caso

Estimativa de prazo não condizente com a complexidade do software

Estudo de Caso Fatores humanos - equipe

Falta de uma equipe de manutenção Lientz e Swanson (1980)

Elevada rotatividade dos profissionais Lientz e Swanson (1980); Dekleva (1992); Estudo de Caso Mantenedores lamentam por não possuírem contato

com estado-da-arte da tecnologia

Dart et al. (2001) Preferência dos profissionais por trabalhos de

desenvolvimento

Dart et al. (2001) Manutenção de software é vista como uma tarefa não

prestigiosa

Dekleva (1992); Dart et al. (2001); Estudo de Caso

Falhas de comunicação com o usuário Estudo de Caso

Métodos inadequados de testes Dekleva (1992); Estudo de Caso

Documentação insuficiente ou superficial (software alterado)

Lientz e Swanson (1980); Dekleva (1992); Dart et al. (2001); Estudo de Caso

Fonte: Padueli (2004)

Os processos para manutenção de software são um conjunto de atividades, métodos, práticas e transformações para manter e desenvolver produtos de software. Há processos comuns com o desenvolvimento e outros exclusivos da manutenção (SWEBOK 2004, cap. 6, p.5). Os processos e atividades serão tratados em seção específica.

(38)

manutenção deveria ficar com um grupo ou com uma pessoa no lugar de uma estrutura organizacional.

A terceirização da manutenção de software tornou-se uma grande indústria com grandes empresas. Algumas questões têm preocupado pesquisadores e profissionais, como:

• Terceirizar apenas os sistemas não essenciais para os negócios; • Manter o controle estratégico;

• Determinar o escopo da manutenção e os detalhes contratuais;

• Lidar com o tempo necessário para a empresa entender os sistemas antes do contrato de manutenção, e;

• Fazer a transição (SWEBOK 2004, cap. 6 p.5).

Estas e outras questões referentes à terceirização e a manutenção de software terceirizado serão retomados em capítulo específico.

2.3.3 Estimativa de custos de manutenção

O SWEBOK(2005, cap. 6, p.6) reconhece que estimar custos é uma atividade muito importante para o planejamento da manutenção e que são usados fatores técnicos e não técnicos para a tarefa. Assim, são usados modelos parametrizados e a experiência dos profissionais de manutenção sendo mais comum o uso combinado destes fatores.

Estimativas de custo de software envolvem responder a questões como o esforço necessário para completar cada atividade, tempo necessário e custo total de cada atividade. Além dos custos com hardware e software, viagens, treinamentos e salários deve-se obter os custos indiretos como: espaço do escritório, pessoal de apoio, rede de comunicações, biblioteca e recreação, seguridade social, pensões, seguros e impostos (SOMMERVILLE, 2007, p.405).

(39)

scripting, a pontos de objeto são uma alternativa encontrada no COCOMO II (SOMMERVILLE, 2007, p.407).

2.3.4 Métricas para manutenção de software

Para o SWEBOK (2004, cap.6, p.6) existem métricas específicas para as atividades de manutenção, inclusive, para cada uma das quatro características, como: a “analisebilidade” (analyzability) que mede o esforço e recursos em tentar diagnosticar deficiências ou causas de falhas ou, identificar que partes do sistema devem ser modificadas; a “modificabilidade” (changeability) que mede o esforço em uma modificação específica; a “estabilidade” (stability) para medir a comportamento inesperado inclusive durante os testes, e; “testabilidade” (testability) para medir os esforços de mantenedores e usuários na tarefa de testar a modificação.

Pigosky (1996, p. 253) agrupou as métricas para manutenção de software em seis áreas: tamanho, produtividade, pessoal, categorias de manutenção, prazos e qualidade. Para o tamanho podem ser usadas linhas de código (LOC) e linhas de comentários. A produtividade pode ser medida com: relatos de problemas, solicitações de alterações, backlog, percentual de linhas de código que sofreram alterações no ano (ACT – Annual Cahnge Trafic), versões, assistência técnica e treinamento, pessoal alocado e pessoal pela quantidade de linhas de código. Para a classificação dos tipos de manutenção entende-se que a comunicação de erros gera naturalmente a manutenção corretiva enquanto que solicitações de melhorias geram manutenção perfectivas ou adaptativas, logo, estas duas consomem cerca de 80% do trabalho ou esforço. Os prazos são referentes ao tempo gasto para entrega das soluções aos problemas e solicitações de melhorias atendidos em uma nova versão do software. A qualidade pode ser medida a partir da solução dada aos problemas relatados.

(40)

avaliação de quais componentes serão afetados; número de solicitação pendentes de mudança (backlog), o aumento desse número pode indicar maior dificuldade de manutenção.

Para conhecer a situação atual, parece importante saber como são as técnicas de estimativa de custos empregadas pela empresa. Sommerville (2007, p.410) relata algumas como: utilização de série histórica de custos, julgamento por especialista até se chegar a um valor comum, por analogia a outra solução semelhante, expansão do trabalho até preencher o tempo disponível, custo estimado em função da capacidade financeira do patrocinador.

Para avaliação de ambiente deve-se procurar respostas a questões como: quem é o fornecedor e se é estável financeiramente, o hardware falha causando problemas aos sistemas, qual a idade do hardware e do software, o desempenho é satisfatório, é necessário apoio ao hardware e software, custos de manutenção de hardware e licenças de software, como são as interfaces com outros sistemas. Para avaliação da qualidade técnica dos sistemas deve-se formular questões e obter respostas aos seguintes fatores: facilidade de compreensão, documentação, modelo de dados, desempenho, linguagem de programação, gerenciamento da configuração, dados de testes, habilidade do pessoal. (SOMMERVILLE, 2007, p.336)

2.4 Processos de manutenção

Os Processos de Manutenção provêem referências e padrões usados para implementar o processo de manutenção de software. Assim, estão organizados em: processos de manutenção e atividades de manutenção.

2.4.1 Processos de manutenção

Para Pressman (2006, p.38-49), toda organização deveria adotar, ou adaptar, um modelo de processo de software entre os seguintes: Modelo em Cascata, Modelo Incremental, Modelo de Desenvolvimento Rápido de Aplicação (RAD), Modelo por Prototipagem, Modelo Espiral, Modelo de Desenvolvimento Concorrente, Desenvolvimento Baseado em Componentes, Modelo de Métodos Formais, Desenvolvimento de Software Orientado a Aspectos e o Processo Unificado (RUP).

(41)

reconhecidos como os modelos para desenvolvimento de software (GRUBB e TAKANG, 2003).

Fournier (1994, p.267-294) propôs uma série de atividades para a manutenção de software, conforme abaixo:

• Avaliar a solicitação de melhoria do sistema;

• Avaliar a solicitação de correção de problema do sistema em produção; • Aplicar conserto de emergência no programa;

• Organizar as solicitações de melhoramentos em releases individuais do sistema; • Analisar o release de solicitações de manutenção do sistema;

• Projetar o release de manutenção do sistema;

• Codificar e testar o release de manutenção do sistema; • Implementar o release de manutenção do sistema; • Executar manutenção preventiva;

• Treinar a equipe;

• Executar avaliações periódicas do sistema; • Executar revisões pós-implementação.

Pigosky (1996, p.51) utilizou a norma ISO/IEC 12207 como um processo de MS a ser implementado. São seis as atividades e tarefas correlatas para a MS:

• Atividade do Processo de Implementação - planejamento da manutenção, requisições de modificação e gerenciamento da configuração;

• Atividade de Análise do Problema e da Modificação – verificação, análise, soluções alternativas, documentação e aprovação;

• Atividade de Implementação da Modificação - itens a serem modificados, processo de desenvolvimento e teste;

• Atividade de Revisão da Manutenção e Aceite – revisão e aprovação;

• Atividade de Migração do Software – padrões, plano de migração, notificação da intenção, operações paralelas, notificação da migração e arquivamento;

• Atividade de Desativação do Software - plano de desativação, notificação da intenção, operações paralelas, notificação da desativação e arquivamento;

(42)

• Transição - seqüência de atividades controladas e coordenadas com as quais se transfere, progressivamente, do grupo de desenvolvimento para o grupo de mantenedores;

• Acordos de Níveis de Serviço e contratos de manutenção especializados - são negociados por mantenedores;

• Requisições de modificações e Relatos de Problemas ao Help-Desk - é um processo usado pelos mantenedores para priorizar, documentar e encaminhar as requisições recebidas;

• Aceite/rejeição de requisições de modificações - requisições de modificações têm certo tamanho/esforço/complexidade que pode ser rejeitada pelos mantenedores e encaminhada aos desenvolvedores.

Também há ferramentas de software e técnicas que foram adaptadas para as especificidades da manutenção, como: simulação de processos; métricas para manutenção de software; software específico para educação e treinamento de mantenedores; precificação dos serviços dos mantenedores; e produção de sistemas de alerta. (APRIL et al., 2005)

Devido a estas e outras diferenças entre MS e desenvolvimento April et al. (2005) concebem o SMmm composto de três processos e subprocessos: Processos Primários, Processos de Suporte e Processos Organizacionais.

Os Processos Primários devem garantir a manutenibilidade e a transferência do sistema para a manutenção bem como o gerenciamento eficiente do dia a dia da manutenção, seus subprocesso são:

● Pré-entrega e Transição;

● Gerenciamento de requisitos de serviços e eventos;

● Suporte operacional;

● Correções;

● Evoluções;

● Monitoração das mudanças;

● “Rejuvenescimento”, migração e “aposentadoria” do software (APRIL et al., 2005).

Os Processos de Suporte são aqueles comuns aos desenvolvedores, mantenedores e operadores servindo para dar sustentação às atividades de manutenção, seus subprocessos:

● Documentação;

(43)

● Garantia de qualidade de processos e produtos

● Verificação e validação

● Revisões e auditorias

● Gerenciamento da Análise de causas e problemas (APRIL et al., 2005).

Os Processos Organizacionais são aqueles supridos por outros departamentos da organização que influenciam na manutenção dos sistemas, seus subprocessos:

● Gerenciamento do planejamento da manutenção

● Gerenciamento das métricas e análises da manutenção

● Melhorias em inovação e entrega

● Melhorias de definição de processos

● Recursos Humanos e treinamento

● Compras, Acordos com fornecedores e SLA (APRIL et al., 2005).

Tanto IEEE 1219 como a ISO/IEC 14764 descrevem e detalham processos de manutenção de software. A primeira inicia com atividade durante a etapa de pós-entrega e inclui atividade de planejamento para manutenção. A segunda é elaborada a partir da primeira e está um pouco modificada na organização das etapas SWEBOK (2004, cap.6, p.6-7). A Figuras 2 coloca lado a lado os Processos da IEEE 1219 e da ISO/IEC 14764.

Figura 2: Processos da IEEE 1219 e ISO/IEC 14764. Fonte: SWEBOK (2004, cap.6, p. 7)