S’inscrire dans le débat public par le biais d’actions concrètes

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.

Anda (2007) realizou uma comparação qualitativa da avaliação da manutenibilidade baseada em medidas estruturais e na avaliação de especialistas em quatro sistemas equivalentes desenvolvidos na linguagem de programação java, comparando os efeitos causados na manutenibilidade devido a diferentes escolhas

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.

Eles explicitam como um exemplo desse problema o ramo de manutenibilidade da Árvore de Características da Qualidade de Software de Boehm (ver Figura 4; as caixas cinzas se referem às atividades enquanto as demais às características de sistema), pois justificam que a semântica ao redor dessa Árvore não é clara ou pelo menos é ambígua devido à mistura entre os termos atividade e característica e que, com isso, essa Árvore não pode indicar uma explanaçã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 Modificabilidade

automática de documentos de orientações para tarefas específicas de manutenção, bem como para a análise de artefatos de sistemas, e a rever omissões bem como contradições nos modelos e nas orientações de qualidade existentes.

Figura 5 – Matriz da Manutenibilidade Fonte: DEISSENBOECK et al., 2007, p.187 (tradução nossa)

Ghosheh et al. (2008) afirmam que é muito importante ter um critério comum para avaliar diferentes modelos de manutenibilidade. Entretanto, essa avaliação é difícil de atingir devido a alguns motivos:

Primeiro, não há um acordo entre os pesquisadores de como medir a manutenibilidade, podendo essa ser medida usando esforço, índice de manutenibilidade, ou alguma das subcaracterísticas de manutenibilidade tais como analisabilidade ou modificabilidade. Alguns modelos também medem a manutenibilidade do design, enquanto outros medem a manutenibilidade do

S it ua çã o In fr ae st ru tu ra P ro du to A sp ec to s di nâ m ic os A sp ec to s es tá ti co s F er ra m en ta s Concorrência Recursão Identificadores Clonagem Formato do código Debugador Refatorador Manutenção Análise Implementação Análise de Impacto Codificação Modificação Conceito Local

X

X

X

X

X

X

X

X

X

X

X

X

código, o que torna a avaliação mais difícil;

Segundo, não há uma concordância nas métricas utilizadas para construir o modelo de manutenibilidade. Os modelos de manutenibilidade podem ser construídos por métricas baseadas em requisitos, no design ou no código

fonte. É difícil comparar métricas de diferentes artefatos. Mesmo quando os modelos de manutenibilidade usam o mesmo artefato, a comparação não é precisa, a menos que as métricas sejam aplicadas a estudos de caso que possuam o mesmo nível de dificuldade e usem tecnologias similares;

Terceiro, os dados usados para validar os modelos de manutenibilidade são diferentes. No caso de experimentos empíricos, alguns modelos usam profissionais enquanto outros modelos usam estudantes, os quais podem ter um desempenho inferior ao dos profissionais. Alguns modelos usam pequenos estudos de caso enquanto outros modelos usam estudos de caso maiores, os quais são mais difíceis de manter;

E por último, a precisão da medida é difícil de comparar, a menos que os modelos usem a mesma avaliação para a manutenibilidade e usem os mesmos dados em seus modelos.

Por esse motivo, os autores (Ghosheh et al., 2008) introduziram um Critério de Avaliação Geral para Modelos de Manutenibilidade (ECMM). Foi proposto então um modelo estrutural baseado na UML para descrever os diferentes modelos de manutenibilidade (conforme a Figura 6). O ECMM é baseado em características do modelo estruturado (como exemplificado no Quadro 3), sendo que para cada característica é atribuído um ponto baseado numa escala de 1 a 10, onde 1 é considerado um valor baixo e 10 um valor alto. O ponto é dado a característica de acordo com a sua importância no processo de avaliação. O total da pontuação do ECMM é calculado somando todos os pontos das características. Quanto maior a pontuação do ECMM, melhor está o modelo. Entretanto, os autores concluíram que a avaliação dos modelos de manutenibilidade é influenciada por mais fatores do que apenas pela precisão do modelo, devendo-se estar atento a outros fatores, tais como a validação das métricas e dos dados usados.

Medição da Acurácia Objetiva Subjetiva Validação da Métrica Empírico Métricas Descrição Número de métricas Coleção Avaliação da Manutenibilidade Tipo Sujeito Profissional Estudante Restrições Descrição Modelo de Manutenibilidade Nome Descrição

Figura 6 – Matriz da Manutenibilidade Fonte: Ghosheh et al., 2008, p.4 (tradução nossa)

Nome das Características Peso Ponto

Precisão da medição - objetiva 10 10 Precisão da medição - subjetiva 1 0

Taxa da manutenibilidade 5 3

Validação de métrica - empírica - estrutura 1 1 Validação de métrica - empírica - estudo de caso - industrial 5 5 Validação de métrica - empírica - estudo de caso - universitário 3 0 Validação de métrica - empírica - experimento - profissional 2 2 Validação de métrica - empírica - experimento - estudantil 1 0

Métricas - usabilidade 3 0

Pontuação ECMM 21

Quadro 3 – Pontuação ECMM Fonte: Ghosheh et al., 2008, p.3 (tradução nossa)

Em um estudo interessante, com a finalidade de estabelecer a importância relativa dos vários artefatos de documentação que ajudam os mantenedores de software a entender o sistema, Souza et al. (2005b) realizaram duas pesquisas: na primeira, foi perguntado aos mantenedores de software a taxa de importância (sem importância, pouco importante, importante, muito importante) dos artefatos de documentação que os ajudam a entender o sistema; na segunda, foi solicitado aos

mantenedores de software para indicarem que artefatos de documentação usaram para obter o entendimento de um software que eles acabaram de finalizar a manutenção. A primeira pesquisa foi baseada em opiniões subjetivas dos mantenedores, enquanto que a segunda, embora objetiva, foi limitada ao escopo do desempenho de mantenedores específicos em sistemas específicos.

Foram aplicados dois questionários, um para cada pesquisa, sendo que cada questionário foi composto por duas partes. No geral, a primeira parte focalizava na caracterização do sujeito e/ou do sistema a ser mantido, enquanto a segunda parte focalizava no alvo da pesquisa em questão. Foi apresentada, nos questionários, uma lista com 34 artefatos, os quais estavam divididos por atividades de um processo de desenvolvimento típico, discriminados, por cada atividade, em artefatos específicos de análise estruturada, de orientação a objetos ou ambos.

Com os resultados das pesquisas, Souza et al. (2005b) concluíram que o código fonte e os comentários são os artefatos mais importantes para entender um sistema a ser mantido. Modelos de dados e descrição de requisitos são outros artefatos importantes. Surpreendentemente, concluíram que, ao contrário do que se encontra na literatura, modelos arquiteturais e outras visões gerais do sistema não são muito importantes. Isso simplesmente indica que esses artefatos de documentação são usados uma vez para ter um entendimento global do sistema e nunca mais são consultados posteriormente. Esse estudo terá uma atenção especial neste trabalho no que diz respeito às conclusões obtidas em relação aos artefatos que podem impactar na manutenibilidade de um software.

Para Anquetil et al. (2007) criar e manter sistemas de software é uma tarefa intensiva de conhecimento. É necessário ter um bom entendimento do domínio da aplicação, do problema a ser resolvido e de todos os seus requisitos, do processo de software usado, dos detalhes técnicos da linguagem de programação, da arquitetura do sistema e como as diferentes partes se encaixam, como o sistema interage com outros ambientes e outros.

Entretanto, todo esse conhecimento é difícil e caro de se obter. É também difícil de armazenar e geralmente se encontra nas mentes dos engenheiros de software que trabalham num determinado projeto. Como resultado dessa falta de conhecimento (explícito), entre 40% e 60% do esforço gasto na manutenção de

software é voltado para tentar entender o sistema a ser mantido (PIGOSKI, 1996) (PFLEEGER, 2001). Por esse motivo, Anquetil et al. (2007) propuseram as seguintes soluções para esse problema:

Projetaram uma ontologia do conhecimento utilizável pela manutenção de software como framework para suportar outras soluções do gerenciamento do

conhecimento;

Experimentaram a técnica de Análise Post-Mortem (PMA) para ajudar no

levantamento do conhecimento adquirido durante a manutenção e o seu registro. Essa técnica foi aplicada em três momentos, sendo utilizado como base o processo de manutenção da ISO 14764: antes e após a implementação do pedido de modificação e ao final do projeto (conforme processo apresentado na Figura 7). Na Quadro 4 é possível visualizar o tipo de conhecimento focado em cada Análise Post-Mortem aplicada.

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)

Processo de Implemntação Análise do Pedido de Modificação Implementação do Pedido de Modificação Revisão da Manutenção Migração Retirada do Software Análise Design Implementação Teste (1) PMA Post-Análise (2) PMA Post-Implementação (3) PMA Final

PMA Tipo de Conhecimento

(1) Post-Análise

Detalhes sobre o pedido de modificação Estrutura organizacional utilizando o software Opções para implementar a modificação Estimativa de esforço para a modificação

Negociação do tempo necessário para fazer a modificação Documentos modificados

Técnica utilizada de elicitação de requisitos Ferramentas usadas

Domínio de aplicativos Detalhes sobre os requisitos

(2) Post-Implementação

Linguagem de programação e ferramentas usadas Técnicas de programação usadas

Componentes de software modificados Inter-relacionamentos entre os sistemas Inconsistências de análise e design

Oportunidades de re-engenharia detectadas Rastreabilidade dos artefatos

Design da base de dados

Técnicas de testes usadas

Documentação de processo e suporte modificada (3) Final

Negociações com outros departamentos tecnológicos Monitoração da modificação

Processo de manutenção

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)

Anquetil et al. (2007) concluíram que a ontologia projetada pode ser vista como uma referência, listando todos os conceitos necessários à manutenção de software; ou pode ser vista como um esquema de classificação para categorizar pedaços de informações que podem ser obtidos; pode ser usada também como uma descrição comum de manutenção para várias ferramentas, tentando extrair informações (essa última parte não foi explorada pelos autores). Em relação à aplicação da técnica de Análise Post-Mortem, obtiveram como resultados

Identificaram que a capacidade da Análise Post-Mortem em evidenciar lições

aprendidas em projetos de manutenção não foi reduzida e várias melhorias possíveis foram propostas;

Demonstraram a possibilidade de levantar outros tipos de conhecimento, particularmente conhecimentos obtidos na manutenção de sistemas e no domínio da aplicação;

Acreditaram que realmente criaram uma cultura do gerenciamento do conhecimento nas organizações submetidas ao estudo. Isso não era um dos objetivos propostos pelos autores, mas veio como um retorno gratificante. Chen e Huang (2009) acreditam que muitos fatores problemáticos na fase de desenvolvimento de software afetam a manutenibilidade dos sistemas de software entregues. Logo, a compreensão desses fatores problemáticos pode ajudar, não só na redução da incidência de falhas no projeto, mas também a garantir a manutenibilidade do software.

Com isso, realizaram um estudo para explorar a relação entre a melhoria de processo de software, os fatores problemáticos do desenvolvimento de software e a manutenibilidade dos sistemas de software que foram entregues. Para esse estudo, vinte e cinco fatores problemáticos, tais como falta de integridade/consistência, inadequada estimativa de custo e cronograma, dentre outros, foram classificados em cinco dimensões (CHEN; HUANG, 2009, p.983):

• Problemas na qualidade da documentação (DOC);

• Problemas na qualidade da programação (PGM);

• Problemas nos requisitos dos sistemas (SYS);

• Problemas de recursos de pessoas (PER);

• Problemas de gerenciamento de processo (PM).

Em seguida, Chen e Huang (2009) elaboraram um questionário com 25 itens relativos a essas cinco dimensões problemáticas do desenvolvimento de software, o qual foi aplicado através de correio eletrônico a 400 gerentes de projeto e engenheiros de software, dos quais apenas 137 retornaram o questionário respondido por completo, sendo, portanto, realizada uma análise empírica a partir de uma base de dados histórica com 137 projetos de software.

Os objetivos desse estudo foram:

Explorar os padrões nas dimensões problemáticas do desenvolvimento de software em problemas de manutenibilidade baixo, médio e alto;

Determinar como a melhoria de processo de software afeta as dimensões problemáticas no desenvolvimento de software e a manutenibilidade de software associada;

Explorar os 10 fatores problemáticos no desenvolvimento de software de alta gravidade que afetam a manutenibilidade do software.

Os resultados do estudo de Chen e Huang (2009) mostraram que as dimensões DOC (Problemas na qualidade da documentação) e PGM (Problemas na qualidade da programação) são as principais dimensões problemáticas que afetam a manutenibilidade de software, podendo ser consideradas como ‘os problemas da compreensão do software’. Logo, os resultados desse estudo revelaram que lidar com sucesso com essas duas dimensões problemas é um requisito fundamental para alcançar a desejada manutenibilidade de software. Além disso, os resultados também apontaram que a melhoria de processo de software pode afetar positivamente a manutenibilidade de software.

Esse trabalho apresentou uma lista com os 10 fatores problemáticos de alta gravidade no desenvolvimento de software, como mostrado no Quadro 5.

Classificação Fatores problemáticos no desenvolvimento de software Sigla Dimensão

1 Comentários inadequados em código fonte PGM 2 Documentação obscura ou não confiável DOC 3 Mudanças não estão adequadamente documentadas DOC

4 Falta de rastreabilidade DOC

5 Falta de aderência a padrões de programação PGM 6 Falta de integridade / consistência DOC 7 Mudanças constantes nos requisitos dos sistemas SYS 8 Rotatividade freqüente dentro da equipe do projeto PER 9 Uso inapropriado das técnicas de programação PGM 10 Falta de considerações sobre os requisitos de qualidade SYS

Quadro 5 – Os 10 fatores problemáticos de alta gravidade no

desenvolvimento de software Fonte: CHEN; HUANG, 2009, p.990 (tradução nossa)

O estudo de Chen e Huang (2009) forneceu evidências empíricas que os fatores problemáticos na fase de desenvolvimento de software podem afetar negativamente a manutenibilidade. Portanto, os requisitos de manutenibilidade de software devem ser considerados, e os fatores problemáticos associados devem ser tratados de forma adequada no momento de se executar as atividades de projeto, análise e implementação durante a fase de desenvolvimento de software, a fim de alcançar maiores níveis de manutenibilidade.

Esse estudo também forneceu evidências empíricas de que a melhoria de processo de software pode ajudar a reduzir o nível de gravidade da qualidade da documentação e os problemas de gerenciamento de processo, e pode ajudar também a melhorar a manutenibilidade de software para um nível médio. Tal conhecimento pode ajudar gerentes de projeto a desenvolverem uma estratégia de gerenciamento efetivo a fim de atingir níveis mais elevados de desempenho do projeto.

Outros trabalhos interessantes, embora não estejam relacionados diretamente com o assunto manutenibilidade de software e sim com manutenção de software, foram o de Teixeira (2009) e o de Martinelli (2009), que utilizaram técnicas de descoberta de conhecimento em banco de dados.

Teixeira (2009) realizou um estudo onde são aplicadas técnicas de mineração de dados visando à obtenção de métricas fundamentadas para a tarefa de manutenção, a fim de gerar uma forma de prever o tempo para manutenção de software. Com base em dados reais sobre solicitações de manutenção de uma grande empresa de prestação de serviço de informática, a autora construiu alguns modelos para predizer o tempo necessário para uma dada manutenção. Funções de regressão foram ajustadas levando-se em consideração perfis de especialistas e características de manutenção como variáveis independentes e o tempo lançado como variável dependente.

A partir dos resultados alcançados com os modelos desenvolvidos, a autora pode verificar que a dimensão temporal, pelo menos num contexto particular como o de uma empresa de Tecnologia da Informação (TI), pode ser modelada com relativa precisão. Pode também observar que os modelos criados estimam, em geral, um prazo para conclusão da manutenção melhor do que o estimado pelos especialistas. Um achado particular dessa pesquisa foi que, ao se incluir o tempo previsto pelo especialista como variável independente, os resultados mostraram-se mais próximos da realidade. Isto demonstra empiricamente, que estimativas dos especialistas podem funcionar como um viés positivo na predição.

Martinelli (2009) realizou um estudo com o objetivo de identificar parâmetros e elaborar um modelo de predição que permitisse a tomada de decisões sobre manutenções evolutivas de software sem envolver a área de TI da organização. A predição proposta por ele ocorreu em estágio anterior às fases do ciclo de vida de manutenção de software, ainda dentro da concepção da mudança, sem suporte nos modelos pré-existentes de predições – na sua grande maioria apoiados no tamanho da mudança a ser realizada e em fases mais avançadas do ciclo de vida do desenvolvimento.

Esse autor pode concluir que o modelo gerado a partir da mineração de dados mostrou-se válido enquanto modelo preditivo, embora com nível de erro significante. Foi confirmada a relevância de realizar teste de validação de desempenho das técnicas de classificação, onde a validação cruzada mostrou-se efetiva. O resultado da aplicabilidade do modelo, quando comparado com o do especialista, foi parcial, demonstrando significativos resultados sobre alguns

conjuntos de dados, enquanto não alcançou os níveis do especialista em outros conjuntos. Identificou-se baixa acurácia do modelo em mudanças com pequena quantidade de esforço e uma alta acurácia em demandas com quantidade de esforço elevado.