Plano de Gerenciamento de Configuração

Transcrição

1 Plano de Gerenciamento de Configuração Controle de Versões Versão Data Autor Notas da Revisão /11/2016 Deborah Araujo Denis Ferreira Ezio Mendonça - Plano de gerenciamento de Configuração Página 1 de 7

2 Sumário 1 Introdução Objetivo Escopo do Projeto Evolução das mudanças Ferramentas, Ambientes e Infraestrutura Ambientes Estrutura do Repositório Controle de Configuração e Mudança 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 Introdução O Plano de Gerenciamento 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 produto. Suas atividades envolvem: identificar a configuração do software, manter sua integridade durante o projeto e controlar sistematicamente as mudanças. 2 Objetivo O objetivo 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 ambiente), as responsabilidades atribuídas e o cronograma de atividades. Plano de gerenciamento de Configuração Página 2 de 7

3 3 Escopo do Projeto Este Plano de Gerenciamento de Configuração é destinados para todos os integrantes da Gyntech Soluções, empresa responsável pela criação e manutenção do software, e abrange todo o controle e gerenciamento da configuração do projeto de controle de acesso proposto no. Será feito um sistema web com visando a segurança do acesso. Nele serão mantidos 2 níveis de acesso ao sistema: um nível administrativo, com possibilidade de cadastramento de novos usuários do tipo administrator, bem como a edição desse cadastro como exclusão ou edição, cadastro de novos produtos com possibilidade de edição (exclusão e edição) e cadastramento de forma de pagamento; E outro nível do tipo cliente, que poderá comprar produtos, efetuar cadastro de cliente e visualizar grade de produtos. 4 Evolução das mudanças O Plano de Gerenciamento de Configuração deve ser mantido e atualizado para refletir o planejamento corrente. Dessa forma, as seguintes situações descrevem como serão iniciadas cada etapa do processo de manutenção das configurações de mudança, para atualização do plano e nova aprovação deste documento: Mudança nos itens de configuração, como se dará e a quem deve se reportar; Mudança na identificação dos arquivos, onde devem ser descritos e como; Mudança na identificação das Tags/Classes; Mudança no padrão de versionamento; Plano de gerenciamento do projeto 3 de 7

4 5 Ferramentas, Ambientes e Infraestrutura Ferramentas GitHub NetBeans Eclipse Postgres Descrição Ferramenta de controle de versão do software, serviço disponibilizado no endereço: Ferramenta de edição e execução do software, serviço disponibilizado nas maquinas disponíveis para os técnicos. Ferramenta de edição e execução do software, serviço disponibilizado nas maquinas disponíveis para os técnicos. Ferramenta de banco de dados para inserção dos dados gerados, serviço disponibilizado nas maquinas disponíveis para os técnicos. 5.1 Ambientes A execução de todas as tarefas deverão ser comitadas e colocadas imediatamente no repositório citado, independentemente de seu término. As ferramentas de desenvolvimento IDEs serão de livre escolha do desenvolvedor, desde que a mesma seja uma ferramenta de Software Livre, como: Eclipse e NetBeans. Plano de gerenciamento do projeto 4 de 7

5 6 Estrutura do Repositório O GitHub é uma plataforma de hospedagem de projetos de software que oferece, além de armazenamento de repositórios GIT, uma área do repositório específica para documentação online (Portal Wiki) e outra para controlar tarefas e mudanças no projeto (issues). Também é possível compartilhar o versionamento do software de forma gratuita, minimizando os custos do projeto. A fim de se ter melhor aproveitamento da plataforma e agilidade no ciclo de vida, todos os artefatos de software e o gerenciamento do projeto serão feito no GitHub e/ou em ferramentas integradas ao GitHub. 7 Controle de Configuração e Mudança 7.1 Processamento e Aprovação de Solicitações de Mudança O repositório é mantido e controlado em conjunto com os desenvolvedores do software, com o conhecimento da parte gestora. Todas as atividades em relação a mudanças no software, deverão ser avisadas previamente via a todos os integrantes do grupo de desenvolvimento. Os commits deverão conter textos detalhando o que foi modificado. Commits com textos não claros, sem conteúdo ou, com semântica desestruturadas serão reportadas a gerencia do projeto podendo acarretar penalidades a quem os efetuem. Toda nova solicitação de mudança, pedido de correção de bug, solicitação de nova funcionalidade, deve antes passar por uma análise de viabilidade e riscos. Se a mudança solicitada é analisada como inviável, deve-se então informar ao autor da solicitação o motivo pelo qual não serão realizados os ajustes e a solicitação deve ser fechada. Caso contrário, os desenvolvedores deverão planejar e executar as mudanças, todo o processo deve ser assistido pelo Gerente de Configuração e Gerente de Verificação e Validação. Caso seja necessário realizar mudanças que causaram grande impacto, Comitê de Mudança deve solicitar uma reunião para discutir o assunto. 7.2 Comitê de Controle de Mudança (CCB) O Comitê de Controle de Mudança (CCB) será responsável por avaliar o impacto, benefícios, riscos associados, além de aprovar e priorizar as mudanças submetidas no projeto. O Comitê é formado pelo Gerente de Configuração, pelos Desenvolvedores do Software e pelo Gerente de Projeto. O gerente de projeto ficará responsável por redigir as análises de viabilidade e riscos e o planejamento de mudanças, coordenar as reuniões, receber, organizar e comunicar informações referentes a mudanças e gerar a pauta, com antecedência de pelo menos um dia, e a ata com as decisões tomadas. Todos os documentos deverão ser disponibilizados em um único repositório para manter histórico de fácil acesso e consulta. Os documentos referentes ao projeto deverão respeitar os templates disponíveis nos e- mails dos integrantes da equipe do projeto. Plano de gerenciamento do projeto 5 de 7

6 As solicitações de mudança (SM) devem ser registradas, assim como as análises de viabilidade de riscos e o planejamento de mudanças, que estão disponíveis no repositório do projeto. Esse registro deverá ser feito via preenchendo o template correspondente e associando todos os responsáveis pela solicitação. A solicitação deve ser entregue ao CCB, antes de qualquer mudança, para que possa ser discutida em reunião. 8 Estimativa do Status de Configuração 8.1 Processo de Armazenamento de Mídia e Liberação do Projeto O repositório local deve ser sincronizado por todos os integrantes da equipe diariamente, garantindo assim, que todos tenham sempre a mesma versão do projeto. Deverão também ser mantidas copias do projeto em repositórios na nuvem, como Dropbox e Drive, para requisições futuras por um período de até 1 ano. Dessa forma existiram duas copias do projeto em locais diferentes. Plano de gerenciamento do projeto 6 de 7

7 8.2 Relatórios e Auditorias As auditorias, serão efetuadas com base nas documentações geradas na verificação e validação de software. Serão realizadas sempre antes da liberação das novas etapas para o cliente, sendo responsável por verificar se o que está sendo liberado para o cliente está completo, atendendo aos requisitos estabelecidos. A auditoria será responsável por verificar se os componentes estão presentes nas versões especificadas e confirmar a presença de todos os artefatos necessários. Caso, durante a auditoria, alguma falha seja encontrada (Item de Configuração não encontrado), os seguintes passos deverão ser executados: Identificação do problema, apresentando o que foi encontrado em desacordo com os requisitos e o que foi produzido. Identificar ação corretiva junto aos membros do CCB. Se for detectado a ausência de algum artefato, deve ser comunicado ao responsável para que ele possa ser incluído no gerenciamento de configuração. Se um artefato não foi feito, ou não está completo, deve-se colocar em pauta para reuniões futura e análise de atrasos recorrentes. Podendo este artefato ser inserido nas atividades subsequentes ou mesmo ser cancelado, caso não exista possibilidade de entrega em tempo hábil. Se uma solicitação (SM) estiver em aberto, deverá ser analisado qual o melhor encaminhamento, se deverá ser fechada, cancelada ou adiada. Obs: Um template para documento de Auditoria de Configuração (ACS) está disponível no da equipe CCB. Plano de gerenciamento do projeto 7 de 7