Saltar para o conteúdo

Pardal

Fonte: Wikiversidade

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.

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.

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.

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

[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ó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

[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 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>
Tabela 4 - Baselines
[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 (b​ug, ​d​uplicate, 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 (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

[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 (m​irror)​ da versão mais recente dos artefatos que se encontram no Redmine na máquina de dois membros da equipe do projeto.

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

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.

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

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]

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:

[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]
code coverage







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.