Discussão dos Resultados

O estudo conduzido para avaliar os benefícios do mapeamento entre as perspectivas na identificação do processo de software foi executado de acordo com o processo de aplicação apresentado no Capítulo 6. As seguintes atividades foram executadas: Obter Registros de Execução do Processo Mapeados, Pré-processar Registros de Execução do Processo, Identificar Processo de Software Executado, e Extrair Métricas de Complexidade.

A partir da obtenção dos registros de execução foi possível identificar o processo de software executado. Ao comparar o modelo de processo descoberto a partir dos registros de execução não mapeados (Figuras 23 e 25) e o modelo de processo descoberto a partir dos registros de execução mapeados (Figuras 24 e 26) é possível observar que a representação de elementos do processo nos registros permite uma melhor compreensão da execução dos processos, uma vez que é possível identificar que as atividades do processo estão explícitas.

Quando se considera para análise do modelo de processo descoberto a partir dos registros de execução não mapeados a visão do processo está implícita, uma vez que não se tem o mapeamento entre cada tarefa com a atividade do processo de referência. Outro fator que impacta no entendimento do processo é o uso de termos conhecidos pelos profissionais envolvidos, uma vez que sem considerar o mapeamento, devido à forma como as tarefas são registradas, seria muito difícil compreender a execução sob a ótica das tarefas do projeto. Na base de dados do Projeto 1, por exemplo, as tarefas estão nomeadas da seguinte forma: “Ajustar UC Cadastrar IMP (INF03), Mudanças no Envio de Appointments de Retirada” e “Ajustar validação de Requisitante e Armador” e estão relacionadas à atividade do processo nomeada “Descrever caso de uso”. Nessa situação, sem a aplicação da solução de mapeamento, que torna explícita a informação do processo, não seria trivial identificar a atividade do processo. Sendo assim, uma vez não estando explícitos os elementos do processo nos registros de execução, a análise da execução dos processos seria muito difícil, como pode ser observado ao comparar os modelos descobertos, nas Figuras 23 e 24 extraídos da base de dados do Projeto 1, e nas 25 e 26 extraídos da base de dados do Projeto 2.

Considerando que o ponto de partida para qualquer atividade de Mineração de Processos são os registros de execução, a qualidade do seu resultado depende diretamente da qualidade dos registros (VAN DER AALST et al., 2011). Desta forma, o

mapeamento afetou diretamente a qualidade dos registros de execução, uma vez que tornou os registros gerados mais claros e estruturados, principalmente por permitir que elementos do processo estivessem explícitos.

Uma forma de avaliar o benefício no entendimento dos processos executados, de forma quantitativa, foi por meio das métricas de complexidades extraídas e apresentadas nas Tabelas 15 e 17. As métricas números de atividades e frequência máxima atividade, extraída dos registros de execução não mapeados e mapeados, em ambos os projetos demonstram a redução da complexidade. Nas bases de dados do Projeto 1 e 2 houve a redução do número de atividades. Um baixo valor para esta métrica indica menor complexidade do modelo. A métrica frequência máxima atividade apresentou em ambas as bases um aumento de valor, quando comparados com registros não mapeados e mapeados. Um alto valor para esta métrica indica menor complexidade do modelo. A redução do número de atividades e o aumento da frequência máxima de ocorrência das atividades são métricas que demonstram maior clareza e estruturação. Neste sentido, a representação das atividades do processo de software no plano do projeto e a definição de sua instância impõem uma estruturação através do mapeamento estabelecido.

Em relação às métricas extended cardoso metric, número de arcos e número de locais, em ambas as bases, observou-se a redução dos valores das métricas, ou seja, o comportamento foi o mesmo quando se comparou o modelo descoberto a partir de registros não mapeados e mapeados. Um baixo valor para estas métricas indica menor complexidade do modelo, conforme apresentado na Subseção 6.2.2.

A hipótese definida no planejamento do estudo foi “O mapeamento entre as perspectivas de processo e projeto beneficia a redução da complexidade do modelo de processo de software executado”, e considerando os resultados obtidos dos estudos descritos, pode-se concluir que o mapeamento entre as perspectivas beneficia a redução da complexidade do modelo de processo de software executado, quando se observa os valores das métricas obtidas. Esta redução impacta na análise das atividades do processo que estão sendo executadas.

Neste sentido, o mapeamento possibilita que as atividades do processo possam ser explícitas, possibilitando o entendimento da execução, sob a ótica do processo de software. Considera-se que esse entendimento pode ser útil para apoiar os gerentes de projetos nas tomadas de decisões. Além disso, reconhece-se que outros aspectos quantitativos podem ser explorados. Por exemplo, as frequências de ocorrência das atividades (Tabela 14 e 16), permitem analisar a quantidade de esforço direcionada às atividades. Por exemplo, a base de dados do Projeto 1 tem no total

2238 registros de execução, sendo que 1553 destes estão relacionados a atividade Construir e testar código, como pode ser observado na Tabela 14.

Uma vez demonstrado que o mapeamento beneficia a redução da complexidade do modelo de processo executado, aspectos qualitativos podem ser explorados, tais como, o impacto da redução da complexidade na tomada de decisão ao longo dos projetos. Nós conjecturamos que, quando o mapeamento é aplicado, o modelo de processo obtido possa ser utilizado para prover outras informações úteis para orientar a tomada de decisões sobre oportunidades de melhoria no processo de software descoberto, tais como: (i) para identificar as atividades “guarda-chuvas”, ou seja, aquelas associadas ao controle da qualidade; (ii) atividades que apresentam um alto ou baixo nível de granularidade; (iii) atividades que precisam ser excluídas; e a (iv) relação de dependência entre as atividades.

Por exemplo, atividades com alta frequência de ocorrência podem ser analisadas como candidata a adaptação do processo de software padrão da organização, sendo divididas em atividades mais específicas. Outro exemplo seria explorar as dependências identificadas pelas transições presentes nos modelos de processo descobertos. Estudos qualitativos serão explorados em trabalhos futuros para avaliar essa conjectura.

Esta subseção apresentou a discussão dos resultados do estudo conduzido. A subseção seguinte irá discutir as ameaças à validade.