IDE
NTIF
ICA
ÇÃO
DE
PROPRIEDADES DE SOFTWARE QUE BENEFICIAM A SUA
MANUTENIBILIDADE
PROGRAMA DE PÓS-GRADUAÇÃO STRICTO SENSU EM
GESTÃO DO CONHECIMENTO E DA TECNOLOGIA DA INFORMAÇÃO
Mestrado
IDENTIFICAÇÃO DE PROPRIEDADES DE
SOFTWARE QUE BENEFICIAM A SUA
MANUTENIBILIDADE
Autora: Pollyana Lima Barreto
Orientador: Prof. Dr. Fábio Bianchi Campos
IDENTIFICAÇÃO DE PROPRIEDADES DE SOFTWARE QUE
BENEFICIAM A SUA MANUTENIBILIDADE
Dissertação apresentada ao Programa de Pós-Graduação Strictu Sensu em Gestão do Conhecimento e 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.
Orientador: Prof. Dr. Fábio Bianchi Campos
Ficha elaborada pela Biblioteca Pós-Graduação da UCB
B273i Barreto, Pollyana Lima
Identificação de propriedades de software que beneficiam a sua manutenibilidade. / Pollyana Lima Barreto – 2011.
264f. : il.; 30 cm
Dissertação (mestrado) – Universidade Católica de Brasília, 2011. Orientação: Fábio Bianchi Campos
1. Software Manutenção. 2. Metodologia. 3.Tecnologia da informação. I. Campos, Fábio Bianchi, orient. II. Título.
A todos os meus familiares e amigos, pelo apoio, incentivo, colaboração e compreensão
nos momentos necessários dedicados a conclusão desta pesquisa, em especial ao meu marido,
pelo companheirismo e por entender as ausências necessárias.
Ao meu professor orientador Dr. Fábio Bianchi Campos, por sua orientação e
objetividade, um especial agradecimento por minha formação como Mestre em Gestão do
Conhecimento e da Tecnologia da Informação.
Aos meus colegas de trabalho que contribuíram, direta ou indiretamente, para que esta
“A vida é uma grande universidade, mas pouco ensina para quem não aprende a aprender."
Augusto Cury
"A diferença entre o sonho e a realidade é a quantidade certa de tempo e trabalho.”
Este trabalho propõe um processo para identificar as propriedades de software que beneficiam a sua manutenibilidade. O principal instrumento da metodologia adotada foi um questionário aplicado a mantenedores e gerentes de projeto, a fim de coletar a opinião deles a respeito da influência que determinadas propriedades de software trazem à manutenibilidade. Além disso, foi definido o uso de um algoritmo de regressão para avaliar quais dessas propriedades de software têm maior influência na manutenibilidade em relação a outras. Com os resultados obtidos, foi possível definir diretrizes para orientar gestores e equipe do processo padrão da organização alvo a focar seus esforços nos aspectos de melhor resultado, no que se refere à atividade de manutenção de software, bem como orientações gerais sobre a forma correta de se usar o processo proposto em outras organizações.
This paper proposes a process to identify properties that benefit your software maintainability. The main instrument of the methodology used was a questionnaire given to maintainers and project managers in order to collect their opinion about the influence that certain properties to bring software maintainability. Moreover, it was defined using a regression algorithm to evaluate which of these properties have more influence on software maintainability compared to others. With these results, it was possible to define guidelines to managers and staff of the standard process of the target organization to focus its efforts on those aspects of a better outcome, with regard to the activity of software maintenance, as well as general guidelines on the correct way to use the proposed process in other organizations.
Figura 1 – Modelo de qualidade do McCall – Fator manutenibilidade - Fonte: MILICIC, 2005, p.6 (tradução nossa) ... 38
Figura 2 – Modelo de qualidade do Boehm – Característica de alto nível manutenibilidade - Fonte: MILICIC, 2005, p.7 (tradução nossa) ... 40
Figura 3 – Fluxograma do procedimento de contagem ... 42
Figura 4 – Árvore de Qualidade de Software - Fonte: DEISSENBOECK et al., 2007, p.187 (tradução nossa) ... 50
Figura 5 – Matriz da Manutenibilidade - Fonte: DEISSENBOECK et al., 2007, p.187 (tradução nossa) ... 51
Figura 6 – Matriz da Manutenibilidade - Fonte: Ghosheh et al., 2008, p.4 (tradução nossa) ... 53
Figura 7 – Visão do processo de manutenção da ISO 14764 com os PMA intermediários e final e seu respectivo escopo - Fonte: ANQUETIL et al., 2007, p. 521 (tradução nossa) ... 55
Figura 8 – Metodologia adotada nesta pesquisa ... 63
Figura 9 – Quatro níveis da metodologia CRISP-DM - Fonte: CHAPMAN et al., 2000, p.9 ... 78
Figura 10 – Fases do modelo de referência CRISP-DM - Fonte: CHAPMAN et al., 2000, p.13 ... 79
Gráfico 1 – Distribuição do esforço por manutenção - Fonte: adaptado por PFLEEGER, 2001 ... 26
Gráfico 2 – Perfil dos Entrevistados ... 92
Gráfico 3 – Anos de experiência dos entrevistados com manutenção de software .. 93
Gráfico 4 – Capacitação dos Entrevistados ... 94
Gráfico 5 – Ocorrências dos Tipos de Manutenção ... 95
Gráfico 6 – Influência da documentação de requisitos na manutenibilidade de um software ... 98
Gráfico 7 – Influência da documentação de requisitos na analisabilidade de um software ... 100
Gráfico 8 – Influência da documentação de requisitos na modificabilidade de um software ... 101
Gráfico 9 – Influência da documentação de requisitos na testabilidade de um software ... 102
Gráfico 10 – Influência da documentação de requisitos na estabilidade de um software ... 103
Gráfico 11 – Influência da documentação de arquitetura na manutenibilidade de um software ... 104
Gráfico 12 – Influência da documentação de arquitetura na analisabilidade de um software ... 106
Gráfico 13 – Influência da documentação de arquitetura na modificabilidade de um software ... 106
Gráfico 14 – Influência da documentação de arquitetura na testabilidade de um software ... 107
Gráfico 17 – Influência do software definido em camadas na analisabilidade de um software ... 110
Gráfico 18 – Influência do software definido em camadas na modificabilidade de um software ... 111
Gráfico 19 – Influência do software definido em camadas na testabilidade de um software ... 112
Gráfico 20 – Influência do software definido em camadas na estabilidade de um software ... 113
Gráfico 21 – Influência da estrutura modular na manutenibilidade de um software 114
Gráfico 22 – Influência da estrutura modular na analisabilidade de um software ... 115
Gráfico 23 – Influência da estrutura modular na modificabilidade de um software . 116
Gráfico 24 – Influência da estrutura modular na testabilidade de um software ... 117
Gráfico 25 – Influência da estrutura modular na estabilidade de um software ... 117
Gráfico 26 – Influência da documentação de análise e projeto na manutenibilidade de um software ... 118
Gráfico 27 – Influência da documentação de análise e projeto na analisabilidade de um software ... 120
Gráfico 28– Influência da documentação de análise e projeto na modificabilidade de um software ... 121
Gráfico 29 – Influência da documentação de análise e projeto na testabilidade de um software ... 122
Gráfico 30 – Influência da documentação de análise e projeto na estabilidade de um software ... 123
Gráfico 31 – Influência da rastreabilidade entre requisitos na manutenibilidade de um software ... 124
Gráfico 34 – Influência da rastreabilidade entre requisitos na testabilidade de um software ... 127
Gráfico 35 – Influência da rastreabilidade entre requisitos na estabilidade de um software ... 128
Gráfico 36 – Influência da rastreabilidade dos requisitos ao código fonte na manutenibilidade de um software... 129
Gráfico 37 – Influência da rastreabilidade dos requisitos ao código fonte na analisabilidade de um software ... 130
Gráfico 38 – Influência da rastreabilidade dos requisitos ao código fonte na modificabilidade de um software ... 131
Gráfico 39 – Influência da rastreabilidade dos requisitos ao código fonte na testabilidade de um software... 132
Gráfico 40 – Influência da rastreabilidade dos requisitos ao código fonte na estabilidade de um software... 133
Gráfico 41 – Influência dos padrões de design na manutenibilidade de um software ... 134
Gráfico 42 – Influência dos padrões de design na analisabilidade de um software 135
Gráfico 43 – Influência dos padrões de design na modificabilidade de um software ... 136
Gráfico 44 – Influência dos padrões de design na testabilidade de um software ... 137
Gráfico 45 – Influência dos padrões de design na estabilidade de um software .... 138
Gráfico 46 – Influência da qualidade da modelagem dos dados na manutenibilidade de um software ... 139
Gráfico 47 – Influência da qualidade da modelagem dos dados na analisabilidade de um software ... 140
Gráfico 50 – Influência da qualidade da modelagem dos dados na estabilidade de um software ... 143
Gráfico 51 – Influência do uso de padronização para implementação de código fonte na manutenibilidade de um software... 144
Gráfico 52 – Influência do uso de padronização para implementação de código fonte na analisabilidade de um software ... 145
Gráfico 53 – Influência do uso de padronização para implementação de código fonte na modificabilidade de um software ... 146
Gráfico 54 – Influência do uso de padronização para implementação de código fonte na testabilidade de um software... 147
Gráfico 55 – Influência do uso de padronização para implementação de código fonte na estabilidade de um software... 148
Gráfico 56 – Influência do uso de comentários em código fonte na manutenibilidade de um software ... 149
Gráfico 57 – Influência do uso de comentários em código fonte na analisabilidade de um software ... 150
Gráfico 58 – Influência do uso de comentários em código fonte na modificabilidade de um software ... 151
Gráfico 59 – Influência do uso de comentários em código fonte na testabilidade de um software ... 152
Gráfico 60 – Influência do uso de comentários em código fonte na estabilidade de um software ... 153
Gráfico 61 – Influência do uso de testes de regressão automatizados na manutenibilidade de um software... 154
Gráfico 62 – Influência do uso de testes de regressão automatizados na analisabilidade de um software ... 155
Gráfico 65 – Influência do uso de testes de regressão automatizados na estabilidade de um software ... 158
Gráfico 66 – Influência do controle de configuração de software na manutenibilidade de um software ... 159
Gráfico 67 – Influência do controle de configuração de software na analisabilidade de um software ... 160
Gráfico 68 – Influência do controle de configuração de software na modificabilidade de um software ... 161
Gráfico 69 – Influência do controle de configuração de software na testabilidade de um software ... 162
Gráfico 70 – Influência do controle de configuração de software na estabilidade de um software ... 163
Gráfico 71 – Influência do processo padrão da organização na manutenibilidade de um software ... 164
Gráfico 72 – Influência do processo padrão da organização na analisabilidade de um software ... 165
Gráfico 73 – Influência do processo padrão da organização na modificabilidade de um software ... 166
Gráfico 74 – Influência do processo padrão da organização na testabilidade de um software ... 167
Tabela 1 – Quantidade de mantenedores de software da organização que participaram da pesquisa ... 67
Tabela 2 – Linguagens de programação e bancos de dados com maior experiência pelos entrevistados ... 96
Tabela 3 – Artefatos de requisitos que tiveram maior influência na manutenibilidade do software, segundo entrevistados ... 99
Tabela 4 – Artefatos de arquitetura que tiveram maior influência na manutenibilidade do software, segundo entrevistados ... 105
Tabela 5 – Artefatos de análise e projeto que tiveram maior influência na manutenibilidade do software, segundo entrevistados ... 119
Tabela 6 – Ordenamento das propriedades de software que trazem maior benefício na manutenibilidade ... 171
Tabela 7 – Ordenamento das propriedades de software que trazem maior benefício na analisabilidade ... 172
Tabela 8 – Ordenamento das propriedades de software que trazem maior benefício na modificabilidade ... 172
Tabela 9 – Ordenamento das propriedades de software que trazem maior benefício na testabilidade ... 173
Tabela 10 – Ordenamento das propriedades de software que trazem maior benefício na estabilidade ... 174
Tabela 11 – Propriedades de software x percentual de influência nas subcaracterísticas de manutenibilidade ... 175
Tabela 12 – Resultados da Aplicação da Matriz de Priorização ... 178
Tabela 13 – Resultado da aplicação de algoritmos com o tipo de teste use training
set... .. 182
Tabela 14 – Resultado da aplicação de algoritmos com o tipo de teste
Quadro 1 – Subcaracterísticas da Manutenibilidade - Fonte: ISO/IEC 9126-1, 2001 (tradução nossa) ... 34
Quadro 2 – Direcionadores de custo - Fonte: TRINDADE et al., 1999 (tradução nossa) ... 48
Quadro 3 – Pontuação ECMM - Fonte: Ghosheh et al., 2008, p.3 (tradução nossa) 53
Quadro 4 – As três manutenções PMA e os tipos de conhecimento que elas focam Fonte: ANQUETIL et al., 2007, p.522 (tradução nossa) ... 56
Quadro 5 – Os 10 fatores problemáticos de alta gravidade no desenvolvimento de software - Fonte: CHEN; HUANG, 2009, p.990 (tradução nossa) ... 59
Quadro 6 – Classificação das propriedades de software que podem beneficiar a sua manutenibilidade ... 86
Quadro 7 – Diferenças nas propriedades de software tratadas no questionário x ferramenta WEKA ... 90
Quadro 8 – Dados a serem tratados na ferramenta WEKA, conforme classificação definida no Quadro 6 ... 181
Quadro 9 – Uso dos atributos tratados na ferramenta WEKA pelos algoritmos apresentados nas Tabelas 13 e 14 ... 183
Quadro 10 – Algoritmo Functions/SMOreg, executado no tipo de teste
cross-validation ... 184
Quadro 11 – Ordenamento propriedades de software x atributos tratados na ferramenta WEKA ... 185
Quadro 12 – Comparação dos critérios de qualidade de McCall e Boehm com as propriedades de software estudadas nesta pesquisa ... 187
Quadro 13 – Comparação das características intermediárias de Boehm com as propriedades de software estudadas nesta pesquisa ... 188
1
Introdução ... 21
1.1 Tema ... 21
1.2 Delimitação do Problema ... 23
1.3 Objetivos ... 25
1.4 Suposições ... 25
1.5 Relevância do Estudo ... 26
1.6 Organização do Trabalho ... 28
2
Revisão da Literatura ... 29
2.1 Teoria Básica em Manutenção de Software ... 29
2.1.1 Classificação dos Tipos de Manutenção ... 31
2.2 Manutenibilidade de Software ... 33
2.3 A Manutenibilidade nos Modelos de Qualidade ... 36
2.3.1 Modelo de Qualidade de McCall ... 36
2.3.2 Modelo de Qualidade de Boehm ... 38
2.4 Técnicas e Modelos de Estimativas em Manutenção ... 40
2.4.1 COCOMO II ... 46
2.5 Estado da Arte em Manutenibilidade ... 48
2.6 Considerações Finais ... 61
3
Material e Métodos de Pesquisa ... 62
3.1 Visão Geral ... 62
3.2 Classificação da Pesquisa ... 63
3.3 Caracterização do Ambiente de Pesquisa ... 65
3.3.1 Universo, População e Amostra do Estudo de Caso ... 65
3.4 Metodologia Adotada ... 68
3.4.2.1 Compreensão do Negócio e Compreensão dos Dados ... 80
3.4.2.2 Preparação dos Dados ... 83
3.4.2.3 Modelagem ... 87
3.4.2.4 Avaliação ... 88
3.4.2.5 Aplicação ... 89
3.4.3 Uso do Questionário em conjunto com uma versão simplificada da metodologia CRISP-DM ... 89
4
Resultados e Análise ... 91
4.1 Resultados da aplicação do Questionário ... 91
4.1.1 Parte 1 - Identificação do Entrevistado ... 91
4.1.1.1 Perfil ... 91
4.1.1.2 Experiência em manutenção de software ... 92
4.1.1.3 Capacitação ... 93
4.1.1.4 Tipos de manutenção de software ... 94
4.1.1.5 Plataformas tecnológicas ... 96
4.1.2 Parte 2 - Identificação de Propriedades de um Software que Beneficiam a sua Manutenibilidade ... 97
4.1.2.1 Documentação de Requisitos... 98
4.1.2.2 Documentação de Arquitetura ... 103
4.1.2.3 Software Definido em Camadas ... 108
4.1.2.4 Estrutura Modular ... 113
4.1.2.5 Documentação de Análise e Projeto ... 117
4.1.2.6 Rastreabilidade Definida entre Requisitos ... 123
4.1.2.7 Rastreabilidade Definida dos Requisitos ao Código Fonte ... 128
4.1.2.8 Padrões de Design ... 133
4.1.2.9 Qualidade da Modelagem dos Dados ... 138
4.1.2.13 Controle de Configuração de Software ... 158
4.1.2.14 Processo Padrão da Organização ... 163
4.1.2.15 Outras Características de um Produto a ser Mantido ... 168
4.1.3 Parte 3 - Resultado desta Pesquisa ... 170
4.1.4 Considerações finais sobre os resultados obtidos com a aplicação do Questionário ... 170
4.2 Resultados da aplicação de uma versão simplificada da metodologia CRISP-DM ... 176
4.2.1 Compreensão do Negócio e Compreensão dos Dados ... 176
4.2.2 Preparação dos Dados ... 179
4.2.3 Modelagem ... 181
4.2.4 Avaliação e Aplicação ... 186
4.3 Comparação dos resultados desta pesquisa com outros trabalhos ... 186
4.3.1 Com os modelos de qualidade de McCall e de Boehm ... 186
4.3.2 Com o trabalho realizado por Souza et al. (2005a) ... 188
4.4 Uso dos resultados desta pesquisa nas organizações ... 190
5
Conclusão ...196
Referências ...199
Apêndice A – Informações gerais sobre o sistema ...205
Apêndice B – Matriz de priorização ...207
Apêndice C – Identificação das propriedades de software que
beneficiam a sua manutenibilidade ...210
Apêndice D – Algoritmos de melhor desempenho na ferramenta WEKA
para a massa de dados selecionada nesta pesquisa ...237
1 Introdução
Este capítulo apresenta o tema no qual este trabalho está inserido, bem como a delimitação do problema, os objetivos, as suposições, a relevância do estudo e finaliza com a organização do trabalho.
1.1 Tema
Atualmente a manutenção de software é a fase do ciclo de vida do software que, normalmente, consome a maior parte dos recursos, tanto financeiros quanto humanos, das organizações de desenvolvimento de software. Segundo Pfleeger (2004), cerca de 80% do orçamento total do ciclo de vida de um software são custos gastos com a manutenção desse software.
“Entretanto, a manutenção de software tem recebido menos atenção durante o planejamento do desenvolvimento de um software.” (CHARETTE et al., 1997, p.43-50). Conforme estudo feito por Dias (2004), observa-se que há um problema cultural em engenharia de software na forma de uma visão um tanto quanto tendenciosa, pois vários segmentos do meio acadêmico e da indústria priorizam o ensino e aprendizado do chamado ‘Desenvolvimento de Software’, ou seja, a construção de um novo produto. Os processos propostos hoje em dia são, na sua maioria, processos orientados ao desenvolvimento que mesclam a manutenção ao longo do ciclo de vida (estratégia não muito eficaz quando aplicada em sistemas legados). A manutenção, em geral, tem sido vista como a última atividade do ciclo de vida cascata, conforme afirmação feita por Sommerville (2007), ou como uma nova iteração de desenvolvimento do RUP (Rational Unified Process) (KRUCHTEN,
Para Pressman (2002), a fase de manutenção aplica novamente os passos das fases de definição e desenvolvimento, mas o faz no contexto de software existente. Já para Pigoski (1996), o ciclo de vida do software relatado na norma ISO/IEC 12207, dentre outros, leva a uma interpretação equivocada do processo de manutenção, pois tem início apenas após o produto já estar pronto e em produção. Pigoski (1996) sugere que o processo de manutenção inicie juntamente com o de desenvolvimento, pois dessa forma mantenedores podem atuar de forma a obter um produto com arquitetura propícia a reparos mais rápidos e baratos.
Em engenharia de software, a maioria dos esforços se concentra em tentar melhorar as condições de desenvolvimento de software com, possivelmente, dois objetivos: tentar diminuir as necessidades de manutenção (presumidamente corretiva) e focar numa atividade que tem mais visibilidade. Entretanto, Anquetil (2008) mostra que essa estratégia é equivocada por vários motivos:
A correção de erros representa, tipicamente, uma pequena parte de todas manutenções executadas num sistema de software durante sua vida;
A evolução dos sistemas de software é uma realidade intrínseca devida às mudanças que acontecem no mundo real e não às características internas dos sistemas;
A melhoria do desenvolvimento só pode ter impacto sobre sistemas no futuro, deixando de lado o enorme leque de sistemas existentes (principalmente escritos em Cobol);
As realidades do desenvolvimento e da evolução de software são diferentes e soluções criadas para uma nem sempre se adequam à outra.
Dar manutenção pode ser muito mais complexo do que desenvolver um software novo, pois manter um software cujo domínio é desconhecido, que possui documentação incompleta, um registro superficial de mudanças, dentre outros, é muito mais trabalhoso do que se ele fosse totalmente refeito, seguindo uma metodologia de projeto e convertido, se for o caso, para uma plataforma mais atual e conhecida no mercado. (BARRETO; BOAS, 2006, p.2).
de manutenção de software. Com isso, não têm uma estimativa precisa do esforço a ser gasto e, consequentemente, do tempo necessário para realizar a manutenção, o que acarreta em erros quanto à previsibilidade do custo e da duração de um projeto de manutenção, podendo impactar na satisfação do cliente.
Nesse sentido, a gestão do conhecimento pode apoiar a tomada de decisões nos projetos de manutenção de software, utilizando o conhecimento dos especialistas envolvidos nas atividades de manutenção e informações de projetos anteriores similares extraídas de uma base histórica. Conforme afirmado por Garcia e Alvarez (1996a), acrescentar propriedades em um software para beneficiar a sua manutenibilidade requer custos adicionais, por isso é necessário que haja um planejamento adequado de quais propriedades um determinado produto deve ter de forma que agregue valor para a fase de manutenção. Manutenibilidade de software diz respeito à facilidade com que o mesmo pode ser modificado para satisfazer requisitos do usuário ou ser corrigido quando deficiências são detectadas (PIGOSKI, 1996).
Mas como fazer esse planejamento sem conhecer quais propriedades de software beneficiam a sua manutenibilidade? Quais dessas propriedades devem estar presentes em um determinado produto, ou seja, em quais se devem dar preferência para investir de acordo com a necessidade do cliente? O tema deste trabalho está direta e indiretamente envolvido com essas questões.
1.2 Delimitação do Problema
na fase de manutenção. Além disso, há também a indisponibilidade de equipes específicas para realizar esse tipo de trabalho, visto que, em geral, sempre há demandas emergenciais a serem atendidas com prioridade superior a todas as demais, dentre outras dificuldades.
Com tantas restrições, raramente as organizações conseguem implementar propriedades para beneficiar a manutenibilidade de um software em todos os seus sistemas legados. Por isso a importância de identificar quais propriedades de software que beneficiam a manutenibilidade devem estar presentes em um determinado produto, ou seja, em quais se devem dar preferência para investir de acordo com a necessidade do cliente. É necessário que as organizações tenham como identificar se o investimento a ser realizado trará uma melhoria na manutenção do projeto de acordo com o esperado, caso contrário, tal investimento não se justifica.
Garcia e Alvarez (1996) afirmam que se as subcaracterísticas de manutenibilidade (modificabilidade, testabilidade, outras) forem distribuídas de maneira uniforme, haverá mau uso de uma grande parte do esforço de manutenibilidade, visto que nem todos os componentes de um sistema têm a mesma necessidade de manutenibilidade. Módulos com grande probabilidade de mudanças durante uma manutenção requerem mais manutenibilidade do que outros com baixa probabilidade.
1.3 Objetivos
O objetivo geral deste trabalho é propor um processo que permita a uma organização que desenvolve e mantém software identificar quais propriedades de seus softwares contribuem para a manutenibilidade.
Os objetivos específicos são:
i. Propriedades que por hipótese beneficiam a manutenibilidade de software identificadas;
ii. Opiniões de especialistas sobre o benefício dessas propriedades identificadas;
iii. Identificação da correlação dessas propriedades identificadas com a manutenibilidade de software.
Espera-se com esta pesquisa que o processo proposto possa ser executado dentro de organizações, pelo grupo de engenharia de software, e pelo escritório de projeto, permitindo aos gestores de projeto tomarem decisões mais eficazes, nos casos em que a manutenibilidade seja importante, tanto em sistemas legados quanto em novos sistemas a serem desenvolvidos.
Com isso, espera-se que seja possível definir um conjunto de diretrizes com a finalidade de orientar gerentes de projeto e também a equipe do processo padrão da organização, de forma que eles tenham insumos para priorizar quais propriedades de software (que beneficiam a sua manutenibilidade) investir em um projeto ou sistema de acordo com os requisitos definidos pelo cliente, dentre outras decisões. Isso trará vários ganhos à organização, pois a aplicação dos resultados desse processo a apoiará a investir de forma mais consciente nas propriedades de software que agregam valor à manutenibilidade.
1.4 Suposições
1.5 Relevância do Estudo
Geralmente a manutenção de software acaba sendo a mais longa e onerosa fase de todo o ciclo de vida de um sistema (PIGOSKI, 1996). Segundo Pressman (2001, p.14) “Dados da indústria de software indicam que cerca de 60% a 80% de todo o esforço despendido no software será gasto depois que ele for entregue ao usuário pela primeira vez”. Pigoski (1996) afirma que a manutenção vem ganhando destaque devido ao fato do seu custo aumentar em relação ao custo de desenvolvimento com o passar dos anos.
Um estudo realizado por Lientz e Swanson (1981, apud PFLEEGER, 2001) com gerentes de 487 organizações buscou identificar como os responsáveis pela manutenção dedicaram seu tempo entre os diversos tipos de manutenção (perfectiva, adaptativa, corretiva e preventiva). Constatou-se que apenas cerca de 21% de todo o trabalho da manutenção é gasto consertando erros. Os 79% restantes são gastos adaptando sistemas existentes a modificações no seu ambiente externo, fazendo melhorias solicitadas por usuários e submetendo uma aplicação à reengenharia, para uso futuro. O Gráfico 1 apresenta o resultado dessa pesquisa.
Com o aumento da dependência de sistemas de software em grande escala, a habilidade para modificar softwares existentes em um tempo reduzido e de maneira econômica se tornou crítico para empresas de diversos ramos. Isso demonstra que o desejo de uma alta manutenibilidade é na verdade um desejo por baixo esforço de manutenção. (DEISSENBOECK, 2007, p.184).
Embora do ponto de vista de uma organização (principalmente as privadas) de desenvolvimento de software possa ser mais benéfico economicamente gastar poucos recursos para desenvolver inicialmente um software manutenível e posteriormente ter maiores ganhos provendo atividades de alto custo na fase de manutenção, não é isso que um cliente deseja. Para ele, é preferível um sistema que seja fácil de manter.
Manutenção de software, em geral, apresenta diferenças significativas em relação ao desenvolvimento de software, visto que mantenedores trabalham com condições técnicas restritas, aonde usualmente não podem escolher o ambiente de trabalho, a linguagem de programação, o sistema de gerenciamento de dados, o modelo de dados, a arquitetura do sistema, etc. Enquanto o desenvolvimento é tipicamente orientado por requisitos, a manutenção é orientada por eventos (PIGOSKI, 1996). Na manutenção, eventos externos (tais como, uma oportunidade de negócio, a descoberta de um erro) requerem a modificação do software e há uma oportunidade muito menor de planejamento em relação a um desenvolvimento. Manutenção é por natureza uma atividade mais reativa (ou caótica).
A manutenção de software é a atividade mais praticada nas organizações de software, mas ainda é pouco ou mal gerenciada. Ela precisa ser gerenciada corretamente e objetivamente para ser executada em melhores condições. Por isso a necessidade de se garantir uma melhoria na produção do software, planejando desde o seu início a inclusão de requisitos não funcionais de manutenibilidade.
que determinadas propriedades de software têm na manutenibilidade em relação a outras propriedades, o que foi proposto por este trabalho.
1.6 Organização do Trabalho
Este trabalho foi organizado em cinco capítulos, incluindo esta Introdução.
O segundo capítulo apresenta uma revisão da literatura, conceituando e detalhando os termos manutenção de software e manutenibilidade. Descreve brevemente alguns modelos (McCall, Boehm, de estimativas em manutenção e COCOMO II) e destaca o estado da arte de assuntos correlacionados ao tema deste trabalho.
O terceiro capítulo se refere ao material e métodos utilizados nesta pesquisa, apresentando uma breve descrição da pesquisa executada, bem como a sua classificação, a caracterização do ambiente de pesquisa e a metodologia adotada.
No quarto capítulo é apresenta os resultados obtidos durante esta pesquisa, bem como uma análise crítica com base nas informações levantadas.
2 Revisão da Literatura
Este capítulo apresenta uma definição de manutenção de software, bem como de manutenibilidade. Descreve brevemente alguns modelos e destaca o estado da arte de assuntos correlacionados ao tema deste trabalho.
2.1 Teoria Básica em Manutenção de Software
À medida que a sociedade se torna cada vez mais dependente de sistemas de vários tipos, estão aumentando os esforços devotados à evolução de sistemas já existentes, em vez de ao desenvolvimento de novos sistemas. Os sistemas existentes, que precisam ser mantidos, são atualmente chamados de sistemas legados. (SOMMERVILLE, 2003, p.31). Sistemas legados são importantes ativos de negócio e deve haver investimentos em mudanças para que o valor desses ativos seja mantido. São sistemas que evoluíram ao longo do tempo e têm um papel importante em uma organização que, em geral, gostaria de substituí-los, mas os riscos de introduzir novos sistemas são altos. (LIMA et al., 2008, p.9).
Fatores internos e externos, como o estado da economia nacional e internacional, as modificações nos mercados, as alterações nas leis, as mudanças de gestão e organização estrutural, provocam mudanças contínuas nas organizações. Essas mudanças geram requisitos de software novos ou modificados; assim, todos os sistemas de software úteis inevitavelmente são modificados quando as organizações passam por mudanças. (SOMMERVILLE, 2003, p.498). Logo, a vida útil de um sistema não acaba com a realização de sua entrega. O sistema final está sujeito a contínuas modificações, mesmo depois de pronto e permanece em contínua evolução. Exceto para os casos mais simples, os sistemas são evolutivos. (PFLEEGER, 2004, p.379).
Segundo Martin e McClure (1983, apud PIGOSKI, 1996), vários são os motivos que levam a um software requerer manutenção, como por exemplo: a correção de falhas; a correção de erros de projeto; o acréscimo de funcionalidades; as mudanças em arquivos ou base de dados; a melhoria do projeto; a conversão dos programas para que facilidades de hardware, software, características de sistema e telecomunicações possam ser usadas.
Essas manutenções são necessárias porque um software precisa acompanhar e atender plenamente às necessidades do negócio no qual está inserido. Como os negócios mudam numa velocidade cada vez mais acelerada, isso faz com que a manutenção seja a fase do ciclo de vida de um software que mais consome recursos financeiros e humanos das organizações. (LIMA et al., 2008, p.16).
Entretanto, conforme citado anteriormente, essa é a fase que recebe menos atenção quando se está planejando o desenvolvimento de um software.
Tradicionalmente, a manutenção de software é definida como a realização de modificações em um produto de software após sua entrega, para corrigir eventuais falhas, melhorar seu desempenho ou outro atributo, ou adaptar o produto a um ambiente diferente. (INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS, 1998, p.4).
Segundo a definição de Pfleeger (2001, p.464) “Manutenção é qualquer trabalho efetuado para modificar o sistema, depois que ele estiver em operação.”
As definições acima pressupõem que as atividades da manutenção acontecem após a entrega do software. Entretanto, Pigoski (1996) ressalta a importância do envolvimento dos mantenedores nas atividades que antecedem a entrega do produto, chamadas de atividades de pré-entrega, e defende que a manutenção deve ser levada em consideração desde as primeiras atividades do desenvolvimento de um software. Além disso, ele defende que a participação dos responsáveis pela manutenção ocorra desde o planejamento do desenvolvimento com o intuito de elaborar e designar as atividades que tornarão o produto melhor de ser evoluído.
help-desk.
Como a definição tradicional da manutenção de software considera que as atividades relativas à manutenção devem ocorrer somente após a entrega do produto de software, ela revelou-se menos eficaz, pois deixando de planejar e aplicar os recursos e esforços necessários para a manutenibilidade desde o desenvolvimento do produto de software, fatalmente os custos e o tempo serão maiores na fase de manutenção. (SOMMERVILLE, 2003, p. 519).
2.1.1 Classificação dos Tipos 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 (PIGOSKI, 1996) (SWEBOK, 2004, cap.6).
Atualmente a norma INTERNATIONAL ORGANIZATION FOR STANDARDIZATION/IEC 14764 (2006, p.3-4) classifica, ou subdivide, a manutenção de software 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; que 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, feita para manter um sistema em funcionamento até que se faça uma manutenção corretiva. (ISO/IEC 14764, 2006, p.3-4).
E sua classificação é fundamentada na natureza de suas causas. Apesar de serem as classificações mais usadas, outros autores sugerem outros tipos de classificação para a manutenção.
Kitchenham et al. (1999) classificam a manutenção em dois tipos, corretiva e de melhoria. A manutenção corretiva não difere da classificação dada pela ISO/IEC 14764 (2006), sendo a mudança para corrigir erros não detectados na fase de teste. A manutenção de melhoria é a mudança para acompanhar a evolução inerente à computação, além de ser utilizada também para atender às necessidades contínuas dos usuários ou para melhorar a manutenibilidade futura. Os autores também defendem que não utilizam as classificações adaptaiva e perfectiva porque elas dependem das razões da mudança e não das características objetivas das mudanças.
Chapin et al. (2001) justificam que não utilizaram as classificações descritas anteriormente porque elas dependem da classificação da intenção de mudança sob a perspectiva do mantenedor. A classificação proposta pelos autores consiste em fazer uma avaliação das evidências de mudanças no software, na documentação, nas propriedades e no suporte ao usuário, classificando a manutenção em doze tipos baseados em evidências objetivas das atividades de manutenção, conforme listado a seguir:
- Regras de Negócio
o Redutiva, Corretiva e de Realce.
- Documentação
o Reformativa e Atualizadora.
- Propriedades de Software
o Groomative (de preparar algo para), Preventiva, Performance e
Adaptativa.
- Interface de Apoio
o De Treino, Consultiva e Avaliativa.
2.2 Manutenibilidade de Software
O SWEBOK agrupa as questões-chave da manutenção de software, responsáveis por lidarem e assegurarem uma manutenção de software efetiva, 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). Para o SWEBOK (2004, cap.6), são quatro as principais questões técnicas relacionadas à manutenção de software, sendo a manutenibilidade uma delas (as demais são: compreensão do sistema, teste, análise de impacto).
O termo manutenibilidade refere-se a facilidade com que um software pode ser adaptado, aprimorado ou corrigido para satisfazer requisitos específicos e é um dos atributos de qualidade de um software. Tornar o sistema mais “manutenível” é uma tarefa difícil, pois durante o desenvolvimento as preocupações dos desenvolvedores costumam ser outras. (ALLIEVI; FIGUEIREDO, 2008, p.17).
Conforme a norma INTERNATIONAL ORGANIZATION FOR STANDARDIZATION/IEC 9126-1 (2001), a manutenibilidade é a capacidade do produto de software de ser modificado, ou seja, se é fácil modificá-lo. Em outras palavras, os requisitos de manutenibilidade especificam com que facilidade um sistema ou componente de software pode ser modificado para corrigir defeitos, melhorar desempenho, melhorar outros atributos, ou se adaptar ao ambiente que mudou. Para Pigoski (1996), manutenibilidade de software diz respeito à facilidade com que o mesmo pode ser modificado para satisfazer requisitos do usuário ou ser corrigido quando deficiências são detectadas.
Subcaracterísticas da Manutenibilidade
Significado da Subcaracterística
Analisabilidade Capacidade do produto de software de permitir o diagnóstico de deficiências ou causas de falhas no software, ou adaptações do software devido a mudanças no ambiente e nos seus requisitos ou especificações funcionais.
É fácil encontrar uma falha, quando ela ocorre?
Modificabilidade Capacidade do produto de software de permitir que uma modificação especificada seja implementada.
É fácil de modificar e adaptar?
Estabilidade Capacidade do produto de software de evitar efeitos inesperados decorrentes de modificações no software.
Há grande risco quando se faz alterações?
Testabilidade Capacidade do produto de software de permitir que o software, quando modificado, seja validado.
É fácil testar as alterações? Conformidade da
Manutenibilidade
Capacidade do produto de software de aderir a normas e convenções relacionadas à manutenibilidade.
Quadro 1 – Subcaracterísticas da Manutenibilidade Fonte: ISO/IEC 9126-1, 2001 (tradução nossa)
Brusamolin (2004) define quatro fatores que impactam na manutenibilidade: arquitetura, tecnologia, documentação e compreensibilidade do programa. Segundo esse autor, para controlar a manutenibilidade de um software, deve-se saber como medi-la. Para isso existem as métricas, que auxiliam na verificação do software produzido, das quais ele cita:
• Métricas de manutenibilidade a nível de código;
• Métricas de complexidade de Halsted;
o Mede a complexidade a partir da quantidade de operadores e operandos no código fonte.
• Métricas de manutenibilidade em nível de design:
o Complexidade ciclomática;
Mede o número de caminhos do código fonte.
• Métricas híbridas (combinação de métricas).
Para o SWEBOK (2004, cap.6), existem métricas específicas para as atividades de manutenção, inclusive para as subcaracterísticas da manutenibilidade, como: a analisabilidade 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 que mede o esforço em uma modificação específica; a estabilidade para medir o comportamento inesperado, inclusive durante os testes, e; testabilidade para medir os esforços de mantenedores e usuários na tarefa de testar a modificação.
Sommerville (2007) argumenta que há a necessidade de métricas do processo, tais como número de solicitações de manutenção corretivas, tempo médio e desejado para análise de impacto e tempo médio para implementar uma solicitação de mudança, para avaliação da facilidade, ou não, de realizar uma manutenção que trata de evolução. Além disso, ressalta a importância de se conhecer as técnicas de estimativa de custos empregadas pela organização. Cita também a avaliação de ambiente (se o desempenho é satisfatório; como são as interfaces com outros sistemas; e outros) e a avaliação da qualidade técnica dos sistemas (qual a facilidade de compreensão; como está a documentação; e outros).
Já Pigoski (1996) 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 e linhas de comentários. A produtividade pode ser medida a partir do percentual de linhas de código que sofreram alterações no ano, do número de versões geradas, ou outros. Entende-se pela classificação dos tipos de manutenção que manutenção corretiva está relacionada a erros e que as manutenções perfectivas ou adaptativas estão relacionadas a melhorias, sendo que estas duas consomem cerca de 80% do trabalho ou esforço. Os prazos são referentes ao tempo gasto para solucionar os problemas e atender as solicitações de melhoria. A qualidade pode ser medida a partir da solução dada aos problemas relatados.
organização que colaboram para a inclusão e manutenção de propriedades de software que beneficiam a sua manutenibilidade. Tais práticas/atividades têm impacto direto no esforço gasto na manutenção e provêem um critério natural para a decomposição da manutenibilidade, conforme explicitado por Deissenboeck (2007).
Pigoski (1996, p.46) sugere algumas práticas que levam à manutenibilidade, dentre elas:
• Fazer revisões de averiguação; • Usar de design orientado a objetos;
• Asseguar que comentários tenham informação útil; • Empregar convenções de programação;
• Usar definições de dados comuns;
• Estabelecer padrões para desenvolvimento de procedimentos e documentos do sistema;
• Estimular a simplicidade;
• Estudar possíveis mudanças futuras e aperfeiçoamentos; • Medir a complexidade dos componentes do sistema; • Registrar os pontos fracos e problemáticos do sistema;
• Estabelecer critérios de aceitação para avaliar a qualidade do software, com particular atenção na qualidade da manutenibilidade; • Prever falhas.
2.3 A Manutenibilidade nos Modelos de Qualidade
2.3.1 Modelo de Qualidade de McCall
Segundo Kitchenham e Pfleeger (1996), um dos modelos de qualidade mais reconhecidos é o modelo de qualidade apresentado por Jim McCall. Esse modelo de qualidade dá uma atenção especial para a lacuna entre usuários e desenvolvedores, focando no número de fatores de qualidade de software que refletem tanto na visão do usuário quanto nas prioridades dos desenvolvedores.
O modelo de qualidade de McCall tem três grandes perspectivas que definem e identificam a qualidade do produto de software, conforme apresentado a seguir (MILICIC, 2005, p.4):
• Revisão do Produto; composta pelos seguintes fatores: manutenibilidade, flexibilidade e testabilidade.
• Transição do Produto; composta pelos seguintes fatores: portabilidade, reusabilidade e interoperabilidade.
O modelo detalha os três tipos de características de qualidade (grandes perspectivas) em uma hierarquia de fatores, critérios e métricas, sendo (MILICIC, 2005, p.5):
• 11 fatores (para especificar), que descrevem a visão externa do software, conforme visão dos usuários;
• 23 critérios de qualidade (para construir), que descrevem a visão interna do software, conforme visão dos desenvolvedores;
• Métricas (para controlar), definidas e usadas para prover uma escala e um método para a medição.
Os fatores de qualidade descrevem diferentes tipos de características comportamentais do sistema e os critérios de qualidade são atributos para um ou mais fatores de qualidade. As métricas de qualidade, por sua vez, objetivam capturar alguns dos aspectos dos critérios de qualidade. Como o foco deste trabalho é na característica de qualidade manutenibilidade, é apresentado na Figura 1 apenas esse fator e seus critérios de qualidade. É possível notar as diferenças entre os critérios desse fator e as subcaracterísticas da norma ISO/IEC 9126-1, podendo-se fazer as podendo-seguintes relações devido à influência que um critério pode exercer na subcaracterística:
Subcaracterística analisabilidade – critérios correlacionados: simplicidade, concisão e auto-descrição;
Subcaracterística modificabilidade – critérios correlacionados: auto-descrição, modularidade;
Subcaracterística estabilidade – critério correlacionado: modularidade;
Subcaracterística testabilidade – critério correlacionado: modularidade;
Figura 1 – Modelo de qualidade do McCall – Fator manutenibilidade Fonte: MILICIC, 2005, p.6 (tradução nossa)
2.3.2 Modelo de Qualidade de Boehm
O segundo modelo de qualidade atual, reconhecido como básico, é o apresentado por Barry W. Boehm, que se dedicou aos defeitos contemporâneos dos modelos que avaliam automaticamente e quantitativamente a qualidade de software. Na essência, esses modelos atentam para definir a qualidade de software quantitativamente por um conjunto de atributos e métricas. O modelo de Boehm é similar ao modelo de qualidade de McCall, uma vez que ele também apresenta uma estrutura de modelo de qualidade hierárquica com características de alto nível, características de nível intermediário, características primitivas – cada uma delas contribui para o nível total da qualidade (MILICIC, 2005).
As características de alto nível representam os requisitos básicos de alto nível usados atualmente para avaliar a qualidade do software – a utilidade geral do software. Essas características endereçam três questões principais que um comprador de software deve ter (MILICIC, 2005, p.6):
• Como é a utilidade: “O quanto (facilmente, confiavelmente, eficientemente) posso usar o software como ele é?”
• Manutenibilidade: “O quanto é fácil entender, modificar e retestar o software?”
• Portabilidade: “Posso continuar usando o software se eu mudar o meu ambiente?”
Manutenibilidade
Simplicidade
Concisão
Auto-descrição
As características de nível intermediário representam sete fatores de qualidade que juntas representam as qualidades esperadas para um sistema de software (MILICIC, 2005, p.6):
• Portabilidade (característica da utilidade geral);
• Confiança, Eficiência, Usabilidade / Engenharia Humana (características de como é a utilidade);
• Testabilidade, Entendimento, Flexibilidade / Modificabilidade (características da manutenibilidade).
O nível mais baixo da estrutura das características hierárquicas do modelo de Boehm são as características primitivas, as quais provêem a definição de métricas de qualidade, o que foi um dos objetivos quando Boehm construiu o seu modelo de qualidade.
Embora os modelos de Boehm e McCall pareçam ser similares, enquanto o modelo de McCall foca essencialmente na medição precisa das características de alto nível ‘como é a utilidade’ (confiança, eficiência e usabilidade), o modelo de Boehm é baseado em um amplo âmbito de características com o foco estendido e detalhado, primordialmente, em manutenibilidade (MILICIC, 2005, p.7).
Figura 2 – Modelo de qualidade do Boehm – Característica de alto nível
manutenibilidade Fonte: MILICIC, 2005, p.7 (tradução nossa)
2.4 Técnicas e Modelos de Estimativas em Manutenção
Neste trabalho, serão apresentadas técnicas e modelos de estimativas em manutenção com a finalidade de identificar possíveis influências de propriedades de software que beneficiam a manutenibilidade do software a ser mantido. A forma com que cada técnica ou modelo de estimativa trata as influências das diversas características consideradas pode auxiliar na definição do processo para identificar as influências dos fatores de manutenibilidade, objeto de pesquisa deste trabalho.
Para avaliar um conjunto de características ou atributos que envolvem a qualidade do software em vários níveis, é necessário escolher um modelo que organize esses atributos e permita avaliar e entender como as diferentes visões resultantes contribuem para a qualidade do produto como um todo (REZENDE; MELLO, 2003, p.8). Métricas quantitativas e modelos para prever a manutenibilidade podem ser usadas para controlar os custos de manutenção. Métricas e modelos de manutenibilidade podem ser úteis para:
Responsabilidade
Comunicabilidade
Auto-descrição
Estruturação
Consistência
Concisão
Expansão Legibilidade Utilidade Geral
Testabilidade Manutenibilidade
Entendimento
Prever a manutenção e o custo das tarefas de manutenção, as quais colaboram em prover estimativas que podem ajudar a alocar os recursos corretos do projeto nas tarefas de manutenção. (FIORAVANTI; NESI, 2001);
Comparar documentos de design, os quais podem ajudar a escolher entre
design diferentes baseados na manutenibilidade do design. (GHOSHES et
al., 2008);
Identificar os componentes de risco de um software, visto que alguns estudos mostraram que a maioria das falhas ocorre em apenas poucos componentes de um sistema de software. (FENTON; OHLSSON, 2000);
Permitir relacionar as variáveis de um sistema de software (que variável tem impacto, direto ou indireto, sobre outra variável);
Apoiar a tomada de decisão pelas gerências com base nos dados gerados pelos modelos;
Apoiar uma gestão de conhecimento mais eficiente dentro da organização devido à criação de bases históricas (armazenamento de lições apreendidas nos projetos, e outros).
Os modelos de qualidade surgiram como uma forma de identificar fatores de qualidade que são importantes e precisam ser avaliados durante o processo de desenvolvimento do software, fornecendo subsídios para o gerente de projeto tomar decisões importantes, minimizando riscos e buscando a garantia da qualidade desse produto (REZENDE; MELLO, 2003).
Conhecer o tamanho do produto é uma das variáveis importantes que os modelos consideram. Esse tamanho pode ser calculado de várias maneiras, sendo uma delas através do Ponto de Função, que é uma medida de dimensionamento de software através da funcionalidade implementada em um sistema, sob o ponto de vista do usuário.
software, ao tempo de duração do projeto, à gerência e apóia a análise de produtividade e qualidade.
Conforme CPM (2005, cap.8), a etapa de contagem Determinar o Fator de Ajuste (ver Figura 3) é a etapa que interessará a esta pesquisa, visto que se baseia em 14 características gerais do sistema (resumidas no fator de ajuste) que classificam as funcionalidades gerais da aplicação que está sendo contada. Cada característica tem descrições associadas que ajudam a determinar o nível de influência da característica, o qual varia em uma escala de 0 a 5, de sem influência até forte influência. Quando aplicado, o fator de ajuste (FA) ajusta a contagem de pontos de função não-ajustados em mais ou menos 35% para produzir a contagem de pontos de função ajustados. As 14 características gerais do sistema são (CPM, 2005, cap.8, p.1-2):
1. Comunicação de Dados; 2. Processamento Distribuído; 3. Performance;
4. Configuração Intensamente Utilizada; 5. Volume de Transações;
6. Entrada de Dados On-Line; 7. Eficiência do Usuário Final; 8. Atualização On-Line; 9. Processamento Complexo; 10. Reusabilidade;
11. Facilidade de Instalação; 12. Facilidade de Operação; 13. Múltiplos Locais;
14. Facilidade de Mudança.
Figura 3 – Fluxograma do procedimento de contagem
Determinar Tipo de Contagem Identificar Escopo de Contagem e Fronteira da Aplicação Contar Funções de Dados Contar Funções Transacionais Determinar os PF Não Ajustados
Determinar o Fator de Ajuste
Algumas dessas características gerais podem remeter as propriedades de software que beneficiam a sua manutenibilidade, aonde cada uma delas isoladamente pode ter uma influência na variação do percentual de ajuste dos pontos de função. Entretanto, uma crítica em relação à determinação do fator de ajuste na técnica de APF é que ele não deveria ser considerado para calcular o tamanho funcional do software, visto que tamanho funcional se baseia nos requisitos funcionais de um projeto de software e não em requisitos não-funcionais. O ideal seria que esse ajuste fosse feito somente após o cálculo de ponto de função (não-ajustados) para estimar com maior precisão o esforço de desenvolvimento, derivando daí custo, esforço, outros, os quais realmente podem ser afetados por essas características gerais, evitando assim gerar um viés, portanto, no tamanho funcional do produto. Uma evidência da concordância disso é que o método de contagem não ajustado foi aceito como norma internacional da ISO, tornando o fator de ajuste opcional. Além disso, a versão 4.3 do CPM retirou o fator de ajuste do método para compatibilizar com essa norma, reconhecendo apenas o PF Não-Ajustado (CPM, 2010).
Outra crítica quanto à técnica de APF é que há uma grande dificuldade na correta identificação do nível de influência (0-5) de cada uma das 14 características gerais, havendo distorções na contagem de um mesmo produto por pessoas diferentes (HAZAN et al., 2008). Um ponto que interessa a esta pesquisa é entender como essas características gerais influenciam na alteração do esforço, custo, produtividade e outros, relacionados à manutenção de software, além de outras características não citadas por essa técnica.
PF_MANUTENÇÃO = ((PF_INCLUÍDO + PF_ALTERADO + PF_CONVERSÃO) x FA_ATUAL) + (PF_EXCLUÍDO x FA_ANTERIOR) (1)
PF_DESENVOLVIMENTO = ((PF_NÃO_AJUSTADO + PF_CONVERSÃO) x
FA_AJUSTE) (2)
É possível notar pelas fórmulas listadas a importância do fator de ajuste na manutenção evolutiva, tanto que ele é considerado em dois momentos, o fator de ajuste anterior na exclusão de uma funcionalidade, pertencente a aplicação implantada, e o fator de ajuste atual caso haja uma nova funcionalidade ou alteração de uma já existente, pertencente ao projeto de manutenção. Logo, o fator de ajuste anterior é o fator de ajuste atual do último projeto de manutenção.
Uma dificuldade (erro) encontrada por muitos, no que se refere a fórmula de cálculo para manutenção evolutiva, conforme afirmado por Hazan et al. (2008), é na determinação da complexidade das funções alteradas, visto que na APF não se conta a alteração da função (intuitivo) e sim a função como um todo. Outro erro comum é a consideração de projetos de manutenção adaptativa como evolutiva (projeto de melhoria - enhancement). Para ter um projeto de melhoria a função
alterada deve ter mudança em arquivos referenciados ou mudança em itens de dados ou mudança em lógica de processamento, considerando as lógicas do CPM (HAZAN et al.,2008). A versão 4.3 do IFPUG (The International Function Point Users
Group) afirma que enhancement é um tipo de manutenção adaptativa da IEEE e
não mais que esses conceitos são sinônimos, conforme constava na versão 4.2.1 (CPM, 2010).
• Manutenção Corretiva
o Aplicação sem documentação ou com documentação desatualizada ou documentação incompleta sem redocumentação de requisitos.
PF = (PF_ALTERADO x FATOR_AJUSTE) x 0,70 (1)
o Aplicação sem documentação ou com documentação desatualizada ou incompleta ou completa com redocumentação de requisitos
PF = (PF_ALTERADO x FATOR_AJUSTE) x 0,80 (2)
o Aplicação com documentação completa
PF = (PF_ALTERADO x FATOR_AJUSTE) x 0,60 (3)
• Manutenção Cosmética (adaptação de interface)
PF = (PF_ALTERADO x FATOR_AJUSTE) x 0,10 (1)
• Manutenção Adaptativa
o Redesenvolvimento de projetos em outra plataforma
PF = (PF_NÃO_AJUSTADO + PF_CONVERSÃO) x FATOR_DE_AJUSTE (1)
o Atualização de Plataforma com necessidade de redocumentação de requisitos
PF = (PF_ALTERADO x FATOR_AJUSTE) x 0,50 (2)
o Atualização de Plataforma sem necessidade de redocumentação de requisitos
PF = (PF_ALTERADO x FATOR_AJUSTE) x 0,40 (3)
o Adequação de funcionalidades às mudanças no ambiente
Considerar 40% a 80% do PF_ALTERADO
sendo, portanto, utilizada uma base histórica, apenas a experiência da autora. Entretanto, é um trabalho interessante e inovador na área, que carece de uma maior atenção e talvez o processo proposto nesta pesquisa possa colaborar para validar ou não essas fórmulas apresentadas.
2.4.1 COCOMO II
O COCOMO II (Constructive Cost Model), assim como o seu predecessor (COCOMO 81), busca medir esforço, prazo, tamanho de equipe e custo necessários para o desenvolvimento de software, desde que se tenha, como premissa, a dimensão do mesmo (TRINDADE et al., 1999, p.3), sendo, portanto, um modelo paramétrico.
Para o cálculo do custo deve-se conhecer o prazo e equipe de trabalho, para então chegar ao valor, sendo que para definir o tamanho do programa, torna-se necessário que se caracterize que medida será adotada (linhas de código, pontos de função ou pontos por caso de uso). No caso desta pesquisa será adotado o ponto de função, por isso todo o enfoque dado anteriormente nessa técnica.
Uma mudança nesta nova versão em relação à anterior foi na estrutura do modelo, sendo composta pelos seguintes submodelos (COCOMO II, 2009):
Composição da Aplicação;
Pré-Projeto;
Pós-Arquitetura.
Além disso, uma das grandes novidades do COCOMO II é a possibilidade de todos os fatores poderem ser alterados, ou por uma nova calibragem publicada pela equipe de pesquisa da própria USC (University of Southern California), ou por
Os modelos de estimativa de custo de software possuem um fator exponencial para considerar os gastos (despesas) e economias relativas às escalas encontradas em projetos de software de tamanhos distintos. Para determinar se o projeto apresenta gastos ou economias, uma variável é utilizada como expoente. O novo método traz valores com uma dinâmica possível a partir da análise de alguns fatores de equilíbrio, também chamados fatores de escala, sendo eles (COCOMO II, 2009):
Precedência em aplicações;
Flexibilidade de desenvolvimento;
Resoluções de arquitetura ou riscos;
Coesão da equipe de desenvolvimento;
Maturidade do processo.
Outra diferenciação é que os direcionadores de custo, na nova versão do COCOMO, deixam de ser 15 e passam a ser, dependendo do submodelo, 7 (Pré-Projeto) ou 17 (Pós-Arquitetura), conforme Quadro 2:
Atributos do Produto
Confiabilidade requerida pelo software Tamanho da base de dados
Documentação
Complexidade do software Reusabilidade requerida
Confiabilidade e complexidade do software
Atributos da Plataforma
Restrições relativas ao tempo de dispositivos Restrições quanto ao uso de memória Mudanças de plataforma
Dificuldades com a plataforma
Atributos da Equipe de Desenvolvimento
Capacidade dos analistas Experiência na aplicação Capacidade dos programadores Experiência com a plataforma
Experiência com linguagem e ferramental Continuidade do pessoal
Capacidade do pessoal
Experiência profissional
Atributos do Projeto
Uso de ferramentas
Desenvolvimento multi-local
Prazo requerido para o desenvolvimento Instalações
LEGENDA:
Células com fundo ...
Branco representam opções exclusivamente do submodelo Pós-Arquitetura.
Cinza escuro representam opções que servem aos submodelos Pré-Projeto e Pós-Arquitetura.
Cinza claro representam opções exclusivamente do submodelo Pré-Projeto.
Quadro 2 – Direcionadores de custo Fonte: TRINDADE et al., 1999 (tradução nossa)
Em relação aos derivadores de custo, este trabalho estará focando no que se refere aos atributos do produto. Realizando um comparativo desse modelo com a técnica de APF, o COCOMO II utiliza apenas os pontos de função não-ajustados como entrada do processo, sendo o fator de ajuste ignorado. Entretanto, fazendo uma relação entre as características gerais do fator de ajuste do PF com os atributos do produto dos derivadores de custo do COCOMO II, as características gerais do sistema (fator de ajuste) Reusabilidade e Facilidade de Mudança estão fortemente vinculadas aos atributos do produto do COCOMO II, em especial, reusabilidade requerida e complexidade do software.
2.5 Estado da Arte em Manutenibilidade
Avaliar a manutenibilidade de um sistema completo é difícil devido à influência de vários fatores, tais como pessoas, tarefas e ferramentas, além do código fonte.
Identificou propriedades (fatores) dos sistemas de software desenvolvidos na linguagem de programação java que foram considerados importantes para a manutenibilidade pelos especialistas que possuem grande experiência de desenvolvimento nessa linguagem. São os seguintes fatores que afetam a manutenibilidade e sua avaliação (ANDA, 2007, p. 209-211):
• Escolha das classes e nomes; • Design;
• Arquitetura; • Componentes; • Encapsulamento; • Herança;
• Bibliotecas; • Simplicidade; • Classificação; • Comentários; • Plataforma técnica.
Identificou também pontos fortes e fracos na avaliação da manutenibilidade usando medidas estruturais e usando a avaliação dos especialistas.
Em seu estudo, Anda (2007) obteve como resultados que as avaliações de especialistas são mais comuns na prática do que os métodos formais e também que a avaliação de especialistas extrapola os métodos formais. Há pontos importantes relacionados à manutenibilidade que não são facilmente detectados por medidas estruturais. E concluiu que a avaliação de especialistas e métodos formais em conjunto geralmente provê os melhores resultados.
Deissenboeck et al. (2007) citam que é necessário um modelo de qualidade para solucionar a ausência de uma base abrangente para avaliação e melhoria da manutenibilidade de um sistema de software. E ntretanto, afirmam que modelos de qualidade geralmente não modelam explicitamente as atividades de manutenção. Logo, tais modelos não são diretamente capazes de explicar como as propriedades dos sistemas influenciam no esforço de manutenção.
coerente para a relação dos dois nódulos, nem pode ser usada para agregar valores.
É possível notar que há diferenças entre as Figuras 2 e 4 (ambas se referem ao modelo de Boehm) devido ao fato de a Figura 4 se referir a um modelo de 1978, enquanto o da Figura 2 a um modelo mais atual (2005). Os autores afirmam que uma determinada situação pode ser decomposta em fatos, por exemplo: um atributo de documentação pode ser afetado por atividades diferentes (por mais de uma equipe), as quais podem ser determinadas por diversos fatores, tais como conhecimento dos engenheiros, a presença de um processo de software apropriado, dentre outros, além da produtividade da equipe.
Figura 4 – Árvore de Qualidade de Software Fonte: DEISSENBOECK et al., 2007, p.187 (tradução nossa)
Deissenboeck et al. (2007) propuseram então um modelo de qualidade de manutenibilidade bi-dimensional, que associa explicitamente propriedades do sistema (fatos) com atividades realizadas durante a manutenção, e concluíram que a separação das atividades e das propriedades (ver Figura 5) facilita a identificação de critérios de qualidade confiáveis e permite justificar suas interdependências, visto que as atividades são o principal fator de custo na manutenção de software. A construção do modelo ajudou a definir uma terminologia consistente (repositório central de definição de qualidade), a qual serviu como uma base para a geração
Acessibilidade
Comunicabilidade
Auto-descrição
Estruturação
Concisão
Legibilidade
Expansão Testabilidade
Manutenibilidade
Entendimento
