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

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
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	30 h	500,00
Ambiente	30 h	500,00
Equipamento	30 h	500,00
Documentação	30 h	500,00
Desenvolvimento	30 h	500,00
Valor	300 h	5000,00
Custos de Avaliação
Testes	30 h	500,00
Inspeção	30 h	500,00
Valor	300 h	5000,00

Dinheiro gasto durante o projeto para evitar falhas

Custo da falta de Conformidade
Custos de falha interna
	Horas Gastas	Valor
Refatoração	30 h	500,00
Valor	30 h	500,00

Dinheiro gasto durante e após o projeto devido a 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	melhorar
Com respeito a	manutenibilidade do software
Sob o ponto de vista da	equipe do projeto
No contexto	projeto Escola X

Analisar	produto
Com o propósito de	entender e melhorar
Com respeito a	confiabilidade do sistema
Sob o ponto de vista da	equipe do projeto
No contexto	projeto Escola X

4.2. Questões

manutenibilidade Qual a facilidade do sistema ser modificado?

• Coffee
• Tea
• Milk

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?	melhorar
Hipóteses de Baselines	Impacto na Hipótese de Baselines
Q1.1. Alta coesão Q1.2. Baixo acoplamento Q2.1. Complexidade ciclomática (0-3 MEZURO) Q3.1 Release 1: Cobertura de teste > 30% e Release 2: Cobertura de teste > 90%	melhorar

Foco da Qualidade	Fatores de Variação
Q3. O produto se mantém no nível de desempenho nas condições estabelecidas?	melhorar
Hipóteses de Baselines	Impacto na Hipótese de Baselines
Q3.1 Release 1: Cobertura de teste > 30% e Release 2: Cobertura de teste > 90%	melhorar

4.3. Métricas

As métricas a serem medidas no projeto são: Tamanho de Bloco, Tamanho de Classe, Complexidade Ciclomática e Tamanho de Método. Abaixo segue o detalhamento de cada uma das ditas métricas.

Métrica	M3.1.1 - Cobertura de teste
Objetivo da medição	melhorar
Fórmula	manutenibilidade do software
Escala da medição	equipe do projeto
Coleta	projeto Escola X
Análise	projeto Escola X
Meta	projeto Escola X

4.3.1. Tamanho de Bloco

TODO

4.3.2. Tamanho de Classe

TODO

4.3.3. Complexidade Ciclómatica

TODO

4.3.4. Tamanho de Método

TODO

5. Ferramentas

Logo	Ferramenta	Propósito
	CodeClimate	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