Skip to content

Métricas de Código Sprint 1

Ronyell Henrique dos Santos edited this page Oct 25, 2017 · 5 revisions

Ao contrário da sprint passada, na sprint 1 houve o acréscimo de novas funcionalidades. Portanto, o acréscimo de novas classes proporcionando um aumento relativamente grande em relação a iteração anterior. Além disso foram observadas algumas pendência técnicas muito relacionadas ao entendimento e complexidade do código fonte. No geral, as métricas ao final dessa sprint se mostraram de forma mais coesa em comparação com as iterações anteriores. Em contrapartida com essa afirmação algumas outras se mostraram com uma leve queda, como a cobertura de código.


Resultados

  • LOC

LOC

O LOC da grande maioria das classes permanece Ótimo, seguindo os parâmetros utilizados. Excetua-se a classe de validação dos campos referentes ao usuário UserValidator que apresenta um LOC considerado BOM, não é necessário nenhum tipo de intervenção pois a métrica indica uma provável facilidade de manutenibilidade do código fonte, mesmo piorando um pouco.

  • AMLOC

AMLOC

A métrica de AMLOC mostrou-se mais coerente ao final dessa sprint. Observa-se, pela tabela acima que classes que estavam sobrecarregadas, com média de muitas linhas por método, foram refatoradas como as classes HealthProfessionalForm e PatientForm, as validações foram transferidas para outras classes.

Assim como as classes HealthProfessionalForm e PatientForm outras classes se encontram em nível REGULAR, não é necessário ações de controle sobre essas classes, todavia é necessário uma atenção para que estas não se tornem muito complexas nas próximas iterações.

  • AMCC

AMCC

A métrica AMCC, assim como a métrica AMLOC, se mostrou mais aceitável. As classes críticas da sprint anterior foram refatoradas, como citado acima, as validações foram transferidas das classes de formulários para classes de validação.

A classe HealthProfessionalForm caiu de TRINTA para UM de AMLOC, representando maior manutenibilidade em relação a iteração passada, de forma semelhante as duas outras classes cŕiticas PatientForm e UpdateUserForm se mostraram também mais manuteníveis nesse quesito. Como foi transferido a responsabilidade de validação para classes de validação,estas se encontram com valores mais altos de Complexidade ciclomática, no entanto bem mais aceitáveis que as classes vistas na sprint precedente. Não necessitando de intervenções, apenas um acompanhamento.

  • CD

CD

Essa métrica se mostrou mais aceitável em relação as sprints passadas. Foi inserido em algumas das classes do tipo docstring que documentam melhor o código fonte. Tal como a iteração passada vale ressaltar a que algumas dessas classes são muito pequenas e os integrantes do grupo julgaram não necessitar de comentários.

  • NLM

NLM

As classes continuam com um número ótimo de métodos. Verifica-se uma alta coesão e provavelmente uma alta granularidade das classes e, provavelmente, um relevante índice de manutenibilidade do código fonte.

  • Duplicação de código

CR2

CR2

CR2

  • Cobertura

CR1

CR3

Grupo 2

logo

Release II

Equipe

Sprints

Sprint 0

Sprint 1

Sprint 2

Sprint 3

Sprint 4

Sprint 5

Sprint 6

Sprint 7

Sprint 8

Release I

Gerência do Projeto














Desenvolvimento de Software

Clone this wiki locally