Resultado da Melhoria 1
Esta página tem por objetivo armazenar as métricas de melhoria de processo para a primeira melhoria proposta, que podem ser encontradas neste link, bem como analisar se os benefícios esperados com as mudanças foram realmente alcançados.
Vale ressaltar que algumas das métricas de melhoria definidas não foram coletadas para essa Sprint, devido a impossibilidade de fazê-lo, levando em conta que a Sprint já havia começado e terminado algum tempo antes destas métricas estarem definidas de fato.
- Percentual de código testado
O percentual de código testado foi obtido da análise a partir da ferramenta incluída na integração contínua, o coveralls.
A cobertura de testes no Repositório do APP é de 38% na branch develop.
A cobertura de testes no Repositório da API é de 86.832% na branch develop.
- Número de erros referentes a folha de estilo proposta
O número de erros foi obtido através da análise realizada pela ferramenta eslint incluída na integração contínua.
O número de erros encontrados pelo eslint no Repositório do APP foi 0.
Não há folha de estilo configurada na integração contínua do Repositório da API.
- Percentual de código testado
O percentual de código testado foi obtido da análise a partir da ferramenta incluída na integração contínua, o coveralls.
A cobertura de testes no Repositório do APP é de 23.96% na branch develop.
A cobertura de testes no Repositório da API é de 87.405% na branch develop.
- Número de erros referentes a folha de estilo proposta
O número de erros foi obtido através da análise realizada pela ferramenta eslint incluída na integração contínua.
O número de erros encontrados pelo eslint no Repositório do APP foi 0.
Não há folha de estilo configurada na integração contínua do Repositório da API.
A complexidade ciclomática foi obtida através da análise na ferramenta Sonar.
No Repositório do APP a ferramenta reportou uma complexidade ciclomática de 180, dividida em 141 métodos, caracterizando uma complexidade de 1.27 por método.
No Repositório da API, a ferramenta reportou uma complexidade ciclomática de 149, dividida em 94 métodos, caracterizando uma complexidade de 1.58 por método.
A complexidade ciclomática foi obtida através da análise na ferramenta Sonar.
No Repositório do APP a ferramenta reportou uma complexidade ciclomática de 244, dividida em 186 métodos, caracterizando uma complexidade de 1.31 por método.
No Repositório da API, a ferramenta reportou uma complexidade ciclomática de 165, dividida em 102 métodos, caracterizando uma complexidade de 1.61 por método.
A porcentagem de duplicação de código foi obtida através da análise realizada pela ferramenta sonar.
No Repositório do APP, não foram encontrados blocos de código duplicado segundo a análise da ferramenta sonar.
No Repositório da API, também não foram encontrados blocos de código duplicado.
A porcentagem de duplicação de código foi obtida através da análise realizada pela ferramenta sonar.
No Repositório do APP, não foram encontrados blocos de código duplicado segundo a análise da ferramenta sonar.
No Repositório da API, também não foram encontrados blocos de código duplicado.
| Data | Auditoria | Resultado | Não conformidade |
|---|---|---|---|
| 23/05/2018 | Teste de Software | Resultado | Não |
| 21/05/2018 | Backlog da Release 2 Refinado | Resultado | Sim |
| 22/05/2018 | Plano de medição ciclo 02 | Resultado | Não |
| 24/05/2018 | Subprocesso de Desenvolvimento | Resultado | Não |
| 23/05/2018 | Backlog Refinado | Resultado | Não |
| 23/05/2018 | Relatório de Retrospectiva | Resultado | Sim |
| 23/05/2018 | Backlog Validado sprint 2 | Resultado | Não |
| 21/05/2018 | Backlog | Resultado | Não |
| 23/05/2018 | Documentação da análise das Métricas | Resultado | Não |
| 26/05/2018 | Relatório de Desempenho sprint 2 | Resultado | Sim |
| 28/05/2018 | Requisitos | Resultado | Não |
| 28/05/2018 | Métricas de código | Resultado | Não |
Com os dados na tabela acima é possível inferir que exitiram 12 auditorias referentes a sprint 2, sendo assim a quantidade de auditorias(QTA) igual a 12. E que dessas 12, 3 apresentam ao menos uma não conformidade. Desta forma a aderência ao processo é:
QTA = 12;
QTDANC = 3;
AP = (1 - 3/12) * 100 = 75%
Por isso, com base no resultado de 75% se encontra na baixa de Regular, apresentando uma aderência ao processo, segundo as auditorias feitas. No entanto é importante que a aderência ao processo seja maior nas próximas coletas, com a diminuição de não-conformidades com a contribuição de mudanças feitas utilizando o modelo IDEAL para melhoria do processo.
Não foi possível coletar a métrica de aderência do processo, o fato é que a métrica é baseada nas auditorias feitas pela equipe de Garantia de Qualidade e estas não foram feitas para a sprint em questão. Dado isso não é possível nem fazer análise e nem agir sobre a possível não aderência ao processo.
Para se ter os valores de pontos concluídos nas sprints será utilizado a imagem do velocity até então.
Com base no velocity da equipe de desenvolvimento tem-se que o percentual de pontos concluídos nas sprints são:
Sprint 1: 8/25 = 32%
Sprint 2: 9/50 = 18%
Sprint 3: 6/31 = 19,35%
[FAZER]
[FAZER]
[FAZER]
Não foi possível realizar a coleta da métrica pois não foram disponibilizados pela Alta Gerência, nem pelos alunos o formulário com os tópicos que seriam avaliados pelos integrantes da equipe. Assim, essa métrica tem sua análise e providência também impedidas.
[FAZER]
Não foi possível realizar a coleta da métrica pois não foram disponibilizados pela Alta Gerência as notas de apresentação parcial e os tópicos insatisfatórios. Assim, essa métrica tem sua análise e providência também impedidas.
[FAZER]
O objetivo dessa métrica é verificar se a metodologia está adequada a disciplina. Seu cálculo é baseado no número de alterações realizadas, onde essas alterações são elencadas com todas as equipes e depois verificado o que destes pontos levantados foram realmente implementadas soluções de melhoria. Para esse ciclo considerou-se que as mudanças propostas foram as encontradas como GAP's do processo considerado IDEAL.Sendo assim a métrica possuiu o valor 6, fazendo com que a metodologia seja considerada adequada.
NAI = 0 (AIGQA) + 4 (AIDEV) + 2 (AIPROC) + 0 (AIMPS)
No próximo ciclo deve-se realizar no início do mesmo o levantamento para que assim a métrica possa ser avaliada novamente posteriormente.
[FAZER]
Essa métrica busca verificar a satisfação dos alunos quanto ao desempenho obtido na disciplina. Seu funcionamento ocorre com o preenchimento de formulário online para verificar qual a nota que a equipe recebeu, o quão correta foi essa nota, o quanto o aluno percebeu que contribuiu ao projeto e se a avaliação foi coerente.
Não é possível realizar no momento o cálculo do valor dessa métrica, pois a mesma tem como um de seus coeficientes de cálculo a Nota de avaliação da Auto Gerência, que é divulgada somente após o término do ciclo.Isso ocorreu porque esta métrica foi definida ao decorrer do ciclo, demandando assim que ocorra uma mudança no planejamento do formato de divulgação de notas da disciplina, o que não foi possível ocorrer até o momento.
[FAZER]
[FAZER]
[FAZER]
[FAZER]
[FAZER]
[FAZER]
Em relação às métricas para medir a mudança na qualidade do produto após a aplicação de um novo processo, não foi possível observar mudança alguma, ou seja, as métricas de manutenibilidade se mantiveram em estado igual ou muito similar tanto antes quanto depois da execução do novo processo.
Existem algumas interpretações possíveis para este fato. Uma delas é a de que não existiu nenhum impacto causado pelas novas mudanças. De fato, é possível que algumas métricas não tenham observado alteração porque, de certa maneira, apesar do aspecto não ter sido definido no processo, estava sendo implementado na execução. Isto é uma possibilidade real, já que a equipe de melhoria priorizou os GAPs do processo em relação a sua definição, e não a sua implementação.
Outra possível interpretação é a de que as mudanças propostas não foram de fato implementadas. De fato, algumas das mudanças propostas não foram implementadas na sua totalidade, como por exemplo a padronização do código, que não foi aplicada (por meio de folha de estilo) no repositório da API.
A recomendação a ser feita para melhorias futuras é que os focos de melhoria sejam identificados em relação ao que está ou não implementado de fato na execução do processo. Isto pode causar mudanças mais visíveis na organização, que poderão ser medidas, e, desta forma, a melhoria poderá ser de fato constatada.
[FAZER]
[FAZER]
[FAZER]
[FAZER]
[FAZER]