A fase de preparação dos dados consiste em uma série de atividades destinadas a obter um conjunto final de dados, a partir do qual, será criado e validado o modelo. Nesta fase são utilizados programas de extração, limpeza e transformação dos dados. Possui como tarefas: selecionar dados, limpeza dos dados, construção dos dados, integrar dados e formatar dados.
Por isso, foram extraídos da base de informações todos os projetos de software de manutenção evolutiva e de manutenção corretiva de pequeno porte, dos sistemas pré-selecionados anteriormente, que foram concluídos no período de 2008
a 2009. Entretanto, devido a um retorno pequeno de projetos que atendiam aos pré- requisitos desejados, esse período foi estendido de 2006 a maio de 2010 com a pretensão de aumentar o número de projetos qualificados para a pesquisa.
Embora o período para extração de dados da base de informações tenha sido estendido para 2006 a maio de 2010, o número de projetos de software de manutenção evolutiva e de manutenção corretiva de pequeno porte do projeto (podendo ter duração superior a seis semanas), dos sistemas pré-selecionados anteriormente, que foram concluídos, foi muito aquém do desejado. Por esse motivo, foram incluídos nesta pesquisa todos os projetos de software de manutenção evolutiva e de manutenção corretiva que atenderam aos pré-requisitos estabelecidos, independente do porte. Mesmo assim, o número de projetos por tecnologia (linguagem de programação e banco de dados) ainda foi pequeno.
Em seguida, buscou-se acesso ao repositório de cada um desses sistemas para acesso direto à documentação, ao código fonte e a outros artefatos mantidos. Esse acesso era necessário para verificar até que ponto uma determinada propriedade de software que beneficia a sua manutenibilidade está ou não presente no sistema em avaliação. Entretanto, devido a restrições de acesso na grande maioria desses repositórios, por conter dados sigilosos a outros que não trabalham diretamente com aquele sistema em questão, não foi possível acessá-los, mas as informações necessárias, de alguns deles, foram repassadas diretamente por membros da equipe do sistema em avaliação, possibilitando a continuidade desta pesquisa.
Paralelamente, os dados extraídos da base de informações foram formatados e “limpos”, de forma a serem utilizados pela ferramenta WEKA, sendo realizados os seguintes ajustes nos dados:
- Foram desconsiderados os projetos que possuíam o campo Ponto de Função Realizado com valor não inteiro ou nulo;
- Foram desconsiderados os projetos que possuíam o campo Esforço Realizado com valor nulo.
Além disso, foi definida uma classificação (conforme Quadro 6), a fim de apurar, para cada projeto dos sistemas qualificados, os valores para cada uma das principais propriedades de software identificadas até então na literatura que possivelmente beneficiam a sua manutenibilidade, com base no processo padrão utilizado pela organização pesquisada e no retorno obtido da aplicação de um questionário a especialistas no assunto (descrito no Apêndice B – Matriz de priorização).
A propriedade de software padrões de design não foi tratada nesta
classificação, uma vez que foi identificada uma grande dificuldade para se conseguir avaliar essa propriedade nos projetos de software da organização alvo, por não estar registrada em nenhum local, requerendo ou o exame do código fonte e da arquitetura ou acesso ao arquiteto do produto para responder a essa questão.
Propriedade de Software Classificação Definida
Documentação de Requisitos
OT – Ótima: possui todos os artefatos de requisitos definidos na matriz de priorização (conforme apresentado na Tabela 12).
BO – Boa: possui maioria dos artefatos de requisitos considerados mais importantes por especialistas na matriz de priorização (conforme apresentado na Tabela 12).
RU – Ruim: não possui maioria dos artefatos de requisitos considerados mais importantes por especialistas na matriz de priorização (conforme apresentado na Tabela 12).
IN – Inexistente.
Arquitetura
OT – Ótima: possui separação de interesses, estrutura modular, alta coesão modular, fraco acoplamento e uma documentação de arquitetura de software.
BO – Boa: possui separação de interesses, estrutura modular, média coesão modular e fraco acoplamento.
RU – Ruim: não possui separação de interesses, nem estrutura modular, possui baixa coesão modular e forte acoplamento.
Documentação de Análise e Projeto
OT – Ótima: possui todos os artefatos de análise e projeto definidos na matriz de priorização (conforme apresentado na Tabela 12). BO – Boa: possui maioria dos artefatos de análise e projeto considerados mais importantes por especialistas na matriz de priorização (conforme apresentado na Tabela 12).
RU – Ruim: não possui maioria dos artefatos de análise e projeto considerados mais importantes por especialistas na matriz de priorização (conforme apresentado na Tabela 12).
IN – Inexistente.
Rastreabilidade
OT- Ótima: rastreabilidade definida dos artefatos (produtos de trabalho) de requisitos ao código fonte.
BO – Boa: rastreabilidade definida somente entre os artefatos (produtos de trabalho) de requisitos.
RU – Ruim: rastreabilidade definida manualmente (sem apoio de uma ferramenta).
IN- Inexistente.
Qualidade da Modelagem dos Dados – BD Relacional
OT - Ótima: padronizada (regras para nome de variáveis, criação de chaves, outras), existência de dicionário de dados, normalizada e possui maioria dos artefatos de BD Relacional considerados mais importantes por especialistas na matriz de priorização (conforme apresentado na Tabela 12).
BO - Boa: normalizada e existência de dicionário de dados. RU - Ruim: desnormalizada e inexistência de dicionário de dados.
Qualidade da Modelagem dos Dados – BD
Hierárquico
OT - Ótima: uso do PREDICT. BO - Boa: uso do SYSDDM.
RU - Ruim: não usa nem o PREDICT nem o SYSDDM.
Padronização Definida para a Implementação de Código Fonte EX - Existente. NE - Não existe. Comentários em Código Fonte
OT - Ótimo: comentário explanatório em trechos complexos do código fonte.
BO - Bom: comentário geral no início de todos os códigos fontes relacionados ao projeto.
RU - Ruim: comentário geral no início de um ou outro código fonte relacionado ao projeto.
IN - Inexistente.
Testes de Regressão Automatizados
OT - Ótimo: os testes envolviam todos os casos de uso mais significativos de um projeto.
BO - Bom: os testes envolviam a maioria dos casos de uso mais significativos de um projeto.
RU - Ruim: os testes envolviam a minoria dos casos de uso mais significativos de um projeto. IN - Inexistente. Controle de Configuração de Software EX - Existente. NE - Não existe. Processo Padrão da Organização UT - Utiliza. UP - Utiliza parcialmente. NU - Não utiliza.
Quadro 6 – Classificação das propriedades de software que podem beneficiar a sua manutenibilidade