\ GamesBI - Documentação

Viabilidade



Métricas e Indicadores

Plano de Medição


1. Introdução


Durante a fase de projeto é necessário garantir a qualidade do produto assim como sua manutenibilidade, para isso a equipe de gestão do projeto GamesBI desenvolvido durante a disciplina de EPS+MDS em 2018.2 necessita do auxílio de métricas para acompanhar a melhoria dos seguintes objetivos: Produtividade da equipe, qualidade de código, alinhamento do produto.


2. Objetivos


A abordagem utilizada em todas as medições será a GQM(Goal Question Metric). Trata-se de uma abordagem com uma hierarquia top-down, ou seja, são definidos a princípio tópicos relevantes que serão destrinchados em vários subtópicos menores. O primeiro tópico a ser abordado são os Goals, ou seja, a meta da medição. A partir das metas, são traçadas perguntas, “questions”, que tentam trazer um questionamento relevante à meta, para que seja guiado a medição. O último nível se encontram as métricas que auxiliam à obtenção de respostas para as perguntas definidas no nível superior



3. Plano GQM

3.1 Objetivo

Analisar

Código de software

Com o propósito de

Controlar e melhorar

Com respeito a

Manutenibilidade e confiabilidade

Sobre o ponto de vista da

Equipe do projeto

No contexto do

Projeto Games BI



3.2 Questões


    • O1Q1: Existe duplicidade de código?

    • O1Q2: Como está a complexidade ciclomática do código?

    • O1Q3: O quanto do código segue a folha de estilo?

    • O1Q4: Qual a taxa de cobertura de testes unitários?



3.3 Métricas


O1Q1M1 - Indicador de código duplicado

Objetivo da Medição

Identificar se foram encontrados códigos duplicados com massa de duplicidade similar ou idêntica.

Fórmula

X = Y


onde:

Y = Massa de duplicidade de código

Escala de Medição

Racional

Coleta

Procedimento: A identificação de duplicidade de código é realizada de forma automática pela ferramenta Code Climate.

Análise

Procedimento: Coletar o valor fornecido pela ferramenta e comparar com a meta.

A massa de duplicidade entre trechos do código deve ser menor que a meta. Acima disso, é necessário que o time revise o trecho para analisar a necessidade de refatoração.

Meta

Aceitável:

A massa de duplicidade entre trechos do código deve ser menor que 32 para Python.


O1Q2M1 - Indicador de complexidade ciclomática do código

Objetivo da Medição

Realizar a contagem da complexidade ciclomática do código avaliando a quantidade de decisões em trechos de código.

Fórmula

X = Y


onde:

Y = Número de caminhos independentes possíveis que percorrem um algoritmo

Escala de Medição

Ordinal

Coleta

Procedimento: A contagem é realizada de forma automática pela ferramenta Code Climate.

Análise

Procedimento: Coletar o valor fornecido pela ferramenta e verificar se está de acordo com a meta.

  • Medida a ser tomada se o valor for até o aceitável: Manter as práticas de desenvolvimento a fim de evitar que a complexidade dos métodos cresça.

  • Medida a ser tomada se o valor for maior que a meta: Direcionar atenção da equipe para a complexidade do código e criar pendências e tarefas de refatoração.

Meta

Valor aceitável: Abaixo de 25

Valor alarmante: Maior ou igual a 25





O1Q3M1 - Indicador de conformidade do código a folha de estilo

Objetivo da Medição

Identificar a porcentagem do código que está em conformidade com a folha de estilo definida.

Fórmula

P = (C / T) * 100


onde:

P = porcentagem,

C = porcentagem de linhas que estão em conformidade

T = número total de linhas que deveriam estar em conformidade

Escala de Medição

Ordinal

Coleta

Procedimento: A contagem será feita pela ferramenta codeclimate, que vai analisar o código em python baseado na folha de estilo pep8

Análise

Procedimento: Coletar o valor fornecido pela ferramenta e compará-lo com a meta definida.

  • Medida a ser tomada caso o valor obtido seja maior ou igual a meta (caso positivo):

Continuar construindo o código baseado na folha de estilo.

  • Medida a ser tomada caso o valor obtido seja menor do que a meta (caso negativo):

Procurar pelas partes do código que não se adequam a folha de estilo e corrigi-las, a fim de se obter o valor estipulado como meta.

Meta

Valor ótimo: Entre 81% e 100%

Valor aceitável: Entre de 51% e 80%

Valor alarmante: Menor ou igual a 50%




O1Q4M1 - Indicador da taxa de cobertura de teste unitários

Objetivo da Medição

Identificar a porcentagem do código a qual foram realizados testes unitários.

Fórmula

P = (M/T) * 100,

sendo

P a porcentagem,

M o número de métodos feitos,

T o número de métodos testados.

Escala de Medição

Ordinal

Coleta

Procedimento: A contagem será feita pela ferramenta Travis CI.

Análise

Procedimento: Coletar o valor fornecido pela ferramenta e compará-lo com a meta definida.

  • Medida a ser tomada caso o valor obtido seja maior ou igual a meta (caso positivo):

Continuar desenvolvendo testes para os blocos de códigos desenvolvidos, a fim de manter a cobertura igual ou maior do que a estipulada.

  • Medida a ser tomada caso o valor obtido seja menor do que a meta (caso negativo):

Procurar pelas partes do código que não possuem testes unitários e desenvolvê-los, a fim de obter a cobertura de testes unitários previamente estipulada.

Meta

Valor ótimo: Acima de 90%

Valor aceitável: Entre 70% e 90%

Valor alarmante: Menor que 70%



4. Objetivo

4.1 Objetivo 2

Analisar

Time de desenvolvimento

Com o propósito de

Controlar e melhorar

Com respeito a

Produtividade

Sobre o ponto de vista da

Equipe do projeto

No contexto do

Projeto Games BI





4.2 Questões


    • O2Q1: A equipe faz entregas contínuas?

    • O2Q2: O conhecimento está sendo horizontalizado?

    • O2Q3: Qual a velocidade de desenvolvimento da equipe?

    • O2Q4: A equipe se sente mais segura em relação às tecnologias?



4.3 Métricas


O2Q1M1 - Burndown

Objetivo da Medição

Identificar se a equipe faz entregas contínuas durante as sprints.

Fórmula

A formula do calculo do burndown é a relação da quantidade de pontos planejados pela quantidade de pontos entregues.

Escala de Medição

Racional

Coleta

Procedimento: O burndown é gerado de forma automática pela ferramenta zenhub de acordo com o acompanhamento das issues pontuadas.

Análise

Procedimento: Coletar o valor fornecido pela ferramenta e comparar com a meta. O burndown da equipe deve ser o mais próximo possível do ideal.

Meta

Aceitável:

O burndown da equipe deve ser o mais próximo possível do ideal



O2Q1M2 - Número de commits por dia

Objetivo da Medição

Identificar se a equipe faz entregas contínuas durante as sprints.

Fórmula


Escala de Medição

Racional

Coleta

Procedimento: Coletar semanalmente o quadro de commits por dias da semana

Análise

Procedimento: Coletar o valor fornecido pela ferramenta e comparar com a meta.

Meta

Aceitável:



O2Q2M1 - O conhecimento está sendo horizontalizado?

Objetivo da Medição

Identificar se o conhecimento adquirido pela equipe está sendo difundido de forma que o nível de conhecimento da equipe seja horizontalizado.

Fórmula

-

Escala de Medição

Racional

Coleta

Procedimento: Coletar os dados dos quadros de pareamento das sprints.

Análise

Procedimento: Analisar se o conhecimento relacionado nos pareamentos está disposto de forma com que ele seja compartilhado igualitáriamente .

Meta

Aceitável:

O conhecimento da equipe deve estar o melhor distribuído possível.


O2Q3M1 - Qual a velocidade de desenvolvimento?

Objetivo da Medição

Medir a velocidade em que a equipe implementa a solução proposta..

Fórmula

X = N

Onde , N é a quantidade de pontos feitos durante a sprint.

Escala de Medição

Racional

Coleta

Procedimento: A coleta dos dados deve ser feita semanalmente através da ferramenta ZenHuB

Análise

Procedimento: Coletar o valor fornecido pela ferramenta e comparar com a meta.

Meta

Aceitável: O nível do velocity é aceitavel quando ele mantem uma variação uniforme entre uma sprint e outra.





O2Q4M1 - A equipe se sente mais segura em relação ao projeto?

Objetivo da Medição

Medir a confiança da equipe em relação a tecnologia e a metodologia adotada no projeto.

Fórmula

X = N/T

Onde , N é o nível de conhecimento em relação a um aspecto e T é o tempo.

Escala de Medição

Racional

Coleta

Procedimento: A coleta dos dados deve ser feita semanalmente através da tabela de conhecimento disponibilizada na página de documentação do projeto.

Análise

Procedimento: Coletar o valor fornecido e analisar a variação.

Meta

Aceitável: O nível de confiança é aceitável quando o conhecimento cresce paralelamente ao velocity e ao quadro de pareamentos.



5. Ferramentas


As métricas de código possui duas categorias, a análise estática e a análise dinâmica. A análise estática é feita sem realizar a execução do código. A análise dinâmica, no entanto, requer a execução do código que está sendo medido.

Conservar um ambiente de testes e integração contínua, é indispensável para todo e qualquer projeto de software. Garantir a qualidade e manter a produtividade com o foco em um entregável que agregue valor para o produto e livre de possíveis erros é de suma importância para o cliente.




5.1 Travis

O Travis possui integração com o Github, uma vez configurado, a cada commit um build é lançado pelo Travis de forma automática. Também conhecido como integração contínua, o processo de executar o build e testes a cada commit.

Planejamos usar o Travis para a realização de testes unitários no projeto Me Representa.


5.2 Code Climate

O Code Climate foi criado por Bryan Helmkamp, bastante conhecido por contribuições em vários projetos open source, incluindo o próprio Rails.

O Code Climate funciona de maneira muito simples, após o cadastro do projeto público ou privado do Github na plataforma ele vai iniciar a verificá-lo até gerar um nota que vai de zero a quatro.

Planejamos usar o Code Climate para analisar estaticamente a qualidade do código, onde será visto a complexidade ciclomática e a duplicidade de código.