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 e realizadas 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 contrário o projeto ficara estagnado.
- Caso a equipe tenha tempo ele conseguirar realizar todas as atividades definidas, caso contrário, tende a piorar
1.3.1 Questão 01: 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: PAP = Percentual de aderência ao processo QAP = a quantidade de atividades planejadas para a sprint 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. |
1.3.2 Questão 02: 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 de desenvolvimento. |
| Descrição | Calcula a razão entre artefatos planejados e artefados concluídos. |
| Fórmula | PAPCS = (QAC/QAP) * 100, Onde: PAPCS = Percentual de artefatos planejados concluídos na sprint. QAP = a quantidade de artefatos planejados para a sprint 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 que não foram concluídos e tratá-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: PMS = Percentual de métricas coletadas QMP = a quantidade de métricas planejadas para a sprint 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: PMM = percentual de melhoria de métricas QME = a quantidade de métricas que evoluíram 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 níveis aceitáveis. |
| 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 indicadores e, consequentemente, a qualidade do projeto. |
| O1: Garantir que o software atenda 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 Objetivo 01: 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á construido de acordo com o que ele quer, caso contrário o produto está ruim.
- Caso os requisitos estejam bem estabelecidos, o produto tende a ser incrementado da maneira que o cliente quer, caso contrário o software não condiz com as necessidades do cliente.
2.2.2 Objetivo 02: Garantir a manutenibilidade
-
Foco na qualidade:
- A manutenabilidade do produto está aceitável?
-
Fontes de variação:
- Testes
- Número de erros referente à 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 Objetivo 01: Garantir que o software atenda as necessidades do cliente
2.3.1.1 Questão 01: 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 atenda 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: PCAC = Percentual de critérios de aceitação concluídos por feature QC = quantidade de critérios de aceitação completados 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 que não foram completados para cada história e, caso necessário, tratá-las como dívida técnica para a próxima sprint. |
| Percentual de histórias entregues por sprints | |
|---|---|
| Objetivo de Medição | Garantir que o software atenda 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: PHS = percentual de histórias entregues por sprints QHC = a quantidade de histórias concluídas 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 a fim de evitar o acúmulo de dívidas técnicas. |
2.3.2 Objetivo 02: Garantir a manutenibilidade
2.3.2.1 Questão 01: A manutenabilidade do produto está aceitável?
| 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 = quantidade de linhas de código testadas L_tt = quantidade de linhas totais. C = 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 = Complexidade Ciclomática, e é calculado com base em um grafo de fluxo A = Número de arestas N = 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 à 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úmero de erros 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 = percentual de endpoints documentados QED = a quantidade de endpoints documentados 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 dívida 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: PCC = quantidade em percentual de comentários no código QLC = a quantidade de linhas de comentários 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 estiver satisfatório, deve-se refatorar o código 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.
3.3.1 Questão 01: 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) Onde: f(t): quantidade de pontos finalizados no tempo t. PP(t): quantidade de pontos planejados no tempo t. PF(t): quantidade de pontos finalizados no tempo 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 | V = PC/T Onde: V = Velocity PC = número de pontos concluídos até aquela sprint T = 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 estar em constância com a coluna verde, ou seja, os pontos concluídos devem ser constantes conforme os pontos planejados. |
| Providência | Manter a constância das duas colunas. |