Reprodução de uma pesquisa científica

Data Mining Techniques for Software Effort Estimation: A Comparative Study

Link: https://ieeexplore.ieee.org/document/5928350/

==> Relação entre o trabalho de referência e a reprodução

Dataset:

Atributos:

Técnicas de predição:

COnteúdo dos dados

Escolhemos nessa reprodução investigar o esforço de uma funcionalidade do projeto, no artigo original o autor focou no esforço do projeto como um todo. Nossa escolha foi motivada para conseguirmos mais dados para compor o dataset. Com relação aos atributos, a principal diferença foi que o artigo original catalogou o propósito do projeto, achamos mais relevante investigar o domínio. Com relação as técnicas de previsão, no trabalho original foram analisadas 13 técnicas, neste trabalho observamos os resultados de quatro métodos utilizando o software Weka. Por fim, resaltar que nesse trabalho realizamos diversas análises não presente no artigo de referência.

1) Introdução

1.1 Contextualização

Realizar estimativas de esforço nas atividades dos projetos é uma tarefa complexa e desafiadora. Existem diversos métodos publicados na comunidade científica para realizar estimativas, porém a acurácia nestas previsões normalmente são baixas. Os erros em estimativas (normalmente calculados em Mean Relative Error- MRE) são comuns e acabam trazendo impacto no orçamento e cronograma. As Características do time (p.e conhecimento nas tecnologias do projeto, experiência de mercado, capacidade de trabalhar em equipe, etc.) e do projeto (tecnologias/linguagens utilizadas, complexidade da solução, restrições de projeto, volatilidade dos requisitos, etc.) precisam ser analisados cuidadosamente, pois influenciam diretamente no esforço necessário para executar as atividades dos projetos. Esses fatores são conhecidos na literatura como cost drivers.

Neste cenário que essa pesquisa se encaixa. Analisar correlações de cost drivers com o quantitativo de esforço para executar as tarefas dos projetos, bem como verificar correlações destes fatores com o valor dos erros das estimativas.

1.2 Objetivo

1.2.1 Avaliar qual a correlação de diferentes cost drivers no esforço para executar tarefas nos projetos. 1.2.2 Avaliar qual a correlação de diferentes cost drivers no MRE das estimativas de tarefas nos projetos.

1.3 Questões de pesquisa

Com relação a análise sobre esforço, as questões de pesquisa são:

RQ1: Qual a correlação entre a linguagem de programação e o esforço para implementar a tarefa?

RQ2: Qual a correlação entre o tamanho do projeto e o esforço para implementar a tarefa?

RQ3: Qual a correlação entre o tamanho do time e o esforço para implementar a tarefa?

RQ4: Qual a correlação entre a experiência do time e o esforço para implementar a tarefa?

No tocante a análise sobre o MRE, as questões de pesquisa são:

RQ5: Qual a correlação entre a linguagem de programação e os erros de estimativas nos projetos?

RQ6: Qual a correlação entre o tamanho do projeto e os erros de estimativas nos projetos?

RQ7: Qual a correlação entre o tamanho do time e os erros de estimativas nos projetos?

RQ8: Qual a correlação entre a experiência do time e os erros de estimativas nos projetos?

1.4 Método

O primeiro passo da pesquisa foi buscar backlogs de projetos encerrados em empresas de desenvolvimento de software. A fonte desses artefatos foram projetos de laboratórios da Universidade Federal de Campina Grande (UFCG), empresas de desenvolvimento de software de Campina Grande - PB, e por fim projetos diversos no Github.

Em seguida filtrou-se apenas os backlogs de projetos Web, que é o contexto escolhido para essa pesquisa.

O passo seguinte foi categorizar as tarefas desses projetos. Para isso, foi criado um modelo para representar todas as possíveis tarefas de projetos web. Esse trabalho aconteceu em parceria com o grupo Intelligent Software Engineering (ISE) da UFCG. Todos oS backlogs analisados foram mapeados de acordo com esse modelo.

Com todos estes backlogs mapeados, uma categoria foi escolhida para análise nessa pesquisa. Escolheu-se a categoria “Realizar Cadastro (CRUD)” por ser o item que mais se repetiu no mapeamento.

Por fim, montou-se o dataset, onde cada registro representa uma ocorrência da execução do CRUD em um projeto Web. Ao lado de cada ocorrência, outras informações foram preenchidas, no tocante a características das equipes de desenvolvimento e do projeto (cost drivers).

1.5 Organização do relatório

O restante deste relatório está organizado desta forma: no capítulo 02 iremos dar mais detalhes do dataset utilizado na pesquisa. No capítulo 03 cada pergunta de pesquisa referente a esforço será discutida de acordo com as análises realizadas, no capítulo 04 vamos responder as perguntas referentes aos erros de estimativas. No capítulo 05 vamos analisar algumas técnicas de previsão. E finalmente no capítulo 06 explanamos as considerações finais desta pesquisa.

02) Conhecendo nossa base de dados

2.1) Dataset

Os campos do dataset são descritos a seguir:

{r} project : Identificador do Projeto

{r} domain : O Domínio da aplicação (web, mobile, games…)

{r} category : Categoria da atividade de Desenvolvimento de Software

{r} lang : Linguagem de programação

{r} size_project : Tamanho do projeto (numérico)

{r} size_team : Tamanho do time (Numérico)

{r} experience : Somatório dos anos de experiência do time (Numérico)

{r} effort : Esforço para executar a categoria (em horas)

{r} mre : Mean relative error (%)

2.2) Preparando os dados

Algumas informações dos dados coletados para montar o dataset:

{r} project : Foram utilizados informações de 27 backlogs de projetos de software

{r} domain : O Domínio dos projetos analisados é Web

{r} category : A categoria de atividades analisadas foi “Realizar Cadastros (CRUDs)”

{r} lang : Os backlogs analisados diferentem em três tipos de linguagens de programação

{r} size_project : Valor correspondente a quantidade de linhas de código de cada projeto

{r} size_team : Valor correspondente a quantidade de integrantes do time de cada projeto

{r} experience : Valor correspondente ao somatório dos anos de experiência de cada integrante

{r} effort : Valor correspondente a Quantidade de horas registradas para execução da tarefa

{r} mre : Valor calculado do Mean relative error (%)

Como mencionado, foram utilizados 27 backlogs na análise, todos estes de projetos de domínio web ({r} domain == Web). Para montar o dataset escolhemos uma categoria de tarefa: os cadastros ({r} category == CRUD). Ao todo, 121 registros formam nosso dataset. No trabalho original cada registro representa o esforço de um projeto, em nossaa pesquisa diminuimos a granularidade e vamos fazer análises sobre o esforço e MRE de uma funcionalidade específica.

Importanto as bibliotecas

library(tidyverse)
library(here)
library(lubridate)
library(knitr)
library(ggplot2)
library(boot) 
library(resample) 
library(readr)

theme_set(theme_bw())

Carregando os dados para análise

Meusdados = read_csv(here::here("MeusDados.csv")) %>%
head(100000)
Meusdados$mre = as.numeric(Meusdados$mre)

03) Analisando a variável esforço em relação aos cost drivers

Nessa parte do experimento iremos analisar a correlação de variáveis com o esforço (variável == {r} effort)

3.1) RQ1: Qual a correlação entre a linguagem de programação e o esforço para implementar a tarefa?

Hipótese: O esforço para executar determinada tarefa é o mesmo independente de linguagem de programação.

Inicialmente vamos observar a distribuição dos valores de esforço para cada linguagem de programação:

Meusdados %>% 
    ggplot(aes(x = effort, color = lang)) + 
    geom_density()  +
  labs(title="Figura 1 - Distribuição de Densidade por Linguagem ", x="Esforço",  y="Densidade")

Podemos observar na Figura 1 que no intervalo inicial de valores de esforço (0 - 18), a linguagem PHP possui os menores valores de esforço. Outro ponto a observar é que apartir do valor 32, apenas valores para as linguagens JAVA e PYTHON foram catalogadas. Portanto a densidade não é constante no gráfico. Vamos então fazer outra análise, na Figura 2 observar os histogramas de esforço por linguagem.

Meusdados  %>%
  arrange(lang) %>%
  ggplot(aes(x =  effort, fill = lang )) +
  geom_histogram(binwidth = 2)  +
  facet_grid(~ lang) +
  labs(title="Figura 2 - Histograma por linguagem ", x="Esforço",  y="Quantidade")

Com base na Figura 2 não podemos confirmar ou refutar nossa hipótese, pois fica claro que temos quantidades diferentes de ocorrências para cada linguagem em nosso Dataset

Portanto, vamos realizar uma terceira análise, analisar o BoxPlot (Figura 3):

Meusdados %>% 
    ggplot() + 
    geom_boxplot(aes(x = lang, y =effort, color = lang))  +  scale_y_log10() +
  labs(title="Figura 3 - BoxPlot ", x="Linguagem",  y="Esforço")

Detalhando o valor dos quartis para cada linguagem:

with(Meusdados, tapply(effort, lang, summary))
## $JAVA
##    Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
##    6.00    8.00   16.00   18.76   23.00   78.00 
## 
## $PHP
##    Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
##    4.00    7.50    8.00   11.31   15.00   26.00 
## 
## $PYTHON
##    Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
##    6.00    7.00   16.00   16.63   21.00   45.00

Conclusão: Hipótese refutada. Observando os quartis, percebemos que Java e Python tem mesmo valores de mediana (16 horas) e PHP um valor bem abaixo (8 horas). E em relação a média, PHP tem valores de esforço menor (11.31 horas) que as outras lingguagens (Java 18.76 e Python 16.63). Concluimos que o esforço para fazer CRUDs na linguagem PHP é menor, e que Python e Java tem valores de esforço bem próximos.

Discussão: PHP tem diversas ferramentas para geração automática de código o que diminui o esforço.

3.2) RQ2: Qual a correlação entre o tamanho do projeto e o esforço para implementar a tarefa?

Hipótese: Projetos maiores tem uma quantidade maior de esforço para executar as tarefas.

Vamos analisar um gráfico das variáveis relacionadas ao tamanho do projeto e o esforço:

plot(Meusdados$effort~Meusdados$size_project, xlab="Tamanho do Projeto", ylab="Esforço")

Visualmente podemos observar que as duas variáveis não tem correlação, não existe uma concentração de pontos em nenhuma parte do gráfico. Também não existe uma curva linear entre as ocorrências das variáveis. Para uma análise mais precisa, vamos calcular o coeficiente de Pearson e Spearman. Através desses testes podemos calcular a correlação, analisando a direção (se valor positivo ou negativo) e força (valores mais próximos de 1 ou -1).

cor(Meusdados$size_project, Meusdados$effort,  method = "pearson")
## [1] -0.125614
cor(Meusdados$size_project, Meusdados$effort,  method = "spearman")
## [1] -0.005147473

Os coeficientes de pearson e spearman tiveram valores próximos de zero. Podemos concluir que a correlação é fraca.

Conclusão: Hipótese refutada. Não existe correlação entre o tamanho do projeto e o esforço.

Discussão: Acreditava-se que projetos maiores tendem a ter mais complexidade e que isso poderia inferir esforços maiores para implementar as funcionalidades. Porém, isso não foi verificado nas análises. Assim, entende-se que o esforço para implementar um CRUD em um projeto pequeno é similar em um projeto maior.

3.3) RQ3: Qual a correlação entre o tamanho do time e o esforço para implementar a tarefa?

Hipótese: Projetos com equipe maiores tem uma quantidade menor de esforço para executar uma tarefa

Vamos analisar um gráfico das variáveis relacionados ao tamanho da equipe e o esforço:

plot(Meusdados$effort~Meusdados$size_team, xlab="Tamanho do Time", ylab="Esforço")

Visualmente podemos observar que as duas variáveis não tem correlação. Para uma análise mais precisa, vamos calcular o coeficiente de Pearson e Spearman.

cor(Meusdados$size_team, Meusdados$effort,  method = "pearson")
## [1] -0.03991313
cor(Meusdados$size_team, Meusdados$effort,  method = "spearman")
## [1] -0.006123808

Os coeficientes de pearson e spearman tiveram valores próximos de zero. Podemos concluir que a correlação é fraca.

Conclusão: Hipótese refutada. Não existe correlação entre o tamanho do time e o esforço.

Discussão: Acreditava-se que um time maior teria mais colaboração e que isso poderia inferir esforços menores para execução das tarefas do projeto. Porém, outros fatores podem justificar a não correlação dessas variáveis, como a dificuldade de comunicação em times maiores.

3.4) RQ4: Qual a correlação entre a experiência do time e o esforço para implementar a tarefa?

Hipótese: Projetos com equipes mais experientes tem uma quantidade menor de esforço para executar as tarefas do projeto.

Vamos analisar um gráfico das variáveis relacionados a experiência do time e o esforço:

plot(Meusdados$effort~Meusdados$experience, xlab="Experiência do time", ylab="Esforço")

Visualmente fica claro que os maiores valores de esforço concentra-se nas equipes com menos experiência.

Vamos calcular a correlação das variáveis:

cor(Meusdados$experience, Meusdados$effort,  method = "pearson")
## [1] -0.5883064
cor(Meusdados$experience, Meusdados$effort,  method = "spearman")
## [1] -0.5637217

Usando o teste de Pearson e Spearman verificamos valores de coeficientes negativos e altos, interpretamos esse valor como uma correlação negativa e forte.

Conclusão: Hipótese confirmada. Quanto maior é a experiência do time, menor é o esforço.

Discussão: time experiente tem mais conhecimento nas tecnologias do projeto, o que acarreta um esforço menor.

04) Analisando os erros (MRE) das estimativas

No artigo de referência (Table 9 - page 393) foram calculados os valores de erro de estimativas para cada um dos nove datasets. Foi verificado que na maioria dos casos os erros são altos, acima de 25%. E que isso não configura um valor preciso de previsão “the estimate is far from the actual value, e.g., more than 25 percent, the estimate can not be considered “accurate.”

No artigo de referência, cada dataset representa os projetos de uma organização. Em nossa reprodução, vamos verificar a média do MRE para cada um dos 27 projetos que compõe nosso dataset.

tapply(Meusdados$mre,Meusdados$project, mean) 
## APP VIRTUS       GLEC        GQA        GTC   INTRANET        LSW 
##   59.00000   23.80000   29.66667   18.75000   15.00000    4.00000 
##  Monitoria         MP       OPME  ORCAMENTO     PORTAL        PPT 
##   44.75000   33.60000   23.60000   15.50000   26.20000   25.42857 
##        PTU        REC   RECGLOSA        SAM       SCCP        SEC 
##   27.00000   27.50000   14.50000   26.83333   29.00000   27.00000 
##        SHC         SO        STV       SUAP        SUT        TID 
##   48.33333   54.66667    0.00000   83.33333   41.00000   26.80000 
##       TISS     TISS_Z         TQ 
##   26.40000   26.42857   27.50000

Podemos observar que na maioria dos projetos de nosso dataset o valor do MRE também foi superior a 25%.

Agora iremos analisar a correlação de variáveis (cost drivers) com o erro das estimativas (variável == {r} mre)

04.1) RQ5: Qual a correlação entre a linguagem de programação e os erros de estimativas nos projetos?

Hipótese: O valor do erro de estimativas não tem relação com a linguagem de programação do projeto.

Inicialmente vamos observar a distribuição dos valores de MRE para cada linguagem de programação:

Meusdados %>% 
    ggplot(aes(x = mre, color = lang)) + 
    geom_density()

A densidade não é constante no gráfico. Vamos verificar os quartis e observar o gráfico BoxPlot.

Meusdados %>% 
    ggplot() + 
    geom_boxplot(aes(x = lang, y =mre, color = lang))  +  scale_y_log10() 

with(Meusdados, tapply(mre, lang, summary))
## $JAVA
##    Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
##    0.00   20.00   25.00   28.95   35.00   78.00 
## 
## $PHP
##    Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
##    0.00   13.50   25.00   21.09   31.00   40.00 
## 
## $PYTHON
##    Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
##    0.00   15.00   45.00   37.05   52.00   92.00

Conclusão: Hipótese refutada. Observamos na análise que Python tem média de MRE maior que as linguagems JAVA e PHP.

Discussão: Acreditamos que a falta de conhecimento na linguagem Pyhton possa ter influenciado em maiores erros de estimativa. Em pesquisas futuras, pode-se verificar quanto o nível de conhecimento na linguagem (criar uma variável sobre os anos de experiência com a linguagem) pode influir no valor das estimativas.

04.2) RQ6: Qual a correlação entre o tamanho do projeto e os erros de estimativas nos projetos?

Hipótese: Projetos maiores proporcionam erros maiores de estimativas.

Vamos analisar um gráfico das variáveis relacionados ao tamanho do projeto e o MRE:

plot(Meusdados$mre~Meusdados$size_project, xlab="Tamanho do Projeto", ylab="MRE")

Visualmente podemos observar que as duas variáveis não tem correlação, não existe uma concentração de pontos em nenhuma parte do gráfico. Também não existe uma curva linear entre as ocorrências das variáveis. Para uma análise mais precisa, vamos calcular o coeficiente de Pearson e Spearman.

cor(Meusdados$size_project, Meusdados$mre,  method = "pearson")
## [1] 0.09390703
cor(Meusdados$size_project, Meusdados$mre,  method = "spearman")
## [1] 0.04631738

Os coeficientes de pearson e spearman tiveram valores próximos de zero. Podemos concluir que a correlação é fraca.

Conclusão: Hipótese refutada. Não existe correlação entre o tamanho do projeto e a taxa de erros de estimativas.

Discussão: Acreditava-se que projetos maiores tendem a ter mais complexidade e que isso poderia inferir maiores erros nas estimativas. Porém, isso não foi verificado nas análises.

04.3) RQ7: Qual a correlação entre o tamanho do time e os erros de estimativas nos projetos?

Hipótese: Projetos com equipe maiores tem uma quantidade menor de erros em estimativas.

Vamos analisar um gráfico das variáveis relacionados ao tamanho da equipe e o MRE:

plot(Meusdados$mre~Meusdados$size_team, xlab="Tamanho do Time", ylab="MRE")

Visualmente podemos observar que as duas variáveis não tem correlação. Para uma análise mais precisa, vamos calcular o coeficiente de Pearson e Spearman.

cor(Meusdados$size_team, Meusdados$mre,  method = "pearson")
## [1] -0.07288108
cor(Meusdados$size_team, Meusdados$mre,  method = "spearman")
## [1] -0.02456927

Como o coeficiente foi pequeno, podemos concluir que a correlação é fraca.

Conclusão: Hipótese refutada. Não existe correlação entre o tamanho do time e o MRE.

Discussão: Acreditava-se que um time maior teria mais colaboração e que isso poderia inferir menores erros de estimativas. Porém, assim como na questão RQ3, outros fatores podem justificar a não correlação dessas variáveis, como a dificuldade de comunicação em times maiores.

04.4) RQ8: Qual a correlação entre a experiência do time e os erros de estimativas nos projetos?

Hipótese: Projetos com equipes experientes tem uma quantidade menor de erros em estimativas.

Vamos analisar um gráfico das variáveis relacionados a experiência do time e o MRE:

plot(Meusdados$mre~Meusdados$experience, xlab="Experiência do time", ylab="MRE")

Visualmente fica claro que os maiores valores de erros concentra-se nas equipes com menos experiência.

Vamos calcular a correlação das variáveis:

cor(Meusdados$experience, Meusdados$mre,  method = "pearson")
## [1] -0.5650034
cor(Meusdados$experience, Meusdados$mre,  method = "spearman")
## [1] -0.5378762

Usando o teste de Pearson e Spearman verificamos valores de coeficientes negativos e altos, interpretamos esse valor como uma correlação negativa e forte.

Conclusão: Hipótese confirmada. Quanto maior é a experiência do time, menor é o erro de estimativas

Discussão: time experiente tem mais conhecimento prévio e consegue estimar com mais precisão

05) Utilizando as técnicas de previsão

Na tabela 05 do artigo de referência foram apresentados valores de MRE resultado da aplicação de diferentes técnicas em cada um dos 09 Dataset. No artigo de referência, as técnicas Log + OLS, BC + OLS, RiR, M5 obtiveram os melhores desempenhos. No trabalho foram utilizados diversos softwares para calcular as previsões: Weka, Matlab, MARS e LS-SVMlab.

Nesta pesquisa escolhemos usar algumas técnicas do Weka para fazer nossos experimentos. Os resultados estão na tabela a seguir

Técnica Erro
M5 48.06%
RandomTree 5.64%
REpTree 48.69%
MulilayerPerceptron 128.86%

Como podemos observar, das técnicas analisadas nesta pesquisa o RandomTree teve melhor desempenho.

OBS: em todas os experimentos, para avaliar a acurácia das técnicas foi utilizado a opção de teste que o programa utilize o próprio conjunto de dados (opção “Use Trainning set”“)

06) CONCLUSÃO

Foram mapeados 27 projetos de 04 diferentes organizações, ao todo foram encontradas 121 ocorrências da funcionalidade CRUD. Foi verificado neste experimento que projetos em Java tem em média mais esforço para implementar essa funcionalidade e que em Python concentram-se os maiores erros de estimativas. Foi observado também que o tamanho do projeto e/ou o tamanho do time não tem correlação com o esforço de desenvolvimento e o erro nas estimativas. E por fim, foi verificado que projetos com equipes mais experientes implementam a funcionalidade com menor esforço e erram menos ao estimar atividades em projetos de software.

6.1) Ameaças a validade

A proposta dessa pesquisa foi realizar uma reprodução do trabalho “Data Mining Techniques for Software Effort Estimation: A Comparative Study”. A principal ameaça a validade diz respeito ao tamanho do Dataset, em nossa pesquisa consideramos um conjunto de dados muito inferior.

6.2) Discussão

As análises realizadas nessa pesquisa servem para auxiliar no planejamento de projetos de software. Para realizar estimativas mais assertivas faz-se necessário conhecer dados históricos. Porém, como mencionado no artigo referência, opiniões de especialistas são necessárias: “These results also indicate that data mining techniques can make a valuable contribution to the set of software effort estimation techniques, but should not replace expert judgment.” Portanto, os dados dessa pesquisa são importantes, pois trazem indicadores para melhor planejamento dos projetos. Porém, para melhor previsão de esforço, além de analisar dados passados, opiniões de especialistas precisam ser considerados.

6.3) Trabalhos Futuros

Avaliar o comportamento das variáveis analisadas em um contexto diferente, por exemplo em projetos Mobile. Também se faz necessário analisar outras funcionalidades além de CRUD’s. Verificar se nestes outros cenários os resultados dessa pesquisa são uniformes.

Outros cost drivers poderiam ser utilizadas nas análises, como por exemplo o conhecimento do time nas tecnologias do projeto e o tipo de Project Owner (se interno ou externo). Analisar se esses fatores tem correlação com o esforço de desenvolvimento de tarefas e o valor dos erros de estimativas em projetos de desenvolvimento de software.