Pardal

Introdução

O Plano de Gerência de Configuração descreve todas as atividades do Gerenciamento de Controle de Configuração e Mudança que serão executadas durante o ciclo de vida do projeto Pardal. Suas atividades envolvem identificar a configuração do software, definir e manter sua integridade durante o projeto e controlar sistematicamente as mudanças.

Finalidade

A finalidade deste documento é criar um padrão a ser seguido por todos os membros da equipe com o intuito de garantir o maior controle do produto no decorrer do projeto.

Escopo

Este Plano de Gerenciamento de Configuração é destinado para todos os integrantes da equipe responsável pelo desenvolvimento do aplicativo Pardal nas disciplinas de MDS e GPP,​e​abrange todo o controle e gerenciamento da configuração do projeto Pardal.

Glossário

Termo	Descrição
Baseline	Conjunto de artefatos que recebe uma aprovação de estabilidade. Uma b​aseline é​usada com uma base no desenvolvimento das próximas fases dos artefatos e tem suas modificações controladas por um processo.
CR	Solicitação de mudança (C​hange Request)​.
SGBD	Sistema de Gerenciamento de Banco de Dados.

Tabela 1 - Glossário

Organização

Identificação dos documentos

Todos os itens de configuração(exceto código fonte) devem ser identificados baseados nomeclatura descrita a seguir:

<Projeto>_<ID_Tipo_de_Artefato>_<Nome_Artefato>

em que:

<Projeto> é o nome do projeto;

<ID_Tipo_de_Artefato> : é a identificação do artefato(ver Tabela 2);

<Nome_Artefato>: nome do documento que compõe o artefato.

Artefato	Identificação
Gerenciamento da Integração do Projeto	GIP
Gerenciamento do Escopo do Projeto	GEP
Gerenciamento do Tempo do Projeto	GTP
Gerenciamento dos Custos do Projeto	GCP
Gerenciamento da Qualidade do Projeto	GQP
Gerenciamento dos Recursos Humanos do Projeto	GRHP
Gerenciamento das Comunicações do Projeto	GCOP
Gerenciamento dos Riscos do Projeto	GRP
Gerenciamento das Aquisições do Projeto	GAP
Especificação dos Requisitos do Sistema	ERS
Arquitetura e Testes	AT

Tabela 2 - Artefatos e suas respectivas identificações

Versão dos documentos

Os artefatos criados ao longo do projeto devem ter um número de versào segundo o o padrão descrito a seguir:

Y .XX

em que:

• X é um número decimal que representa uma versão final do artefato;
• YY é um número hexadecimal que representa um draft da versão X do artefato.

O número de versão dos artefatos muda de acordo com as regras descritas a seguir:  

• A primeira versão do artefato deve ser 0.01;
• A cada modificação, o valor YY deve ser incrementado;  
• Após cada aprovação do artefato, a versão X deve ser incrementada de uma unidade e o valor YY retorna 00. 

O controle de versão dos códigos-fonte se dará pela ferramenta Git, utilizando o serviço de repositório remoto GitHub. 

Localização dos artefatos

Todos itens de configuração (exceto o código­fonte) devem ser mantidos na plataforma Redmine no seguinte domínio: <http://lappis.unb.br/redm/projects/grupo­1­sistema­multa­dprf/wiki>. O código fonte deve ser mantido no repositório remoto GitHub no seguinte domínio: <https://github.com/Modesteam/Pardal> . A localização específica dos artefatos nos diretórios está descrita na tabela 3.

Diretório	Subdiretório	Artefatos
desenvolvimento	ERS	Documento de Visão
		Especificação Suplementar
		Especificação de Casos de Uso
	AT	Especificação de Casos de Teste
		Relatório de Teste
		Documento de Arquitetura
gerenciamento	GIP	Project Charter
		Plano de Gerenciamento do Projeto
		Plano de Gerenciamento de Mudanças
	GEP	Plano de Gerenciamento do Escopo
		Plano de Gerenciamento dos Requisitos
		EAP
		Registro de Controle do Escopo
	GTP	Plano de Gerenciamento do Cronograma
		Cronograma do Projeto
		Registro de Controle do Cronograma
	GCP	Plano de Gerenciamento dos Custos
		Registro de Controle dos Custos
	GQP	Plano de Gerenciamento de Qualidade
		Registro do Controle da Qualdiade
	GRHP	Plano de Gerenciamento dos Recursos Humanos
		Registro de Controle dos Recursos Humanos
	GCOP	Plano de Gerenciamento das Comunicações
		Registro do Controle das Comunicações
	GRP	Plano de Gerenciamento dos Riscos
		Registro do Controle dos Riscos
	GAP	Plano de Gerenciamento das Aquisições
		Registro do Controle das Aquisições

Tabela 3 - Organização dos diretórios

Baselines do projeto

Baseline	Descrição	Padrão
Definição do Escopo	Deve ser marcado assim que o escopo for totalmente definido.	PARDAL_REQ_<iteração>
Definição dos Requisitos e Arquitetura do Sistema	Deve ser marcado assim que for concluída a definição de requisitos e arquitetura do sistema de cada iteração.	PARDAL_REQ_ARQ_<iteração>
Release	Deve ser criada uma milestone​no GitHub para cada release a ser desenvolvida.​	PARDAL_RELEASE_<versão>
Build	Criado para cada geração de build para o software.	PARDAL_BUILD_<versão>

Branches

Esta seção define as políticas de branch utilizada no processo.

Branches de documento

Durante o projeto, não será definida uma política de branches para criação de documentos.

Branches de código

Para cada funcionalidade, deve ser criada uma respectiva branch de trabalho no repositório remoto.

Controle de Configuração

Procedimentos de mudança

Caso uma funcionalidade ou mudança a ser implementada for identificada por algum membro do grupo, uma CR deve ser aberta conforme descrito no sub-tópico abaixo.

Criação de Solicitação de Mudança (CRs)

As solicitações de mudanças ou funcionalidades devem ser criadas em forma de issues no próprio repositório remoto do GitHub. A issue criada sempre deve conter um título, uma descrição associada, um tipo (b​ug, ​d​uplicate, enhancement, etc)​, uma milestone associada e uma pessoa responsável.

Ciclo de vida das Solicitações de Mudança (CRs)

As issues devem possuir os seguintes estados: aberta (o​pen) ​e fechada (c​losed)​.

Qualquer membro da equipe pode abrir uma i​ssue,​e da mesma forma qualquer membro da equipe pode tomar para si uma i​ssue a​berta. Quando uma i​ssue a​berta for concluída, deve­-se fecha-­la o mais rápido possível.

Integração Contínua

A equipe de Gerência de Configuração deve configurar um servidor Jenkins que irá fazer um build do projeto inteiro a cada push no repositório remoto. O Jenkins também deve informar a cobertura de código atual a cada build, e notificar por e-mail os membros do projeto caso um build tenha falhado.

Auditoria de Configuração

As auditorias de configuração devem ser feitas para cada ciclo do processo de desenvolvimento de forma a garantir que o processo de Gerência da Configuração vem sendo aplicado corretamente.

Plano de Contingência

Uma vez por semana será feito um backup (m​irror)​ da versão mais recente dos artefatos que se encontram no Redmine na máquina de dois membros da equipe do projeto.

Ferramentas

Ferramenta	Descrição
Ubuntu 14.04 ­ Linux	Sistema Operacional utilizado para desenvolvimento.
Android Studio IDE	IDE utilizado no desenvolvimento da aplicação.
Android SDK Tools	Android Software Development Kit
SQLite 3.8.9	SGBD a ser utilizado no projeto.
Astah Professional	Modelagem UML.
DotProject	Ferramenta de cronograma.
Jenkins	Ferramenta de integração contínua.

Tabela 4 - Ferramentas

Jenkins

O Jenkins é uma ferramenta utilizada para realizar a integração contínua, uma das práticas mais importantes do desenvolvimento ágil. Com a integração contínua é possível agilizar a compilação de um projeto e a execução de seus testes automatizados. Usando o Jenkins como servidor de integração contínua, essas tarefas são executadas a cada mudança no repositório de código e, em caso de erros de compilação ou falhas nos testes automatizados, todos os desenvolvedores são alertados rapidamente.

Cronograma

A tabela abaixo define as atividades da Gerência de Configuração no contexto do projeto Pardal e também quando elas serão realizadas.

DATA	Atividade
10/05	Divulgação do Plano de GCS para a equipe de desenvolvimento
25/05	Reunião com todos os membros de GPP e MDS do projeto Pardal
25/05 - 10/06	Configuração da ferramenta Jenkins para build do código
10/06 - 17/06	Configuração da ferramenta Jenkins para build de testes automatizados
15/06	Reunião com os membros de GPP e MPS do projeto Pardal
24/06 - 01/07	Gerar builds periodicamente trazendo report com a cobertura de código

Relatório

Configuração do Jenkins para build de Testes Unitários e Cobertura de Código com Jacoco para aplicações desenvolvidas no Android Studio

1-Para instalação do Jenkins em sistemas Ubuntu, digite os seguintes comandos no terminal:

wget -q -O - https://jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -

sudo sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list'

sudo apt-get update

sudo apt-get install jenkins

3-Após isso, acesse o Jenkins pelo navegador através do link:

https://localhost:8080

4-Selecione a opção “Gerenciar Jenkins, e em seguida “Gerenciar plugins”. Na aba “Disponíveis”, procure e instale os seguintes plugins:

• Git plugin;

• Github plugin;

• Android Emulator Plugin;

• Gradle plugin;

• Jacoco Plugin.

7-Em seguida, selecione “Adicionar ação de pós-build” e selecione “Record JaCoCo coverage suport".

No campo "Path to exec files (e.g.: **/target/**.exec, **/jacoco.exec)", coloque o caminho: " **/**.ec”.

No campo "Path to class directories (e.g.: **/target/classDir, **/classes)” coloque o caminho: “**/app/build/intermediates/classes/" (ou o caminho onde se encontra os arquivos .class do projeto).

No campo "Path to source directories (e.g.: **/mySourceFiles)” coloque o caminho: “**/app/src/main/java" (ou o caminho onde se encontra o código fonte da aplicação).

8-No arquivo build.grade (que se encontra no workspace da aplicação), adapte conforme descrito a seguir:

// Adicione

apply plugin: 'jacoco'

android {
          .
          .
          .
          /* No final da função adicione: */
          testInstrumentationRunner “android.support.test.runner.AndroidJUnitRunner"

          buildTypes {

                 debug {
                             testCoverageEnabled = true
                 }
                 release {
                             minifyEnabled false
                             proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
                 }
         }
}

jacoco {
            version "0.7.1.201405082137"
}

dependencies {
            .
            .
            .
            /* No final da função adicione: */
            testCompile ‘junit:junit:4.12’
            testCompile “org.mockito:mockito-core:1.9.5"
}
sourceSets {
        testLocal {
              java.srcDir file('src/androidTest/')
        }
}

9-O JaCoCo requer que o emulador esteja executando para que os testes sejam construídos. Para isso, pode-se executar o emulador do Android Studio, ou configurar o Jenkins para lança o emulador durante o build.

Para que isso seja feito, deve-se marcar a opção “Run an Android emulador during build” na seção de configurações do job. Em seguida, escolha uma das opções: “Run existing emulator" ou "Run emulador with properties" (escolha a que melhor se adequar a seu contexto).

Imagem do gráfico de cobertura gerado da branch first_release

code coverage

Dificuldades

1-O Gradle é utilizado pelo Android Studio para automatizar as builds. No decorrer do trabalho encontramos dificuldades em encontrar materiais de apoio para trabalhar com o Gradle, a maioria dos materiais dão apoio para os que utilizam Ant.

2-Dificuldade em rodar os testes e gerar o gráfico de cobertura de código, pois para isso o arquivo build.gradle teve que ser alterado.