QualisTec. Plano de Gerência de Configuração. Projeto: Simul-e. Versão 1.1. Página 1 de 16. Plano de Gerência de Configuração

Transcrição

1 1 QualisTec Projeto: Simul-e Versão 1.1 Arquivo: Gerenciamento de Configuração QualisTec - v1.1.doc Página 1 de 16

2 2 Histórico de Alterações Data Versão Descrição Autor 28/04/ Documento de Gerenciamento de Configuração 30/04/ Alteração e Revisão do Documento de Gerenciamento de Configuração Hugo Pazolline Hugo Guilherme 11/05/ Revisão de todo o documento Hugo Pazolline 25/05/ Peer review Ivonaldo Torres Arquivo: Gerenciamento de Configuração QualisTec - v1.1.doc Página 2 de 16

3 Conteúdo 1. INTRODUÇÃO FINALIDADE ESCOPO DEFINIÇÕES, ACRÔNIMOS E ABREVIAÇÕES REFERÊNCIAS VISÃO GERAL GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE ORGANIZAÇÃO, RESPONSABILIDADES E INTERFACES FERRAMENTAS, AMBIENTE E INFRAESTRUTURA O PROGRAMA DE GERENCIAMENTO DE CONFIGURAÇÃO IDENTIFICAÇÃO DA CONFIGURAÇÃO Métodos de Identificação Localização de Artefatos Baselines do Projeto Versionamento dos Itens de Configuração Trunk...Erro! Indicador não definido Política de Commit Política de Criação de Branches Política de Criação de Tags Política de realização de Merge Versionamento de Software Versionamento de Banco de Dados Permissão de Acesso Processamento e Aprovação de Solicitações de Mudança Comitê de Controle de Mudança (CCB) ESTIMATIVA DO STATUS DE CONFIGURAÇÃO Processo de Armazenamento de Mídia e Liberação do Projeto Relatórios e Auditorias MARCOS...ERRO! INDICADOR NÃO DEFINIDO. 5. TREINAMENTO E RECURSOS...ERRO! INDICADOR NÃO DEFINIDO. 6. CONTROLE DE SOFTWARE DE SUBCONTRATADOS E FORNECEDORES A LIBERTY ACCESS NÃO SUBCONTRATA ATUALMENTE DESENVOLVIMENTO DO SOFTWARE Arquivo:.doc Página 3 de 16

4 4 1. Introdução A intenção do Gerenciamento de Configuração é estabelecer e manter a integridade dos produtos do projeto durante seu ciclo de vida. As principais atividades envolvem identificar a configuração de software, manter sua integridade durante o projeto e controlar sistematicamente as mudanças. Esse plano contém todas as informações referentes ao sistema de gerência de configuração para o projeto Simul-e. 1.1 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. Para que isso aconteça serão detalhados os recursos necessários (equipes, ferramentas e computadores), as responsabilidades atribuídas e o cronograma de atividades. 1.2 Escopo Este Plano de Gerenciamento de Configuração é destinado para todos os integrantes da equipe responsável pelo desenvolvimento do aplicativo Simul-e na disciplina de Gerência de Projetos, e abrange todo o controle e gerenciamento da configuração do projeto. 1.3 Definições, Acrônimos e Abreviações. Esta seção explica o conceito de alguns termos importantes que serão mencionados no decorrer deste documento, os quais estão diretamente relacionados ao processo de gerência de configuração de software Termo SCRUM GC ou GCS CCB RH SG I.D.E CVS CR CI Significado É um processo ágil que permite manter o foco na entrega do maior valor de negócio, no menor tempo possível. Gerência de Configuração Comitê para o Controle de Mudanças. Recursos Humanos Sistema de Gerenciamento IntegratedDevelopmentEnviroment É um sistema de controle de versão É o pedido de alteração de baseline. Item de Configuração: Qualquer artefato produzido durante o ciclo de vida do projeto e mudanças será controlado através de um processo formal. Arquivo:.doc Página 4 de 16

5 5 Baseline Conjunto de artefatos aprovados e revisados que serão usados em atividades posteriores. É uma base de comum acordo para evoluções e desenvolvimento. Branch Build Linha de desenvolvimento paralela a linha principal do repositório. Representa uma versão ainda incompleta do sistema em desenvolvimento, mas com certa estabilidade. Caso venha a ser liberado, deverá ser feito através de um release. Contém arquivos de instalação, código fonte, arquivos de dados, programas de instalação e documentação. GEDES Gerente de Configuração Item de Configuração Merge Gerência de Desenvolvimento Responsável pela atividade de gerência de configuração de software durante um projeto de software. Qualquer artefato produzido durante o ciclo de vida do projeto cujas mudanças serão controladas por um processo formalizado. O merge é uma operação que integra alterações de uma determinada branch com ao trunk do repositório (ou até mesmo com uma outra branch). PGCS Release de Software Versão do sistema validada. Conjunto de itens que é enviado para o cliente. Cada release pode incluir novas funcionalidades ou alguma mudança decorrente de customização, desenvolvimento, testes, mudança de legislação, etc Repositório Tag/Label Commit Local onde os itens de configuração são armazenados. Rótulo de identificação para um conjunto deitens de configuração. A ação de enviar as alterações ou obter a versão mais recente do repositório App Aplicativo FACOL Faculdade Escritor Osman da Costa Lins Simul-e Nome do aplicativo a ser desenvolvido Mobile Refere-se a dispositivos móveis MySQL Sistema de Gerenciamento de Banco de Dados Android Sistema Operacional para dispositivos móveis O.S. Operational System (Sistema Operacional) JAVA Linguagem de programação Arquivo:.doc Página 5 de 16

6 6 1.4 Referências Template de Plano de Gerenciamento de Configuração, , IBM. 1.5 Visão Geral As próximas seções deste documento estão divididas conforme a tabela abaixo Seção 2 Descrição São relacionados os papéis, as responsabilidades das atividades e as ferramentas dentro da GC da Fábrica. 3 É apresentado como serão criadas e controladas as Baselines São abordados os detalhes sobre quando o Plano de Gerenciamento de Configuração deve ser atualizado. Descreve as ferramentas de software, o pessoal e o treinamento necessários para implementar as atividades de CM especificadas. Descreve de que forma o software desenvolvido fora do ambiente do projeto será incorporado. 2. Gerenciamento de Configuração de Software 2.1 Organização, Responsabilidades e Interfaces Papéis Equipe Responsabilidade Gerente de Configuração CCB Hugo Pazolline Paulo Rafael/Hugo Guilherme Estabelecer Políticas de GC Escrever Plano de GC Configurar Ambiente de GC Criar Espaços de Trabalho de Integração Criar Baselines Promover Baselines Estabelecer Processo de Controle de Mudanças Revisar Solicitação de Mudança Arquivo:.doc Página 6 de 16

7 7 Equipe de desenvolvimento Todos os Papéis Hugo Guilherme/ Paulo Rafael Eduardo Felipe/ Paulo Rafael Seguir os padrões e procedimentos definidos no Plano de Gerência de Configuração Enviar Solicitação de Mudança Atualizar Solicitação de Mudança Seguir os padrões e procedimentos definidos no 2.2 Ferramentas, Ambiente e Infraestrutura As seguintes ferramentas poderão ser utilizadas para manter o controle da Gerência de Configuração: Ferramenta Tipo Versão ProjectLibre Controle de mudança 2015 Google Drive Armazenamento de arquivos 2015 Microsoft Office Excel Microsoft Office PowerPoint Microsoft Office Word Planilha 2013 Apresentação 2013 Editor de Texto 2013 MySQL Banco de dados Hangouts Ferramenta de comunicação Cloud Service WhatsApp Ferramenta de comunicação Windows 7/8 Java/Xml Android Studio Sistema Profissional Linguagem de Programação p/ desenvolvimento do aplicativo. IDE de desenvolvimento de software Java Ultimate Edition Jre1.8.0_45 Luna SR2 (4.4.2) Arquivo:.doc Página 7 de 16

8 8 3. O Programa de Gerenciamento de Configuração 3.1 Identificação da Configuração Esta seção aborda os temas referentes à identificação dos itens de configuração, tais como identificação, nomenclatura, localização e versionamento Métodos de Identificação Os itens de configuração são os artefatos que terão seu ciclo de vida controlado ao longo do processo de desenvolvimento. Todos os itens de configuração, com exceção do código fonte e scripts de banco, devem ser identificados de seguinte forma: Parte da Linha ORGANIZAÇÃO Identifica da empresa: QualisTec Significado PROJETO Identifica o projeto: Simul-e ARTEFATO Nome do artefato utilizado na criação do sistema. VERSÃO Número da versão EXT Extensão do arquivo do documento Localização de Artefatos Esta seção descreve a localização onde os artefatos estão armazenados. É apresentada uma versão de visão gráfica dos diretórios baseado na estrutura de diretórios em que cada artefato deve ser armazenado. Arquivo:.doc Página 8 de 16

9 Baselines do Projeto As baselines serão definidas em três fases. Fases Planejamento Arquitetura o projeto Release Itens de Configuração da Baseline Documentação (Artefatos do projeto) Código fonte contendo apenas a arquitetura do Projeto. - Camadas - Garantia transacional Fontes do sistema pronto Os Artefatos entrarão em baseline quando atingirem a forma mais estável do sistema Versionamento dos Itens de Configuração Todos os artefatos versionados no SVN deverão ter a descrição da alteração efetuada. O número de versão dos itens segue o padrão: X.Y Onde: X é um número decimal que representa uma versão final do artefato; Y é um número decimal 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 primeira versão do artefato deve ser 1.0; A cada modificação no artefato, o valor Y deve ser incrementado; Após cada aprovação do artefato, a versão X deve ser incrementada de uma unidade e o valor Y retorna para 0, sendo assim gerada uma nova versão oficial; Exemplo: Data Versão Descrição Autor Aprovador 28/04/ Versão inicial do documento. Hugo Pazolline Ivonaldo Torres Arquivo:.doc Página 9 de 16

10 10 Para que a versão de um artefato seja modificada é necessária a aprovação do moderador. É considerada uma aprovação do documento a aprovação do documento após uma revisão e aprovação por pelo menos dois membros do core group responsável pelo respectivo artefato Política de Commit Deve ser realizada a operação de Commit sempre que um caso do Mantis for concluído. Para os casos mais complexos (em que o desenvolvimento excederá um dia de programação) a realização Commit deverá ocorrer ao final do dia de trabalho no caso específico. Quando da realização da operação de Commit o registro do comentário deverá seguir o padrão: [MXXXX - SXXX] Comentário. Onde: MXXXX: Consiste na identificação do caso do Mantis a que se refere a mudança, sendo XXXX o número de identificação do caso no Mantis. SXXXX: Consiste na identificação da Sprint em que a mudança ocorreu, sendo XXX o número que identifica a Sprint. Este campo se aplica somente a projetos que utilizam a metodologia Scrum. Comentário: Consiste em informação relevante que identifica semanticamente a mudança realizada. O registro dos números do caso do Mantis e da Sprint são obrigatórios. Para projetos que não utilizam a metodologia Scrum deve ser informado explicitamente a não existência destas informações. O campo Comentário é opcional para casos triviais embora seja altamente recomendável o seu preenchimento. Não deverá ser realizado Commit para códigos que não compilem Política de Criação de Branches Uma nova branch deve ser criada sempre ao final de cada sprint. Esta branch será mantida até que o sistema seja homologado e entre em produção. Nela deverão ser feitas todas as alterações da versão do sistema que se encontra em processo de homologação. Em casos de modificações urgentes no sistema que devem ser tratados fora dos padrões do scrum, um novo branch também deverá ser criado. Quando as alterações forem concluídas, este branch deve ser integrado ao trunk do repositório. A nomenclatura de Branches, deve respeitar o seguinte padrão: Onde: <Versão> <Versão> é a versão do sistema que está sendo desenvolvida. O comentário quando da criação de Branch deve seguir o seguinte padrão: Criação de Branch <Nome>: <Motivo> - <SXXX> Arquivo:.doc Página 10 de 16

11 11 Onde: <Nome> é o nome da Branch conforme o padrão estabelecido nesta seção. <Motivo> é uma breve descrição da aplicação a que será destinado o Branch. <SXXX> é a identificação da sprint em que a Branch foi criada. Este campo só se aplica aos projetos sob a metodologia Scrum. Por exemplo, um Branch criado para corrigir possíveis erros durante a homologação de um sistema deverá registrar o seguinte comentário: Criação de Branch v1.11.4: Correção de Erros de Homologação S Política de Criação de Tags Uma nova tag deverá ser criada sempre que o sistema for submetido aos testes formais ou homologação e sempre que um novo release for liberado. A nova tag poderá ser feita a partir do branch que está sendo utilizado no processo de homologação do sistema. Ou do próprio trunk caso não existam alterações no processo de teste formais ou homologação (caso onde alterações são feitas no branch). A nomenclatura de Tags, deve respeitar o seguinte padrão: <Versão>TXX quando o sistema estiver em processo de teste. Ou: <Versão>HXX quando o sistema estiver em processo de homologação. Ou: <Versão> quando o sistema estiver homologado. Onde: <Versão> é a versão do sistema que está sendo desenvolvida. XX é um número sequencial iniciado em 01 que deve ser incrementado quando uma versão submetida a homologação for liberada e reiniciada quando uma nova versão do sistema for lançada. Quando o sistema estiver estável no ambiente de produção as tags de teste e homologação referente a esta versão do sistema devem ser apagadas. O comentário quando da criação de Tags deve seguir o seguinte padrão: Criação de Tag de <Tipo> <Nome> - <SXXX> Onde: <Tipo> define a destinação da Tag. Os tipos podem ser: Teste, Homologação e Produção. <Nome> é o nome da Tag conforme o padrão estabelecido nesta seção. Arquivo:.doc Página 11 de 16

12 12 <SXXX> é a identificação da sprint em que a Tag foi criada. Por exemplo, uma Tag criada durante a Sprint 11 para marcar o segundo Build que será destinado a Homologação na versão deverá registrar o seguinte comentário: Criação de Tag de Homologação v1.2.0h2 S Política de realização de Merge Sempre que houver alterações realizadas em um branch, após a homologação das mesmas deve ser realizada a atividade de Merge entre a tag homologada (decorrente da branch) e o trunk a fim de garantir que os erros corrigidos não retornem. <A descrição da atividade de realização de merge utilizando o TortoiseSVN se encontra no Processo de Gerência de Configuração> O comentário quando da realização de Merge deve seguir o seguinte padrão: Onde: Merge entre: <Tipo_Origem> <Nome_Origem> e <Destino> - <SXXX> <Origem> é o local de onde as mudanças serão obtidas. <Destino> é o local que receberá as mudanças. São exemplos de <Origem> e <Destino>: Branch v1.5.4, Tag v2.3.1, Trunk. <SXXX> é a identificação da sprint em que a Tag foi criada. Na situação em que se pretende levar ao Trunk as correções realizadas na Branch v4.0.1 durante a Sprint 20 deverá ser registrado o seguinte comentário: Merge entre: Branch v4.0.1 e Trunk S Versionamento de Software O versionamento de software deve seguir o seguinte padrão: Versão Maior.Versão Menor.Revisão Onde: Arquivo:.doc Página 12 de 16

13 13 Versão Maior: Somente é incrementado quando houver uma mudança significativa da arquitetura. Geralmente quando o núcleo do sistema é alterado, a compatibilidade com a versão antiga seja quebrada ou quando o sistema é completamente reescrito. Versão Menor: Incrementado quando houver alguma adição de funcionalidade ao sistema, quando houver alguma grande correção de bugs do sistema ou quando for realizada alguma melhoria no sistema. Revisão: Incrementado sempre que houver alguma correção de bug, pequena mudança de layout ou qualquer alteração de baixo esforço Versionamento de Banco de Dados O versionamento dos scripts de Banco de Banco deve seguir o padrão: - Nome do Banco_Libertya_Tipo do Script_Nome do Objeto[_Número de Sequência] MySQL - Tipo do Script: Pode assumir os valores: Procedure, Create, Alter, Indice, Constraints, View e DML. Ex.: Procedure - Nome do Objeto: Deve ser definido o nome do Objeto com base no padrão adotado pela UGBD. Ex.: SpAdvogadoComplemento_D_ Número de Sequência: Este campo é opcional devendo ser incluído apenas nos nomes dos arquivos de scripts de objetos que possam ter mais de um script com o mesmo nome do objeto. O número de sequência é um número de três dígitos. Para as procedures não é necessária a inclusão deste campo. Exemplos: dbcor01_dbo_create_atendimento_001.scp dbjze01_dbo_procedure_spadvogadocomplemento_d_001.scp Arquivo:.doc Página 13 de 16

14 Permissão de Acesso Para permissões de acesso na Ferramenta de Gestão de Configuração, segue: Equipe de Projeto Gerente de Configurações Acesso de leitura, criação e alteração (R, C, A) na estrutura de pastas do projeto que estiver atuando, exceto na pasta Gerenciamento de Configuração. Para os demais projetos e na pasta Gerenciamento de Configuração o acesso será somente de leitura (R). Acesso completo (R, C, A, D) em todos os projetos. Gerente de Projeto Acesso de leitura, criação e alteração (R, C, A) na estrutura de pastas do projeto que estiver atuando, exceto na pasta Gerenciamento de Configuração. Para os demais projetos e na pasta Gerenciamento de Configuração o acesso será somente de leitura (R). Acesso de leitura para todos os projetos (R). Analista de Qualidade Gerente de Fábrica de Software Acesso de leitura para todos os projetos (R). Legenda: R (read), C (check in/check out), A (add/rename/delete) e D (destroy) Processamento e Aprovação de Solicitações de Mudança O Comitê de Controle de Mudança estabelecido deve se reunir sob demanda e coletar todas as solicitações de mudanças em aberto. Para cada uma, o Comitê de Controle de Mudança deve fazer uma avaliação detalhada dos impactos em: Cronograma do projeto. Custos do projeto. Esforço. Artefatos/Componentes do sistema. A avaliação pode ser feita baseada em: - Tamanho da mudança. - Complexidade da mudança. Arquivo:.doc Página 14 de 16

15 15 - Severidade da mudança. - Prioridade da mudança. - Necessidade de testes da mudança; - Possíveis alternativas para a mudança. O moderador da inspeção deve revisar e aprovar todos os artefatos alterados pelos responsáveis pela solicitação de mudança. É importante notar que o moderador também é responsável por avaliar a integridade do(s) artefato(s) alterado(s) com outros itens da baseline Comitê de Controle de Mudança (CCB) O comitê de Controle de Mudanças (CCB) será formado por Analista de sistemas e Gerente de Projetos. 3.2 Estimativa do Status de Configuração Processo de Armazenamento de Mídia e Liberação do Projeto O backup do repositório deverá ser feito toda semana pelo gerente de configuração. Os artefatos alterados durante a semana de trabalho serão armazenados em mídia de CD. Um para cada Mês. Os CDs deverão conter a seguinte descrição: a data e hora e a periodicidade. Liberação de release: Basicamente os projetos irão ser desenvolvidos e testados na main-line. Para gerar o release a versão em questão tem que estar devidamente testada, livre de erro e aprovado pelo analista responsável Relatórios e Auditorias As auditorias e os relatórios de configuração devem ser feitas para cada ciclo do processo de desenvolvimento de forma a garantir que o processo de gerência de configuração vem sendo aplicado corretamente. Os artefatos gerados baseados no template devem ser armazenados no repositório do projeto e devem ser acompanhados pelos Gerentes de Qualidade e pelos Gerentes de Projeto. 4. Marcos Serão feitas três Marcos principais, nos seguintes momentos: Arquitetura do sistema: Capacidade Operacional Inicial: Release do Produto: Arquivo:.doc Página 15 de 16

16 16 5. Treinamentos e recursos Descrição dos treinamentos efetuados para os integrantes do Grupo. Treinamento Objetivo Público Alvo Repositório O Gerente de Configuração estará efetuando o treinamento ensina para instruir como acessar o repositório através de uma máquina cliente, como dar os comandos principais do repositório, como incluir novos itens dentro do repositório e também como remover do mesmo. Toda a equipe do projeto 6. Controle de Software de Subcontratados e Fornecedores A Qualistec não subcontrata atualmente desenvolvimento do software. Arquivo:.doc Página 16 de 16