Plano de Gerenciamento da Qualidade

Histórico de modificações

Data	Versão	Descrição	Autor
27/09/2017	0.1	Adicionando Plano de Medição	Álax Alves
27/09/2017	0.2	Consertando Links	Lucas Martins
27/09/2017	1.0	Revisando o Documento	Lucas Martins

Sumário

1. Lista de Abreviaturas e Siglas
2. Contexto
3. Objetivos
4. Metodologia
5. Plano de Projeto
   1. Introdução
   2. Cronograma
   3. Organização
      1. Time GQM
      2. Time de Projeto
   4. Treinamento e Promoção
6. Definição
   1. Descrição
      1. Objetivos de Medição
      2. Entrevistas GQM
      3. Questões e hipóteses
         1. Objetivo de Medição 1
         2. Objetivo de Medição 2
      4. Definir Métricas
         1. Objetivo de Medição 1
         2. Objetivo de Medição 2
      5. Diagrama GQM
   2. [O1] - Garantir a Manutenibilidade do Código
   3. [O2] - Otimizar o Gerenciamento de Recursos

1.1. Lista de Abreviaturas e Siglas

• GQM - Goal Question Metric
• GPP - Gestão de Portfólios e Projetos de Software
• MDS - Métodos de Desenvolvimento de Software
• RUP - Rational Unified Process
• XP - eXtreme Programming

1.2. Contexto

Esta wiki descreve o trabalho desenvolvido durante a disciplina de Medição e Análise no curso de Engenharia de Software que tem o intuito de explicitar a importância da área de qualidade e possibilitar, dentro da disciplina, o contato com a prática, além da teoria na Medição. Para aplicar as medições, foi selecionado um projeto de software em desenvolvimento nas disciplinas GPP e MDS, Falko.

O projeto a ser analisado propõe a implementação de um sistema para automatizar atividades dentro da área de gestão de projetos de software, permitindo a centralização de artefatos gerados para gerência e facilitando a análise e tomada de decisões dentro de projetos. O desenvolvimento do Falko foi dividido em duas releases, até a primeira a metodologia utilizada é uma abordagem tradicional adaptada do RUP. Após essa primeira parte, utilizarão métodos ágeis do Scrum e XP.

O projeto de medição será implementado durante a segunda parte, na utilização da metodologia ágil, com o intuito de assegurar que os integrantes de GPP e MDS consigam entregar artefatos de qualidade coerentes com o que é proposto pelas respectivas disciplinas.

1.3. Objetivos

Durante as disciplinas de GPP e MDS o time de gerenciamento é responsável por diversas áreas:

• Gerenciamento de Aquisições;
• Gerenciamento de Custos;
• Gerenciamento de Comunicação;
• Gerenciamento de Configuração de Software;
• Gerenciamento de Escopo;
• Gerenciamento de Qualidade;
• Gerenciamento de Recursos Humanos;
• Gerenciamento de Requisitos;
• Gerenciamento de Riscos;
• Gerenciamento de Tempo.

Com o intuito de descentralizar a responsabilidade e conseguir trazer um foco maior na qualidade, propõe-se este projeto que ocorrerá em paralelo, para selecionar métricas, realizar medições e analisar resultados, recomendando ao grupo das outras disciplinas ações para gerenciamento de qualidade do seu projeto.

1.4. Metodologia

O método utilizado para o desenvolvimento deste trabalho é o Goal Question Metric (GQM) que possibilita a utilização de métricas orientadas a objetivo, assim permitindo a coleta de métricas apenas para fins claramente explicitados (Van Solingen, 1999, p. 21-22). Este é dividido em quatro fases: planejamento, definição, coleta de dados e análise de dados. Na disciplina, o trabalho ficou dividido em duas entregas, na primeira, serão focadas as fases de planejamento e definição e na segunda a coleta e análise de dados.

A primeira fase do GQM, a fase de Planejamento, tem como intuito a coleta de informações para formar uma introdução completa e preparar e motivar membros do projeto a realizarem o programa de medição (Van Solingen, 1999, p. 42). O artefato gerado durante esta fase é o plano de projeto, e as atividades realizadas estão descritas na Tabela abaixo.

Atividade	Descrição
Estabelecimento do time GQM	Escolha dos membros do time responsável pelo programa de medição.
Selecionar área de melhoria	Selecionar uma área de melhoria de produto ou processo.
Selecionar projeto para aplicação e estabelecer o time do projeto	Selecionar um projeto e um time que estejam dispostos a participar da medição.
Criar o plano de projeto	Criar uma proposta de medição na qual o programa será baseado.
Treino e promoção	O time do projeto deve ser orientado quanto à proposta do programa de medição e a metodologia GQM.

2.1. Plano de Projeto

2.1.1. Introdução

O programa de medição proposto terá como objetivo produzir medições que auxiliem os alunos das disciplinas de GPP e MDS desenvolverem seu projeto com eficiência e qualidade. O projeto a ser trabalhado, Falko, pode ser acompanhado nas seguintes páginas:

• Falko-2017.2-BackEnd
• Falko-2017.2-FrontEnd

2.1.2. Cronograma

O grupo deve atentar-se as seguintes datas:

19/09/2017 - Entrega 1 (E1): Onde serão entregues as realizações das fases de planejamento e definição

28/11/2017 - Entrega 2 (E2): Onde serão entregues as realizações das fases de coleta e análise de dados

Lista de artefatos que devem ser entregues ao longo do projeto, com suas datas de entrega sinalizadas:

• Plano de Projeto (E1)
• Plano GQM (E1)
• Plano de Medição (E1)
• Plano de Análise (E1)
• Base de métricas (E2)
• Folha de Análise (E2)
• Resultados de medição (E2)

2.1.3. Organização

2.1.3.1. Time GQM

Integrantes

Time GQM
Fabíola Malta Fleury
Lucas de Araújo Martins
Matheus Richard Torres Gomes de Melo
Matheus Vítor Joranhezon
Thalisson Barreto de Melo Silva

2.1.3.2. Time de Projeto

Integrantes

Nome do Integrante	Disciplina sendo cursada
Aláx de Carvalho Alves	GPP
Lucas Araújo Martins	GPP
Matheus de Sousa Bernardo	GPP
Matheus Richard Torres Gomes de Melo	GPP
Thalisson Barreto de Melo Silva	GPP
Adrianne Alves da Silva	MDS
Daniel Ashton Oda	MDS
Leonardo dos Santos Silva Barreiros	MDS
Mateus de Oliveira Barbosa	MDS
Matheus Roberto Alves da Silva	MDS
Pedro Kelvin de Castro M Batista	MDS
Vinícius de Castro Cantuária	MDS

Processo de desenvolvimento

O processo de desenvolvimento utilizado pelo time de projeto é baseado nos métodos ágeis, sendo uma adaptação do Scrum e do XP.

O desenvolvimento é realizado em sprints, possuindo os eventos: reunião de planejamento da sprint, reunião diária, reunião de revisão da sprint e retrospectiva da sprint. Uma sprint possui o tempo de realização de uma semana e é utilizada para desenvolvimento do incremento (produto) de acordo com as tarefas que foram selecionadas na reunião de planejamento. As reuniões diárias são promovidas para analisar o desenvolvimento e descobrir se há algum impedimento, para que este seja retirado o quanto antes. A revisão e retrospectiva são reuniões de final de sprint para análise do que foi entregue e de como decorreu a sprint. Possui como principais artefatos: backlog do produto, backlog da sprint e o incremento. O backlog do produto e backlog da sprint são a forma de documentar os requisitos (em formato de histórias de usuário) e o incremento é a evolução do produto que é entregue ao final de cada sprint.

Os papéis envolvidos são: time de desenvolvimento, product owner e scrum master. O product owner é responsável por organizar o backlog do produto e priorizar histórias de usuário, contribuindo com a visão do cliente em relação ao processo. O scrum master tem como papel garantir que o scrum esteja sendo aplicado de forma correta, ajudando o time a maximizar sua produtividade. O time de desenvolvimento é responsável pela entrega do produto e deve gerenciar e organizar o seu próprio trabalho (SCHWABWER, 2013).

São também realizados testes de aceitação e testes unitários automatizados e programação em pares, seguindo o proposto pelo XP.

2.1.4. Treinamento e Promoção

Durante a coleta de dados sobre o time de projeto, foi observado que os integrantes que cursam a disciplina GPP possuem algum conhecimento em medição (já cursaram ou estão cursando a disciplina Medição e Análise) enquanto os integrantes de MDS não possuem conhecimentos sobre medição.

Sendo assim, propõe-se um treino sobre a importância da utilização de métricas no desenvolvimento de software e sobre a metodologia GQM para os integrantes de MDS, antes da realização de outras etapas. Dessa forma, estarão alinhados sobre o projeto de medição e terão mais facilidade em contribuir para ele.

Também será realizada entrevista após o treino inicial, e depois da escolha das métricas, será realizado outro treino para explicá-las, sobre como o time pode contribuir para a coleta e como a analise será importante.

  Durante a fase de Definição, são realizadas todas as definições formais do programa de medição. Os principais artefatos gerados durante esta fase é o plano de medição, o plano GQM e o plano de análise (Van Solingen, 1999, p. 49). As atividades exercidas podem ser observadas na tabela a seguir.

Atividade	Descrição
Definir objetivos de medição	Por meio da análise da área de melhoria, selecionar objetivos de medição.
Conduzir entrevistas GQM	Conduzir entrevista com o time de projeto sobre o programa de medição.
Definir questões e hipóteses	A partir dos resultados das entrevistas, definir as questões e hipóteses.
Revisar questões e hipóteses	Revisar as questões e hipóteses estabelecidas.
Definir métricas	A partir das questões e hipóteses, definir as métricas.
Produzir plano GQM	Utilizando os objetivos de medição, questões e hipóteses e métricas, construir o plano GQM.
Produzir plano de medição	Detalhar as métricas estabelecidas no plano de medição.
Produzir plano de análise	Estabelecer a análise para os resultados das medições.
Revisar planos	Revisar os três planos construídos (plano GQM, plano de medição e plano de análise).

3.1 Definição

3.1.2. Descrição

3.1.2.1. Objetivos de Medição

• [O1] Objetivo de Medição - Manutenibilidade de código

Analisar	o código
para o propósito de	melhorar
com respeito a	manutenibilidade
sob o ponto de vista	dos desenvolvedores
no contexto	do projeto Falko (GPP/MDS)

• [O2] Objetivo de Medição - Gerenciamento de Recursos

Analisar	recursos
para o propósito de	melhorar
com respeito a	produtividade
sob o ponto de vista	dos gerentes de projeto
no contexto	do projeto Falko (GPP/MDS)

3.1.2.2. Entrevistas GQM

As entrevistas foram conduzidas focadas nas quatro seções do Abstraction sheet que foi construído após o término das entrevistas de todos os membros do time de projeto.

• Quais são as métricas possíveis para atingir um objetivo(manutenibilidade e gerenciamento de recursos)?
• Das métricas que foram sugeridas, quais seus conhecimentos em relação a elas?
• Quais os fatores (de ambiente) você espera que influenciem as métricas?
• Quais os fatores (de ambiente) você espera que serão influenciados pelas métricas?
• Quais tipos de dependências entre as métricas e fatores de influência serão assumidos?

Abstraction sheet do Objetivo 01

Abstraction sheet do Objetivo 02

3.1.2.3. Questões e hipóteses

Após definidos os objetivos, elaborou-se questões derivadas do contexto e necessidades da equipe.

3.1.2.3.1. Objetivo de Medição 1

• O1Q1: Qual é a porcentagem de cobertura de testes?
  • Tem como objetivo equalizar a quantidade de testes feitos, de maneira a mostrar ao cliente que o código está realizando aquilo que deve.
• O1Q2: O código está seguindo boas práticas de programação?
  • Tem como objetivo garantir que o código seja escrito de maneira legível, assim como verificação da lógica de programação.
• O1Q3: O código é complexo?
  • Tem como objetivo verificar a dificuldade em se modificar o código.

3.1.2.3.2. Objetivo de Medição 2

• O2Q1: O conhecimento do time está nivelado?
  • Tem o objetivo de verificar a discrepância de conhecimento entre os membros do time.
• O2Q2: O time está seguindo o planejamento da sprint estabelecido?
  • Tem o objetivo de averiguar se o time está cumprindo os prazos estabelecidos para suas entregas.
• O2Q3: Quão produtiva é a equipe?
  • Tem o objetivo de verificar se o trabalho está sendo feito de forma contínua, ou apenas em espaços curtos próximos ao fim do prazo.

3.1.2.4. Definir Métricas

3.1.2.4.1. Objetivo de Medição 1

Objetivo	Questão	Métricas
Manutenibilidade de código	Qual é a porcentagem da cobertura de testes?	Número de linhas testadas divididas pelo número de linhas de código.
	O código está seguindo boas práticas de programação?	Número de erros com a folha de estilo.
		Duplicação de código.
		Número de linhas por método.
	O código é complexo?	Churn vs Complexidade.
		Duplicação de código.

3.1.2.4.2. Objetivo de Medição 2

Objetivo	Questão	Métricas
Gerenciamento de Recursos	O conhecimento do time está nivelado?	Diferença entre níveis dos membros no quadro de conhecimento.
	O time está seguindo o planejamento da sprint?	Burndown da Sprint.
	Quão produtiva é a equipe?	Velocity.
		Burndown da Sprint.
		Earned value management (EVM).

3.1.2.5. Diagrama GQM

3.2.1. [O1] - Garantir a Manutenibilidade do Código

Métrica	Porcentagem de código testado
Objetivo de Medição	Garantir a qualidade e a 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 = Lts/Ltt, Onde Lts representa as linhas de código testadas, e Ltt representa as linhas totais. Esta razão resulta em C, que representa a cobertura total de testes.
Escala	Racional
Coleta	Responsável: Fabíola. Periodicidade do Evento: Ao final de cada sprint. Ferramenta: simplecov.
Procedimento	Submissão do código fonte à ferramenta de análise de cobertura de testes.
Análise	Release 1: O valor da cobertura total de testes deve ser maior ou igual a 0.3. Release 2: O valor da cobertura total de testes deve ser maior ou igual a 0.9.
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.

Métrica	Duplicação de Código
Objetivo de Medição	Garantir a 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	Matheus Joranhezon Periodicidade do Evento: Ao final de cada sprint. Ferramenta: rubocop (codeclimate)
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 [3], portanto duplicações e similaridades devem ser eliminadas, exceto em casos onde sejam estritamente necessárias.
Providência	Deve se aplicar esforços de refatoração nas duplicações e similaridades identificadas.

Métrica	Número de Linhas por Método
Objetivo de Medição	Garantir a manutenibilidade do código fonte.
Descrição	Consiste no número de linhas de código presente em um determinado método do código fonte.
Fórmula	Contagem de todas as linhas de código presentes em um dado método.
Escala	Absoluta
Coleta	Responsável: Matheus Richard. Periodicidade do Evento: Ao final de cada sprint. Ferramenta: codeclimate
Procedimento	Submissão do código fonte à ferramenta de análise de tamanho dos métodos.
Análise	A análise do número de linhas por método irá tomar como base os intervalos padrão da ferramenta, os quais indicam que este valor deve ser inferior ou igual a 30 [4].
Providência	Deve se aplicar esforços de refatoração nos métodos identificados, dividindo-os em métodos menores.

Métricas	Complexidade Ciclomática
Objetivo de Medição	Garantir a manutenibilidade e a legibilidade 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].
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: Lucas Martins. Periodicidade do Evento: Ao final de cada sprint. Ferramenta: rubocop (codeclimate)
Procedimento	Submissão do código fonte à ferramenta de análise de complexidade ciclomática.
Análise	A análise da complexidade ciclomática irá tomar como base os intervalos padrão da ferramenta, os quais indicam que este valor deve ser inferior ou igual a 6 [4].
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.

Métrica	Churn
Objetivo de Medição	Garantir a manutenibilidade do código fonte.
Descrição	É a contagem das alterações feitas em cada um dos arquivos do projeto.
Fórmula	Cada arquivo possuirá sua contagem de número de alterações de acordo com os commits.
Escala	Absoluta
Coleta	Matheus Joranhezon Periodicidade do Evento: Ao final de cada sprint. Ferramenta: codeclimate
Procedimento	Submissão do código fonte à ferramenta de análise de churn.
Análise	A análise do churn dará-se juntamente com a análise da complexidade, por meio de gráfico, que sinaliza tanto a complexidade quanto o acesso por arquivo.
Providência	Dependendo do quadrante que o arquivo se apresente no gráfico, recomenda-se sua refatoração.

Métrica	Número de erros com a folha de estilo
Objetivo de Medição	Garantir a manutenibilidade do código fonte.
Descrição	Consiste no número de descumprimentos que o código apresenta em relação à folha de estilo.
Fórmula	Contagem de todos erros presentes no projeto.
Escala	Absoluta
Coleta	Fabíola Periodicidade do Evento: Ao final de cada sprint. Ferramenta: rubycop
Procedimento	Submissão do código fonte à ferramenta de análise estática de lint.
Análise	A análise do número de erros será: Ideal - nenhum erro; Bom - < 30 erros; Ruim - > 30 e <150; Péssimo - >150;
Providência	Deve se aplicar esforços de refatoração nos erros indicados.

3.2.2. [O2] - Otimizar o Gerenciamento de Recursos

Métrica	Diferença entre níveis dos membros no quadro de conhecimento
Objetivo de Medição	Gerenciamento de Recursos.
Descrição	O quadro de conhecimentos consiste em uma matriz onde cada linha representa um membro da equipe, e cada coluna a uma tecnologia utilizada no projeto. Cada membro atribui um dos valores, presentes em uma escala predefinida, a cada tecnologia em sua respectiva célula. Ao longo do tempo são elaboradas diferentes versões deste quadro, indicando o estado do conhecimento da equipe ao longo do tempo.
Fórmula	-
Escala	Ordinal
Coleta	Responsável: Thalisson Barreto. Periodicidade do Evento: Ao final de cada sprint.
Procedimento	No início do projeto e ao final de cada sprint uma nova versão do quadro de conhecimentos é gerada, e nela os membros da equipe indicam qual é o seu nível de conhecimento sobre cada uma das tecnologias presentes no quadro.
Análise	A análise é feita com base na escala a seguir: Ótimo: Indica que o membro da equipe domina aquela tecnologia em questão. Bom: Indica que o membro da equipe possui um conhecimento elevado sobre a tecnologia em questão. Regular: Indica que o membro da equipe possui um conhecimento médio sobre a tecnologia em questão. Ruim: Indica que o membro da equipe possui pouco conhecimento sobre a tecnologia em questão. Péssimo: Indica que o membro da equipe não possui qualquer conhecimento sobre a tecnologia em questão. Esta escala permite visualizar sobre quais tecnologias os membros da equipe possuem mais conhecimento, e sobre quais eles possuem menos conhecimento. Além disso, pode-se analisar o nível de alinhamento do conhecimento da equipe.
Providência	O quadro de conhecimentos proporciona várias possibilidades de providência: - Caso o nível de conhecimento da equipe esteja alto, tarefas mais complexas podem ser alocadas em um menor período de tempo. - Caso o nível de conhecimento da equipe esteja baixo, tarefas mais simples devem ser alocadas. - Caso o nível de conhecimento da equipe esteja baixo, um maior tempo deve ser disponibilizado para a equipe realizar determinadas tarefas. - Caso o nível de conhecimento da equipe esteja baixo, treinamentos devem ser realizados para que o conhecimento da equipe seja aprimorado. - Caso o conhecimento da equipe esteja desnivelado, práticas como pareamentos podem ser implantadas para incentivar a propagação do conhecimento.

Métrica	Earned value management (EVM)
Objetivo de Medição	Gerenciamento de Recursos.
Descrição	A métrica em questão é uma técnica para medir performance e progresso do projeto, combinando custos, escopo e tempo.
Fórmula	É expressado em um gráfico com os eixos do tempo x custo. São traçadas três retas: custo real, valor agregado e valor planejado.
Escala	Racional
Coleta	Responsável: Time de gerenciamento. Periodicidade do Evento: Ao final de cada sprint.
Procedimento	O valor deve ser calculado para cada sprint e também para o total do projeto.
Análise	Esta métrica possibilita visualizar a cada entrega da equipe, se está de acordo com o custo e o tempo planejado para tal.
Providência	Caso o valor agregado esteja muito abaixo do valor planejado, é sinal de que a equipe está produzindo menos do que o esperado.

Métrica	Burndown
Objetivo de Medição	Gerenciamento de Recursos
Descrição	O burndown é um gráfico que representa o trabalho entregue em determinado período de tempo. A partir desse gráfico é possível identificar como está a rotina de trabalho da equipe, assim como sua rapidez para terminar as atividades propostas.
Fórmula	O burndown utiliza um sistema de pontos que faltam entregar na sprint versus o tempo. A partir dessa medida obtém-se uma reta que indica a progressão de trabalho do time no decorrer da sprint.
Escala	Racional
Coleta	Responsável: Matheus Richard. Periodicidade do Evento: Ao final de cada sprint.
Procedimento	Utilização do gráfico burndown do github.
Análise	Existem 3 cenários possíveis ao se analisar o burndown. Primeiro, os integrantes da equipe terminam as atividades propostas em um tempo muito menor do que o esperado, o que pode significar falha de gerenciamento ou que os membros da equipe de desenvolvimento foram subestimados. Segundo, o gráfico mantêm-se constante, de maneira que indica que a equipe está seguindo com a metodologia e que houveram boas decisões de gerenciamento. Terceiro, todo o trabalho é queimado em apenas um dia, no fim da sprint, ou até mesmo não é queimado. Isso pode significar que a equipe de desenvolvimento não foi capaz de fazer as atividades por falta de conhecimento, implicando em decisões de gerenciamento falhas, ou que o time de desenvolvimento não está levando o projeto a sério.
Providência	Primeiro caso: a sprint deverá ser terminada mais cedo do que o esperado, de maneira que ocorra urgentemente o planejamento de outra sprint. Segundo caso: mantém-se a mesma gestão da sprint anterior em relação aos pontos. Terceiro caso: espera-se treinamentos de tecnologias e pareamentos visando a disseminação de conhecimento. Além disso, as histórias para sprint seguinte devem ser mais fáceis que a anterior.

Métricas	Velocity
Objetivo de Medição	Gerenciamento de Recursos
Descrição	O velocity é uma estimativa da quantidade de trabalho que uma equipe consegue realizar dentro do período de uma sprint.
Fórmula	[(SPn+SPn-1)/n]Onde SP é o número de pontos para uma determinada interação e n é a própria interação
Escala	Racional
Coleta	Responsável: Thalisson Melo. Periodicidade do Evento: Ao final de cada sprint.
Procedimento	Verificação dos pontos definidos para a sprint e os pontos realizados pela equipe.
Análise	Existem 3 cenários possíveis para analisar velocity: - Primeiro caso: A equipe pode realizar todos os pontos determinados para a sprint e nenhum mais, nesse caso o velocity coincide com os pontos realizados pela equipe na sprint. - Segundo caso: A equipe pode realizar todos os pontos determinados para a sprint e pontos a mais, nesse caso os pontos realizados na sprint pela equipe estão acima do velocity. - Terceiro caso: A equipe pode não realizar todos os pontos determinados para a sprint, nesse caso os pontos realizados na sprint pela equipe estão abaixo do velocity.
Providência	Verificar os pontos definidos para a sprint e os pontos realizados pela equipe.

Referências

[1] https://docs.codeclimate.com/v1.0/docs/cyclomatic-complexity

[2] https://docs.codeclimate.com/v1.0/docs/duplication-concept

[3] MCCONNELL, S. Code Complete http://aroma.vn/web/wp-content/uploads/2016/11/code-complete-2nd-edition-v413hav.pdf

[4] https://docs.codeclimate.com/v1.0/docs/rubocop

[5] SUTHERLAND, Scrum: The art of doing twice the work in half the time