Plano de gerência de configuração Mercadonline

Transcrição

1 BACHARELADO EM SISTEMAS DE INFORMAÇÃO 1 FUNDAMENTOS DE ENGENHARIA DE SOFTWARE Plano de gerência de configuração Mercadonline Alunos: Carlos César Bezerra Fonseca Cybele Félix Amorim Veríssimo Geraldo Gomes da Cruz Júnior Larissa Karollyne de Melo Ferreira Mário Gomes de Melo Wendislau Victor Santos da Silva Turma: 3º período Professora: Teresa Maciel Versão: 1.0 Recife, 06 de Março de 2013

2 2 1. Sumário 2. Introdução Convenções, termos e abreviações Atribuições do grupo de desenvolvimento Identificação dos itens de configuração Identificação dos documentos Versão dos documentos Repositório Ferramentas de apoio Políticas para Branch e Merge Baselines programadas Auditorias de configuração (Física e Funcional) Auditoria de Configuração Física: Auditoria de Configuração Funcional: Controle de mudanças Criando Solicitação de Mudanças Plano de Contingência Bibliografia... 10

3 3 2. Introdução Este documento descreve a organização, nomenclatura e regras para o versionamento do projeto Mercadonline. O Plano de Gerenciamento de Configuração estabelece e mantem a integridade de códigos-fonte e demais artefatos do projeto Mercadonline, permitindo o acompanhamento destes itens durante todo o ciclo de vida do projeto, e preservando o histórico de evolução dos sistemas. Auxiliando a gerenciar o estado dos itens de configuração dos sistemas, controlar as mudanças em itens de configuração e rastrear modificações nos itens de configuração ao longo do tempo. 2.1 Convenções, termos e abreviações Esta seção explica o conceito de alguns termos importantes que serão mencionados no decorrer deste documento. Estes termos são descritos a seguir, estando apresentados por ordem alfabética: Termo Baseline CCB CR CVS DBA SCMP SVN Descrição Conjunto de artefatos que recebe uma aprovação de estabilidade. Change Control Board, grupo responsável por autorizar modificações nos itens de configuração e estabelecimento de baselines. Solicitação de Mudança (Change Request). Sistema de Controle de Versão (Control Version System). Database administrator, profissional responsável por gerenciar, instalar, configurar, atualizar e monitorar um banco de dados ou sistemas de bancos de dados. Plano de Gerência de Configuração de Software (Software Configuration Management Plan). Sistema de controle de versão. 3. Atribuições do grupo de desenvolvimento A disposição das atribuições e responsabilidades dos membros do grupo formam a seguinte tabela:

4 4 Nome Carlos Cézar Bezerra Fonseca Cybele Félix Amorim Veríssimo Geraldo Gomes da Cruz Júnior Larissa Karollyne de Melo Ferreira Mário Gomes de Melo Wendislau Victor Santos da Silva Atribuição Developer, DBA, CCB, Maintenance Tester, Design, DBA, CCB, Quality control, Auditors Developer, DBA, Documentation, Desing, CCB, Requirements, Graph Tester, Documentation, DBA, CCB, Requirements, Graph, Auditors Developer, DBA, CCB, Maintenance Tester, CCB, Quality control, Auditors 4. Identificação dos itens de configuração A identificação dos itens de configuração do projeto Mercadonline seguira os seguintes padrões: 4.1 Identificação dos documentos Todos dos itens de configuração, com exceção do código fonte, devem ser identificados baseados na nomenclatura descrita a seguir: Nome do projeto _ ID_ARTEFATO _DATA em que: Nome do projeto : Se refere ao nome do projeto; ID_ARTEFATO : Se refere à identificação do artefato em questão; DATA : Se refere à data de criação do artefato, ou seja, a data da primeira versão do artefato em questão. Para descrição da data o formato DDMMAAAA deve ser utilizado. Por exemplo: PlanoGerenciaConfiguração_SCM_ É importante salientar que as letras do ID_ARTEFATO que caracterizam os documentos devem estar em caixa alta.

5 5 Identificações dos artefatos do projeto: Artefato Relatório do Sistema Casos de Uso Documento de Requisitos Plano de Gerência de Configuração Diagrama de Caso de Uso Diagrama de Classe Diagrama de Pacote User Story Business Value Modelo de Entidade Relacional Auditoria de Configuração Física Auditoria de Configuração Funcional Base Line Quadro Scrum Diagrama de atividades Identificação RS UC REQ SCM UCD CD PKGD US BV MER PCA FCA BL SB AD 4.2 Versão dos documentos O padrão de versionamento dos artefatos (exceto código e relatórios) deve ter um número de versão segundo o padrão descrito a seguir: XX.YY onde: X é um número decimal que representa uma versão final do artefato; YY é um número 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 0.01; A cada modificação no artefato, 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 para 00, sendo assim gerada uma nova versão oficial. Para que a versão de um artefato seja modificada é necessária à aprovação do moderador e êxito em testes. É considerada ainda a aprovação após uma revisão e por pelo menos dois membros do grupo responsáveis pelo artefato respectivo. 5. Repositório O repositório utilizado foi o Code.google.com.br, SVN, ambiente para promoção de código livre, interação com desenvolvedores e gerenciamento de projetos.

6 6 O repositório do Mercadonline pode ser acessado a partir deste link: A ferramenta de repositório Google Code já segue uma estrutura padrão de abas, colocando em seu menu principal: Project Home: Página principal do projeto; Downloads: Página para downloads de arquivos; Wiki: Coleção de páginas construídas coletivamente, em que pessoas do grupo podem alterar o seu conteúdo; Issues: Página com possíveis problemas, solicitações de complementos e observações do sistema; Source: Espaço dedicado para gerenciamento do repositório e códigos. Na Project Home foi criado um sub menu, para facilitar o acesso as distintas áreas do sistema, com os seguintes links: Home: Página principal do projeto; Descrição do sistema: Página com a descrição das principais funções do sistema; Requisitos: Página com os requisitos funcionais e não funcionais do sistema; Casos de Uso: Página com os detalhamentos dos casos de uso do sistema; Diagramas: Página com todos os diagramas do sistema; Docs: Página com a documentação do sistema; Desenvolvedores: Página com nome e contado dos desenvolvedores do projeto; Bibliografia: Página com as referências utilizadas no sistema; Vídeos: Página com vídeos do sistema. 6. Ferramentas de apoio Segue abaixo uma lista das ferramentas utilizadas no processo de desenvolvimento do projeto Mercadonline. TortoiseSVN : Ferramenta para Gerência de Configuração (Subversion); Facebook: Ferramenta de comunicação; Astah Professional: Ferramenta para desenvolvimento de diagramas; GoogleGroups: Ferramenta de comunicação; Google drive: Ferramenta de armazenamento remoto na nuvem;

7 7 Picassa: Ferramenta para armazenamento de imagens na nuvem; Eclipse Juno: Ambiente de desenvolvimento; My SQL : Ambiente do banco de dados; Windows build v.1.5.2: Complemento do Eclipse para desing. 7. Políticas para Branch e Merge Branch: É a ação da duplicação de um objeto, sob controle de versão, a partir de um objeto principal, para que as modificações possam acontecer em paralelo ao longo do desenvolvimento. Merge: Em um processo de desenvolvimento com branchs inseridos, a ação do merge no controle de versão é necessária. Em um desenvolvimento onde mais de uma pessoa atua sobre o mesmo código de origem, parent branch, ao se subir as suas alterações, commit, sobre o código original, é necessária a integração, o mesclar entre o código alterado e o atual código no repositório, trunk. No decorrer do projeto Mercadonline os branch s permitiram que partes do software possam ser desenvolvidas em paralelo com a atuação dos programadores. O merge permitirá que os códigos sejam mesclados ao fim de um processo de desenvolvimento. Frente ao baixo tempo de entrega do projeto e a complexidade do mesmo as políticas para branch e merge serão asseguradas pelo controle de qualidade, mudança e auditórias. Sendo o projeto em se assegurado pelo plano de contingência. 8. Baselines programadas As baselines ocorreram quando os membros do grupo concordarem que ouve o fim de um processo de desenvolvimento. E.x: Diagramas e documentos em suas ultimas versões já aprovadas e um caso de uso, ou requisito funcional concluído. A baseline só será aprovada frete a um novo processo de testes e aprovações pelos desenvolvedores, testers e gerente do projeto. A baseline será constituída por uma lista com os artefatos e suas versões em estado estável esta lista será identificada por um valor XX, que será incrementado a cada nova baseline. 9. Auditorias de configuração (Física e Funcional)

8 8 As auditorias de configuração devem ser realizadas para cada ciclo do processo de desenvolvimento de forma a garantir que o processo de gerência de configuração esta sendo aplicado corretamente. Os artefatos gerados devem ser armazenados no repositório do projeto e devem ser acompanhados pelo Gerente do Projeto e Tester. 9.1 Auditoria de Configuração Física: Uma Auditoria de Configuração Física (PCA) identifica os componentes de um produto que serão implantados do Repositório do Projeto. Execução: Identificar a baseline a ser implantada (pelo número desta, verificando sua lista de artefatos, com versões). Confirmar que todos os artefatos necessários, conforme especificado pelo Caso de Desenvolvimento, estão presentes na baseline. Deve-se listar os artefatos ausentes em descobertas da Auditoria de Configuração. No último estágio, as auditorias devem se limitar a verificar os produtos liberados necessários que estão presentes, sem se preocupar em revisar o conteúdo. (Rational Unified Process) 9.2 Auditoria de Configuração Funcional: Uma Auditoria de Configuração Funcional (FCA) confirma que uma baseline atende aos requisitos estabelecidos para ela. Execução: Preparar um relatório que liste cada requisito estabelecido para a baseline, seu procedimento de teste correspondente e o resultado de teste (aprovado/reprovado) da baseline. Confirmar que cada requisito passou por um ou mais testes e que o resultado de todos esses testes foi 'aprovado'. Em Descobertas da Auditoria de Configuração, listar quaisquer requisitos que não tenham passado por procedimentos de teste e os requisitos que estão com teste incompleto ou que foram reprovados. Gerar uma lista das CRs estabelecidas para essa baseline. Confirmar que cada CR foi fechada. Em Descobertas da Auditoria de Configuração, listar quaisquer CRs que não estão fechadas. 10. Controle de mudanças As mudanças nos itens de configuração do projeto devem estar sempre associadas a uma ou mais solicitações de mudanças. Dessa forma, para toda e qualquer modificação nos itens de configuração, uma CR deve ser aberta Criando Solicitação de Mudanças

9 9 As solicitações de mudanças devem ser criadas através da ferramenta de issues disponível no site do projeto Para tanto o usuário deve estar logado como administrador. O preenchimento dos campos deve ser feito seguindo as orientações descritas a seguir. Devem ser aprovadas pelos membros do grupo responsáveis pelo artefato em questão. Campo Summary Description Status Owner Cc Labels Valor Breve descrição do problema Descrição detalhada do problema Open Statuses: New- A issue ainda não teve sua revisão inicial; Accepted problema reproduzido/precisa reconhecimento; Started o trabalho nesta issue começou. Closed Statuses: Fixed Desenvolvedor fez as mudanças pedidas, responsável deve verificar; Verified Responsável verificou que o reparo foi trabalhado; Invalid Relatório não válido; Duplicate Este relatório duplica uma issue existente; WonFix foi decidido não examinar esta issue. Responsável pela CR. Lista de destinatários de cópias de s relativos a essa mudança. Permite que seja selecionado o tipo e a prioridade da issue. Type-Defect Relato de um defeito no artefato a ser mudado. Type-Enhancement Requerimento para melhoria no artefato. Type-Task os artigos trabalhados não requerem mudança no código ou nos docs. Type-Pach Correção do código fonte para revisão. Type-Other Algum outro tipo de issue. Priority-Hign Prioridade alta para a resolução do evento

10 10 especificado. Priority-Medium Prioridade média para a resolução do evento especificado. Priority-Low Prioridade baixa para a resolução do evento especificado. Component-Persistence issue relaciona-se ao componente de armazenamento de dados. Component-Scripts roteiro de utilização e instalação. Componet-Docs issue relacionada à documentação do usuário final. Security segurança de risco dos usuários. Performance issue de desempenho. Usability efeitos da usabilidade do programa. Maintainability impedir mudanças futuras. 11. Plano de Contingência Uma vez por semana será feito um backup da versão mais recente dos artefatos que se encontram no CVS na máquina de dois membros do grupo de desenvolvimento. 12. Bibliografia 1. BROWN, William J. et ali. Antipatterns and Patterns in Software Configuration Management. Nova Iorque: Wiley computer publishing, MIKKELSEN, Tim, PHERIGO, Suzanne. Parctical Software Configuration Management: The Latenight Developer's Handbook. Upper Saddle River, NJ, EUA: Prentice Hall PTR, MOLINARI, Leonardo. Gerência de Configuração - Técnicas e Práticas no Desenvolvimento do Software. Florianópolis: Visual Books, PRESSMAN, Roger S.. Engenharia de Software. São Paulo: Pearson Makron Books,