Coleta I
Na release 1, em detrimento da metodologia só foram coletados as métricas em relação ao Objetivo 02 (Código Fonte) do plano de qualidade pelo motivo de que as métricas do Objetivo 01 (Equipe do Projeto Receituário Médico (GPP/MDS)) são feitas através de artefatos que serão coletados apenas no desenvolvimento ágil.
- LOC
A quantidade de linhas por classe, em detrimento da pouca complexidade das funcionalidades até então, não há problemas e todas estão no nível ÓTIMO que nos diz que as classes estão com poucas responsabilidades. Conforme o software for crescendo é preciso ter mais atenção nessa métrica.
- AMLOC
Quanto mais atómico um método, mais fácil será fazer manutenção e testas os mesmos. Quando se encontram métodos em que o nível seja considerado Regular ou Preocupante a ação a ser tomada conforme o plano de qualidade é refatorar os métodos da classe em questão, dividindo-o em funções atômicas para que eles se tornem mais manuteníveis.
Entretanto, ao se analisar as classes UserForm, PatienteForm e UpdateUserForm pode-se perceber que a quantidade de linha dessas classes crescem conforme a quantidade de dados que serão utilizadas para se cadastrar o usuário ou paciênte crescem. Mas ainda dá para se enxergar alguns pontos passíveis de refatoração.
- AMCC
Complexidade ciclomática é o número de caminhos independentes que um software pode seguir em sua execução, logo quanto menos caminhos independentes mais manutenível é o software.
Como pode ser visto na tabela acima, a maior parte das classes está em um nível EXCELENTE, entretanto temos mais uma vez as classes UserForm, PatienteForm e UpdateUserForm em um nível preocupante. Como já dito na análise da métrica AMLOC estas classes devem ser refatoradas, refatorando os métodos responsáveis por essa complexidade, na tentativa de o dividir em outros métodos, dando menos responsabilidade e evitando o uso de grandes estruturas de decisão.
- CD
O código também é um documento do projeto, portanto, deve ser legível. Considerando que a linguagem é de tipagem dinâmica os comentários são muito importantes para o entendimento do mesmo.
Mais uma vez, em detrimento da falta de experiência da equipe de desenvolvimento (MDS), a quantidade de comentários foi extremamente preocupante em boa parte das classes. Conforme especificado no plano de qualidade cabe-se definir para a Release 2 uma política de aceitação de das funcionalidades apenas quando o mesmo estiver bem documentado, ou seja, com uma quantidade satisfatório de comentários por clase.
- NLM
Ao se coletar a métrica de número de métodos por classe, pode-se ver que todas as classes tem um resultado ÓTIMO, assim como indicado na métrica LOC elas estão tendo uma responsabilidade única conforme o desejado.
- Duplicação de código
Para a ferramenta utilizada (CodeClimate) um código é duplicado quando a massa é maior ou igual 32, ela é calculada pela arvore sintática que vai vendo se existe ou não similaridade.
Existem dois tipos de código duplicado, os idênticos e o similares(mesma estrutura, mas o conteúdo em si é diferente).
Durante o desenvolvimento inicial de sistemas por equipes menos experiêntes é muito comum haver duplicação de códigos, como pode ser visto nas fíguras acima. Foram encontradas QUATRO ocorrências de duplicação de código sendo que duas delas estão em uma classe já considerada problemática em relação as métricas AMLOC e AMCC, ou seja, pode-se melhorar tanto a métrica de AMLOC quanto a métrica de CD refatorando a classe UserForm.
A providência a ser tomada é modularizar classes em que se encontram essas duplicidades, ou seja, deve-se deve-se refatorar o código fonte seguindo o princípio Do not Repeat Yourself (DRY), conforme especificado no plano de qualidade.
- Cobertura
Durante o desenvolvimento dos casos de uso na primeira iteração de desenvolvimento, em função da falta de conhecimento do time de desenvolvimento (MDS), não foram cobrados que os mesmos fizessem testes automatizados para a aplicação. Em função disso a cobertura do código está em 0%, que é considerado uma situação MUITO CRÍTICA quando se trata do desenvolvimento de um software.
Entretanto, esta foi uma situação planejada no começo da iteração, pois após a iteração de desenvolvimento dos casos de uso, haverá uma refatoração do código e teste dos mesmo, previdência esta definida no plano de qualidade, com o auxilio da equipe de GPP antes da entrega da Release 1 e serão coletadas as métricas novamente após esta refatoração.
