Medição
Como foi dito anteriormente, utilizamos o Sonarqube para ter um feedback sobre a qualidade do nosso código. E conforme os resultados apresentados na subseção anterior, nosso código apresenta um bom percentual de qualidade, visto que está dentro do que esperávamos.
Na analise podemos perceber que possuímos 1 (um) ponto de Code Small, ou seja, nosso código possui um máximo de 4 funções de complexidade alta, que está dentro do que definimos como máximo permitido. Vale ressaltar também que foi detectado um possível Bug, que será sanado realizando uma refatoração em nosso código.
Abaixo segue uma tabela que mostra as métricas de qualidades definidas, e a pontuação para cada sprint.
| Sprint | Bug/Vulnerabilidade | Duplicidade | Code Small |
|---|---|---|---|
| 1 | 8/10 | 5 | 13 |
| 2 | 6/8 | 8 | 9 |
| 3 | 5/7 | 10 | 9 |
| 4 | 3/3 | 7 | 6 |
| 5 | 2/0 | 6 | 4 |
| 6 | 1/0 | 2 | 1 |
Abaixo mostramos o gráfico de burndown, que foi utilizado para medir o progresso que o projeto teve:
(Story Points x Sprints)
Nesse gráfico mostramos como foi a realização de cada uma das sprints. Conforme podemos visualizar, nós acabamos não mensurando de maneira correta a dificuldade do nosso projeto, o que acabou gerando esse aumento na pontuação final e a enorme variação no cumprimento das sprints.
Por sua vez, para medir a qualidade do projeto, utilizamos o gráfico X-bar e R (mostrado nas figuras abaixo). Nesse gráfico mostramos a diferença entre os pontos de histórias de usuários estimados e o pontos que realizamos em cada sprint.
(Story Points x Sprints)
(Story Points x Sprints)
Planilha utilizada para gerar os gráficos disponível em usp=sharinghttps://docs.google.com/spreadsheets/d/16Zc3c2bv9evJqHYSOsbsLJjq8GSN9k7uICo57PV2ar4/edit?usp=sharing