GQM
A documentação abaixo segue o seguinte modelo de acordo com o processo.
- x. Nome da área de medição (processo ou equipe ou produto)
- x.y Nível conceitual (Objetivos)
- x.y Nível operacional (Perguntas - Abstraction Sheet)
- x.y Nível quantitativo (Métricas e Rastreabilidade)
As coletas serão feitas utilizando o template de coletas realizada de acordo com o especificado no plano de medição
| O1: Garantir que o processo seja adequado ao contexto da equipe | |
| Objeto | Processo |
| Propósito | Garantir adequação a equipe |
| Foco de qualidade | Melhoria de processo |
| Ponto de vista | Da equipe de processo e gerência. |
| Contexto | UnBFeelings |
-
Foco na qualidade:
- A equipe está aderindo ao processo?
- A equipe está executando as atividades propostas?
-
Fontes de variação:
- Disposição da equipe
- Tempo para realizar as atividade
-
Hipótese de Baseline:
- No momento a equipe está seguindo o processo inicial.
- Muitas atividades definidas no processo não estão sendo realizadas.
-
Impactos nas hipóteses de Baseline:
- Caso a equipe esteja disposta a aderir ao novo processo melhorado, o projeto terá uma melhoria, caso contrario o projeto ficara estagnado.
- Caso a equipe tenha tempo ele conseguirar realizar todas as atividades definidas, caso contrario, tende a piorar
Q1: A equipe está aderindo ao processo?
| Percentual de aderência ao processo | |
|---|---|
| Objetivo de Medição | Garantir que o processo seja adequado ao contexto da equipe. |
| Descrição | Razão entre a quantidade de atividades planejadas e atividades realizadas numa sprint. |
| Fórmula | "PAP = (QAR/QAP) * 100", onde QAP é a quantidade de atividades planejadas para a sprint e QAR é a quantidade de atividades realizadas na sprint. |
| Escala | Racional |
| Coleta | Responsável: Equipe de medição |
| Procedimento | Deve se observar quais são as atividades do processo que são realizadas a cada sprint e verificar quais delas foram de fato realizadas. |
| Análise |
|
| Providência | Deve-se investigar a razão da não realização das atividades, e de acordo com o resultado auxilar a equipe de desenvolvimento encontrar os gargalos e/ou melhorar o processo para melhor se adequar ao contexto da equipe. |
Q2: A equipe está executando as atividades propostas?
| Percentual de artefatos planejados concluídos por sprint | |
|---|---|
| Objetivo de Medição | Garantir que o processo seja adequado ao contexto da equipe. |
| Descrição | Calcula a razão entre artefatos planejados e artefados concluídos. |
| Fórmula | "PAPCS = (QAC/QAP) * 100", onde QAP é a quantidade de artefatos planejados para a sprint e QAC é a quantidade de artefatos concluídos na sprint. |
| Escala | Racional |
| Coleta | Responsável: Equipe de medição |
| Procedimento | Durante a reunião de Revisão de Sprint, deve-se averiguar os artefatos entregues. |
| Análise |
|
| Providência | Avaliar quais são os artefatos não foram concluídos e trata-los como dívida técnica para a próxima sprint |
| Percentual de métricas coletadas | |
|---|---|
| Objetivo de Medição | Garantir que o processo seja adequado ao contexto da equipe. |
| Descrição | Calcula a razão entre métricas planejadas e métricas coletadas. |
| Fórmula | "PMS = (QMC/QMP) * 100", onde QMP é a quantidade de métricas planejadas para a sprint e QMC é a quantidade de métricas coletadas na sprint. |
| Escala | Racional |
| Coleta | Responsável: Equipe de Medição |
| Procedimento | Durante a reunião de Revisão de Sprint, deve-se verificar quais métricas foram devidamente coletadas. |
| Análise |
|
| Providência | Avaliar quais métricas não foram coletadas e coletá-las assim que possível. |
| Percentual de melhoria de métricas | |
|---|---|
| Objetivo de Medição | Garantir que o processo seja adequado ao contexto da equipe. |
| Descrição | Calcula a razão entre métricas que evoluíram para um nível melhor (ou que se mantiveram em níveis aceitáveis) e as métricas totais. |
| Fórmula | "PMM = (QME/QTM) * 100", onde QME é a quantidade de métricas que evoluíram e QTM é a quantidade total de métricas. |
| Escala | Racional |
| Coleta | Responsável: Equipe de Medição |
| Procedimento | Durante a reunião de Revisão de Sprint, deve-se verificar quais métricas evoluíram ou se mantiveram em niveis aceitaveis. |
| Análise |
|
| Providência | Deve-se verificar quais métricas não evoluíram, e entender o porquê, para que se possa tomar providências que visem melhorar os indicadoes e, consequentemente, a qualidade do projeto. |
| O1: Garantir que o software atende as necessidades do cliente | |
| Objeto | Software |
| Propósito | Atender as necessidades do cliente |
| Foco de qualidade | Melhoria |
| Ponto de vista | Da equipe de desenvolvimento e gerência. |
| Contexto | UnBFeelings |
| O2: Garantir a manutenibilidade | |
| Objeto | Software |
| Propósito | Garantir manutenibilidade |
| Foco de qualidade | Melhoria |
| Ponto de vista | Da equipe de desenvolvimento e gerência. |
| Contexto | UnBFeelings |
2.2.1 Garantir que o software atende as necessidades do cliente
-
Foco na qualidade:
- O produto atende os requisitos do cliente?
-
Fontes de variação:
- Satisfação do cliente
- Requisitos
-
Hipótese de Baseline:
- No momento o cliente não está satisfeito com o produto gerado.
- No momento os requisitos estão bem estabelecidos
-
Impactos nas hipóteses de Baseline:
- Caso a satisfação do cliente esteja alta, quer dizer que o produto está ficando de acordo com o que ele quer, caso contrário o produto está ruim.
- Caso os requisitos estejam bem estabelecidos, o produto saída da maneira que o cliente quer, caso contrario o software não condiz com as necessidades do cliente.
2.2.2 Garantir a manutenibilidade
-
Foco na qualidade:
- A manutenabilidade do produto está aceitavel?
-
Fontes de variação:
- testes
- número de erros referente a folha de estilo
-
Hipótese de Baseline:
- O software não apresenta testes no momento
- O software está seguindo uma folha de estilo
-
Impactos nas hipóteses de Baseline:
- Caso o software não apresente testes, a confiabilidade por parte dos usuários será baixa, caso contrario será alta.
- Caso o software esteja com uma nota alta em alguma ferramenta de análise estática de código, a manutenabilidade do mesmo será boa, caso contrário não.
2.3.1 Garantir que o software atende as necessidades do cliente
- Q1: O produto atende os requisitos do cliente?
| Percentual de critérios de aceitação concluídos por feature | |
|---|---|
| Objetivo de Medição | Garantir que o software atende as necessidades do cliente |
| Descrição | Calcula a quantidade de critérios de aceitação validados pelo cliente, para cada feature. |
| Fórmula | "PCAC = (QC/QF) * 100" onde QC é a quantidade de critérios de aceitação completados e QF é a quantidade de critérios de aceitação por feature. |
| Escala | Racional |
| Coleta | Responsável: Equipe de medição |
| Procedimento | Reunião pautada para avaliação de critérios concluídos junto aos _stakeholders_ para validar quais foram finalizadas |
| Análise |
|
| Providência | Avaliar quais são os critérios não foram completados para cada história e caso necessário tratá-las como divida técnica para a próxima sprint |
| Percentual de histórias entregues por sprints | |
|---|---|
| Objetivo de Medição | Garantir que o software atende as necessidades do cliente |
| Descrição | Calcula a razão entre histórias concluídas e histórias planejadas por sprint |
| Fórmula | "PHS = (QHC/QHP) * 100" onde QHC é a quantidade de histórias concluídas e QHP é a quantidade de histórias planejadas. |
| Escala | Racional |
| Coleta | Responsável: Equipe de medição |
| Procedimento | Reunião de planejamento de sprint, avaliar a quantidade de histórias não concluídas com o PHS |
| Análise |
|
| Providência | Verificar a quantidade de histórias não concluídas por _sprint_ para melhor avaliar o planejamento das sprints afim de evitar o acumulo de dividas técnicas |
2.3.2 Garantir a manutenibilidade
- Q1: A manutenabilidade do produto está aceitavel?
| Percentual de código testado | |
|---|---|
| Objetivo de Medição | Manutenibilidade do código fonte. |
| Descrição | Calcula a razão entre as linhas de código testadas e as linhas totais do software. |
| Fórmula | "C = L_ts/L_tt" onde "L_ts" representa as linhas de código testadas, e "L_tt" representa as linhas totais. Esta razão resulta em "C", que representa a cobertura total de testes. |
| Escala | Racional |
| Coleta | Responsável: Equipe de medição |
| Procedimento | Submissão do código fonte à ferramenta de análise de cobertura de testes. |
| Análise |
|
| Providência | Caso a cobertura total de testes não satisfaça o intervalo determinado, serão necessários esforços de refatoração e elaboração de testes. |
| Complexidade Ciclomática | |
|---|---|
| Objetivo de Medição | Manutenibilidade do código fonte. |
| Descrição | É a contagem dos caminhos linearmente independentes ao longo do código fonte, ou seja, o número de decisões que um determinado bloco de código deve realizar.1(https://docs.codeclimate.com/v1.0/docs/cyclomatic-complexity) |
| Fórmula | CC = A - N + 2 Onde CC representa a Complexidade Ciclomática, e é calculado com base em um grafo de fluxo, onde A representa o número de arestas e N o número de nós. |
| Escala | Racional |
| Coleta | Responsável: Equipe de medição |
| Procedimento | Submissão do código fonte à ferramenta de análise de complexidade ciclomática. |
| Análise |
|
| Providência | Caso a complexidade ciclomática ultrapasse os valores aceitáveis, serão alocados esforços de refatoração dos blocos de código indicados como demasiadamente complexos. |
| Número de erros referentes a folha de estilo proposta | |
|---|---|
| Objetivo de Medição | Manutenibilidade do código fonte. |
| Descrição | O código escrito está seguindo corretamente a folha de estilo utilizada pela comunidade de desenvolvedores da tecnologia(s) utilizada(s). |
| Fórmula | Nº errors apontados pela ferramenta de guia de estilo. EX: flake8 error log |
| Escala | Absoluta |
| Coleta | Responsável: Equipe de medição e/ou Equipe de desenvolvimento. |
| Procedimento | Submissão do código fonte à ferramenta de análise estática de lint. |
| Análise |
|
| Providência | Deve se aplicar esforços de refatoração nos erros indicados |
| Duplicação de código | |
|---|---|
| Objetivo de Medição | Manutenibilidade do código fonte. |
| Descrição | É a verificação da presença de código duplicado ao longo do código fonte. |
| Fórmula | A ferramenta calcula a duplicação de código por meio de AST’s (abstract syntax trees) que possui nós, cada um com um tipo e um conjunto de valores. Ao calcular a duplicação, todos os nós são comparados. Nós com o mesmo tipo, mas valores diferentes, são considerados “similares”, já os nós que possuem o mesmo tipo e os mesmos valores são considerados “duplicados”. |
| Escala | Racional |
| Coleta | Responsável: Equipe de medição |
| Procedimento | Submissão do código fonte à ferramenta de análise de duplicação de código. |
| Análise | A duplicação de código implica em uma menor manutenibilidade, portanto duplicações e similaridades devem ser eliminadas, exceto em casos onde sejam estritamente necessárias.2(http://aroma.vn/web/wp-content/uploads/2016/11/code-complete-2nd-edition-v413hav.pdf) |
| Providência | Deve se aplicar esforços de refatoração nas duplicações e similaridades identificadas. |
| Percentual de endpoints documentados | |
|---|---|
| Objetivo de Medição | Manutenibilidade do código fonte. |
| Descrição | Razão entre endpoints documentados e endpoints totais. |
| Fórmula | (PED = QED/QET) * 100, onde PED é a quantidade de endpoints documentados e QET é a quantidade total de endpoints. |
| Escala | Racional |
| Coleta | Responsável: Equipe de medição |
| Procedimento | Reunião de planejamento de sprint, avaliar a quantidade de histórias não concluídas com o PED. |
| Análise |
|
| Providência | Avaliar quais endpoints não foram documentados, e tratá-los como divida técnica para a próxima sprint. |
| Percentual de comentários no código | |
|---|---|
| Objetivo de Medição | Manutenibilidade do código fonte. |
| Descrição | Razão entre número de linhas de comentários e linhas de código totais. |
| Fórmula | (PCC = QLC/QLT) * 100, onde QLC é a quantidade de linhas de comentários e QLT é a quantidade total de linhas de código. |
| Escala | Racional |
| Coleta | Responsável: Equipe de medição |
| Procedimento | Em cada Pull Request deve-se verificar a quantidade de linhas de comentários e avaliar o produto software com o PCC. |
| Análise |
|
| Providência | Se o valor do PED não estive satisfatório, deve-se refatorar o codigo de forma a adequar o número de linhas de comentários. |
| O1: Desempenho da equipe | |
| Objeto | Equipe |
| Propósito | Melhorar |
| Foco de qualidade | Desempenho |
| Ponto de vista | Da equipe de desenvolvimento e gerência. |
| Contexto | UnBFeelings |
-
Foco na qualidade:
- O desempenho da equipe está satisfatório?
-
Fontes de variação:
- Desempenho
-
Hipótese de Baseline:
- No momento o desempenho da equipe está baixo.
-
Impactos nas hipóteses de Baseline:
- Caso o desempenho esteja alto o software ficará pronto mais rápido, caso contrário não.
Q1: O desempenho da equipe está satisfatório?
| Burndown | |
|---|---|
| Objetivo de Medição | Verificar a quantidade de pontos finalizados em relação aos pontos planejados. |
| Descrição | Gráfico que acompanha a diferença entre os pontos planejados e os finalizados em relação ao tempo. |
| Fórmula | f(t) = PP(t) - PF(t) |
| Escala | Racional |
| Coleta | Responsável: Equipe de medição |
| Procedimento | Produzir um gráfico em relação ao tempo dos pontos planejados e pontos finalizados. |
| Análise |
|
| Providência | Tentar queimar os pontos ao longo da sprint de maneira que a linha azul coincida com a linha cinza que é o ideal. |
| Velocity | |
|---|---|
| Objetivo de Medição | O velocity indica a quantidade de pontos que a equipe consegue concluir em uma sprint. |
| Descrição | O gráfico possui uma coluna verde que indica a quantidade de pontos planejados para aquela sprint e a coluna cinza que indica a quantidade de pontos concluídos naquela sprint. |
| Fórmula | número de pontos concluídos até aquela sprint / número de semanas de desenvolvimento até aquela sprint |
| Escala | Racional |
| Coleta | Responsável: Equipe de medição |
| Procedimento | Produzir um gráfico através da média dos pontos finalizados pela quantidade de sprints, demonstrando a produtividade da equipe de desenvolvimento. |
| Análise | A coluna cinza tem que está em constância com a coluna verde |
| Providência | Manter a constância das duas colunas. |