ESTIMATIVA PRECOCE EM MANUTENÇÃO
EVOLUTIVA DE SOFTWARE
Autor: Osíris Francisco Martinelli
Orientador: Prof. Dr. Fábio Bianchi
Mestrado
OSÍRIS FRANCISCO MARTINELLI
ESTIMATIVA PRECOCE EM MANUTENÇÃO EVOLUTIVA DE SOFTWARE
Dissertação apresentada ao Programa de Pós-Graduação Stricto Sensu em Gestão do Conhecimento e Tecnologia da Informação da Universidade Católica de Brasília, como requisito parcial para obtenção do Título de Mestre em Gestão do Conhecimento e Tecnologia da Informação.
Orientador: Prof. Dr. Fábio Bianchi
Ficha elaborada pela Biblioteca Pós-Graduação da UCB
M385e Martinelli, Osíris Francisco
Estimativa precoce em manutenção evolutiva de software / Osíris Francisco Martinelli. – 2009.
184 f. : il. ; 30 cm
Dissertação (mestrado) – Universidade Católica de Brasília, 2009. Orientação: Fábio Bianchi
1. Tecnologia da informação. 2. Software Manutenção. 3. KDD. 4. Manutenção preventiva. 5. Processo decisório. 6. Controle preditivo. 7. Processo decisório. I. Bianchi, Fábio, orient. II.Título.
Dissertação de autoria de Osíris Francisco Martinelli, intitulada ESTIMATIVA PRECOCE EM MANUTENÇÃO EVOLUTIVA DE SOFTWARE, apresentada como requisito parcial para obtenção do grau de Mestre em Gestão de Software e Tecnologia da Informação da Universidade Católica de Brasília, em 27 de novembro de 2009, defendida e aprovada pela banca examinadora abaixo assinada:
_______________________________________________ Prof. Dr. Fábio Bianchi
Orientador
Mestrado em Gestão do Conhecimento e da Tecnologia da Informação - UCB
_______________________________________________ Prof. Dr. Luiz Carlos Miyadaira Ribeiro Junior
Universidade de Brasília - UnB
_______________________________________________ Prof. Dr. Edílson Ferneda
Mestrado em Gestão do Conhecimento e da Tecnologia da Informação - UCB
À Zulmira, minha sempre presente e amada esposa, que assumiu o papel de pai e de mãe para permitir a realização deste trabalho.
As minhas filhas Jéssica e Alessandra, que entenderam e permitiram o meu afastamento para a realização do trabalho.
AGRADECIMENTO
Ao meu orientador, professor Fábio Bianchi, por seu excepcional comprometimento com a orientação, direcionamento e experiência que contribuíram significativamente para o resultado deste trabalho.
A professora Luiza Alonso pela atenção e carinho demonstrado para com o curso de pós-graduação da Universidade Católica de Brasília.
“Quem sabe concentrar-se numa coisa e insistir nela como único objetivo, obtém, ao cabo, a capacidade de fazer qualquer coisa.” (Gandhi)
“O mecanismo do descobrimento não é lógico e intelectual, é uma ilusão subcutânea, quase um êxtase.”
RESUMO
Referência: MARTINELLI, Osíris Francisco. Estimativa Precoce em Manutenção
Evolutiva de Software. 2009. 184 folhas. Dissertação para obtenção do grau de Mestre em
Gestão do Conhecimento e da Tecnologia da Informação junto à Universidade Católica de Brasília, Brasília (DF), 2009.
Grandes sistemas são submetidos a evoluções constantes para adequá-los a novas necessidades. Tomar decisão de qual mudança realizar em primeiro lugar depende da estimativa do seu custo e envolve, normalmente, o uso de especialista de TI. Envolver a área de TI no processo de estimativa o torna moroso e dispendioso, embora estimar esforço de manutenção sem ter os requisitos do software descritos enseje alto grau de incerteza. A elaboração de um modelo preditivo que possibilite gerar estimativa de manutenção em fase anterior ao envolvimento da área de TI, pode trazer maior poder de decisão às áreas de negócio ao mesmo tempo que reduzem os custos de manutenção da TI. Pela ausência de modelos que atuam na predição precoce de manutenção, bem como face à pequena quantidade de parâmetros preditivos conhecidos, esta pesquisa buscou identificar, por meio de estudo exploratório, parâmetros preditivos precoces que permitissem a proposição de um modelo de estimativa que não envolvesse a área de TI. Utilizou-se como metodologia um processo de descoberta de conhecimento (KDD), aplicado a uma base de projetos de manutenções pré-existentes para a identificação de parâmetros preditivos. O resultado demonstrou que as informações de projetos passados mostraram-se parcialmente efetivas para o fornecimento de elementos preditivos. Da mesma forma, o modelo preditivo gerado como resultado da mineração de dados também mostrou-se parcialmente aplicável, pois quando comparado com o especialista, o desempenho do modelo foi relativamente pior. O modelo demonstrou significativos resultados sobre alguns conjuntos de dados, enquanto não alcançou os níveis de acurácia do especialista em outros conjuntos. Identificou-se que o modelo apresenta baixa acurácia em manutenções com pequena quantidade de esforço e uma acurácia melhor em demandas com quantidade de esforço elevado. O modelo demonstrou ser promissor, indicando-se a realização de novas pesquisas que permitam sua rápida evolução para torná-lo de plena aplicação prática.
ABSTRACT
Large systems are subject to continuous evolutions in order to make them suitable to new needs. Making a decision about which change must be made first depends on its cost estimation and usually demands the work of an IT expert. Involving the IT department in the estimation process might make it slow and expensive, although estimating the maintenance effort before knowing the software requisites accurately might lead to a high degree of uncertainty. The elaboration of a foreseeable model that allows to generate the maintenance estimation before involving the IT department may bring to the business areas a higher decision power and at the same time it reduces the IT maintenance costs. Due to the absence of models that work with early foresee of maintenance, as well as due to the small amount of known foreseeable parameters, this research intended to identify, by means of exploiting study, early foreseeable parameters that would allow the proposition of an estimation model that would not involve the IT department. The methodology used was the process defined for data mining (KDD), that was applied to a pre-existing set of maintenance projects in order to identify the predictive parameters. The result demonstrated that the information about bygone projects proved to be partially effective for supplying foreseeable elements. In the same way, the predictive model, generated as the result of data mining, also proved to be partially applicable, since when compared to the specialist, the performance of the model was relatively worse. The model showed significant results on some sets of data, while not reaching specialist levels on other sets. It was evident that the model shows low accuracy on maintenances that demand low effort and a better accuracy on demands that take high effort. The model proved to be promising, suggesting the realization of new research that allows its fast evolution in order to bring entire practical application to it.
LISTA DE ILUSTRAÇÕES
Figura 1 – Atividades do processo de manutenção IEEE 1219-98. ...30
Figura 2 – Processo de manutenção ISO/IEC 14764-00. ...30
Figura 3 – O dilema da estimativa...45
Figura 4 – A qualidade do resultado depende da qualidade da entrada ...45
Figura 5 – Fatores a considerar no nível da estimativa ...49
Figura 6 – Mineração de Dados como uma confluência de muitas disciplinas...69
Figura 7 – O processo de descoberta de conhecimento em bancos de dados (KDD). ...69
Figura 8 – Quatro das tarefas centrais da mineração de dados...71
Figura 9 – Modelo de relacionamento...80
Figura 10 – Fluxo de solicitação e atendimento das demandas de TI. ...81
Figura 11 – Processo de descoberta de conhecimento em banco de dados...83
Figura 12 – Fase de pré-processamento. ...84
Figura 13 – Fase de extração de padrões...86
Figura 14 – Formação de modelo preditivo...88
Figura 15 – Modelo preditivo...91
Figura 16 – Processo de priorização das mudanças de TI...92
Figura 17 – Fase de pós-processamento...94
Figura 18 – Estrutura gráfica da árvore gerada pela técnica M5P...111
Figura 19 – Estrutura gráfica da árvore gerada pela técnica M5P...125
Figura 20 – Weka Explorer – Importação arquivo – aba Preprocess. ...175
Figura 21 – Weka Explorer – de atributos não-supervisionados...176
Figura 22 – Weka Explorer – Aplicação de técnica de classificação...177
Figura 23 – Weka Explorer – Aplicação de técnica de classificação – Opções de teste...177
Figura 24 – Weka Explorer – Armazenar o resultado. ...178
LISTA DE TABELAS
Tabela 1 - Categorias de manutenção de software ...26
Tabela 2 - Resultado alcançado pelos projetos em função do tamanho ...38
Tabela 3 – Taxa de produtividade para tipos de projetos comuns...52
Tabela 4 – Equivalência entre declarações de linguagem de alto nível e a linguagem C. ...53
Tabela 5 – Fatores do Cocomo II organizados em ordem de significância...54
Tabela 6 – Equações do Cocomo I. ...62
Tabela 7 – HISTÓRICO_DEMANDAS – Base histórica de demandas de TI ...100
Tabela 8 – HISTÓRICO_AÇÕES – Base histórica de ações de demandas de TI ...101
Tabela 9 – CARACTERÍSTICAS - Características dos sistemas...101
Tabela 10 – Estrutura de dados para mineração...104
Tabela 11 – Resultado da análise dos algoritmos de classificação...105
Tabela 12 – Resultado do treinamento e validação cruzada das técnicas de classificação. ...106
Tabela 13 – Variáveis utilizadas em cada técnica. ...106
Tabela 14 – Quantidade de variáveis utilizadas por técnica...108
Tabela 15 – Resultado da eliminação de variáveis não utilizadas...108
Tabela 16 – Variáveis selecionadas...108
Tabela 17 – Comparação das técnicas com variáveis significantes e não-significantes. ...109
Tabela 18 – Comparação entre o resultado de avaliação do desempenho das técnicas. ...110
Tabela 19 – Parâmetros preditivos selecionados...110
Tabela 20 – Classes formadas pela técnica M5P...112
Tabela 21 – Cálculo da estimativa do MEP nos registros da classe LM5...113
Tabela 22 – Cálculo da MRE das estimativas do MEP – classe LM6. ...114
Tabela 23 – MMRE resultante da estimativa do MEP. ...114
Tabela 24 –MMRE resultante da estimativa do especialista...115
Tabela 25 – Comparação entre a MMRE da estimativa do MEP e do especialista. ...115
Tabela 26 – PRED(0,25) resultante da estimativa do MEP. ...116
Tabela 27 – PRED(0,25) resultante da estimativa do especialista. ...117
Tabela 28 – Análise entre a MMRE e a PRED(0,25) da estimativa do MEP. ...117
Tabela 29 – Comparação entre a MMRE e a PRED(0,25) da estimativa do especialista...118
Tabela 30 –Acerto das estimativas do MEP com níveis de PRED diferenciados...119
Tabela 31 – Acerto das estimativas do especialista com níveis de PRED diferenciados...120
Tabela 33 – Comparação das técnicas utilizando conjunto diferente de variáveis. ...123
Tabela 34 – Seleção da técnica para compor o modelo preditivo ...124
Tabela 35 – Cálculo da MMRE e da PRED do especialista...128
Tabela 36 – Cálculo da MMRE e da PRED do MEP...130
Tabela 37 – Comparação entre o MEP e o especialista...131
Tabela 38 – Estimativas do especialista com níveis de PRED diferenciados. ...132
Tabela 39 –Estimativas do MEP com níveis de PRED diferenciados. ...132
Tabela 40 – Estrutura completa dos dados utilizados na mineração. ...147
Tabela 41 – Relação dos registros de dados utilizados na mineração...148
Tabela 42 –Técnicas e algoritmos de classificação disponíveis no Weka 6.3.1...156
Tabela 43 –Níveis “l” da PRED aplicados. ...161
Tabela 44 –Resultados dos níveis “l” da PRED(l) da estimativa do modelo...162
Tabela 45 –Resultados dos níveis “l” da PRED(l) da estimativa do especialista...163
LISTA DE GRÁFICOS
Gráfico 1 – Resultado alcançado pelos projetos de software ...37
Gráfico 2 – Posicionamento dos projetos quanto à estimativa prevista ...37
Gráfico 3 – Estimativa proposta em substituição a estimativa padrão...39
Gráfico 4 – Melhoria na estimativa de projetos na Força Aérea dos Estados Unidos ...41
Gráfico 5 – Melhoria na estimativa de projetos na Boeing Company...41
Gráfico 6 – Cone da Incerteza ...42
Gráfico 7 – Cone da Incerteza – Redução da variabilidade ...43
Gráfico 8 – Nuvem da Incerteza...44
Gráfico 9 – Representação do Cone da Incerteza em ambiente de requisitos instáveis...45
Gráfico 10 – Variação de estimativa com Cocomo II - 22 variáveis subjetivas ...46
Gráfico 11 – Variação de estimativa com uma única variável subjetiva...46
Gráfico 12 – Esforço x crescimento do tamanho do software...50
Gráfico 13 – Esforço a ser considerado no projeto com base no aspecto pessoal...53
Gráfico 14 – Comparação entre modelos KLOC ...62
Gráfico 15 – Curvas Rayleigh...63
Gráficos 16 – Variação do nível de acerto do MEP. ...120
Gráficos 17 – Variação do nível de acerto do especialista...121
LISTA DE QUADROS
Quadro 1 – Resultado da aplicação da técnica M5P. ...111
Quadro 2 – Fórmula linear para o grupo LM3. ...112
Quadro 3 – Fórmula linear para a classe LM3. ...125
Quadro 4 – Passos para importação de tabela para o Weka Explorer. ...175
Quadro 5 – Alteração de campo numérico para nominal no Weka Explorer...177
Quadro 6 – Passos para aplicação de técnica de classificação no Weka. ...177
Quadro 7 – Passos para remoção de campos desnecessários da base no Weka Explorer. ...178
LISTA DE SIGLAS
3GL – Linguagem de terceira geração 4GL – Linguagem de quarta geração ACT – Annual Change Traffic
AMEffMo – Modelo de esforço de manutenção adaptativa ARE – Average of Relative Errors
Arff – Formato padrão de arquivo reconhecido pelo aplicativo Weka. BTS – Sistemas que gerenciam defeitos
CBR – Case-Based Reasoning CMM – Capability Matutity Model
CMMI – Capability Maturity Model Integration CSCI – Computer Software Configuration Item CVS – Sistemas gerenciadores de código fonte
DCBD – Descoberta de Conhecimento em Base de Dados ENNA – Ensemble of Neural Networks with Associative Memory FP – Pontos por função (Function Point)
IEC - IEEE -
ISPA - Sociedade Internacional de Análise Paramétrica ISO -
KDD – Descoberta de Conhecimento em Banco de Dados (Knowledge Discovery in Databases)
KLOC – Linhas de código
KNNR – K-Nearest Neighbor Regression
KSLOC – Linhas de código fonte (Source Lines of Code) multiplicadas por 1000 LeastMedSq – Método de regressão linear
LOC - Linhas de código (Lines Of Code)
M5P – Modelo de aprendizado em árvore (model tree learner)
M5Rules – Modelo de regras derivado do modelo de aprendizado em árvore M5P MAE – Mean of Absolute Errors
MD – Mineração de dados
MEP – Modelo de Estimativa Precoce
MMRE – Média da Magnitude do Erro Relativo MR – Mean of Residues
MRE – Magnitude do Erro Relativo (Mean of magnitude of relative errors)
Nasa – Administração Nacional do Espaço e da Aeronáutica (National Aeronautics and Space Administration)
OP – Pontos por objeto (Object Points)
PPARS – Irish Personnel, Payrol and Related Systems
PRED(L) – Porcentagem do Desvio do Erro Relativo dentro de “L” (PREDiction at level L) R2 – Coefficient of determinant
RAD – Desenvolvimento rápido de aplicação RMSE – Root Mean of Squares of Error
RMSRE – Root Mean of Squared Relative Errors ROI - Return of Investiment
SCM - Software Configuration Management SEI - Software Engineering Institute
SEP – Controle estatístico de processo
SLIM – Gerenciamento do ciclo de vida do software (Software LIfecycle Management) SLOC – Linhas de código fonte (Source lines of code)
SQA - Software Quality Assurance
STSC – Software Technology Support Center TI – Tecnologia da Informação
UCB – Universidade Católica de Brasília UnB – Universidade de Brasília
SUMÁRIO
CAPÍTULO 1 - INTRODUÇÃO...15
1.1 Tema ...15
1.2 Delimitação do problema...16
1.3 Objetivo geral e específico ...17
1.4 Suposições ...17
1.5 Relevância do estudo...18
1.6 Organização...19
CAPÍTULO 2 - REVISÃO DA LITERATURA...21
2.1 Estudos sobre estimativa de esforço...21
2.2 Manutenção de software...25
2.3 Estimativa de prazo e esforço...36
2.4 Nível de confiabilidade da estimativa de esforço de software ...42
2.5 Elementos para estimar esforço de software ...48
2.5.1 Primeira camada ...49
2.5.2 Segunda camada ...54
2.6 Métodos de estimativa de esforço de software...56
2.7 Parâmetros preditivos das abordagens existentes...66
2.8 Mineração de dados...68
2.8.1 Domínio do conhecimento ...70
2.8.2 Fase do pré-processamento...70
2.8.3 Fase da mineração de dados ...70
2.8.3.1 Tarefa...71
2.8.3.2 Algoritmo ...73
2.8.4 Fase do pós-processamento ...75
2.9 Modelos de avaliação de acurácia de estimativa de custo de software ...75
CAPÍTULO 3 - METODOLOGIA ...79
3.1 Classificação da pesquisa ...79
3.2 Caracterização do ambiente de pesquisa ...79
3.2.1 Universo, população e amostra...81
3.3 Instrumentos e procedimentos...82
3.3.1 Fase do pré-processamento...83
3.3.2 Fase da extração de padrões ...86
3.3.3 Fase do pós-processamento ...92
3.3.4 Cálculo da estimativa de esforço do modelo...94
3.3.5 Cálculo da MMRE da estimativa gerada pelo modelo...95
3.3.6 Cálculo da MMRE gerada pelo especialista...96
3.3.7 Análise comparativa da MMRE do modelo e do especialista...96
3.3.8 Cálculo da PRED da estimativa gerada pelo modelo...97
3.3.9 Cálculo da PRED da estimativa gerada pelo especialista...98
3.3.10 Análise da MMRE e da PRED da estimativa gerada pelo modelo ...98
3.3.11 Análise da MMRE e da PRED da estimativa gerada pelo especialista...98
3.3.12 Análise da PRED sob diferentes níveis de acertos...99
4.1 Fase do pré-processamento...100
4.2 Fase de extração de padrões ...104
4.2.1 Análise das técnicas de classificação ...105
4.2.2 Seleção das variáveis...106
4.2.3 Seleção da técnica...110
4.2.4 Detalhamento do modelo preditivo ...110
4.3 Fase do pós-processamento ...112
4.3.1 Cálculo da estimativa de esforço do MEP...113
4.3.2 Cálculo da MMRE da estimativa gerada pelo MEP...113
4.3.3 Cálculo da MMRE da estimativa gerada pelo especialista...114
4.3.4 Análise do MMRE do MEP e do especialista ...115
4.3.5 Cálculo da PRED da estimativa gerada pelo MEP...116
4.3.6 Cálculo da PRED da estimativa gerada pelo especialista...116
4.3.7 Análise da MMRE e da PRED da estimativa gerada pelo MEP ...117
4.3.8 Análise da MMRE e da PRED da estimativa gerada pelo especialista...118
4.3.9 Análise da PRED sob diferentes níveis ...118
CAPÍTULO 5 - DISCUSSÃO...122
5.1 Análise dos parâmetros preditivos...122
5.2 Aplicabilidade do modelo...126
5.2.1 Indicadores de acurácia e níveis de validade...127
5.2.2 Análise da MMRE e PRED do especialista ...127
5.2.3 Análise da MMRE e PRED do MEP...129
5.2.4 Análise comparativa do desempenho do MEP em relação ao especialista ...131
5.2.5 Considerações finais...134
CAPÍTULO 6 - CONCLUSÃO...136
REFERÊNCIAS ...142
APÊNDICE 1 ...147
APÊNDICE 2 ...156
APÊNDICE 3 ...158
APÊNDICE 4 ...161
APÊNDICE 5 ...165
CAPÍTULO 1 - INTRODUÇÃO
1.1 TEMA
O ciclo de vida de um software passa por uma série de etapas que vai da sua concepção até a sua desativação. Destacam-se as seguintes etapas: concepção, em que o produto de software é concebido a partir de uma necessidade identificada por uma área de negócio ou de controle; construção da solução, em que se definem os requisitos, elabora-se a análise do sistema, estrutura-se o projeto, faz-se a codificação, elaboram-se os testes e promove-se a implantação da solução; manutenção, a mais longa do ciclo de vida do software, em que a aplicação sofre modificações provenientes de necessidades de correção de erros, de mudança do ambiente operacional e também da necessidade de evolução ou alteração das funcionalidades existentes; e a desativação, em que o software é retirado de produção em função de não ter mais utilidade ou pela substituição por outro.
As grandes organizações normalmente são estruturadas em áreas de negócio e de controle, possuindo estruturas específicas para o desenvolvimento e a manutenção de soluções de sistemas que suportam os seus modelos de negócios. As equipes de desenvolvimento são utilizadas para a criação de novas soluções e também para fazer a manutenção e evolução das soluções existentes.
A gestão da mudança das soluções existentes é compartilhada entre as áreas de negócio – gestão do negócio - e a área de TI1 – gestão da tecnologia. Quando a mudança é decorrente de um defeito ocasionado por um erro na implementação, de mudança no ambiente operacional ou de melhoria no desempenho, é de responsabilidade do gestor de tecnologia promover a correção, independentemente de solicitação por parte da área de negócio. Por outro lado, sempre que ocorrer mudança no mercado ou no próprio modelo de negócios que exigir ajustes na solução de software, seja alterando, ou introduzindo novas funcionalidades, a unidade gestora do negócio deve fazer as avaliações necessárias para a mudança e solicitá-las ao gestor de tecnologia.
Em grandes organizações, o ambiente de negócios é muito dinâmico e requer constante ajuste no seu modelo de negócios. Esse ajuste é decorrente da mudança de cenários, introdução de marco regulatório e também pelo aparecimento de novas oportunidades de negócios.
Grandes sistemas normalmente possuem uma grande quantidade simultânea de alterações e adequações que pode ser originária tanto de solicitações de mudanças oriundas das áreas de negócios, quanto da necessidade de ajustes em função de erros ou melhoria operacional. Essa situação requer adequada priorização das mudanças a serem realizadas, bem como planejamento do momento da liberação das alterações para o ambiente de produção, a fim de limitar o risco de impacto no processo produtivo.
Para que a gestão da priorização possa ser adequadamente realizada, a unidade gestora da solução de software necessita estimar o esforço/custo de cada mudança, a fim de dimensionar a relação custo/benefício das mudanças concorrentes, além de verificar a viabilidade em se implementar ou não a mudança.
A estimativa de esforço da manutenção evolutiva traduz os custos e o tempo necessário para a implantação da mudança, constituindo-se em elemento importante para o processo de tomada de decisão de fazer ou não fazer, bem como da ordem em que as mudanças devem ser realizadas.
Entretanto, estimar o esforço e o custo de uma mudança em aplicação preexistente requer profundo conhecimento da arquitetura do sistema, da forma como os módulos e componentes estão estruturados, bem como em quais módulos as mudanças interferirão e em que profundidade. Outro aspecto que amplia a complexidade e dificulta a estimativa é quando a mudança interfere em outros sistemas que interagem com o sistema em foco.
Entender e conhecer estes aspectos intrínsecos do sistema existente requer o envolvimento de analistas da área de TI para estabelecer o esforço da mudança. Esse envolvimento implica retardo no tempo da tomada de decisão sobre qual mudança fazer, além de encarecer o custo da manutenção como um todo.
1.2 DELIMITAÇÃO DO PROBLEMA
As organizações possuem capacidade limitada de recursos humanos para prover ajustes nos sistemas de TI. A fim de evitar que mudanças menos importantes sejam realizadas à frente de mudanças mais relevantes, as solicitações de mudanças são previamente priorizadas por meio de tomada de decisão.
realizar. O uso da área de TI para definir os custos da implementação implica custo adicional a ser acrescido aos projetos aprovados.
A fim de buscar uma tomada de decisão onde não seja necessário envolver a área de TI e com isso reduzir os custos da tomada de decisão em manutenções evolutivas, identifica-se o identifica-seguinte problema:
Que parâmetros poderiam atuar como preditores precoces2 do esforço de manutenções evolutivas de software?
De forma complementar a esta questão-problema fundamental, pode-se formular uma questão secundária:
Será possível elaborar modelo para gerar estimativa a partir dos parâmetros identificados?
Assim, tais questões têm por sujeito e extensão a manutenção evolutiva de software e por objeto e extensão os parâmetros que servem como preditores precoces de esforço.
1.3 OBJETIVO GERAL E ESPECÍFICO
O objetivo geral da pesquisa é identificar elementos preditores que possam fazer parte de uma abordagem de estimativa de esforço de manutenção evolutiva de software a fim de que possam ser adotados para estimar manutenções no momento da concepção do produto, sem envolver a área de TI.
Os objetivos específicos são:
a) identificar parâmetros que possam constituir um modelo para ser utilizado como preditor;
b) elaborar um modelo para gerar estimativa a partir dos parâmetros identificados.
1.4 SUPOSIÇÕES
Suposição Básica
A partir de dados preexistentes, é possível identificar informações e elementos que possam ser indicados como preditores para vir a compor um procedimento que possa estimar o esforço de manutenção evolutiva sem o envolvimento da área de TI.
Suposições Auxiliares
As técnicas de Descoberta de Conhecimento em Banco de Dados (KDD3) permitem a identificação de técnica que possa servir como parâmetro componente de um modelo de predição.
As interdependências entre os sistemas envolvidos na manutenção são variáveis independentes válidas.
1.5 RELEVÂNCIA DO ESTUDO
Pesquisas no desenvolvimento de equipamentos de hardware para a área de TI têm gerado redução de custos significativos e incrementais. Entretanto, na área de desenvolvimento de software, as pesquisas não têm evoluído na mesma velocidade, o que torna o custo do software significante (KEMERER, 1998, p. 63).
O custo de manutenção de software é reconhecido como o principal fator de custos da área de desenvolvimento de software, representando de 50 a 75% dos custos da área (BOEHM, 1984 apud SHUKLA; MISRA, 2008, p. 107). As organizações necessitam aumentar a produtividade dos recursos de TI a fim de reduzir os custos e a área de manutenção de software pode contribuir significativamente com a redução nos custos de desenvolvimento da organização.
Dentro do ciclo de vida do software, a manutenção representa entre 67 e 75% do esforço total (BHATT et al., 2004, p. 1) existindo situações que apontam que, a partir do quinto ano, o custo da manutenção excede o valor despendido com o desenvolvimento da solução (STSC, 2008, p. 36). Essa situação evidencia a importância e a relevância do assunto “manutenção no ciclo de vida”. Além do que, as manutenções evolutivas ocorrem em diferentes momentos da vida do software, o que requer sempre o envolvimento de especialistas de TI para estimar o esforço da mudança, a fim de permitir a adequada priorização das mudanças a serem realizadas.
Os atuais métodos de estimativa de esforço para estabelecer custos para manutenção evolutiva de software implicam identificação dos requisitos e objetivos do projeto de software, normalmente realizados pela área de TI (STSC, 1995, p. A-1), o que, por sua vez, implica avançar nas etapas do desenvolvimento de aplicativo para se ter uma noção dos custos do projeto, gerando significativos custos para as organizações.
3 KDD –
Knowledge Discovery in Databases (descoberta de conhecimento em banco de dados) – “é o
A estimativa preliminar do esforço para o desenvolvimento de software é importante para avaliar a viabilidade em termos de análise de custo e benefício (FENTON; PFLEEGER, 1997, p. 432). A avaliação de custo e benefício em fase anterior ao desenvolvimento de software permite maior poder de decisão às áreas de negócio, ao mesmo tempo em que reduz a necessidade de envolvimento da área de TI com a conseqüente redução de custos.
Este trabalho, ao examinar uma alternativa para identificar novo modelo para realizar estimativa precoce, contribui para a melhora prática e teórica do processo de TI ligado à manutenção evolutiva de software. Tal esforço encontra perfeita aderência à área de pesquisa de Engenharia e Sistemas de Conhecimento do Mestrado em Gestão do Conhecimento e Tecnologia da Informação (MGCTI), da Universidade Católica de Brasília.
1.6 ORGANIZAÇÃO
O presente trabalho está estruturado em seis capítulos. Este capítulo inicial que apresenta a relevância do tema, delimitação do problema, objetivo geral e específico, suposições e relevância do estudo.
O capítulo dois apresenta a revisão da literatura, onde está estruturada a fundamentação teórica e são abordados os assuntos: manutenção de software, estimativa de esforço, confiança da estimativa de esforço, elementos para estimar esforço, processo de estimativa, métodos de estimativa, escolha de procedimentos e parâmetros preditivos das abordagens existentes.
O capítulo três apresenta os aspectos de trabalho metodológicos no qual estão descritos os métodos e as técnicas utilizadas tanto na coleta quanto na análise dos dados utilizados.
O capítulo quatro apresenta os resultados alcançados.
O capítulo cinco apresenta a discussão no qual são interpretados os resultados alcançados.
No capítulo seis é descrita a conclusão, onde é apresentada uma auto-crítica sobre o resultado obtido na pesquisa, relacionando sugestões de aspectos do tema a serem pesquisados.
CAPÍTULO 2 - REVISÃO DA LITERATURA
A revisão da literatura está subdividida nos seguintes assuntos: estudos prévios sobre o tema estimativa de esforço em manutenção de software; manutenção de software; estimativa de esforço; confiabilidade da estimativa de esforço de software, elementos para estimar esforço de software, processo de estimativa, métodos de estimativa de esforço mais utilizados e escolha de um modelo de estimativa de esforço de software.
2.1 ESTUDOS SOBRE ESTIMATIVA DE ESFORÇO
Nesse estudo sobre estimativa, busca-se elaborar uma revisão do estado da arte do que foi escrito e publicado sobre o tema “estimativa de esforço de manutenção de software” bem como fazer considerações relativas às limitações das técnicas de estimativas existentes para tratar as dificuldades relacionadas com estimativa nas fases iniciais da manutenção evolutiva.
Um importante aspecto do gerenciamento de projetos de software é a estimativa de esforço e de custos. Experiências demonstram que estimativas corretas são difíceis de obter e um erro médio de 100% pode ser aceitável enquanto um erro de 32% pode ser excelente (VICINANZA; et al.apud ANTONIOL; et al., 1999, p. 250). Dependendo do momento em que se faz a estimativa, pode-se ter um maior ou menor grau de certeza e, portanto, de aceitação da dimensão do erro da estimativa.
As abordagens de estimativa de custos incluem: julgamento por especialista, estimativa por algoritmo, estimativa por analogia, estimativa top-down, estimativa bottom-up,
design to cost, modelos paramétricos, entre outros (GALORATH; EVANS, 2006, p. 39 e 40). Listam-se, a seguir, estudos acerca do tema “estimativa de esforço em manutenção de software”.
Basili et al. (1996, p. 465) apresentam uma abordagem incremental e indutiva para melhorar a manutenção de software por focar na construção de modelo preditivo baseado em LOC4 para estimar o esforço necessário para a construção de versões, a fim de estabelecer previsão do tamanho da versão decorrente da manutenção do software. Tal abordagem serve tanto para manutenção evolutiva como para correção de erros.
4
Source lines of code (SLOC) - linhas de código fonte ou lines of code (LOC) - linhas de código – é uma métrica
No contexto de manutenção evolutiva de software, Ramil (2000, p. 701) endereça o problema do custo de estimativa por meio da construção de modelos quantitativos que utilizam o relacionamento entre esforço, produtividade e um conjunto de métricas de evolução de software obtido por meio de bases de dados empíricas.
Juan Ramil e Meir Lehman (2000, p. 163) descreveram modelos que predizem esforço como função de um conjunto de métricas de evolução de software. Dentre as métricas utilizadas destacam-se indicadores baseados em módulos e subsistemas. O estudo confirmou a utilidade do uso de conjunto de métricas de evolução de software obtido de registros de mudança de software (RAMIL; LEHMAN, 2000, p. 171).
Para manutenção de sistemas distribuídos orientados a objeto, Sneed (2001, p. 180) apresenta um estudo que busca melhorar o processo de manutenção de software por meio da construção de um banco de dados relacional povoado de metadados com uma ampla variedade de artefatos de software de cada um dos níveis semânticos das fases do desenvolvimento do software. A partir das informações coletadas, é possível determinar a análise de impacto e a estimativa de custo das mudanças requeridas antes da sua implementação. Similarmente, Antoniol et al. (1999, p. 250) propõem um modelo de estimativa de esforço em processo de desenvolvimento iterativo com base na análise das classes impactadas pela solicitação de mudança.
Um modelo de estimativa prévia de esforço de manutenção massiva de software baseado no conhecimento de uma parte dos programas que compõem o pacote de trabalho foi proposto por Delucia et al. (2002, p. 234). Esse estudo utiliza análise de regressão e considera que, conhecendo pequena parte dos programas que será alterada, consegue-se chegar à estimativa de esforço de toda a mudança a ser realizada.
Por outro lado, Sneed (2004, p. 269) define parâmetros diferentes para estimar cada tipo de manutenção:
a) custo de correção de erro: número de erros sérios na última versão, esforço médio para correção dos erros da última versão, tamanho da última versão, tamanho da próxima versão, cobertura de testes da última versão e cobertura de testes da próxima versão;
c) custo da evolução: a partir dos requisitos, converte-os para uma métrica de tamanho como pontos por função ou pontos por objeto e ajustado pela qualidade existente, complexidade do sistema e dividido pela produtividade;
d) custo da melhoria técnica: por ser derivada do código preexistente, a estimativa deve considerar os componentes a serem alterados e ajustados pela sua complexidade e qualidade.
O esforço total é obtido a partir da equação do COCOMO-II que recebe a produtividade de projetos de reengenharia anteriores (SNEED, 2004, p. 269-271).
Modelos de regressão foram utilizados para construir o modelo de esforço de manutenção adaptativa (AMEffMo), que utiliza como métricas a quantidade de número de linhas de código alteradas e o número de operadores alterados (HAYES; et al., 2004, p. 254).
Bhatt et al. (2004, p. 1) apresentam a implementação de um modelo de sistemas dinâmicos para predizer os esforços envolvidos na manutenção de software, que utiliza uma abordagem holística com fatores quantitativos e qualitativos como insumos. O modelo proposto considera que o esforço de manutenção é primariamente influenciado por duas categorias de parâmetros: capacidade e atitude (BHATT et al., 2004, p. 3).
Baldassarre et al. (2005, p. 273) propõem o uso da Calibração Dinâmica como uma abordagem flexível para estimar esforço de manutenção massiva de software. Como mecanismo para reduzir a necessidade do elemento humano na estimativa e tornar o modelo mais determinístico, passaram a fazer uso do Controle Estatístico de Processo (SEP), utilizado como ferramenta de suporte à decisão, que identifica quando o modelo deve ser recalibrado (BALDASSARRE et al., 2005, p. 273).
Amor et al. (2006, p. 5) apresentam uma proposta para evolução dos modelos de estimativa de custos, considerando o desenvolvimento de software livre. Dentro do modelo, propõem que a estimativa de esforço considere as informações obtidas junto a sistemas gerenciadores de código fonte (CVS), de arquivos de lista de e-mails (ML) e também de sistemas que gerenciam defeitos (BTS).
Em ambientes onde há limitada quantidade de dados para estimar esforço, o uso do método de máquina de aprendizagem combinado com redes neurais e memória associativa demonstrou ser mais eficaz que o uso isolado de redes neurais. Foi desenvolvido o ENNA –
resultados com baixa variância. Os mesmos autores reforçam que modelos orientados a aprendizagem são tão bons ou melhores que modelos paramétricos (KULTUR et al., 2008, p. 330).
O uso de rede neural na estimativa de manutenção de software tem sido proposto como um mecanismo eficiente para a obtenção do esforço necessário para estimar o tamanho da mudança. Shukla e Misra (2008, p. 107) desenvolveram um modelo que utilizou como base o algoritmo back-propagation empregando treinamento de regularização Bayesiana.
Uma proposta de estimativa por meio da técnica de rede Bayesiana foi proposta para estimar a manutenção de software para a indústria militar da aviação utilizando seis parâmetros: experiência do mantenedor, tipo do teste final, tamanho base do software a ser mantido, existência de interface entre itens de configuração de software, número de componentes de software e número de unidades de software. Esses seis parâmetros estão distribuídos em quatro aspectos – características estruturais, experiência do mantenedor, tipo de teste final e tamanho do software. O modelo pode ser utilizado para prever o esforço do software na fase de planejamento do projeto de manutenção de software uma vez que as características estruturais fazem parte de uma estrutura bem definida e padronizada para a área de aviação militar (SONG et al., p. 407-410, 2007). A partir das variáveis utilizadas, esse modelo também pode ser também utilizado para realizar estimativa precoce, visto que todo o conhecimento necessário é preexistente.
Teixeira (2009, p. 19) apresenta um modelo de estimativa de esforço de manutenção de software, resultante do uso de técnicas da “Descoberta de Conhecimento em Base de Dados” (DCBD), área da qual a mineração de dados faz parte. O modelo foi construído utilizando variáveis referentes ao sistema, cliente, complexidade, criticidade, tipo de serviço e tipo de atendimento. Para melhorar o resultado foi utilizada também a quantidade de horas de esforço prevista pelo especialista de TI. Segundo a pesquisa, a estimativa resultante do modelo foi melhor que a obtida unicamente pela percepção do especialista.
Não foi encontrada pesquisa sobre mecanismos de estimativa para avaliar o esforço necessário no desenvolvimento de novas funcionalidades em fases anteriores a do desenvolvimento do software nas organizações em geral. Diante disso, percebe-se a existência de uma lacuna na literatura decorrente da inexistência uma proposta de procedimento que permita fazer estimativa prévia do esforço de manutenção de software sem o envolvimento da área de TI ainda no momento da concepção da mudança.
2.2 MANUTENÇÃO DE SOFTWARE
A Engenharia de Software é responsável por estabelecer os métodos, ferramentas e procedimentos que oferece ao profissional uma base para a construção de soluções de software de alta qualidade e produtividade ao mesmo tempo em que estabelece os mecanismos de controle e acompanhamento para os gerentes, a fim de que os objetivos sejam alcançados (PRESSMAN, 1995, p. 31).
O modelo de construção de software se dá por meio de um dos inúmeros paradigmas de engenharia de software propostos pela academia e adotados pelas organizações (PRESSMAN, 1995, p. 32 a 45). O STSC5 (2008, p. 136) relaciona como principais abordagens do ciclo de vida do software: modelo em cascata; desenvolvimento em espiral; desenvolvimento evolucionário; desenvolvimento incremental; desenvolvimento ágil; desenvolvimento rápido de aplicação (RAD).
O ciclo de vida do produto “software” é composto por uma série de fases que vai da sua definição, desenvolvimento, manutenção e desativação (PRESSMAN, 1995, p. 46-47). Para cada uma dessas fases a engenharia de software propõe, por meio dos paradigmas, os métodos, ferramentas e procedimentos a serem utilizados pelos engenheiros.
A manutenção tem sido definida com qualquer atividade realizada no software após a sua liberação na produção e essa definição tem sido amplamente aceita no âmbito acadêmico e contábil (SNEED, 2004, p. 265-266). O IEEE Standard for Software Maintenance define “manutenção de software” como: “the modification of a software product after delivery to
correct faults, to improve performance or other attributes, or to adapt the product to a
modified environment” (IEEE, 2004, cap. 6).
Considerando amplamente, manutenção de software inclui correção de erros, migração para novas tecnologias, mudanças – ajustes ou implementar evoluções, melhorias
5
operacionais e adaptação para novos requisitos do usuário (BHATT et al., 2004, p. 1; SHUKLA; MISRA, 2009, p. 313). Também para melhorar o projeto; interfaces com outros sistemas; migração de software legado e desativação do software (IEEE, 2004, cap. 6).
O custo de manutenção de software inclui duas categorias principais: melhorias no software, também denominadas de “categorias de manutenção de software”; e retenção do conhecimento do produto de software (STSC, 2008, p. 36).
Lienz e Swanson (apud IEEE, 2004, cap. 6) definiram três categorias iniciais de manutenção de software, posteriormente essa definição foi evoluída pelo Standard for
Software Engineering-Software Maintenance – ISO/IEC 14764 – que incluiu uma quarta
categoria. As categorias de manutenção de software são:
a) corretiva: modificação executada para a correção de defeitos percebidos;
b) adaptativa: adequação do software para mantê-lo operacional devido a uma alteração ou
mudança do ambiente. Alguns autores inserem nessa categoria as mudanças de requisitos funcionais (ABRAN; MAYA, 1995, p. 287; ABDEL-HAMID, 1993, p. 21);
c) perfectiva: modificação realizada para melhorar o desempenho ou a sua manutenibilidade. Pressman (1995, p. 47) inclui também o melhoramento funcional nesta categoria; e
d) preventiva: adequações no software para corrigir falhas latentes antes que elas efetivamente comecem a ocorrer (IEEE, 2004, cap. 6).
Essas categorias, embora ocorram sempre após a entrega do produto em produção, podem ser ainda classificadas em proativas e reativas, conforme a tabela 1.
Tabela 1 - Categorias de manutenção de software
Correção Melhoria
Proativa Preventiva Perfectiva Reativa Corretiva Adaptativa
(Fonte: IEEE, 2004, cap. 6)
contexto, a fase de manutenção não se confunde com a entrada em produção do software, diferentemente da definição adotada pelo IEEE e pela ISO/IEC.
Embora não haja consenso sobre a extensão do que se denomina “manutenção de software” nem em que momento ela efetivamente começa, para este trabalho considerar-se-á a extensão proposta por Sneed e Bhatt, que envolve qualquer mudança após a sua implantação em produção, inclusive as evoluções promovidas em função da necessidade do negócio – manutenção evolutiva6.
A retenção do conhecimento, como segunda categoria do custo da manutenção, é muito relevante para a fase de manutenção do software e normalmente é negligenciada pelas organizações. O STSC (2008, p. 36) aponta ser relevante alocar uma quantidade de recursos suficientes para retenção do conhecimento do produto de software a fim de mantê-lo em funcionamento. Aponta ainda que, para grandes produtos de software, esse número não é pequeno.
A manutenção de software abocanha uma fatia considerável dos recursos financeiros para o ciclo de vida do software. A percepção de que a manutenção somente corrige defeitos não é uma realidade. Estudos indicam que 80% dos custos gastos com manutenção são utilizados para a evolução do produto e que somente 20% são destinados para correção de problemas (SHUKLA; MISRA, 2009, p. 313).
Na manutenção de software há uma série de aspectos que devem ser considerados a fim de se obter efetividade no trabalho de manutenção. Dentre os principais, destacam-se os aspectos: técnicos; gerenciais; estimativa de custos; e medidas (IEEE, 2004, cap. 6).
No aspecto técnico, o entendimento do software a ser alterado é fator significante uma vez que é gasto em torno de 50% do esforço do mantenedor tentando entender os programas (HIROTA et al., 1994, p. 439) para conhecer onde a mudança deve ser feita. Uma análise de impacto deve sempre ser realizada a fim de determinar como conduzir a mudança, os custos efetivos e a amplitude dos impactos na solução como um todo. A definição do que deve e o que não deve ser testado assume um papel crítico no processo de manutenção, visto que o custo de testar o software como um todo é muito grande (IEEE, 2004, cap. 6).
No aspecto gerencial, atenção deve ser dada à demonstração do alinhamento das
6 Neste trabalho utilizar-se-á o termo
manutenção evolutiva (SNEED, 2004, p. 264) para designar unicamente as
mudanças de funcionalidades solicitadas pelo gestor do negócio suportado pela solução de software. Essa iniciativa busca diferenciar do termo manutenção adaptativa utilizado pela maioria dos autores que serve
atividades de manutenção do software com os objetivos organizacionais. A demonstração do retorno sobre o investimento, embora difícil em manutenção, também deve ser feita. Atrair, manter e motivar a equipe de manutenção é tarefa importante, visto que, pela avaliação do IEEE, esses profissionais se percebem como de segunda classe. O processo de manutenção de software possui atividades que diferem de algumas existentes no desenvolvimento de soluções novas, o que apresenta desafio para os gerentes. Manter uma estrutura apartada somente para a função de manutenção ou manter a função com a equipe original é uma escolha que deve ser feita caso a caso, em face dos prós e contras dos dois modelos. A terceirização da manutenção tem sido feita em soluções de software menos críticas, em face do receio de perda de controle das soluções que sustentam as organizações (IEEE, 2004, cap. 6).
A estimativa de custo de uma manutenção depende da quantidade do esforço necessária para fazer a mudança e a sua extensão depende do impacto que a mudança gera nos sistemas existentes bem como por fatores técnicos e não-técnicos. Dentre as abordagens de estimativa existentes, as mais populares, apontadas pela ISO/IEC 14764, são o uso de modelos paramétricos, da experiência e uma combinação dos dois modelos (IEEE, 2004, cap. 6). Por outro lado, há uma grande quantidade de modelos, embora não tão populares, que também tentam buscar alternativas para estimar a manutenção de software.
Para gerenciar efetivamente o processo de versionamento de software, os gerentes devem ser supridos com informações corretas a fim de melhorar o processo de tomada de decisão (BASILI et al., 1996, p. 464). Medidas de manutenção de software são adotadas normalmente por meio de programas de medidas de software e o mantenedor deve identificar quais são as mais apropriadas para a sua organização.
O SEI7 identificou como medidas comuns à maioria das organizações: tamanho, esforço, prazo e qualidade. (IEEE, 2004, cap. 6). Por outro lado, pesquisadores apontam estudos que indicam como igualmente relevantes fatores de ajustes como: complexidade, manutenibilidade, reuso, confiabilidade, turnover e experiência dos mantenedores (SHUKLA; MISRA, 2008, p. 107-108; FIORAVANTI; NESI, 2001, p. 1062-1063; ABDEL-HAMID, 1993, p. 20; HIROTA et al., 1994, p. 439; BHATT et al., 2004, p. 1). Situação que indica que a manutenção de software é representada por aspectos de várias origens.
Em um programa de medidas de manutenção de software, o IEEE (2004, cap. 6)
7
Software Engineering Institute da Universidade Carnegie (Pittsburgh, EUA), mantenedor do CMMI
sugere que seja incluído medidas para cada uma das quatro subcaracterísticas da manutenibilidade:
a) analisibilidade: medida do esforço consumido em diagnosticar a causa da falha ou na identificação das partes a serem modificadas;
b) mutabilidade: medida do esforço associado com a implementação de uma mudança específica;
c) estabilidade: medida que expressa o comportamento não esperado de um software, incluindo a fase de testes;
d) testabilidade: medida do esforço do mantenedor e usuário em testar o software modificado.
O uso de ferramentas comerciais facilita a obtenção de algumas medidas (LAGUË; APRIL, 1996 apud IEEE, 2004, cap. 6).
Complementando os aspectos que afetam a efetividade da manutenção, Bhatt et al. (2004, p. 2) apresentam também quatro categorias principais que contém fatores chaves que afetam as atividades de manutenção de software:
a) programador: normalmente o serviço de manutenção é visto como atividade menos criativa e pode levar a um processo de desmotivação e de alta rotatividade de profissionais o que leva a perda da experiência técnica, conhecimento do domínio, conhecimento da aplicação e domínio da linguagem de programação;
b) atitude gerencial: falta de apoio gerencial para as equipes que realizam manutenção, quadro de pessoal reduzido, salários mais baixos, falta de treinamento, prazos apertados, recompensar o mantenedor retirando-o da manutenção;
c) código-fonte: a qualidade do código tem impacto direto no esforço e na eficiência da manutenção – estrutura e arquitetura pobre, falta de documentação e falta de padrões – tornando muitas vezes o estudo de qualquer mudança muito difícil, se não impossível;
Figura 1 – Atividades do processo de manutenção IEEE 1219-98. (IEEE, 2004, cap. 6)
O processo de manutenção de software provê as atividades, as entradas e saídas que são necessárias para a realização da manutenção do software e está descrito nos padrões de manutenção de software IEEE 1219 e ISO/IEC 14764 (IEEE, 2004, cap. 6), vide figura 1.
Figura 2 – Processo de manutenção ISO/IEC 14764-00. (SNEED, 2004, p. 267)
Outro modelo foi proposto por Rajlich e Bennett (apud SNEED, 2004, p. 267), figura 2, no contexto da teoria da evolução do software, composto por um conjunto de cinco fases denominado “modelo estageado”:
fazer o sistema;
b) fase do desenvolvimento: fase em que o sistema está bem definido e pode ser utilizado método de estimativa convencional com certo grau de acerto;
c) fase de evolução: após a entrega da primeira versão na fase anterior, a fase de evolução compreende uma série contínua de versões entregue. A fase como um todo não pode ser estimada, mas cada versão pode. Nessa fase, uma parte do esforço é utilizada para corrigir a versão anterior e parte para construir a nova versão. Essa fase é concluída quando uma última versão é liberada;
d) fase de manutenção: é considerada quando não mais se investe no sistema, ele está congelado – seja por obsolescência ou em face do custo/benefício gerado – caso em que são executadas somente correções de erros e mudanças imprescindíveis;
e) fase de aposentadoria: fase em que o sistema deixa de existir, seja por perda de conhecimento da equipe, seja por necessidade de mudança do ambiente ou mesmo por sua completa obsolescência (SNEED, 2004, p. 267).
Esse “modelo estageado” busca isolar e identificar o que se define como manutenção do que é evolução do software, a fim de haver correta alocação dos custos com desenvolvimento de software por parte dos gerentes e contabilistas.
Embora existam diferentes visões e estudos sobre o que é considerada manutenção de software, como já mencionado neste trabalho, considera-se que pequenas evoluções da funcionalidade do produto em produção é parte do processo de manutenção de software.
Já as atividades dos processos IEEE e ISO/IEC são muito parecidas, embora seu agrupamento seja um pouco diferente, as atividades são muito similares àquelas do desenvolvimento de software: requisitos, análise, projeto, codificação, testes e documentação (IEEE, 2004, cap. 6). Entretanto, há atividades que são únicas do processo de manutenção e que possuem características inerentemente diferentes (DE LUCIA et al., 2002 apud BHATT et al., 2004, p. 1).
Dentre essas atividades destacam-se (IEEE, 2004, cap. 6):
a) transição: sequência de atividades que progressivamente transferem software do desenvolvedor para o mantenedor;
c) help desk de reporte de problema e pedido de modificação: função de suporte ao usuário final para disparar a análise e priorização dos pedidos de mudança;
d) análise de impacto;
e) suporte: ajuda aos usuários da solução;
f) acordo de nível de serviço: para garantir aspectos que são de responsabilidade do mantenedor.
Outras atividades que também são específicas da manutenção e que também podem ser executadas pelo mantenedor são (IEEE, 2004, cap. 6):
a) atividades de suporte: planejamento da atividade de suporte, gerenciamento da configuração de software, verificação e validação, assegurar a qualidade do software, revisão, auditoria e treinamento do usuário;
b) o planejamento da manutenção se dá em diferentes níveis da organização: nível organizacional – planejamento de negócio; nível de transição – planejamento de manutenção; nível de software – planejamento de versão; nível de pedido – planejamento de pedido de mudança individual. A atividade de planejamento de versão requer que o mantenedor: colete os dados de disponibilidade do pedido individual, concorde com os usuários sobre o conteúdo das versões subsequentes, identifique conflitos potenciais e desenvolva alternativa, avalie risco da versão e construa plano alternativo de retorno, e comunique os stakeholders8.
Além das atividades mencionadas, existem dois processos que não podem ser descuidados (IEEE, 2004, cap. 6):
a) gerenciamento da configuração de software (SCM9): procedimentos que provêem a verificação, validação e auditoria de cada etapa requerida para identificar, autorizar, implementar e liberar a versão do produto, além de ser possível controlar cada modificação feita;
b) qualidade do software: deve ser planejada e os processos e técnicas para assegurar a qualidade do software (SQA10) devem ser implementadas para assegurar que o processo
8
Stakeholder - parte interessada ou interveniente - é um termo usado em administração que se refere a qualquer
pessoa ou entidade que afeta ou é afetada pelas atividades de uma empresa. 9
Software Configuration Management – é a tarefa de localizar e controlar mudanças no software.
10
Software quality assurance – consiste de um meio de monitorar os processos de engenharia de software e
de manutenção seja suportado e tenha o nível desejado de qualidade.
Uma situação que gera conflito nas organizações é o que pode ser esperado da manutenção. Quando há forte restrição para a realização de mudanças requeridas pelos usuários, estes ficam frustrados e insatisfeitos. Por outro lado, organizações que são lenientes e fazem tudo o que o usuário solicita, tendem a perder o controle do orçamento (SNEED, 2004, p.265). Esse conflito decorre da forma como as organizações conceituam e tratam as suas manutenções, bem como as priorizam.
Abran e Nguyenkim (1993 apud ABRAN; MAYA, 1995, p. 292) propõem a subdivisão das manutenções quanto ao tamanho das mudanças a serem realizadas. Pequena manutenção é levada a efeito dentro do conceito de serviço, enquanto grandes manutenções são atendidas por uma estrutura de gerenciamento de projetos. As principais características que diferenciam os dois tipos de manutenções são (ABRAN; NGUYENKIM, 1993 apud ABRAN; MAYA, 1995, p. 292):
a) Grandes manutenções: os problemas a serem resolvidos são complexos e requerem uma grande equipe envolvendo técnicos e gestores de negócios; um plano de negócio identifica os benefícios e custos da mudança; orçamento específico deve ser aprovado; recursos devem ser alocados e deve ser preparado um planejamento, cronograma e deve ser acompanhado; os projetos são priorizados com antecedência para um ciclo de tempo orçamentário, normalmente um ano e a priorização se dá com base no ROI11. No curso de execução, outros projetos podem ser aprovados, entretanto devem possuir um significativo retorno e devem obter orçamento extra para sua execução; os projetos devem ser aprovados por executivo sênior, um líder deve ser nomeado, pontos de controle devem ser definidos e acompanhados por um comitê.
b) Pequenas manutenções: o tamanho e a complexidade do trabalho são pequenos e podem ser executados por uma ou duas pessoas; os pedidos de mudanças variam, dependendo da organização, de 30 a 80 dias de uma pessoa para serem concluídos – Sneed (2001, p. 185) aponta que não deveriam ultrapassar 20 dias ou uma pessoa/mês; solicitações de mudanças são relativamente aleatórias e não possuem uma contabilização orçamentária individual previamente definida; as solicitações de mudança são avaliadas e priorizadas em comitês com representantes das áreas gestoras e de gerentes da área de manutenção; o
11
Return of Investiment – Retorno sobre o investimento também chamado “taxa de retorno”, “taxa de lucro” ou
comitê de operação deve possuir um orçamento anual pré-definido e deve gerenciar a fila de solicitações, bem como acompanhar o andamento das execuções; a carga de trabalho de manutenção não é gerida como projeto, entretanto há reporte do progresso da fila de solicitações, mostrando os trabalhos que estão aguardando, os que estão sendo feitos e os concluídos; a manutenção é orientada a serviço do usuário (user-service-oriented) e orientada a responsabilidade da aplicação (application-responsibility-oriented). As prioridades podem ser mudadas a qualquer tempo e os problemas na produção possuem prioridade sobre qualquer trabalho que esteja sendo realizado; havendo a necessidade de mais orçamento, o comitê executivo é abordado para aprovar mais recursos para melhorar o nível de serviço e não para solicitações de mudanças específicas.
Como pode ser visto, a clara definição do que será coberto pelo custo da manutenção e o que não será, bem como a delimitação da forma de se fazer às solicitações e os níveis de alçada de autorização e priorização são fundamentais para uma adequada gestão da área de manutenção de soluções de software. O uso de acordos de níveis de serviços pode contribuir significativamente para essa gestão.
Como bem coloca Sneed (2004, p. 265), é relevante que as organizações façam a separação orçamentária entre evolução e manutenção a fim de se ter um adequado modelo de custo de manutenção.
Independentemente do tamanho da manutenção envolvida, sempre será necessário especificar a mudança a ser realizada em nível suficiente de detalhes a fim de evitar a necessidade de que os usuários, analistas, desenvolvedores e testadores precisem estar próximos e em constante contato para poderem executar as tarefas, uma vez que a necessidade de proximidade impede a terceirização do processo de manutenção. Visto que para a realização da manutenção é necessária uma compreensão completa do problema e do produto de software, é necessária muito mais a documentação formal (SNEED; HUANG, 2007, p. 171).
Considerando a necessidade de recursos necessários para a manutenção de software, o STSC (2008, p. 36) apresenta para a definição do esforço necessário para a melhoria do sistema o conceito de ACT12 que considera que 10% de todo o código-fonte existente será melhorado. O esforço de melhoria do componente é dado pela expressão:
total
S gPF ACT E1=
onde E1 é o esforço da melhoria (PM por ano)
ACT é a quantidade de mudanças (número decimal)
g é a qualidade relativa de manutenção da organização (0,5 a 1,7)
PF fator de produtividade de desenvolvimento de software (linhas por pessoa-mês) Stotal é o tamanho total do software (SLOC)
Por outro lado, não se pode descuidar da necessidade de manter pessoas com domínio sobre o produto de software desenvolvido. Para estabelecer o número de pessoas necessárias para a atividade de retenção do conhecimento operacional do produto de software, o STSC (2008, p. 37) apresenta um método para projetar, com base em uma antiga eurística – “’Each
programmer can maintain four boxes of cards’ (where a card box contained 2,000 computer
punch cards) is almost as old as software itself.” Uma versão atualizada dessa eurística que
pode ser aplicada hoje é:
total
S gD E2 = 9,2
onde E2 é o esforço da melhoria (PM por ano) D é a efetiva complexidade de produto de software
g é a qualidade relativa de manutenção da organização (0,5 a 1,5) 1,5 indica organizações excepcionais
Stotal é o tamanho total do software (KSLOC)
Para se obter o número de pessoas necessárias para a realização da manutenção do produto de software, pode-se utilizar a fórmula a seguir STSC (2008, p. 38):
) , max(E1 E2
Em = onde Em é o esforço declarado como suficiente para manutenção de produto de software E1 é o esforço da melhoria (PM por ano)
E2 é o esforço da melhoria (PM por ano)
As pessoas envolvidas na melhoria do software podem ser as mesmas que são responsáveis por reter o conhecimento da solução de software. Dessa forma, a quantidade de recursos existentes para reter o conhecimento pode ser suficiente para atender as demandas de melhoria do produto de software.
Como pode ser visto, o processo de manutenção de software é muito similar ao do desenvolvimento, entretanto há características diferentes e que devem se consideradas a fim de se ter uma estimativa adequada do esforço necessário para a sua priorização e elaboração.
12
Annual Change Traffic – A fração do código fonte do produto de software que muda durante um ano, seja pela
2.3 ESTIMATIVA DE PRAZO E ESFORÇO
Estimar significa declarar um valor aproximado de alguma quantidade e é baseado em pressuposição imperfeita e incompleta do que ocorrerá no futuro (GALORATH; EVANS, 2006, p. 34). Não se espera que a previsão seja exata, mas que ela seja próxima o suficiente do número correto para permitir uma tomada de decisão (FENTON; PFLEEGER, 1997, p. 428).
A estimativa de software é realizada em dois níveis: de sistema e de componente (CSCI13). A estimativa no nível de sistema é realizada na fase inicial do desenvolvimento quando todos os detalhes relacionados com a arquitetura e com o projeto ainda não estão disponíveis. Muitas vezes o sistema pode ser somente um conceito e os requisitos a serem alocados aos componentes não são bem conhecidos. A estimativa ao nível de componente é realizada quando o desenvolvimento já possui claro entendimento dos requisitos e estes são alocados aos componentes dos subsistemas. Nesse momento todas as informações para a definição de cronograma, alocação de recursos e para a construção do componente já estão definidos (STSC, 2008, p.20). A estimativa ao nível de componente é muito mais precisa que a estimativa realizada ao nível do sistema, visto que possui maior grau de informação, entretanto, só pode ser realizada em estágio avançado do processo de desenvolvimento.
O Standish Group publicou o The Chaos Report 2009, que descreve o resultado de projetos de software. Pode-se observar, no gráfico 1, que, ao longo dos últimos anos, há um crescimento dos projetos que foram realizados dentro do prazo previsto. Por outro lado, embora houvesse uma tendência de redução dos projetos que falham, nos últimos três anos, houve um aumento de 5%. Quanto aos projetos que atrasam, percebe-se ainda um grande caminho a ser trilhado no que tange a melhoria das métricas de estimativas, visto que a grande maioria dos projetos – 44% – atrasa e, certamente, um percentual não conhecido desse número se deve a falha na estimativa total do esforço e, por conseguinte, do prazo do projeto.
13
Computer Software Configuration Item – Um grupo de software tratado como uma simples entidade por um
Resultado alcançado pelos projetos de software
16%
27% 26% 28%
34%
29%
35%
32% 53%
33%
46% 49%
51% 53%
46%
44%
31%
40%
28%
23%
15% 18%
19%
24%
0% 10% 20% 30% 40% 50% 60%
1994 1996 1998 2000 2002 2004 2006 2009
Ano
P
e r
c e n
t
u
a l
Suces s o Atras ou Falhou
Font e: The Curious Case of t he CHA OS Report 2009 por Jorge Dominguez
Gráfico 1 – Resultado alcançado pelos projetos de software
McConnell (2006, p. 36) apresenta gráfico com o posicionamento de 80 projetos de software concluídos por uma indústria (gráfico 2). A análise do gráfico demonstra que somente um projeto foi entregue antes do prazo, poucos no prazo e os demais, quase totalidade, foram entregues atrasados. Ou seja, nessa indústria, 75% dos projetos de software ultrapassam o tempo de sua estimativa (MCCONNELL, 2006, p. 18).
Gráfico 2 – Posicionamento dos projetos quanto à estimativa prevista (MCCONNELL, 2006, p. 36)
custos ficaram superiores a 400% do valor original foi a construção de uma rodovia – Boston´s Big Dig – o projeto originalmente estimado em $2.6 bilhões de dólares custou perto de $15 bilhões. A área de software também conta com projetos que apresentam números dramáticos, como é o caso do sistema Irish Personnel, Payrol and Related Systems (PPARS) que foi cancelado após ter ultrapassado em mais de 1500% o custo inicialmente projetado de €8.8 milhões de euros (MCCONNELL, 2006, p. 43).
Shukla e Misra (2008, p. 107) apontam que problemas relacionados com turnover dos mantenedores, recrutamento, custo e tempo gasto na licitação da manutenção e otimização na alocação dos recursos tem tornado a estimativa de manutenções de longo prazo um grande desafio para as organizações de manutenção. Por outro lado, pode ser que a indústria de software esteja subestimando o problema a ser trabalhado no projeto de manutenção, o que levaria a estimativas irreais e, em decorrência, a atrasos nos projetos.
Já Fenton e Pfleeger (1997, p. 433) declaram que nem sempre os erros nas estimativas decorrem da natureza do problema. Capers Jones (1998 apud MCCONNELL, 2006, p. 35), contribuindo com a análise de atraso dos projetos, apresenta uma visão de que quanto maior o projeto, maior o risco de atraso e também de falha, conforme pode ser observado na tabela 2, a seguir.
Tabela 2 - Resultado alcançado pelos projetos em função do tamanho Tamanho em Pontos por Função
(e linhas de código aproximada)
Cedo No
Prazo
Atrasado Falhou
(Cancelado)
10 PF14 ( 1.000 LOC) 11% 81% 6% 2%
100 PF (10.000 LOC) 6% 75% 12% 7%
1.000 PF (100.000 LOC) 1% 61% 18% 20%
10.000 PF (1.000.000 LOC) <1% 28% 24% 48%
100.000 PF (10.000.000 LOC) 0% 14% 21% 65%
Fonte: Estimating Software Costs (Jones 1998).
(Fonte: MCCONNELL, 2006, p. 35)
McConnell (2006, p.43) aponta que o erro na estimativa provém de quatro origens genéricas:
a) informação incompleta sobre o projeto que se está estimando;
b) informação incompleta sobre as capacidades da organização que irá executar o projeto;
c) ausência de processo adequado para a condução do projeto e da própria estimativa –
14 Pontos por função (PF) -
Function Point (FP) – é uma unidade de medida para expressar o conjunto de
