Machine Translated by Google

Recebido em 18 de junho de 2023, aceito em 26 de julho de 2023, data de publicação em 23 de agosto de 2023, data da versão atual em 28 de agosto de 2023.

Identificador de Objeto Digital 10.1109/ ACCESS.2023.3307310

Aplicando aprendizado de máquina para estimar o

esforço e a duração de tarefas individuais em software
Projetos
ANDRÉ O. SOUSA1, DANIEL T. VELOSO1 , HENRIQUE M. GONÇALVES1 ,
JOÃO PASCOAL FARIA 1,2, (Vogal, IEEE), JOÃO MENDES-MOREIRA 1,2, RICARDO GRAÇA3 , DUARTE
GOMES4 RUI NUNO ,CASTRO3 1Faculdade de , E PEDRO CASTRO HENRIQUES4
Engenharia, Universidade do Porto, 4200-465 Porto, Portugal
2 INESC TEC, 4200-465 Porto, Portugal
3Fraunhofer Portugal AICOS, 4200-135 Porto,
Portugal 4Strongstep, 4100-429
Porto, Portugal Autor correspondente: João Pascoal Faria (jpf@fe.up.pt)

Este trabalho foi apoiado pelo Programa Operacional Regional Norte de Portugal (NORTE 2020), no âmbito do Acordo de Parceria Portugal
2020, através do Fundo Europeu de Desenvolvimento Regional (FEDER) no âmbito do Projeto PROMESSA-NORTE-01-0247-FEDER-039887.

RESUMO A estimativa de software é uma atividade de gerenciamento de projetos vital, porém desafiadora. Vários métodos, desde empíricos
até algorítmicos, foram desenvolvidos para se adequarem a diferentes contextos de desenvolvimento, desde orientados a planos até ágeis.
Recentemente, as técnicas de aprendizado de máquina mostraram potencial neste domínio, mas ainda são pouco exploradas, especialmente
para estimativa de tarefas individuais. Investigamos o uso de técnicas de aprendizado de máquina na previsão do esforço e da duração das
tarefas em projetos de software para avaliar sua aplicabilidade e eficácia em ambientes de produção, identificar os algoritmos de melhor
desempenho e identificar as principais variáveis de entrada (recursos) para previsões. Realizamos experimentos com conjuntos de dados de
diversos tamanhos e estruturas exportados de três ferramentas de gerenciamento de projetos utilizadas por empresas parceiras. Para cada
conjunto de dados, treinamos modelos de regressão para prever o esforço e a duração de tarefas individuais usando oito algoritmos de
aprendizado de máquina. Os modelos foram validados usando validação cruzada k-fold e avaliados com diversas métricas. Algoritmos de
conjunto como Random Forest, Extra Trees Regressor e XGBoost superaram consistentemente os não-ensemble nos três conjuntos de dados.
No entanto, a precisão da estimativa e a importância dos recursos variaram significativamente entre os conjuntos de dados, com uma magnitude
média do erro relativo (MMRE) variando de 0,11 a 9,45 nos conjuntos de dados e nas variáveis de destino. No entanto, mesmo no conjunto de
dados com pior desempenho, as estimativas de esforço agregadas ao nível do projeto mostraram boa precisão, com MMRE = 0,23. Algoritmos
de aprendizado de máquina, especialmente aqueles de conjunto, parecem ser uma opção viável para estimar o esforço e a duração de tarefas
individuais em projetos de software.

No entanto, a qualidade das estimativas e as características relevantes podem depender em grande parte das características dos conjuntos de
dados disponíveis e dos projetos subjacentes. No entanto, mesmo quando a precisão das estimativas individuais é fraca, as estimativas
agregadas ao nível do projeto podem apresentar uma boa precisão devido à compensação de erros.

TERMOS DE INDEXAÇÃO Estimativa de esforço, estimativa de duração, aprendizado de máquina, estimativa de tarefas, projetos de software.

I. INTRODUÇÃO As crucial como base para determinar os custos do projeto e prever datas de
equipes de desenvolvimento de software geralmente dividem seu trabalho em entrega. Isso ajuda a otimizar a alocação de recursos, estabelecer prazos
unidades de trabalho menores, como tarefas ou problemas. Estimar o esforço e realistas e, em última análise, entregar um produto de alta qualidade dentro do
o tempo (duração) necessários para concluí-los é prazo.
No entanto, elaborar essas estimativas durante as fases iniciais de
O editor associado que coordena a revisão deste manuscrito e planejamento, quando são mais valiosas, é um desafio devido às incertezas
quem aprovou para publicação foi Tyson Brooks . inerentes ao desenvolvimento de software.

Este trabalho está licenciado sob uma Licença Creative Commons Atribuição-NãoComercial-SemDerivações 4.0.
VOLUME 11, 2023 Para obter mais informações, consulte https://creativecommons.org/licenses/by-nc-nd/4.0/ 89933
Machine Translated by Google
AO Sousa et al.: Aplicação de ML para estimar o esforço e a duração de tarefas individuais
(como incerteza nos requisitos) e confiança nas experiências anteriores da
equipe. Uma equipe sem experiência suficiente no domínio do negócio, nas
tecnologias envolvidas ou nas técnicas de estimativa provavelmente
produzirá estimativas ruins. Além disso, a estimativa de software pode ser
demorada e sujeita a distorções e variações humanas significativas.
Por esse motivo, vários métodos de estimativa, desde empíricos até
algorítmicos, foram desenvolvidos ao longo dos anos para ajudar
desenvolvedores e gestores na estimativa de software em diferentes
contextos, desde orientados a planos até ágeis. Recentemente, técnicas
baseadas em aprendizado de máquina (ML), particularmente métodos de
conjunto, mostraram potencial para estimativa de software (ver seção II).
Essas técnicas combinam dois ingredientes necessários para qualquer
método de estimativa bem-sucedido: usar dados históricos, para reduzir
vieses, e combinar estimativas múltiplas, para reduzir a variância.
Entretanto, eles ainda são pouco explorados para estimativa de tarefas
individuais, como pretendemos fazer aqui.
Para enfrentar os desafios e limitações mencionados acima,
desenvolvemos três módulos de software, aproveitando algoritmos de ML
para estimar o esforço e o tempo (duração) necessários para lidar com
novas tarefas ou problemas em diferentes ferramentas de gerenciamento
de projetos: SCRAIM da Strongstep, Project Control do Fraunhofer AICOS
e JIRA também utilizado pelo Fraunhofer AICOS. Esses módulos fazem
parte de uma iniciativa maior – PROject Management Intelligent aSSis-tAnt,
ou PROMESSA – que visa facilitar tarefas como priorização de projetos,
alocação de recursos, análise de risco e estimativa de esforço usando
técnicas de ML. Esses módulos oferecem serviços para treinar modelos de
estimativa baseados em dados históricos, extraídos dos repositórios de
ferramentas, e prever o esforço e a duração de novas tarefas ou problemas
usando esses modelos.
Este artigo tem como objetivo apresentar e discutir os resultados obtidos
com os três módulos de software desenvolvidos, bem como comparar e
discutir as diferenças entre eles, visto que o modelo de cada módulo foi
treinado com um conjunto de dados diferente. Ao fazer isso, pretendemos
identificar as características mais relevantes no treinamento de modelos de
ML focados em estimar o esforço e a duração de problemas ou tarefas em
um projeto de desenvolvimento de software. Ao testar os mesmos algoritmos
de ML em três conjuntos de dados diferentes extraídos das ferramentas
mencionadas anteriormente, podemos avaliar se algum algoritmo tem um
desempenho consistentemente melhor, apesar das variações nos dados
de entrada. Por último, as descobertas fornecerão informações sobre o
desempenho dos métodos de estimativa baseados em ML em relação aos
métodos tradicionais.
Mais especificamente, pretendemos abordar as seguintes questões de
pesquisa:
• RQ1: Quais são os algoritmos de ML de melhor desempenho para
estimativa de esforço e duração de tarefas?
• RQ2: Quão eficazes são as técnicas de ML na previsão do esforço e
da duração de tarefas individuais ou questões de
projetos de software em ambientes de produção? • QP3:
Quais são as características que mais influenciam na previsão do
esforço e da duração das tarefas individuais?
As principais contribuições deste estudo são:
89934
• Exploração de ML para estimativa de software em nível de tarefa:
Exploramos algoritmos de ML para prever o esforço e a duração de
tarefas individuais em projetos de software, enquanto a maioria dos
estudos anteriores analisou apenas o projeto como um todo. Isso
contribui para um crescente corpo de literatura sobre aplicações de
ML em engenharia de software. • Avaliação empírica
de algoritmos de ML para estimativa de software em nível de tarefa:
comparamos empiricamente oito algoritmos de ML em três conjuntos
de dados fornecidos por duas empresas usando quatro métricas de
avaliação. Mostramos que algoritmos de conjunto, como Random
Forest, Extra Trees Regressor e XGBoost, superam os não-ensemble
para estimar a duração e o esforço de tarefas individuais. Isso
fornece informações úteis sobre quais algoritmos apresentam melhor
desempenho para esta aplicação específica.
• Informações sobre a precisão das estimativas: mostramos que a
precisão das estimativas dos modelos pode variar significativamente
entre conjuntos de dados, dependendo de fatores como o tamanho
do conjunto de dados e o grau de variância da variável alvo, entre
outros. Mesmo quando a precisão das estimativas individuais é fraca,
mostramos que as estimativas agregadas ao nível do projeto ainda
podem ser precisas devido à compensação de erros.
Isso melhora nossa compreensão de como as especificidades do
projeto e dos dados influenciam a precisão das estimativas das
tarefas e como interpretamos e aplicamos essas
estimativas. • Insights sobre a importância dos recursos: descobrimos
que as variáveis de entrada (recursos) importantes para uma
estimativa precisa das tarefas variam significativamente entre os
conjuntos de dados, possivelmente devido a diferenças no escopo
de gerenciamento de projetos (macro ou micro), tipos de projetos e
práticas de coleta de dados. Isto poderia ajudar os profissionais a
concentrar os esforços de recolha de dados nas variáveis mais
importantes e a informar a concepção de futuros modelos de ML para esta tarefa.
As seções restantes deste artigo estão estruturadas da seguinte forma.
Uma revisão de trabalhos relacionados sobre o uso de ML para estimativa
de software é apresentada na seção II. Na seção III são descritos os
conjuntos de dados utilizados para treinar os modelos e apresentados os
métodos utilizados para pré-processamento e teste.
A Seção IV apresenta os resultados dos algoritmos testados em cada um
dos módulos do software desenvolvido, bem como uma interpretação
desses resultados. Por fim, a seção V apresenta as conclusões extraídas
com base no trabalho desenvolvido e nos resultados obtidos, e aponta
possíveis trabalhos futuros.
II. TRABALHOS
RELACIONADOS Nas últimas duas décadas, extensas pesquisas foram
feitas em termos de aplicação de mineração de dados, algoritmos
estatísticos e de ML para estimativa de software. A Tabela 1 resume as
principais características dos estudos analisados nesta seção.
De acordo com Pospieszny et al. [5], a maioria das pesquisas focou em
estimar o esforço e a duração nas fases iniciais de um projeto, uma vez
que as previsões nessas fases são geralmente mais desafiadoras devido à
incerteza e ao conhecimento limitado, e o fracasso nessas fases iniciais
poderia comprometer o projeto.
sucesso.
VOLUME 11, 2023
Machine Translated by Google
AO Sousa et al.: Aplicação de ML para estimar o esforço e a duração de tarefas individuais
TABELA 1. Resumo dos estudos sobre a utilização de ML para estimativa de esforço e duração em projetos de software.
Usando vários algoritmos de ML, Pospieszny et al. [5] obtiveram
modelos preditivos com desempenho muito bom para estimar o esforço
total e a duração do projeto, em um conjunto de dados fornecido pelo
International Software Benchmarking Standards Group (ISBSG). Após
a limpeza, o conjunto de dados consistia em 1.192 projetos. Usando
Máquinas de Vetores de Suporte (SVM), eles alcançaram pontuações
de Erro Relativo de Magnitude Média (MMRE) de 0,13 e 0,15 e
pontuações PRED(30) de 81,2% e 81,6% nos modelos de esforço e
duração, respectivamente, onde PRED(30) representa o porcentagem
de amostras com Magnitude de Erro Relativo (MRE) ÿ 0,30. Como
entrada, eles usaram 11 variáveis que descrevem as características
gerais do projeto (setor da indústria, tipo de aplicação, tipo de
desenvolvimento, plataforma de desenvolvimento, tipo de linguagem,
personalização de pacotes, tamanho relativo, arquitetura, uso de
métodos ágeis, metodologia usada e nível de recurso). ), incluindo o
tamanho relativo do projeto em pontos de função agrupados em
categorias.
Uma pesquisa extensa e abrangente foi feita por Wen et al. [6],
revisando 84 estudos sobre métodos de ML para estimativa de esforço
de software. De acordo com seus resultados, nas últimas duas
décadas, os pesquisadores concentraram sua atenção principalmente
na adaptação de algoritmos individuais para melhor desempenho,
como Redes Neurais Artificiais (RNA), modelos de Raciocínio Baseado
em Casos (CBR) e Árvores de Decisão (DT).
A partir desta pesquisa, também ficou claro que os modelos ML
tiveram melhor desempenho do que outros modelos tradicionais e
estatísticos, com MMRE variando de 0,35 a 0,55 e PRED(25) de 45 a
75%. Os pesquisadores também observaram que, dependendo do
conjunto de dados e da abordagem de pré-processamento, os
algoritmos de ML podem ter um desempenho muito diferente devido
a valores discrepantes, valores ausentes ou problemas de ajuste
excessivo. Uma atualização recente da pesquisa de Wen et al. foi
publicado por Cabral et al. [24], envolvendo uma revisão de 30 estudos.
Suas descobertas reforçam resultados anteriores e mostram que as
técnicas de aprendizagem em conjunto superaram os modelos individuais.
A discrepância nos resultados e abordagens para a construção de
modelos de ML é ainda mais perceptível quando se analisam estudos
individuais, como o trabalho de Tronto et al. [7], onde a precisão das
abordagens de RNA foi comparada com modelos de regressão múltipla
para estimativa de esforço usando o conjunto de dados COCOMO,
com MMRE e PRED como métricas de avaliação, e tamanho do
produto e vários direcionadores de custo como variáveis independentes.
Outro exemplo é o trabalho de Berlin et al. [8], que
VOLUME 11, 2023
examinaram e compararam a precisão dos modelos RNA e regressão
linear (LR) para previsões de esforço e duração em um conjunto de
dados IBSG e um conjunto de dados israelense, usando tamanho do
produto, produtividade histórica e complexidade do produto
(complexidade funcional) como independentes variáveis. Ambos
concluíram que a RNA superou os demais modelos testados, embora
os resultados sejam diferentes entre eles. Também é importante notar
que na pesquisa de Berlim, foi utilizada uma transformação logarítmica
das variáveis de entrada e saída para melhorar a precisão.
Mais um exemplo dessa discrepância de resultados é o trabalho de
López-Martin [9], que se concentrou em comparar a precisão da
predição entre diferentes tipos de redes neurais na estimativa de
esforço e normalização de variáveis dependentes. Como variável de
entrada, utilizaram os pontos de função ajustados (AFP) de cada
projeto, que mede a complexidade funcional ajustada por diversos
fatores. MAE (erro absoluto médio), MdAE (erro absoluto mediano) e
R2 (coeficiente de determinação) foram utilizados como métricas de
avaliação. Nesta pesquisa, a Rede Neural de Função de Base Radial
(RBFNN) teve melhor desempenho com um alto nível de confiança,
embora, por exemplo, na pesquisa de Pospieszny a MLP-ANN tenha
sido preferida [5].
Rhaman e Islam [10] compararam diferentes tipos de RNA e árvores
de decisão (DTs) usando a raiz do erro quadrático médio (RMSE)
como métrica de avaliação e o tamanho do produto como variável
independente, e concluíram que as DTs foram mais eficazes em
pequenas empresas. conjuntos de dados medianos, enquanto as
RNAs apresentaram melhor precisão em conjuntos de dados maiores.
Outros trabalhos interessantes, como Minku e Yao [11], sobre a
sensibilidade dos métodos de ML ao ruído dentro dos conjuntos de
dados, apoiaram a noção de que os modelos não deveriam depender
de algoritmos individuais, mas sim de um grupo deles, o que deveria
aumentar a precisão da previsão e fortalecer o modelos para lidar com
dados ruidosos e, como resultado, problemas de overfitting. Outras
publicações apoiam esta ideia, como Kocaguneli et al. [12], que
propuseram vários métodos de conjunto, como técnicas de boosting,
bagging e amostragem aleatória complexa. Embora as técnicas de
ensemble possam apresentar vantagens, Azhar et al. [13] afirmaram
que esses métodos podem introduzir sobrecarga substancial de
desempenho se aplicados excessivamente. Com isso em mente, Ho
[14] concluiu que um conjunto de algoritmos diferentes, mas limitados,
e abordagens de conjunto simples, como a média das estimativas
89935
Machine Translated by Google
AO Sousa et al.: Aplicação de ML para estimar o esforço e a duração de tarefas individuais
obtido, deve ser usado para construir modelos de ML para previsão de esforço
e duração.
Outra pesquisa extensa, porém mais genérica, foi feita por Fernández-
Delgado et al. [15], onde foi feita uma revisão de 77 modelos de regressão
populares pertencentes a 19 famílias de algoritmos. Todos eles foram treinados
usando 83 conjuntos de dados diferentes, dividindo os dados em 50% para
treinamento, 25% para ajuste de parâmetros e os últimos 25% para teste. Foi
utilizada uma estratégia inteligente de pré-processamento e validação cruzada,
e MAE, RMSE e R2 foram utilizados para avaliar e comparar as diferentes
famílias de algoritmos. Esta revisão classificou cada algoritmo entre conjuntos
de dados de tamanhos diferentes e concluiu que os algoritmos mais eficazes
para os vários problemas de regressão estavam na seguinte ordem: regras de
regressão cubistas e M5, máquinas de aumento de gradiente (GBM), árvores
extremamente randomizadas, máquinas de vetores de suporte (SVM), Redes
Neurais, Busca de Projeto (PPR) e Vizinhos Mais Próximos. Além disso, um
conjunto de modelos MARS teve um desempenho decente. Também foi
realizada uma comparação de tempo e erro (em termos de memória e erros de
tempo), e a conclusão foi que as regras de regressão e os conjuntos de reforço
eram mais rápidos e menos propensos a erros, enquanto SVMs e Redes
Neurais eram mais propensos a erros e mais lentos.
Apesar do maior número de abordagens adotadas para construir modelos
de ML e prever esforço e duração, recomendações importantes podem ser
extraídas para implementá-los na prática.
Algumas dessas recomendações enfatizam técnicas de pré-processamento,
como exclusão ou imputação de valores, que, dependendo do conjunto de
dados, podem ajudar a lidar com valores discrepantes e valores ausentes [16].
Conforme afirmado por Strike et al. [17], os valores faltantes devem ser
descartados para remover vieses. Para remover valores discrepantes, Ruan et
al. [18] propõem usar a regra comum dos três desvios padrão de uma média.
No entanto, como este método pode ser tendencioso, uma vez que a média
também é afetada por outliers, Leys et al. [19] propuseram, em vez disso, uma
abordagem de desvio absoluto da mediana ou o método interquartil típico para
detectar e remover valores discrepantes. Berlim et al. [8] e López-Martín [9]
também indicam que a transformação logarítmica de esforço e duração tende
a gerar estimativas mais precisas, embora não seja necessária em algoritmos
de ML.
Além das limitações acima e, como afirmado por Pospieszny [5], a aplicação
de métodos de ML a conjuntos de dados pequenos e desatualizados (por
exemplo, COCOMO, NASA), e o facto de estes raramente seguirem as
metodologias de software atuais e abordagens de desenvolvimento modernas,
levaram a resultados inconclusivos. resultados e menos implementações de
algoritmos de ML para estimativa de esforço e duração nas organizações.
Em relação às previsões no nível de tarefas ou problemas individuais,
existem alguns estudos que empregam abordagens de ML [21] e baseadas em
pesquisa [22] para prever o tempo de resolução de problemas ou bugs
recentemente relatados, principalmente durante os estágios de manutenção.
Em [21], os autores alcançam pontuações de exatidão, precisão, recall e F1
superiores a 0,9 na previsão se o tempo de resolução de um bug recém-relatado
estará abaixo ('rápido') ou acima (''lento') da resolução mediana tempo no
conjunto de dados de treinamento.
89936
Eles usaram um conjunto de dados com 8.498 relatórios de bugs extraídos da
instalação do Bugzilla do LiveCode. O tempo de resolução de um bug foi
calculado como o tempo decorrido entre a data em que o relatório de bug foi
atribuído pela primeira vez e a data em que o status do bug foi definido como
'resolvido'. O problema de prever o tempo de resolução de um bug ('lento' ou
'rápido') é formulado como uma tarefa de categorização de texto supervisionada,
baseada na descrição e comentários do bug e em um modelo de linguagem pré-
treinado (BERT). No entanto, eles não tentaram prever o tempo (ou duração)
real da resolução como pretendemos fazer aqui.
Em [22], os autores também tentam prever o tempo de resolução de
problemas recém-relatados, representando solicitações de recursos, relatórios
de bugs, etc. Eles usaram algoritmos genéticos para gerar iterativamente
modelos candidatos e procurar o modelo ideal para estimar o tempo de
resolução de problemas. . Eles usaram um conjunto de dados com 8.260
problemas de cinco grandes projetos de código aberto, calculando o tempo de
resolução de cada problema subtraindo o tempo “resolvido” do tempo “criado”.
Em comparação com linhas de base (baseadas em média e mediana) e técnicas
de última geração (como Random Forest), eles alcançaram valores MAE e
Precisão Padronizada (SA) significativamente melhores. SA avalia a eficácia de
um modelo de estimativa em relação à adivinhação aleatória.
No entanto, eles não calcularam métricas baseadas em erros relativos, como o
MMRE, adequado para comparação entre diferentes conjuntos de dados.
Concluindo, a maioria dos estudos encontrados procura fazer estimativas ao
nível do projeto, e não ao nível das tarefas ou questões individuais, como
fazemos aqui. Além disso, a maioria dos estudos aproveita estimativas de
tamanho ou complexidade como entrada para estimar o esforço e a duração do
projeto, embora não assumamos a existência de qualquer estimativa prévia de
tamanho ou complexidade para ajudar a prever o esforço ou duração da tarefa.
III. DADOS E MÉTODOS
A. CONJUNTOS DE DADOS
Os três conjuntos de dados utilizados neste trabalho foram fornecidos por duas
empresas parceiras do projeto PROMESSA: Strongstep e Fraunhofer AICOS.
As variáveis relevantes selecionadas em cada conjunto de dados (como
características de entrada ou variáveis alvo), bem como outras características
desses conjuntos de dados, estão resumidas na Tabela 2.
1) CONJUNTO DE DADOS
SCRAIM O primeiro conjunto de dados, fornecido pela Strongstep, é um conjunto
de dados relativamente pequeno, composto por 853 amostras úteis (tarefas)
em 27 projetos armazenados no SCRAIM, com as variáveis mais relevantes
indicadas na Tabela 2 .
2) JIRA DATASET O
segundo conjunto de dados, fornecido pelo Fraunhofer AICOS, é
significativamente maior, consistindo em um conjunto inicial de 11.798 amostras
(problemas) em 68 projetos no JIRA, com as variáveis mais relevantes indicadas
na Tabela 2 .
Este conjunto de dados incluía muitas amostras que não puderam ser usadas
para treinar os modelos devido a valores ausentes em variáveis de destino ou
recursos de treinamento importantes. Além disso, os valores discrepantes foram
VOLUME 11, 2023
Machine Translated by Google
AO Sousa et al.: Aplicação de ML para estimar o esforço e a duração de tarefas individuais
TABELA 2. Resumo das variáveis mais relevantes selecionadas para estimativa de esforço e duração e características dos conjuntos de dados.
identificados e, consequentemente, removidos também. Com isso, o número
de amostras utilizadas para os modelos de estimativa de esforço e duração
caiu para 3.435 e 4.094, respectivamente.
3) CONJUNTO DE DADOS DE CONTROLE
DE PROJETOS Por último, o terceiro conjunto de dados, também fornecido
pela Fraunhofer AICOS, consiste em 54.153 amostras (tarefas) em 1.127
projetos, todas alojadas em um banco de dados MySQL integrante do Project
Control - o sistema proprietário da empresa para macrogerenciamento de
P&D&I projetos de software, desde a elaboração e aprovação de propostas até
a execução e relatórios.
No Controle de Projetos, um plano de projeto é essencialmente um gráfico
de Gantt, no qual o projeto é dividido em pacotes de trabalho e tarefas, com
duração planejada (em meses) e datas de início e término (em meses desde o
início do projeto) para cada pacote de trabalho. e tarefa, e alocação planejada
de recursos para cada tarefa (por exemplo, uma pessoa em meio período). Um
plano de projeto pode ter diversas linhas de base ao longo do tempo, em
momentos importantes de (re)planejamento (elaboração da proposta,
replanejamento após aprovação, etc.).
Durante a execução do projeto, os membros da equipe registram sua
alocação de tempo para as tarefas do projeto em planilhas de horas, permitindo
assim calcular o esforço real por tarefa.
As variáveis-alvo para este conjunto de dados são a duração da tarefa (em
meses) e o esforço da tarefa (em pessoas-mês), ou seja, o objetivo é ajudar os
gerentes de projeto a estimar a duração e o esforço da tarefa.
VOLUME 11, 2023
cada tarefa, com base em atributos de tarefa ou atributos derivados de
entidades relacionadas disponíveis no momento do planejamento.
Este conjunto de dados é o nosso maior conjunto de dados; também é
único, pois fornece informações sobre tarefas de macrogestão, proporcionando
uma perspectiva mais ampla sobre o gerenciamento de projetos.
B. MÉTODOS
Os testes foram realizados em oito algoritmos de ML: Random Forest (RF),
Extra Trees Regressor (ETR), Gradient Boosted Trees (GBT), XGBoost, Lasso,
K-Nearest Neighbours (KNN), Support Vector Regression (SVR) e Artificial.
Rede Neural (Perceptron multicamadas, MLP-ANN). Os primeiros quatro são
algoritmos de conjunto.
A justificativa por trás da seleção desses algoritmos é avaliar de forma
independente várias estratégias de modelagem, cada uma com pontos fortes e
fundamentos teóricos distintos. Ao avaliar métodos conjuntos e não conjuntos,
pretendemos compreender as compensações de desempenho em termos de
precisão, robustez, interpretabilidade e complexidade no contexto de dados de
projetos de software. Isto pode ajudar a determinar os algoritmos mais
adequados para prever o esforço e a duração de tarefas individuais em projetos
de software.
Para prosseguir com o pré-processamento dos dados e o ajuste dos
hiperparâmetros, um conjunto de validação com 25% dos dados foi dividido
conforme melhor explicado em cada subseção.
O fluxo de trabalho geral de processamento é ilustrado na Figura 1.
89937
Machine Translated by Google
AO Sousa et al.: Aplicação de ML para estimar o esforço e a duração de tarefas individuais

FIGURA 1. Fluxo de trabalho de processamento seguido para cada combinação de conjunto de dados, variável de destino e algoritmo.

1) PRÉ-PROCESSAMENTO 2 • R - também conhecido como coeficiente de determinação, refere-

DE DADOS Quanto às tarefas de pré-processamento de dados comuns se à proporção de variância na variável alvo que pode ser explicada
a todos os projetos, as variáveis categóricas foram codificadas por meio pelas variáveis independentes utilizadas [2]. Um valor mais elevado
de codificação one-hot. Esta técnica representa cada classe da variável significa que uma proporção igualmente maior da variância acima
categórica através de um novo atributo com valor 0 ou 1, onde 0 indica a mencionada pode ser explicada pelas variáveis independentes.
ausência daquela classe e 1 indica sua presença. Isso foi usado, por
exemplo, nas variáveis Tipo, Status e Prioridade do segundo conjunto de n 2
eu = 1 (Yi - Y eu)
dados. R2=1ÿ n (1)
2
eu = 1 (Yi - Y eu)
O escalonamento de recursos foi usado para dimensionar o intervalo
de valores de variáveis independentes quantitativas, como a variável • Erro Médio Absoluto (MAE) - média da diferença entre os valores
#Participants no primeiro conjunto de dados ou #Sprints e #Links no previstos e os reais. Pode ser usado para verificar a que distância
segundo conjunto de dados. Esta é uma etapa importante no fluxo de as previsões feitas estavam dos resultados reais [3].
trabalho de pré-processamento de dados porque, se o intervalo de valores
n
de um atributo diferir significativamente do intervalo de valores de outro 1
atributo, o primeiro se tornará dominante em modelos que usam medidas MAE = Yi - Sim eu (2)
n
eu=1
de distância, por exemplo, K-vizinhos mais próximos, afetando
negativamente o desempenho preditivo desses modelos. • Root Mean Square Error (RMSE) - esta métrica dá mais peso aos
A tokenização foi aplicada aos campos de texto, nomeadamente à erros com valores absolutos maiores, penalizando a variância no
descrição da tarefa no primeiro conjunto de dados. É usado para conjunto de dados como resultado [4]. Um valor mais baixo de
transformar cada descrição de tarefa em um vetor de contadores de RMSE indica melhores resultados. A maioria dos algoritmos de ML
palavras. O vetor contém uma entrada para cada palavra que ocorre no que usamos (incluindo todos os de conjunto) tentam minimizar o
conjunto de todas as descrições de tarefas no conjunto de dados, RMSE, por padrão.
ignorando palavras irrelevantes e sinais de pontuação. Antes da
n
tokenização, as palavras eram reduzidas à sua forma raiz (stemming). 1
REQM = 2
(Yi - Y eu) (3)
n
eu=1
2) AJUSTE DE HIPERPARÂMETROS
• Magnitude Média do Erro Relativo (MMRE) - medida da diferença
Antes de executar os testes para os diferentes algoritmos, foi realizado
entre os valores reais e os valores previstos, em relação aos
o ajuste de hiperparâmetros com o objetivo de obter o melhor conjunto
valores reais.
de hiperparâmetros para cada algoritmo, conjunto de dados e variável
Um valor mais baixo de MMRE indica melhor desempenho preditivo.
alvo (num total de 48 combinações). Os hiperparâmetros diferem dos
É uma métrica independente de escala, adequada para comparação
parâmetros internos de um algoritmo porque não podem ser aprendidos
entre diferentes conjuntos de dados. Mas também tem sido criticado
a partir dos dados durante a fase de treinamento [1].
devido à sua extrema sensibilidade a previsões individuais com
Esse processo foi realizado no conjunto de validação (contendo uma 1
MREs excessivamente grandes [23].
amostra aleatória de 25% dos dados) com o uso de validação cruzada de
n
5 vezes, pesquisa em grade e RMSE como métrica para otimizar. Como 1 Yi - Sim eu
MMRE = (4)
exemplo, o número ideal de vizinhos obtido para o algoritmo KNN foi 3 n Sim
eu=1
para ambas as variáveis alvo no conjunto de dados do Project Control.
Essas métricas fornecem informações diversas, portanto, a análise de
seus resultados fornece muitos insights sobre a qualidade das previsões
3) AVALIAÇÃO DO MODELO feitas pelos modelos desenvolvidos.

Para avaliar a qualidade dos modelos treinados, foram utilizadas diversas 1No caso de subestimativas, o MRE pode variar de 0 a 1, enquanto
métricas de avaliação: no caso de superestimativas pode variar de 0 a ÿ.

89938 VOLUME 11, 2023

Machine Translated by Google
AO Sousa et al.: Aplicação de ML para estimar o esforço e a duração de tarefas individuais
TABELA 3. Resultados da avaliação do modelo de duração da tarefa SCRAIM
com diferentes algoritmos.
TABELA 4. Resultados da avaliação do modelo de estimativa de esforço SCRAIM
com diferentes algoritmos.
A validação cruzada K-fold com k = 5 foi utilizada durante a fase de
testes para obter os resultados que serão apresentados.
Neste processo, o conjunto de validação (25% das amostras) foi reservado
temporariamente, e os 75% restantes das amostras são utilizados na
instância K-fold. Com k = 5, a instância K-fold irá dividi-los em 5 grupos
diferentes. Então, deixando um grupo diferente para teste, todos os
grupos restantes juntamente com o conjunto de validação são utilizados
para treinamento. Isto é repetido 5 vezes deixando um grupo diferente
dos cinco para teste (processo de validação cruzada).
4. RESULTADOS E DISCUSSÃO A. CONJUNTO DE
DADOS SCRAIM
1) ESTIMATIVA DE DURAÇÃO COM O DATASET SCRAIM O
conjunto de dados SCRAIM foi utilizado para treinar o modelo de duração
da tarefa. Os resultados são apresentados na Tabela 3.
A melhor pontuação R2 (0,37) e melhor pontuação RMSE (3,23) foram
obtidas pelo Random Forest, a melhor pontuação MAE (1,88) foi
alcançada pelo XGBoost e a melhor pontuação MMRE (0,56) foi
alcançada pela Regressão de Vetores de Suporte.
No geral, os algoritmos de conjunto são as melhores opções para este
conjunto de dados específico em relação , Métricas MAE e RMSE.
ao R2. A regressão vetorial de suporte apresenta o melhor MMRE, mas com
um R2 significativamente pior , ,então os algoritmos de conjunto parecem ser
as melhores opções com este conjunto de dados.
2) ESTIMATIVA DE ESFORÇO COM O DATASET SCRAIM O
modelo de estimativa de esforço foi treinado utilizando o conjunto de dados
SCRAIM. A Tabela 4 apresenta os resultados.
As melhores pontuações de R2 (0,51), MAE (2,61) e RMSE (5,29) são
apresentadas pelo algoritmo Random Forest. XGBoost apresenta o
melhor MMRE (0,64).
VOLUME 11, 2023
TABELA 5. Resultados da avaliação do modelo de duração de problemas do
JIRA com diferentes algoritmos.
TABELA 6. Resultados da avaliação do modelo de estimativa de esforço JIRA
com diferentes algoritmos.
No geral, os algoritmos de conjunto tiveram melhor desempenho do que
os outros algoritmos em todas as métricas de avaliação.
B. CONJUNTO DE DADOS JIRA
1) ESTIMATIVA DE DURAÇÃO COM O DATASET JIRA A
Tabela 5 mostra os resultados dos testes realizados para o modelo
de duração do problema treinado com o dataset JIRA.
O algoritmo XGBoost apresenta as melhores pontuações para R2
(0,37), MAE (125,52) e RMSE (162,87). Support Vector Regressions
apresenta a melhor pontuação para MMRE (9,45).
No geral, os algoritmos de conjunto superam as outras métricas algo-
Os ritmos relativos à , MAE e RMSE. Apoiar
regressão vetorial R2 apresentam o melhor MMRE, mas com pontuações
significativamente piores para as restantes métricas, pelo que os
algoritmos ensemble parecem ser as melhores opções com este conjunto de dados.
Não incluímos a descrição do problema nas funcionalidades de
treinamento, pois os resultados de desempenho com seu uso não
melhoraram, para uma maior complexidade de processamento. Utilizando
a descrição do problema, as melhores pontuações para R2 (0,35), MAE
(126,20) e RMSE (165,20) e MMRE (9,45) são piores do que aquelas
obtidas sem o uso da descrição do problema (Tabela 5).
2) ESTIMATIVA DE ESFORÇO COM O DATASET JIRA A
Tabela 6 mostra os resultados dos testes realizados para o modelo de
esforço do problema treinado com o dataset JIRA.
Desta vez, Random Forest apresenta as melhores pontuações para
R2 (0,36) e RMSE (9,23), enquanto sua pontuação MAE ficou atrás
apenas do XGBoost. Mais uma vez, Support Vector Regressions
apresenta a melhor pontuação para MMRE (2,65).
Mais uma vez, os algoritmos de conjunto superam os outros algoritmos
,
em relação às métricas R2 MAE e RMSE.
89939
Machine Translated by Google
AO Sousa et al.: Aplicação de ML para estimar o esforço e a duração de tarefas individuais

A Regressão do Vetor de Suporte apresenta a melhor pontuação no MMRE, TABELA 7. Resultados da avaliação do modelo de duração da tarefa de Controle de
Projeto com diferentes algoritmos.
mas com pontuações significativamente piores para as demais métricas.
Não incluímos a descrição do problema nas funcionalidades de
treinamento, por motivos semelhantes aos apresentados para o modelo de
estimativa de duração. Utilizando a descrição do problema, as melhores
pontuações para R2 (0,26), MAE (5,58) e RMSE (10,82) e MMRE (0,92) nos
modelos de estimativa de esforço, são piores que as melhores pontuações
obtidas sem usar a descrição do problema (Tabela 6 ) . A única exceção é
uma melhoria significativa no MMRE (0,94) com Rede Neural, mas com
pontuações muito piores nas demais métricas.

TABELA 8. Resultados da avaliação do modelo de esforço da tarefa de Controle de

Projeto com diferentes algoritmos.
3) COMPARAÇÃO COM ESTIMATIVAS DOS
DESENVOLVEDORES No conjunto de dados JIRA, as estimativas de
esforço realizadas pelos desenvolvedores também estavam disponíveis para
um subconjunto de amostras (1.371 de 3.435 amostras), além do esforço
real despendido. Assim, também foi realizado um teste para avaliar como
as previsões do modelo se comparam às previsões dos desenvolvedores.
Em relação às estimativas dos desenvolvedores, o MAE para este novo
conjunto de dados é 5,53, pior que o MAE dos modelos de melhor
desempenho na Tabela 6. Para uma comparação mais direta entre as
estimativas dos desenvolvedores e as estimativas baseadas no modelo,
treinamos um novo esforço modelos de estimação baseados no conjunto de
dados menor (com 1.371 amostras). Neste conjunto de dados, todos os
0,11 e PRED(0,3) = 91%, o que pode ser considerado muito bom para
algoritmos de conjunto alcançaram melhores pontuações no MAE (5,06 a
aplicação prática.
5,38) do que os desenvolvedores (5,53).
Dado que os métodos baseados em ML para estimativa de esforço
2) ESTIMATIVA DE ESFORÇO COM O CONTROLE DO PROJETO
consomem menos tempo do que as abordagens tradicionais, nossas CONJUNTO DE DADOS

descobertas destacam os avanços potenciais que essas técnicas oferecem

no campo, especialmente se mais dados de boa qualidade puderem ser
usados para treinar os modelos.
4) COMPARAÇÃO COM LIMIARES DE REFERÊNCIA Mesmo
que as estimativas baseadas em ML sejam melhores do que as estimativas
do desenvolvedor no conjunto de dados JIRA, nenhum algoritmo chega perto
do limite proposto por Jorgeensen e Shepperd [20] , que consideram um
modelo preciso quando MMRE ÿ 0,25, entre outros
critério.
Contudo, é importante notar que tais limiares foram propostos e aplicados
principalmente para estimativas ao nível do projecto, em oposição ao nosso
foco em tarefas ou questões individuais. Na seção IV-E, discutiremos mais
detalhadamente esse assunto.
A Tabela 8 apresenta os resultados dos testes realizados para o modelo de
esforço da tarefa treinado com o conjunto de dados Project Control.
Mais uma vez, todos os algoritmos de conjunto superam consistentemente
os outros algoritmos em todas as métricas.
O Extra Trees Regressor tem melhor desempenho nas métricas MMRE
e PRED(0,3), com MMRE = 0,36 e PRED(0,3) = 80%. Portanto, atende ao
limite de precisão do modelo acima mencionado para PRED(30) e está
próximo de atingir o limite para o MMRE. Portanto, este modelo deve ser
aplicado na prática com cautela. No entanto, espera-se que ocorram
pontuações muito mais baixas no MMRE devido à compensação de erros
quando as estimativas de esforço são agregadas ao nível do projeto (ver
secção IV-E).
D. IMPORTÂNCIA DO RECURSO

C. CONJUNTO DE DADOS DE CONTROLE DO PROJETO

1) ESTIMATIVA DE DURAÇÃO COM O CONTROLE DO PROJETO
CONJUNTO DE DADOS
A Tabela 7 mostra os resultados dos testes realizados para o modelo de
duração da tarefa treinado com o conjunto de dados Project Control.
Todos os algoritmos de conjunto superam consistentemente os demais
algoritmos em todas as métricas, apresentando pontuação igual para R2
(0,96).
Os modelos ensemble também satisfazem os limites de precisão do
Avaliar a importância de vários recursos utilizados no treinamento é crucial.
Ajuda a desvendar se a variação nos resultados das métricas decorre em
grande parte da disparidade nas amostras de dados usadas para treinar os
modelos, dos modelos que atribuem diferentes níveis de importância a vários
recursos ou de uma combinação de ambos. Esta análise ajuda a melhorar a
nossa compreensão do desempenho dos modelos e dos mecanismos
subjacentes.
1) IMPORTÂNCIA DO RECURSO NO CONTROLE DO PROJETO

CONJUNTO DE DADOS
modelo definidos por Jorgeensen e Shepperd [20]: MMRE ÿ 0,25 e PRED(0,3)
ÿ 75%. O modelo Extra Trees Regres-sor tem melhor desempenho nessas A Tabela 9 mostra a classificação de importância do recurso dada por um
métricas, com MMRE = Random Forest Regressor para a variável de destino de duração da tarefa

89940 VOLUME 11, 2023

Machine Translated by Google
AO Sousa et al.: Aplicação de ML para estimar o esforço e a duração de tarefas individuais

TABELA 9. Avaliação da importância do recurso para a variável alvo de duração da TABELA 11. Avaliação da importância do recurso para a variável alvo de duração do
tarefa no conjunto de dados do Project Control (6 principais). problema no conjunto de dados JIRA (6 principais).

TABELA 10. Avaliação da importância do recurso para a variável alvo do esforço

TABELA 12. Avaliação da importância do recurso para a variável alvo do esforço
da tarefa no conjunto de dados do Project Control (6 principais).
do problema no conjunto de dados JIRA (6 principais).

no conjunto de dados de controle de projeto. Não é novidade que as informações de

No geral, apesar de algumas variações na importância relativa, as principais
duração dos nós de nível superior da estrutura do projeto (pacote de trabalho e projeto
características de ambos os modelos não diferem muito. É então provável que a
geral) desempenham um papel fundamental na previsão da duração da tarefa
diferença observada nas suas pontuações R2 seja causada pela
individual, seguida por um atributo específico da tarefa (tipo de tarefa). A abordagem de
tamanho menor do conjunto de dados usado para os testes de esforço do problema em
planejamento de cima para baixo valida o uso desses preditores. Como a duração da
comparação com os testes de duração do problema.
tarefa está vinculada aos tempos do pacote de trabalho e do projeto geral, é lógico que
Com base numa análise mais aprofundada dos conjuntos de dados e em discussões
projetos e pacotes de trabalho mais longos geralmente levem a tarefas mais longas. A
com os seus fornecedores, a importância destas características pode ser explicada da
influência da numeração das tarefas e dos pacotes de trabalho (as próximas variáveis
seguinte forma:
influentes) pode ser explicada por padrões na estruturação do projeto (por exemplo,
tarefas mais longas precedendo as mais curtas). • ID do Cessionário: pode ser atribuído à variabilidade em
ritmo de trabalho entre os indivíduos;
• ID relatada e ID do criador (geralmente idênticas): funcionários de nível superior,

A Tabela 10 mostra a classificação de importância do recurso dada por um Random como proprietários de produtos, podem criar tarefas mais amplas, enquanto

Forest Regressor para a variável alvo do esforço da tarefa no mesmo conjunto de desenvolvedores ou pessoal de controle de qualidade geralmente criam tarefas

dados. A duração da tarefa é a variável mais importante, seguida pela duração do mais curtas; •

pacote de trabalho e pelo número de sequência. Mais uma vez, as variáveis relacionadas #Sprints: questões vinculadas a mais sprints geralmente exigem maior esforço e

com a duração são consideradas as mais importantes. Usar a duração planejada da tempo. Os motivos podem incluir extensão de tarefas, reabertura de problemas,

tarefa para prever o esforço da tarefa é válido devido à abordagem de planejamento etc., necessitando de reestimativa de esforço no início de cada sprint. Esse efeito

seguida (a duração da tarefa é estimada antes do esforço). é esperado, pois nosso conjunto de dados tem como alvo o esforço e a duração
total do problema, e não por sprint; • Status Resolvido: normalmente, problemas

O esforço necessário para uma tarefa (por exemplo, duas pessoas por mês) é o 'Resolvidos' – aqueles resolvidos,

resultado de uma alocação de recursos (por exemplo, uma pessoa em meio período) mas que aguardam testes – registram menos tempo e esforço em comparação com

pela duração da tarefa (por exemplo, quatro meses). Dado o potencial para que as aqueles em estágios subsequentes, como 'Concluído' ou 'Fechado'. Treinar um

alocações de recursos exibam um grau de uniformidade entre as tarefas, a compreensão modelo usando problemas 'Resolvidos' pode ser útil se os desenvolvedores

da duração de uma tarefa e do seu pacote de trabalho correspondente provavelmente quiserem prever o tempo e o esforço necessários até a resolução, em vez do

oferecerá informações valiosas sobre o espectro de valores de esforço considerados encerramento final, que pode depender de outro pessoal; • Tipo Bug: problemas

aceitáveis para a tarefa. do tipo 'Bug' tendem a exigir significativamente menos tempo e esforço para
serem corrigidos do que outros tipos de problemas (por exemplo, 'Novo
recurso').

2) IMPORTÂNCIA DO RECURSO NO CONJUNTO DE DADOS JIRA

A importância do recurso também foi analisada no conjunto de dados JIRA, com o

objetivo de avaliar quais recursos são considerados mais importantes para cada variável
de destino e tentar encontrar recursos que sejam consistentemente importantes nas 3) IMPORTÂNCIA DO RECURSO NO CONJUNTO DE DADOS SCRAIM

duas variáveis de destino. Como a tokenização substitui a descrição da tarefa por um grande número de recursos
As Tabelas 11 e 12 mostram a classificação de importância do recurso dada por um de treinamento (um por palavra), não é prático analisar a importância do recurso da
Random Forest Regressor para as variáveis alvo de duração e esforço, respectivamente. mesma forma que nos conjuntos de dados anteriores.

VOLUME 11, 2023 89941

Machine Translated by Google
AO Sousa et al.: Aplicação de ML para estimar o esforço e a duração de tarefas individuais
TABELA 13. Desempenho do modelo no conjunto de dados SCRAIM dependendo do
uso da descrição da tarefa.
Em vez disso, dois modelos de estimativa foram construídos para cada
variável alvo e algoritmo, um incluindo a descrição da tarefa nas variáveis
de entrada (tokenizadas) e o outro excluindo a descrição da tarefa, e seu
desempenho preditivo foi comparado.
Os resultados de desempenho estão resumidos na Tabela 13. Para cada
métrica e experimento, é mostrado o valor do algoritmo de melhor
desempenho. Os resultados detalhados para os diferentes algoritmos,
utilizando a descrição da tarefa, foram apresentados anteriormente nas
Tabelas 3 e 4.
Os resultados obtidos utilizando a descrição da tarefa nos recursos de
treinamento apresentaram resultados muito melhores. Na verdade, esta
característica é tão importante que sem ela todas as pontuações do R2
foram negativas ou 0 no modelo de estimativa de duração, o que significa
que, sem a descrição da tarefa, nenhum algoritmo consegue explicar a
relação entre as variáveis de entrada e a duração da tarefa.
A eliminação de outros recursos do conjunto de variáveis de entrada levou
a uma menor degradação do desempenho, portanto é possível concluir que
para ambos os modelos SCRAIM (duração da tarefa e estimativa do esforço
da tarefa), o recurso de descrição da tarefa é o mais importante.
E. COMPARAÇÃO COM TRABALHOS RELACIONADOS E EFEITO DE
GRANULARIDADE DA ESTIMAÇÃO
Tal como salientado na secção II, a maioria dos estudos existentes procura
fazer estimativas ao nível do projeto, e não ao nível de tarefas ou questões
individuais, como fazemos neste artigo, pelo que os resultados de
desempenho não são diretamente comparáveis. Além disso, a maioria dos
estudos aproveita estimativas de tamanho ou complexidade como entrada
para o esforço do projeto e estimativa de duração, embora não assumamos
a existência de quaisquer estimativas de tamanho ou complexidade (por
exemplo, pontos de história) para ajudar a prever o esforço. ou duração
exigida por uma tarefa ou problema.
Por exemplo, Pospieszny et al. [5] obtiveram pontuações muito boas no
MMRE (0,13-0,15) e no PRED(30) (81-82%) na previsão do esforço geral e
da duração do projeto em um conjunto de dados do ISBSG com 1.192
projetos. Suas variáveis de entrada incluíam o tamanho relativo do projeto
em pontos de função agrupados em categorias (semelhantes aos tamanhos
de camisetas) – geralmente um importante preditor do esforço e da duração
do projeto. Uma diferença adicional ao nosso trabalho é que eles
transformaram logaritariamente as variáveis-alvo, mas não aplicaram a
transformação reversa ao calcular as métricas de desempenho, o que
possivelmente levou a pontuações excessivamente otimistas, conforme
reconhecido pelos autores.
89942
FIGURA 2. Esforço real versus esforço previsto por problema no conjunto de dados JIRA.
Conforme mencionado na seção II, existem alguns estudos que tentam
prever o tempo de resolução de problemas ou bugs recentemente relatados.
Ardimento e Mele [21] tentam prever se a resolução de um bug será 'lenta'
ou 'rápida', mas não o tempo real de resolução (ou duração) como no nosso
caso. Al-Zubaidi et al. [22] tentam prever o tempo de resolução de problemas
recém-relatados, representando solicitações de recursos, relatórios de bugs,
etc., mas não relatam métricas adequadas para comparação entre diferentes
conjuntos de dados.
Devido à compensação de erros que ocorre quando estimativas
individuais são agregadas (por exemplo, ao somar as estimativas de esforço
de tarefas individuais para chegar a uma estimativa de esforço para todo o
projeto), é lógico que o MRE da estimativa agregada do projeto é menor que
o MRE das estimativas de tarefas individuais, especialmente se as
estimativas individuais forem imparciais e independentes.
Em geral, obter estimativas precisas de esforço e duração ao nível de
tarefas ou questões individuais é muito mais desafiante e muito poucos
trabalhos abordam tais desafios.
Na prática, estimativas de esforço individuais com pouca precisão, mas com
um bom equilíbrio entre estimativas excessivas e subestimadas, podem
levar a estimativas precisas ao nível do projeto – as mais importantes para
assumir compromissos com os clientes.
Esse fenômeno pode ser observado mesmo em nosso conjunto de dados
que apresentou desempenho inferior na estimativa de esforço - o conjunto
de dados JIRA, conforme ilustrado nas Figuras 2 e 3.
A Figura 2 ilustra a correlação entre os valores de esforço reais e aqueles
previstos por um Random Forest Regressor em um conjunto de dados de
teste. Os valores reais apresentam um certo grau de discretização, uma vez
que o registo de tempo é frequentemente realizado em múltiplos de horas.
Por outro lado, cada ponto na Figura 3 representa um projeto único dentro
do conjunto de dados de teste; as coordenadas 'x' e 'y' indicam os valores
cumulativos de esforço real e previsto para o projeto específico,
respectivamente. As diferenças na precisão das estimativas são
impressionantes, seja pela inspeção visual ou pela observação de que o
MMRE cai de 3,94 para 0,23 quando as estimativas do esforço da tarefa são
agregadas ao nível do projeto.
VOLUME 11, 2023
Machine Translated by Google
AO Sousa et al.: Aplicação de ML para estimar o esforço e a duração de tarefas individuais
FIGURA 3. Esforço real versus previsto por projeto no conjunto de dados JIRA.
TABELA 14. Algoritmo de melhor desempenho para cada conjunto de dados e variável de destino.
F. RESPOSTAS ÀS QUESTÕES DE PESQUISA Em
seguida, tentaremos responder às nossas questões iniciais de pesquisa.
RQ1: Quais são os algoritmos de ML de melhor desempenho para
estimativa de esforço e duração de tarefas?
A Tabela 14 mostra o algoritmo de melhor desempenho para cada conjunto
de dados e variável alvo, com base em pontuações normalizadas calculadas da
seguinte forma: (i) para cada experimento e métrica, o algoritmo de melhor
desempenho recebe uma pontuação normalizada de 100; (ii) os algoritmos
restantes recebem pontuações normalizadas em relação a este melhor
desempenho; (iii) finalmente, a pontuação geral de cada algoritmo é calculada
pela média de suas pontuações normalizadas em todas as quatro métricas que
estamos considerando.
Os algoritmos de melhor desempenho são todos baseados em conjuntos –
Random Forest, Extra Trees Regressor e XGBoost. No geral, em todos os
conjuntos de dados e variáveis-alvo, o XGBoost tem o melhor desempenho, com
uma pontuação média normalizada de 92,02, seguido de perto pelos outros
algoritmos baseados em conjunto (com valores entre 88,70 e 92,02), e com uma
pontuação significativa. -cant distância para o algoritmo não-conjunto de melhor
desempenho (Supper Vector Regression, com 72,19).
Nossas descobertas em três conjuntos de dados sugerem que algoritmos
baseados em conjunto, como Random Forest, Extra Trees Regressor e XGBoost,
são a melhor escolha para esforço de tarefa e estimativa de duração.
RQ2: Quão eficazes são as técnicas de ML na previsão do esforço e da
duração de tarefas individuais ou problemas de projetos de software em
ambientes de produção?
VOLUME 11, 2023
TABELA 15. Eficácia do algoritmo de melhor desempenho para cada conjunto de dados e
variável de destino.
A Tabela 15 mostra, para cada conjunto de dados e variável alvo, as
pontuações obtidas pelo algoritmo de melhor desempenho (ver Tabela 14) para
as métricas que são comparáveis entre conjuntos de dados (R2 e MMRE), bem
como o número de amostras em cada conjunto de dados e o número de variáveis
de entrada usadas para treinamento.
No geral, o coeficiente de determinação (R2 ) e a precisão da estimativa,
medida pelo MMRE, variaram significativamente entre os conjuntos de dados,
com os melhores resultados alcançados com o conjunto de dados de Controle do
Projeto.
Tomando como referência os limites propostos por Jorgeensen e Shepperd
[20] para classificar a precisão de um modelo de estimativa (MMRE ÿ 0,25 e
PRED(0,3) ÿ 75%), a precisão da estimativa de nossos modelos pode ser
classificada como boa no terceiro conjunto de dados , ruim no segundo conjunto
de dados e intermediário no primeiro conjunto de dados.
Contudo, é importante notar que estes limiares foram propostos e aplicados
principalmente para estimativas ao nível do projecto, em oposição ao nosso foco
em tarefas ou questões individuais. Na Seção IV-E, demonstramos que mesmo
quando a precisão das estimativas individuais é baixa, as estimativas agregadas
no nível do projeto podem apresentar uma boa precisão devido à compensação
de erros.
Portanto, são necessárias mais pesquisas para determinar as melhores
métricas e limites para avaliar a precisão dos modelos de estimativa de esforço e
duração no nível de tarefas ou problemas individuais em projetos de software.
No que diz respeito às causas da variação de desempenho entre os diferentes
conjuntos de dados, os resultados mostram que ter mais amostras de dados nem
sempre resulta em modelos melhores. Embora os modelos treinados com o
conjunto de dados Project Control (que tinham mais amostras de dados e recursos
de treinamento) tenham tido o melhor desempenho, os modelos treinados com o
conjunto de dados SCRAIM tiveram melhor desempenho do que aqueles treinados
com o conjunto de dados JIRA, apesar de terem menos amostras de dados e
recursos de treinamento.
Portanto, outros fatores, além da quantidade de dados ou do número de
recursos, também desempenham um papel significativo. Por exemplo, o conjunto
de dados JIRA contém problemas de granularidade muito diversa, com esforço
variando de 1 minuto a 240 horas. Se o esforço previsto para uma tarefa de 1
minuto for de 1 hora, seu MRE será 60. Dado que o MMRE é extremamente
sensível a previsões individuais com MRE excessivamente grande, o alto MMRE
resultante deste conjunto de dados de 5,62 não é surpreendente. Por outro lado,
o conjunto de dados SCRAIM cobre uma faixa de esforço mais estreita, de 30
minutos a 147 horas, contribuindo potencialmente para previsões gerais mais
precisas e um MMRE menor. Estas observações sugerem que o grau
89943
Machine Translated by Google
AO Sousa et al.: Aplicação de ML para estimar o esforço e a duração de tarefas individuais
da variância da variável alvo também pode ser um importante fator de influência
na precisão da previsão. Alcançar alta precisão de previsão pode ser um desafio
para variáveis-alvo com maior variância, a menos que possuamos variáveis
altamente preditivas para compensar essa variabilidade.
RQ3: Quais são as características que mais influenciam a previsão
avaliando o esforço e a duração de tarefas individuais?
Nas experiências realizadas, as características mais influentes variaram
amplamente entre os conjuntos de dados, possivelmente devido a diferentes
abordagens subjacentes à gestão de projetos e à recolha de dados.
O conjunto de dados de Controle de Projeto é significativamente diferente dos
outros dois, pois compreende dados de macrogestão produzidos de acordo com
uma abordagem de planejamento top-down, com granularidade de tempo em
meses, enquanto os conjuntos de dados SCRAIM e JIRA compreendem
principalmente dados de microgestão, com granularidade de tempo em horas.
Portanto, é natural que as características mais importantes para estimar o esforço
e a duração das tarefas nos níveis macro e microgestão sejam significativamente
diferentes.
A principal diferença entre os conjuntos de dados SCRAIM e JIRA é a
importância díspar do recurso de descrição da tarefa em conjuntos de dados
diferentes, com uma importância alta no conjunto de dados SCRAIM e uma
importância muito baixa (quase nula) no conjunto de dados JIRA, possivelmente
devido a diferentes tipos de dados. projetos e práticas de coleta de dados nas
respectivas empresas de origem. Em trabalhos futuros pretendemos explorar
outras técnicas, baseadas em modelos de linguagem pré-treinados, para tentar
aproveitar melhor as descrições das tarefas.
G. AMEAÇAS À VALIDADE
A seguir indicamos algumas ameaças à validade que poderiam estar presentes
em nossa pesquisa e as medidas que tomamos para mitigá-las.
1) VALIDADE EXTERNA
Nosso estudo utiliza dados de ferramentas de gerenciamento de projetos utilizadas
por nossos parceiros corporativos. Consequentemente, existe o risco de que os
resultados não se estendam perfeitamente a outros contextos ou indústrias de
desenvolvimento de software. Além disso, as características específicas destes
conjuntos de dados podem influenciar o desempenho dos modelos de ML,
limitando potencialmente a sua eficácia com diversos tipos de dados ou projetos.
Para resolver esta preocupação, analisamos vários conjuntos de dados e
identificamos padrões e variações nos resultados em diferentes conjuntos de
dados.
2) VALIDADE INTERNA Nosso
estudo envolve a aplicação de vários algoritmos de ML e métricas de avaliação,
levantando preocupações de que o ajuste desses algoritmos e a escolha de
métricas possam potencialmente influenciar os resultados. Para mitigar isso,
adotamos práticas recomendadas para ajuste de hiperparâmetros e empregamos
múltiplas métricas de avaliação.
3) REPRODUTIBILIDADE
Neste estudo, utilizamos conjuntos de dados proprietários fornecidos por nossos
parceiros corporativos. Isto pode representar desafios para outros pesquisadores
que pretendam reproduzir os resultados devido ao acesso limitado aos dados.
Reconhecemos esta restrição como uma
89944
consequência inevitável do uso de dados corporativos autênticos.
Embora tenhamos anonimizado certas informações confidenciais, as preocupações
com a privacidade nos impedem de disponibilizar publicamente os conjuntos de
dados.
V. CONCLUSÃO
Com o objetivo de avaliar a aplicabilidade e eficácia de técnicas baseadas em ML
para estimar o esforço e a duração de tarefas ou problemas individuais em
projetos de software, foram desenvolvidos três módulos de software baseados em
ML. Eles fornecem estimativas sobre o esforço e a duração do problema em três
ferramentas de gerenciamento de projetos: SCRAIM, Project Control e JIRA.
Embora os conjuntos de dados utilizados fossem diferentes, a configuração
experimental permaneceu tão igual quanto possível para aumentar a relevância
das comparações e análises realizadas. O mesmo conjunto de algoritmos também
foi testado nos três módulos de software, com a intenção de tentar encontrar
algoritmos que tivessem um desempenho consistentemente bom.
Depois de analisar os resultados dos testes, descobrimos que algoritmos
baseados em conjunto, como Random Forest, Gra-dient Boosted Trees, Extra
Trees Regressor e XGBoost foram consistentemente os algoritmos de melhor
desempenho em todos os conjuntos de dados. Embora a ordem variasse
dependendo da métrica de avaliação e do conjunto de dados, eles sempre
estiveram entre os quatro algoritmos de melhor desempenho em relação à maioria
das métricas de avaliação. Isso correspondeu a alguns dos resultados encontrados
em
a literatura, como a pesquisa de Pospieszny et al. [5], Kogacuneli et al. [12], ou
Fernández-Delgado et al. [15].
Esses resultados mostram que, com o tipo e a quantidade certos de
informações, as abordagens baseadas em ML para a previsão do esforço e da
duração da tarefa são viáveis. Os modelos desenvolvidos foram integrados ao
módulo principal do projeto, tornando-os prontos para serem utilizados pelas três
ferramentas de gerenciamento de projetos mencionadas anteriormente.
Em trabalhos futuros, pretendemos explorar outras técnicas de pré-
processamento de texto, nomeadamente modelos de linguagem pré-treinados como o BERT.
REFERÊNCIAS
[1] J. Wu, X.-Y. Chen, H. Zhang, L.-D. Xiong, H. Lei e S.-H. Deng, ''Otimização de hiperparâmetros
para modelos de aprendizado de máquina baseados em otimização bayesiana'', J. Electron.
Ciência. Tecnologia, vol. 26–40, março de 2019, doi: 10.11989/JEST.1674-862X.80904120.
[2] F. Moksony, ''Small is beautiful: The use and interpreting of R2 in social research'', Szociológiai
Szemle, pp.
[3] S. Bhatia e VK Attri, ''Técnicas de aprendizado de máquina em estimativa de esforço de
software usando conjunto de dados COCOMO'', J. Comput. Ciência. Eng., vol. 1, não. 6,
pp. 101–106, junho de 2015.
[4] T. Chai e RR Draxler, ''Raiz do erro quadrático médio (RMSE) ou erro médio absoluto (MAE)?
—Argumentos contra evitar RMSE na literatura,'' Geoscientific Model Develop., vol . 7,
não. 3, pp. 1247–1250, junho de 2014, doi: 10.5194/GMD-7-1247-2014.
[5] P. Pospieszny, B. Czarnacka-Chrobot e A. Kobylinski, ''Uma abordagem eficaz para esforço
de projeto de software e estimativa de duração com algoritmos de aprendizado de
máquina'', J. Syst. Softw., vol. 137, pp. 184–196, março de 2018.
[6] J. Wen, S. Li, Z. Lin, Y. Hu e C. Huang, '' Revisão sistemática da literatura de modelos de
estimativa de esforço de desenvolvimento de software baseados em aprendizado de
máquina, '' Inf . Suave. Tecnologia, vol. 54, não. 1, pp. 41–59, janeiro de 2012.
[7] IF de Barcelos Tronto, JDS da Silva e N. Sant'Anna, ''Uma investigação de redes neurais
artificiais baseadas em sistemas de previsão em gerenciamento de projetos de software'',
J. Syst. Softw., vol. 81, não. 3, pp. 356–367, março de 2008.
VOLUME 11, 2023
Machine Translated by Google
AO Sousa et al.: Aplicação de ML para estimar o esforço e a duração de tarefas individuais

[8] S. Berlin, T. Raz, C. Glezer e M. Zviran, ''Comparação de estimativa DANIEL T. VELOSO está atualmente buscando o
métodos de custo e duração em projetos de TI,'' Inf. Suave. Tecnologia, vol. 51, licenciatura em engenharia electrotécnica e de computadores
não. 4, pp. 738–748, abril de 2009. pela Faculdade de Engenharia da Universidade do Porto. Seu
[9] C. López-Martín, ''Comparação de precisão preditiva entre redes neurais e regressão estatística interesse de pesquisa inclui inteligência computacional para
para esforço de desenvolvimento de software
resolver problemas do mundo real
projetos,'' Appl. Computação Suave., vol. 27, pp. 434–449, fevereiro de 2015. em vários domínios.
[10] Md. T. Rahman e Md. M. Islam, ''Uma comparação de aprendizado de máquina
algoritmos para estimar esforço em software de tamanhos variados,'' em Proc. IEEE
Região 10 Simp. (TENSYMP), junho de 2019, pp.
[11] LL Minku e X. Yao, ''Conjuntos e localidade: Insights sobre como melhorar a estimativa de esforço
de software'', Inf. Suave. Tecnologia, vol. 55, não. 8,
pp. 1512–1528, agosto de 2013.
[12] E. Kocaguneli, T. Menzies e JW Keung, '' Sobre o valor do conjunto
estimativa de esforço,'' IEEE Trans. Suave. Eng., vol. 38, não. 6, pp.
Novembro de 2012.

[13] D. Azhar, P. Riddle, E. Mendes, N. Mittas e L. Angelis, ''Usando conjuntos para estimativa de
HENRIQUE M. GONÇALVES obteve o M.Sc.
esforço da web'', em Proc. Internacional ACM/ IEEE. Simp. Empírico
Licenciatura em Engenharia Informática e Computação pela
Suave. Eng. Medidas, outubro de 2013, pp.
[14] T. Kam Ho, ''O método de subespaço aleatório para construir florestas de decisão'', IEEE Trans.
Faculdade de Engenharia da Universidade
Padrão Anal. Mach. Intel., vol. 20, não. 8, do Porto, em 2021. Os seus interesses de investigação incluem

pp. 832–844, agosto de 1998. aprendizado de máquina na estimativa de projetos de software

[15] M. Fernández-Delgado, MS Sirsat, E. Cernadas, S. Alawadi, S. Barro, e previsão de entrega.
e M. Febrero-Bande, ''Uma extensa pesquisa experimental de regressão
métodos, '' Neural Netw., vol. 111, pp. 11–34, março de 2019.
[16] J. Huang, Y.-F. Li e M. Xie, ''Uma análise empírica de pré-processamento de dados para estimativa
de custos de software baseada em aprendizado de máquina'', Inf. Suave.
Tecnologia, vol. 67, pp. 108–127, novembro de 2015.
[17] K. Strike, K. El Emam e N. Madhavji, '' Estimativa de custo de software com
dados incompletos,'' IEEE Trans. Suave. Eng., vol. 27, não. 10, pp.
Outubro de 2001.

[18] D. Ruan, G. Chen, E. Kerre e G. Wets, Mineração Inteligente de Dados: Técnicas e Aplicações
(Estudos em Inteligência Computacional), vol. 5. JOÃO PASCOAL FARIA (Membro, IEEE) é actualmente
Berlim, Alemanha: Springer-Verlag, janeiro de 2010.
Professor Associado de Engenharia de Software na Faculdade
[19] C. Leys, C. Ley, O. Klein, P. Bernard e L. Licata, ''Detectando outliers:
de Engenharia da Universidade do Porto, e Investigador Sénior
Não use o desvio padrão em torno da média, use o desvio absoluto em torno da mediana”, J.
com
Experim. Psicologia Social, vol. 49, não. 4,
a Computação e Informação Centradas no Ser Humano
pp. 764–766, julho de 2013.
Centro de Ciência, INESC TEC. Os seus interesses de
[20] M. Jorgensen e M. Shepperd, ''Uma revisão sistemática de estudos de estimativa de custos de
investigação incluem engenharia de software, nomeadamente
desenvolvimento de software'', IEEE Trans. Suave. Eng., vol. 33, não. 1,
pp. 33–53, janeiro de 2007.
melhoria de processos de software, testes de software e

[21] P. Ardimento e C. Mele, ''Usando BERT para prever o tempo de correção de bugs'', em engenharia de software orientada a modelos.

Processo. Conferência IEEE. Evoluindo Adaptar. Intel. Sist. (EAIS), maio de 2020, pp.
[22] WHA Al-Zubaidi, HK Dam, A. Ghose e X. Li, ''Multi-objetivo
abordagem baseada em pesquisa para estimar o tempo de resolução de problemas'', no Proc. 13º Int.
Conf. Software de análise de dados de modelos preditivos. Eng., novembro de 2017, pp.
[23] T. Foss, E. Stensrud, B. Kitchenham e I. Myrtveit, '' Um estudo de simulação
do critério de avaliação do modelo mmre,'' IEEE Trans. Suave. Eng., vol. 29,
não. 11, pp. 985–995, novembro de 2003.
[24] JTHDA Cabral, ALI Oliveira e FQB da Silva, ''Ensemble JOÃO MENDES-MOREIRA é atualmente Professor Associado
estimativa de esforço: uma revisão sistemática atualizada e ampliada da literatura,''
de ciência de dados na Faculdade de Engenharia da

J.Sist. Softw., vol. 195, janeiro de 2023, art. não. 111542. Universidade do Porto e
Pesquisador Sênior com Inteligência Artificial
e Centro de Apoio à Decisão, INESC TEC. Dele
interesses de pesquisa incluem descoberta de conhecimento,
mineração de dados e aprendizado de máquina.

ANDRÉ O. SOUSA obteve o B.Sc. licenciatura em
tecnologia da informação pela Universidade do
Açores, e o M.Sc. licenciatura em engenharia de software pela
Faculdade de Engenharia da Universidade
do Porto, em 2021. Os seus interesses de investigação incluem
abordagens de aprendizado de máquina para melhorar
tarefas no ciclo de vida de desenvolvimento de software, como
como gestão de riscos e estimativa de esforço.
RICARDO GRAÇA recebeu o M.Sc. grau
em engenharia de informática e computação pela
Faculdade de Engenharia da Universidade do Porto,
em 2013. Atualmente é Android e Flutter
Desenvolvedor e Investigador no Fraunhofer Portugal AICOS.

VOLUME 11, 2023 89945

Machine Translated by Google
AO Sousa et al.: Aplicação de ML para estimar o esforço e a duração de tarefas individuais

DUARTE GOMES obteve o M.Sc. grau PEDRO CASTRO HENRIQUES recebeu o

em engenharia de software pela Faculdade de licenciatura em engenharia informática e computação
Engenharia, Universidade do Porto, em 2018. da Faculdade de Engenharia da Universidade de
Atualmente é Gerente de Projetos e Consultor de Porto, em 2005. Foi Cofundador e
Melhoria de Processos de Software na CEO da Strongstep–Inovação em Qualidade de Software,
Strongstep – Inovação em Qualidade de Software. desde 2009, onde lidera diversas consultorias
e projetos de pesquisa e desenvolvimento.

RUI NUNO CASTRO licenciou-se em engenharia

electrotécnica e de computadores pela Faculdade de
Engenharia da Universidade do Porto, em 1996,
e o M.Sc. licenciatura em comunicações digitais
sistemas e tecnologia pela Chalmers University of
Technology, em 1999. Atualmente é
Líder do Grupo de Gestão de Investigação da Fraun-
hofer Portugal AICOS, que se ocupa da gestão de
projetos com financiamento público e está interessado
na aplicação de aprendizado de máquina para projetar
gerenciamento.

89946 VOLUME 11, 2023