Kanunen Kabul Edilmeyen Giderler Uygulamasında Mali Kara

A busca por formas de monitorar e melhorar processos de software não é nova. São encontradas na bibliografia diversas contribuições tratando do assunto. Este capítulo apre- senta os trabalhos vistos como mais relevantes para a pesquisa, envolvendo a exploração de dados de execução de PDS para descoberta de conhecimento sobre processos e tam- bém análise de conformidade.

5.1 Sorumgard [SOR97]

Sorumgard (46) estudou verificação de conformidade na engenharia de software, de maneira experimental. Nesse sentido, as contribuições do trabalho se concentram em qua- tro aspectos principais:

• Definir um modelo de conformidade para a engenharia de software

• Estabelecer um guia para modificação de processos, de forma que ele possa permitir a medição da conformidade em sua execução

• Estabelecer um guia para modificação de processos, de forma que ele possa permitir a medição da conformidade em sua execução

• Testar a proposta por meio de um experimento controlado

Com relação à definição do modelo, é introduzido o conceito de vetor de desvio. Esse vetor serve para representar a conformidade de acordo com determinadas dimensões. Di- mensões são interpretadas aqui como propriedades ou elementos de um processo. O mod- elo de conformidade proposto é definido com base em parâmetros, que pertencem a três categorias: processos, produtos e recursos. Para cada um desses parâmetros são estab- elecidos atributos observáveis. Por exemplo, um processo possui tempo, esforço, número de eventos e custo. Um produto possui uma medida de tamanho e qualidade. Assume-se que, para cada um desses atributos, possam ser definidos valores esperados. Tais medi- das comparadas com as obtidas na execução do processo produzirão um vetor de desvio, conforme ilustrado na figura 5.1. Esse vetor de desvio pode ter um número qualquer de dimensões, dependendo dos atributos observados. A figura 5.1 mostra um possível ve- tor envolvendo as dimensões tempo e qualidade. As variáveis Ci,p e Qi,p representam os

valores esperados (predicted) para as dimensões em questão. Já os valores medidos na execução estão representados por Ci,e e Qi,e. O vetor de desvio expressa então a difer-

ença vetorial entre o processo pressuposto e o realizado. Por exemplo, se o processo é executado exatamente como esperado o vetor de desvio terá valor [0,0].

Figura 5.1: Vetor de desvio que representa a conformidade. Fonte:(46)

O trabalho é bastante consistente, abrangendo vários aspectos de um processo rela- cionados à discrepância entre planejamento e execução. No entanto, é focado na análise da diferença entre medições obtidas sobre cada atributo envolvido no processo. O trabalho assume que, uma vez definidos os atributos necessários para medir a conformidade, ex- istem valores pré-definidos para cada dimensão. Dessa forma o trabalho foca em definir formalismos matemáticos para obter o vetor de desvio que representa a conformidade do processo.

5.2 Huo et al. [HZJ06]

Neste trabalho os autores propõem um método para a descoberta de padrões sobre da- dos de PDS. Tais padrões são expressos em um modelo em rede de Petri que, segundo os autores, pode ser usado para ser comparado com um modelo padrão de desenvolvimento adotado pela empresa. Para descoberta de relações entre atividades, o trabalho propõe uma solução, baseada no algoritmo α (8). Entretanto, o algoritmo proposto em (32) busca superar as limitações existentes naquela solução. Primeiro, o algoritmo α tenta descobrir um modelo completo. Consequentemente, o conjunto de dados precisa ser completo. A solução proposta busca inferir qualquer padrão recorrente identificado nos dados, não ne- cessitando de instâncias do log com todas as atividades executadas. Essa abordagem se aproxima da utilizada por métodos estatísticos (50) (27). Porém, os autores argumentam que tais soluções exigem um grande volume de dados, o que não é uma situação comum em projetos de software. Além disso, os autores salientam a necessidade de garantir a equivalência no nível de abstração entre os padrões obtidos por mineração e o modelo predefinido. No contexto apresentado, as atividades registradas podem estar em menor granularidade do que os elementos do modelo. Para resolver o problema os autores sug- erem o mapeamento manual, feito por pessoas conhecedoras do domínio. Para garantir um mapeamento correto é utilizado o método Kappa, para medir a concordância entre difer-

entes avaliadores. Dessa forma é garantido que o modelo/padrão minerado poderá ser comparado diretamente com o modelo de desenvolvimento predefinido.

Uma restrição identificada neste trabalho, contudo, é relacionada à forma da compara- ção pressuposta. Primeiro, não é considerada a análise de instâncias em separado, já que os padrões inferidos são obtidos de todo o conjunto de dados. Segundo, a comparação se daria apenas de forma visual, sem a produção de nenhuma medida objetiva sobre a con- formidade entre modelo e execução. No entanto, a contribuição é vista como complementar à pesquisa por tratar um problema inclusive já identificado no presente trabalho, que en- volve o mapeamento e seleção correta das atividades na base de métricas para realização da comparação de forma adequada.

5.3 Silva e Travassos [ST04]

Assim como em (46), Silva e Travassos (45) também estudaram a verificação de con- formidade na engenharia de software experimental. Essa área é identificada pelos autores como carente desse tipo de verificação. São citados estudos constatando que normal- mente pessoas não seguem os processos propostos durante a realização de experimentos. O objetivo principal do trabalho trata-se da implementação e avaliação (por meio de ex- perimentos com observação não intrusiva) de uma ferramenta para auxílio na inspeção de artefatos em PDS. A ferramenta é baseada no conceito Perspective Based Reading (PBR) (45) para inspeção. Seus objetivos principais são: i) guiar o executor da inspeção de acordo com a técnica proposta e ii) facilitar a descrição das discrepâncias identificadas. Além disso a ferramenta é capaz de coletar dados sobre a execução da inspeção (tempo total de in- speção, tempo e ordem das tarefas na identificação de discrepâncias, número de consultas a uma ferramenta de ajuda, etc.). Essa funcionalidade serve para monitorar o utilizador da ferramenta de forma não intrusiva, para garantir que a técnica definida na ferramenta foi realmente seguida. Entretanto, o trabalho cita a utilização das métricas em um experimento realizado para avaliar o uso da própria ferramenta. Embora não contendo nenhum dado conclusivo, os autores esperam responder questões como:

• A eficiência dos revisores é maior quando utilizando a ferramenta?

• O uso da ferramenta pode motivar os revisores a seguirem as técnicas propostas? • A ferramenta pode melhorar o entendimento sobre a técnica?

Porém, os autores não descrevem detalhes sobre a forma na qual essas métricas deve- riam ser interpretadas, buscando avaliar conformidade na execução da técnica PBR. O foco do trabalho se restringe a discutir algumas abordagens de monitoração de execução para analisar conformidade, além da implementação da ferramenta.

Tabela 5.1: Comparação entre algoritmos de mineração de processos

Dimensões (46) (45) (32) [CRU10]

Contexto PDS PDS PDS PDS

Objetivo Verificar con- formidade Avaliar ferra- menta/Verificar conformi- dade Inferir padrões recorrentes Verificar con- formidade Dados uti- lizados Formulários preenchi- dos man- ualmente durante um experimento controlado Métricas coletadas por uma ferramenta específica durante um experimento controlado Banco de da- dos de um EPG Base de métricas de software Preparação de dados

Não envolve Não envolve Não definido Discutida em um estudo de caso exploratório

5.4 Considerações sobre o Capítulo

Embora o problema da conformidade em PDS seja bastante citado, os trabalhos encon- trados não discutem detalhes sobre como uma solução para verificação de conformidade poderia ser implementada nesse ambiente. Os trabalhos analisados não tratam objetiva- mente da estrutura, fonte e preparação de dados necessárias para viabilizar a exploração de dados de execução em PDS. Além disso, as contribuições encontradas são pontuais. Pro- cessos de software não são tratados amplamente, sob todas suas perspectivas incluindo: ordem atividades, recursos e artefatos. Com exceção de (32), as outras contribuições as- sumem a avaliação da conformidade do processo pela simples coleta de medidas específi- cas, posteriormente comparadas com valores estimados. No entanto, tanto o fato de apenas coletar métricas, quanto as próprias métricas identificadas nos trabalhos em si, não são vis- tas como suficientes para se ter uma visão consistente sobre a aderência aos processos na engenharia de software. Tendo isso como fator motivador, o presente trabalho busca melhorar o entendimento sobre o assunto, analisando o problema em um ambiente real, que envolve a operação de software da empresa parceira.