Autor	Data
Josué Nascimento	16/03
Josué Nascimento	17/03
Josué Nascimento	19/03
Álax Alves	22/03
Josué Nascimento	24/03
Rodrigo Oliveira	25/03

Partindo do processo descrito, segue os resultados de cada respectiva atividade.

Partindo do interesse da equipe em ter diretrizes que comprovem a boa aplicação dos padrões de projeto, existe a necessidade produzir código que obeceça as diretrizes propostas pelos mesmos.

Analisar	o código
Com o proposito de	produzir incrementos que obedeçam padrões de projeto
Com respeito a	a disciplina de Desenho de Software
Sobre o ponto de vista do	desenvolvedor
No contexto do	Projeto Pan Pan

Objeto	Proposta	Foco de qualidade	Ponto de vista
Padrões de Projeto	Aplicação	Boa aplicação de padrões de projeto	Equipe de desenvolvimento

Foco na qualidade: Os Padrões de Projeto estão aplicados de forma eficiente?	Fatores de variação: Dificuldade na aplicação dos padrões de projeto Desconhecimento da tecnologia utilizada.
Hipótese de baseline: A equipe desconhece valores para essas métricas.	Impacto das hipóteses de base line: Desconhecimento dos padrões a serem aplicados.

As seguintes métricas foram escolhidas pelo time - embasados por Kemerer,1994 - e serão utilizadas para avaliar a "qualidade" da implementação dos padrões de projeto.

Métricas
Response for a Class(RFC)
Lack of Cohesuin of Methods(LCOM)
Coupling Between Object Classes(CBO)
Depth Of Inharitance(DIT)
Number of Children(NOC)

A ferramenta a ser utilizada para a obtenção dessas métricas será o Analizo.

Objetivo	Analisar a combinação de complexidade de uma classe através do numero de métodos e da quantidade de comunicação com outras classes
Escala de medição	Escala Absoluta
Coleta	Responsável: Equipe de desenvolvimento Periodicidade: Ao final de cada sprint Procedimentos: Submeter o projeto a ferramenta analizo
Analise	Responsavel: Equipe de desenvolvimento

Objetivo	Analisar a coesão de classe e similaridade entre métodos
Escala de medição	Escala Absoluta
Coleta	Responsável: Equipe de desenvolvimento Periodicidade: Ao final de cada sprint Procedimentos: Submeter o projeto a ferramenta analizo
Analise	Responsavel: Equipe de desenvolvimento

Objetivo	Analisar o acoplamento entre classes
Escala de medição	Escala Absoluta
Coleta	Responsável: Equipe de desenvolvimento Periodicidade: Ao final de cada sprint **Procedimentos:**Submeter o projeto a ferramenta analizo
Analise	Responsavel: Equipe de desenvolvimento

Objetivo	Analisar grau de complexidade da arvore de hierarquia
Escala de medição	Escala Absoluta
Coleta	Responsável: Equipe de desenvolvimento Periodicidade: Ao final de cada sprint Procedimentos: Submeter o projeto a ferramenta analizo
Analise	Responsavel: Equipe de desenvolvimento

Objetivo	Analisar grau de complexidade da arvore de hierarquia
Escala de medição	Escala Absoluta
Coleta	Responsável: Equipe de desenvolvimento Periodicidade: Ao final de cada sprint **Procedimentos: **Submeter o projeto a ferramenta analizo
Analise	Responsavel: Equipe de desenvolvimento

O plano de Análise é um documento que simula a interpretação dos dados para a definição das métricas, ele fornece orientação sobre como as informações a serem coletadas precisam ser organizadas para facilitar a sua utilização e garantir a permanência do foco sobre os objetivos. Os valores para os indicadores dessas métricas foram retirados do artigo A Validation of Object-Oriented Design Metrics as Quality Indicators e do site Objecteering

INDICADOR	Response for Class
RESPONSÁVEL PELA COLETA	Equipe de desenvolvimento
DEFINIÇÃO	Analizo
ANÁLISE	Quanto maior o RFC, mais complexa é a classe, portanto o valor permitido neste projeto deve estar entre 0 - 50
FREQUÊNCIA	Acada interação
ORIGEM	Repositório do Github

INDICADOR	Lack of Cohesion of Methods
RESPONSÁVEL PELA COLETA	Equipe de desenvolvimento
DEFINIÇÃO	Analizo
ANÁLISE	O índice varia entre [0-1], onde 0 indica máxima coesão e 1 total falta de coesão. Valor máximo permitido para este projeto é de 0.5.
FREQUÊNCIA	Acada interação
ORIGEM	Repositório do Github

INDICADOR	Coupling Between Object Classe
RESPONSÁVEL PELA COLETA	Equipe de desenvolvimento
DEFINIÇÃO	Analizo
ANÁLISE	Um valor de 0 indica que uma classe não tem relação com nenhuma outra classe no sistema e, portanto, não deve fazer parte do sistema. Um valor entre 1 e 4 é bom, pois indica que a classe está fracamente acoplada. Um número maior do que isso pode indicar que a classe está muito fortemente acoplada a outras classes no modelo, o que complicaria o teste e a modificação e limitaria as possibilidades de reutilização. Considere desacoplar essa classe das classes às quais essa classe está acoplada e construa a classe para que seja mais independente, fornecendo um conjunto mais completo de operações.
FREQUÊNCIA	Acada interação
ORIGEM	Repositório do Github

INDICADOR	Depth Of Inharitance
RESPONSÁVEL PELA COLETA	Equipe de desenvolvimento
DEFINIÇÃO	Analizo
ANÁLISE	Um balanço entre o alto desempenho fornecido pela herança e a complexidade que aumenta com a profundidade deve ser encontrado. Um valor entre 0 e 4 respeita este balanço. Um valor maior que 4 compromete o encapsulamento e aumenta a complexidade.
FREQUÊNCIA	Acada interação
ORIGEM	Repositório do Github

INDICADOR	Number of Children
RESPONSÁVEL PELA COLETA	Equipe de desenvolvimento
DEFINIÇÃO	Analizo
ANÁLISE	Os limites superior e inferior de 1 e 3 correspondem a uma média desejável. Porém classes do tipo utilitárias poderão ter índices maiores que 3.
FREQUÊNCIA	Acada interação
ORIGEM	Repositório do Github

CHIDAMBER, S. R.; KEMERER, C. F. A Metrics Suite for Object Oriented Design. IEEE Transactions on Software Engineering, v. 20, n. 6, June 1994. BASILI,R.V; MELO, L. W. A Validation of Object-Oriented Design Metrics as Quality Indicators 10 Octuber 1996 ROSENBERG, L. H.; Software Quality Metrics for Object-Oriented Environments