Pardal
Introdução
[editar | editar código-fonte]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
[editar | editar código-fonte]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
[editar | editar código-fonte]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,eabrange todo o controle e gerenciamento da configuração do projeto Pardal.
Glossário
[editar | editar código-fonte]Termo | Descrição |
---|---|
Baseline | Conjunto de artefatos que recebe uma aprovação de estabilidade. Uma baseline é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 (Change Request). |
SGBD | Sistema de Gerenciamento de Banco de Dados. |
Tabela 1 - Glossário
Organização
[editar | editar código-fonte]Identificação dos documentos
[editar | editar código-fonte]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
[editar | editar código-fonte]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
[editar | editar código-fonte]Todos itens de configuração (exceto o códigofonte) devem ser mantidos na plataforma Redmine no seguinte domínio: <http://lappis.unb.br/redm/projects/grupo1sistemamultadprf/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
[editar | editar código-fonte]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 milestoneno 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> |
Tabela 4 - Baselines
[editar | editar código-fonte]Branches
[editar | editar código-fonte]Esta seção define as políticas de branch utilizada no processo.
Branches de documento
[editar | editar código-fonte]Durante o projeto, não será definida uma política de branches para criação de documentos.
Branches de código
[editar | editar código-fonte]Para cada funcionalidade, deve ser criada uma respectiva branch de trabalho no repositório remoto.
Controle de Configuração
[editar | editar código-fonte]Procedimentos de mudança
[editar | editar código-fonte]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)
[editar | editar código-fonte]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 (bug, duplicate, enhancement, etc), uma milestone associada e uma pessoa responsável.
Ciclo de vida das Solicitações de Mudança (CRs)
[editar | editar código-fonte]As issues devem possuir os seguintes estados: aberta (open) e fechada (closed).
Qualquer membro da equipe pode abrir uma issue,e da mesma forma qualquer membro da equipe pode tomar para si uma issue aberta. Quando uma issue aberta for concluída, deve-se fecha-la o mais rápido possível.
Integração Contínua
[editar | editar código-fonte]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
[editar | editar código-fonte]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
[editar | editar código-fonte]Uma vez por semana será feito um backup (mirror) da versão mais recente dos artefatos que se encontram no Redmine na máquina de dois membros da equipe do projeto.
Ferramentas
[editar | editar código-fonte]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
[editar | editar código-fonte]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
[editar | editar código-fonte]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
[editar | editar código-fonte]Configuração do Jenkins para build de Testes Unitários e Cobertura de Código com Jacoco para aplicações desenvolvidas no Android Studio
[editar | editar código-fonte]1-Para instalação do Jenkins em sistemas Ubuntu, digite os seguintes comandos no terminal:
[editar | editar código-fonte]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
2-Execute o comando “android" no terminal e em seguida instale todas as dependências necessárias para o build do projeto.
[editar | editar código-fonte]3-Após isso, acesse o Jenkins pelo navegador através do link:
[editar | editar código-fonte]4-Selecione a opção “Gerenciar Jenkins, e em seguida “Gerenciar plugins”. Na aba “Disponíveis”, procure e instale os seguintes plugins:
[editar | editar código-fonte]• Git plugin;
• Github plugin;
• Android Emulator Plugin;
• Gradle plugin;
• Jacoco Plugin.
5-Na Dashboard, selecione “Novo job”, dê um nome para o job, e selecione “Construir um projeto de software free-style”. Coloque o nome do projeto, a URL do repositório Git, a branch a ser analisada, e etc.
[editar | editar código-fonte]6-Na seção “Build”, selecione "Adicionar passo no build” e escolha “Invoke Gradle script”. Selecione a opção “Use Gradle Wapper”. No campo “Tasks”, coloque os comandos: "clean jacocoTestReport”.
[editar | editar código-fonte]7-Em seguida, selecione “Adicionar ação de pós-build” e selecione “Record JaCoCo coverage suport".
[editar | editar código-fonte]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:
[editar | editar código-fonte]// 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.
[editar | editar código-fonte]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).
10-Após essas configurações, clique no botão Salvar e depois clique na opção “Construir agora”. O Jenkins deve fazer um build dos testes, e gerar um relatório com a cobertura de código.
[editar | editar código-fonte]Imagem do gráfico de cobertura gerado da branch first_release
[editar | editar código-fonte]
Dificuldades
[editar | editar código-fonte]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.