Detalhes bibliográficos
Ano de defesa: |
2020 |
Autor(a) principal: |
Freitas, Guilherme Dutra Diniz de |
Orientador(a): |
Kulesza, Uirá |
Banca de defesa: |
Não Informado pela instituição |
Tipo de documento: |
Dissertação
|
Tipo de acesso: |
Acesso aberto |
Idioma: |
por |
Instituição de defesa: |
Universidade Federal do Rio Grande do Norte
|
Programa de Pós-Graduação: |
PROGRAMA DE PÓS-GRADUAÇÃO EM SISTEMAS E COMPUTAÇÃO
|
Departamento: |
Não Informado pela instituição
|
País: |
Brasil
|
Palavras-chave em Português: |
|
Link de acesso: |
https://repositorio.ufrn.br/handle/123456789/31359
|
Resumo: |
A qualidade do software é um atributo essencial para o sucesso de todo projeto de software, sendo uma das principais responsáveis pela competitividade na indústria de software. Integração contínua é uma prática de desenvolvimento de software bastante disseminada na indústria e na literatura por melhorar a qualidade do software. Nesta dissertação, realizamos uma série de estudos para investigar a relação entre integração contínua e métricas de qualidade de código que não foram exploradas por estudos já realizados. Para isso, analisamos se a adoção ou a maturidade de adoção de integração contínua estão relacionadas com melhores métricas de qualidade de código. Como resultado, encontramos que não existem evidências estatísticas que a adoção e a maturidade de integração contínua se relacione com tais métricas de qualidade de código. Por outro lado, descobrimos que a cobertura dos testes é a prática de integração contínua que mais afeta parte das métricas investigadas. A integração de builds com mais frequência não está relacionada a nenhuma das métricas estudadas. Além disso, descobrimos que projetos com builds mais rápidos tendem a ter melhor estruturação entre classes e pacotes, mas tendem a ter maior acoplamento. Também observamos que projetos com correções rápidas de builds tendem a ter menores hierarquias de herança e uma melhor estruturação das classes. Em relação à cobertura de teste, os projetos com maior cobertura de teste tendem a ter uma menor complexidade intrínseca de operações, mas uma estrutura de operação pior se comparada aos projetos com uma menor cobertura de teste. |