Relatório de Qualidade

Histórico de Versão

Data	Versão	Descrição	Autor(es)
14/04/2017	0.1	Elaboração Inicial	Naiara Andrade
15/04/2017	1.0	Finalização do Documento	Naiara Andrade, Matheus Figueiredo, Victor Hugo, Lucas Mattioli, Leonardo Arthur
15/04/2017	1.1	Revisão do documento	Leonardo Arthur
19/04/2017	2.0	Alteração de variação de qualidade , impacto de hipóteses de baseline e revisão final do documento	Leonardo Arthur, Lucas Mattioli, Naiara Andrade

Sumário

1. Processos de Qualidade
   1.1. Qualidade dos artefatos
   1.2. Qualidade do código
2. Custo da Qualidade
   2.1. Release 1
   2.2. Release 2
3. Benchmarking
4. GQM
   4.1. Objetivos
   4.2. Questões
   4.3. Métricas
5. Ferramentas
   5.1. CodeClimate
   5.2. Travis CI
   5.3. Coveralls
   5.4. Cucumber
6. Monitoramento e Controle
   6.1. Periodicidade
   6.2. Responsáveis
7. Referência Bibliográfica

1. Processos de Qualidade

O ciclo PDCA será utilizado durante todo o projeto e tem por objetivo da melhoria contínua das etapas dos processos, visando a qualidade dos resultados obtidos. Resultados que serão periodicamente comparados as baselines dos artefatos e as métricas estipuladas de um software de qualidade.

1.1. Qualidade dos artefatos

Para o processo de qualidade dos artefatos é sequenciada as atividades a seguir, sabendo que o ciclo PDCA se encontra presente em uma ou mais atividades.

Confeccionar artefatos: Essa atividade engloba o planejamento e a elaboração dos artefatos (Planejar e Fazer). Os planos da gerência (GPP) para condução do projeto e os artefatos do time de desenvolvimento (MDS).

Revisar artefatos: Essa atividade consiste em Checar se os artefatos estão em conformidade. Caso estejam, como é mostrado na imagem o fluxo principal, o artefato é concluído. Caso contrário, é apontado os erros ou pontos de melhoria.

Corrigir artefatos: Essa atividade que pode acontecer simultaneamente com propor melhorias e consiste na correção dos artefatos, é a ação do PDCA. Seguindo, após a correção dos artefatos o processo retorna a revisão dos artefatos até que atingir a qualidade esperada.

Propor melhorias: Atividade que pode acontecer simultaneamente com corrigir artefatos, consiste em propor melhorias caso a qualidade ainda não tenha sido alcançada. Após a proposta, nesse fluxo alternativo, o processo retorna as atividades do início: confeccionar artefatos até que se tenha o artefato concluído.

1.2. Qualidade do código

Para o processo de qualidade do código é sequenciada as atividades a seguir, sabendo que o ciclo PDCA se encontra presente em uma ou mais atividades.

Definir métricas: Como parte do Planejar, essa atividade engloba os dados que serão coletados e as métricas que serão analisadas no código.

Coletar dados: Após a confecção do código é realizado a coleta dos dados anteriormente definidos. Essa atividade faz parte do Fazer.

Interpretar dados: Essa atividade consiste em interpretar os dados coletados.

Analisar resultados das medições: Essa atividade consiste em analisar os dados coletados, inferindo resultados. Caso a análise das medições estejam em conformidade com o planejado e obter a qualidade o software é concluído no fluxo principal. Caso contrário, será revisado o código.

Revisar código: Essa atividade consiste em Checar e revisar o código para saber que Ação tomar.

Refatorar código: Podendo ocorrer simultaneamente com a proposta de melhorias após a revisão do código, a refatoração de código é uma opção para se obter a qualidade do software. O processo retorna a atividade de coleta de dados e segue até se concluir o fluxo principal.

Propor melhorias: Podendo ocorrer simultaneamente com refatorar código a atividade de propor melhorias é uma proposta para que se alcance a qualidade planejada.

2. Custo da Qualidade

2.1. Release 1

Custo de Conformidade
Prevenção de Custos
	Horas Gastas	Valor
Treinamento	181 h 43 m	R$ 2.780,27
Ambiente	15 h	R$ 229,5
Documentação	293 h 52 m	R$ 4.496,16
Desenvolvimento	211 h 49 m	R$ 3.240,80
Valor	702 h 24 m	R$ 10.746,72
Custos de Avaliação
Testes	39 h 21 m	R$ 602,10
Valor	39 h 21 m	R$ 602,10

Dinheiro gasto durante o projeto para evitar falhas

2.2. Release 2

3. Benchmarking

Partindo da técnica de benchmarking para uma maior agregação do grupo, para que entenda as boas práticas realizadas por outros projetos da disciplina, seus erros cometidos e as ferramentas utilizadas. Os projetos que foram utilizados nessa técnica foram a Missão Nascente, WikiLegis e Owla.

Foram realizadas pesquisas pela equipe de GPP para saber quais serviços e ferramentas se adequariam ao projeto e que atendesse a tecnologia utilizada. Por ter sido o primeiro contato da equipe com a tecnologia também foi buscado conselhos e opiniões de professores da Universidade da Brasília, coaches e alunos que entendem do assunto.

Algumas das informações obtidas foram:

• Utilização de GQM para justificar a escolha das métricas;
• A ferramenta de cobertura de teste CodeClimate;

4. GQM

4.1. Objetivos

Analisar	código produzido
Com o propósito de	entender e melhorar
Com respeito a	manutenibilidade do software
Sob o ponto de vista da	equipe do projeto
No contexto	projeto Escola X

4.2. Questões

Foco da Qualidade	Fatores de Variação
Q1. O quão fácil é diagnosticar eventuais problemas e identificar as causas das falhas? Q2. Qual a capacidade de se testar sistema modificado? Q3. O produto se mantém no nível de desempenho nas condições estabelecidas?	- O código se torner complexo a nível dos desenvolvedores não conseguirem dar manutenção - Ferramentas para debuggar código não estarem funcionando - Ocorrerem mudanças continuamente no projeto de modo que não seja possível terminar de rodar os testes. - O volume de acessos simultâneos no banco de dados aumentar . - O volume de usuários aumentar consideravelmente no sistema.
Hipóteses de Baselines	Impacto na Hipótese de Baselines
Q1.1. Alta coesão Q1.2. Baixo acoplamento Q2.1. Complexidade ciclomática Excelente - [0, 3) Bom - [3, 5) Regular - [5, 7) Ruim - [7, INF) Q3.1. Release 1: Cobertura de teste > 30% e Release 2: Cobertura de teste > 90%	- Falta de conhecimento da equipe para aplicar os padrões GRASP diminuirá coesão e aumentará acoplamento. - Falta de conhecimento da equipe de GPP em ruby on rails poderá diminuir coesão e acoplamento no código - A cobertura de testes não alcançar 30% na release 1 demandará mais tempo do time para testes. - Falta de conhecimento da equipe em testes demandará um esforço maior e tempo em testes.

4.3. Métricas

Métrica	M1.1.1 - Tamanho de Classe
Objetivo da medição	Garantir que a coesão do código esteja boa
Fórmula	Total de linhas da classe
Escala da medição	Ordinal
Coleta	Responsável: Lucas Mattioli Periodicidade ou Evento: Release 1: Após a finalização dos casos de usos Release 2: Ao final de cada sprint Ferramenta: Code Climate/Rubocop Armazenamento: Os dados ficarão armazenados em planilha excel disponível no google drive do projeto para consultas futuras e cruzamento de dados.
Análise	Responsável: Matheus Figueiredo Procedimentos: Verificar se o limite estipulado foi ultrapassado. Se sim, providenciar refatoração da classe
Meta	O número máximo de linhas de uma classe recomendado pelo Rubocop é 100. Logo, uma dada classe será considerada boa em relação a essa métrica caso seu tamanho não ultrapasse 100.

Métrica	M1.2.1 - ABC Metric
Objetivo da medição	Garantir que o número de atribuições, condicionais e branches de métodos não sejam elevados, garantindo, então, um menor acoplamento de código (fonte). A ferramenta Rubocop adaptou tal métrica para códigos Ruby.
Fórmula	sendo A o número de atribuições em um método, B o número de branches e C o número de condicionais.
Escala da medição	Racional
Coleta	Responsável: Lucas Mattioli Periodicidade ou Evento: Release 1: Após a finalização dos casos de usos Release 2: Ao final de cada sprint Ferramenta: Code Climate/Rubocop Armazenamento: Os dados ficarão armazenados em planilha excel disponível no google drive do projeto para consultas futuras e cruzamento de dados.
Análise	Responsável: Matheus Figueiredo Procedimentos: Verificar se o limite estipulado foi ultrapassado. Se sim, providenciar a redução de atribuições, condicionais ou branches dos métodos identificados até que o valor da métrica seja menor ou igual ao valor estipulado.
Meta	O valor máximo da ABC Metric recomendado pela ferramenta Rubocop é 15.0. Logo, um método será considerado bom em relação a essa métrica caso seu valor ABC não ultrapasse 15.0.

Métrica	M2.1.1 - Complexidade Ciclomática
Objetivo da medição	Garantir que a testabilidade (fonte) e a coesão (fonte) do software estejam boas
Fórmula	M = E - N + 2P, onde M é a complexidade ciclomática, E é o número de arestas do digrafo de fluxo de controle, N é o número de nós do dígrafo e P é a quantidade de componentes fortemente conectados no digrafo
Escala da medição	Nominal
Coleta	Responsável: Lucas Mattioli Periodicidade ou Evento: Release 1: Após a finalização dos casos de usos Release 2: Ao final de cada sprint Ferramenta: Code Climate/Rubocop Armazenamento: Os dados ficarão armazenados em planilha excel disponível no google drive do projeto para consultas futuras e cruzamento de dados.
Análise	Responsável: Matheus Figueiredo Procedimentos: Analisar os pontos do código em que a complexidade está alta e agir para que tais pontos sejam refatorados.
Meta	Baseando-se nos limites da ferramenta Mezuro: Excelente - [0, 3) Bom - [3, 5) Regular - [5, 7) Ruim - [7, INF)

Métrica	M3.1.1 - Cobertura de teste
Objetivo da medição	Garantir que produto mantenha no nível de desempenho nas condições estabelecidas
Fórmula	Cobertura = Linhas testadas/Total de linhas de código
Escala da medição	Racional
Coleta	Responsável: Lucas Mattioli Periodicidade ou Evento: Release 1: Após a finalização dos casos de usos Release 2: Ao final de cada sprint Ferramenta: Coveralls Armazenamento: Os dados ficarão armazenados em planilha excel disponível no google drive do projeto para consultas futuras e cruzamento de dados.
Análise	Responsável: Matheus Figueiredo Procedimentos: Fazer um histórico de porcentagem de testes das histórias e buscar entender padrões e causas de desvio da meta.
Meta	Release 01: Esperado: > 30% Release 02: Esperado > 90%

5. Ferramentas

Logo	Ferramenta	Propósito
	CodeClimate	Realiza coleta de métricas
	Rubocop	Realiza coleta de métricas
	Travis CI	Realiza integração contínua
	Coveralls	Realiza cobertura de teste
	Cucumber	Realiza testes de aceitação automatizados

5.1. CodeClimate

O CodeClimate é a ferramenta utilizada para análise estática de código e coleta de métricas. O CodeClimate conta com o suporte de várias engines (plugins), que, basicamente, são ferramentas desacopladas desenvolvidas pelo próprio time do CodeClimate e por usuários externos. Esses plugins podem ser facilmente acoplados e desacoplados da aplicação do projeto por meio do arquivo de configuração .codeclimate.yml.

A principal engine do CodeClimate utilizada no projeto é a Rubocop. Esta faz análise de atributos como complexidade ciclomática, tamanho de métodos, tamanho de blocos e tamanho de classes.

5.2. Travis CI

A ferramenta Travis CI é responsável por verificar se toda modificação feita em código gera uma build funcional. Isto é, a cada commit, são verificados erros de sintaxe, erros de configuração, falha nos testes etc. Caso nada disso aconteça, a build é dita como "aceita" e o desenvolvedor tem o indicativo de que a sua alteração está, provavelmente, correta.

5.3. Coveralls

Para este projeto, a ferramenta Coveralls será utilizada para fazer a cobertura de testes. Com o auxílio do Travis CI, o Coveralls indica, em porcentagem, a quantidade de linhas testadas para cada arquivo do projeto, além da cobertura de testes geral do projeto.

5.4. Cucumber

Cucumber é uma ferramenta que permite times de desenvolvimento descrever, em texto, como o software deve se comportar. O texto é escrito em uma linguagem de domínio específica e serve como documentação e instruções para os testes automatizados

6. Monitoramento e Controle

6.1. Periodicidade

O monitoramento e controle até a release 1 ocorrerá uma vez em caso do fluxo principal chegar até o fim sem nenhum erro, em caso de entrar em fluxos alternativos será realizado a melhoria de código e quantos monitoramentos e controle forem necessários até a data de entrega (19/04/17).

Na release 2 com a utilização de métodos ágeis, o monitoramento vai ocorrer uma vez por semana, ao final de cada sprint.

6.2. Responsáveis

Qualidade dos artefatos
Atividade	Responsáveis
Confeccionar artefato	Todos os membros
Revisar artefato	GPP
	Coaches
Corrigir artefato	Membros que elaboraram artefato
Propor melhorias	Todos os membros
	Coaches
	Professor
Qualidade de código
Atividade	Responsáveis
Coletar dados	Lucas Mattioli
	Victor Hugo
Interpretar dados	Matheus Figueiredo
	Naiara Andrade
Analisar resultados das medições	Matheus Figueiredo
	Naiara Andrade
Revisar código	Leonardo Arthur
	Victor Hugo
	Membro de MDS que não participou da elaboração do código
Refatorar código	Membro(s) MDS/GPP que elaborou o código
Propor melhorias	Qualquer membro da equipe

7. Referência Bibliográfica

• Disponível em <https://blog.guilhermegarnier.com/2014/11/ferramentas-para-avaliacao-de-qualidade-de-codigo-ruby/>. Acesso em 15/04/2017

• Disponível em <https://docs.codeclimate.com/v1.0/docs/list-of-engines>. Acesso em 15/04/2017

• Disponível em <http://www.mccabe.com/pdf/mccabe-nist235r.pdf>. Acesso em 18/04/2017

• Disponível em <http://thescipub.com/PDF/jcssp.2005.137.144.pdf>. Acesso em 18/04/2017