Gerência de Configuração Processo, Mantis, Plano e Auditoria. Equipe de Gerência de Configuração/UES 03/2010 Diretoria de Informática Gerência de Desenvolvimento

Gerência de ConfiguraçãoProcesso, Mantis, Plano e Auditoria.

Equipe de Gerência de Configuração/UES03/2010

Diretoria de Informática Gerência de Desenvolvimento

Unidade de Engenharia de Software

Agenda

EQD/UES

Prosoft: Gerência de Configuração;

Mantis: Novas Máquinas de Estados;

Plano de Gerência de Configuração v2.0;

Auditoria de Gerência de Configuração;

Dúvidas e Esclarecimentos;

EQD/UES

Equipe de Gerência de Configuração/UES: Gestores:

José Mário Ribeiro

Raphael D’Castro

Integradores: Jefferson Pereira (Time A)

Washington Luiz (Time B);

Prosoft:Gerência de Configuração

Processo de Desenvolvimento de Software do TJPE - Prosoft;

Disponível atualmente em: http://192.168.251.88/Intranet/melhoriacontinua/pdstj/processov43

Futuramente disponível em: http://www.tjpe.jus.br/prosoft

Mantis:Novas Máquinas de Estados

Máquina do Mantis para Gerenciamento de Mudanças de Software:

Mantis:Novas Máquinas de Estados

Máquina do Mantis para Entrega de Software.

Plano v2.0:Gerência de Configuração

Compreende as informações pertinentes à padronização de repositório para armazenamento e versionamento dos itens de configuração;

Itens abordados pelo Plano de Gerência de Configuração Estrutura de armazenamento dos itens; Nomenclatura dos artefatos; Políticas de alteração nos itens: Trunk, Branches, Tags,

Merges; Controle de Versão de Software; Controle de Versão de Scripts de Banco de Dados; Níveis de acesso;


Evolução do Plano de GC: v1.0:

Definição das responsabilidades; Identificação dos itens de configuração; Estrutura Básica dos Repositórios; Versionamento dos Artefatos e Sistemas; Política para criação de Tag, Branch e Merge;

v2.0: Revisão na nomenclatura dos artefatos; Revisão das políticas de Tag, Branch e Merge; Redefinição da nomenclatura para Tag e Branch; Ampliação da Estrutura Básica; Padronização dos Comentários; Versionamento de Banco de Dados Controle de Acesso;


Repositórios:

Catálogo de Repositórios: http://sapltjpe6.tjpe.gov.br:8080/ (acesso via navegador);

Tipos de repositórios: Sistemas – Prevê a criação de linhas paralelas de desenvolvimento

(Branches) e inclui espaço para as disciplinas: Requisitos, Análise de Projetos, Implementação e Teste;

Projetos – Versão simplificada que conta com a disciplina Gestão de Projeto;


Estrutura repositório de sistema:

Sistematrunk

01-Requisitos

Documento de Modelagem do Negócio

Documento de Relação de Casos de UsoDocumento de Visão do SistemaEspecificação de Casos de UsoEspecificação de Regras de NegócioEspecificações SuplementaresModelo Conceitual de Dados

02–AnaliseProjeto

Diagrama de ClassesDiagramas de SequenciaDocumento de Arquitetura do SistemaModelo Lógico de Dados

03–Implementacao Códigos fontes, Scripts de banco e Builds.<Detalhamento no próximo slide>

04-Teste 05-Homologacao

06-Configuracao Plano de Gerência de Configuração do Sistema.

07-Qualidade Plano de Garantia da Qualidade do Projeto

08-OutrosDocumentos

tags <NOME DA TAG> <Estrutura idêntica à raíz do trunk>branches <NOME DA BRANCH> <Estrutura idêntica à raíz do trunk>


Pasta 03-Implementacao:

03–Implementacao

01-SrcFontesBibliotecas

02-Db

01-Tables Scripts de criação e alteração de tabelas 02-Procedures Script de criação de procedures 03-Formularios Formulários de intervenção

04-Outros

ÍndicesConstraintsViewScripts DML

03-BuildExecutáveis do Sistema (Delphi)Pacote de Instalação (Java)


Estrutura repositório de projeto:

Projetotrunk

01-GestaoProjeto

CronogramaDocumento de Visão do ProjetoPlano do Projeto

02-Qualidade Plano de Garantia da Qualidade do Projeto.

03-Configuracao Plano de Gerência de Configuração do Projeto

04-OutrosDocumentos

tags <NOME DA TAG> <Estrutura idêntica à raíz do trunk>


Nomenclatura dos Artefatos:

Padrão: <ID_SISTEMA>_<ID_ARTEFATO> ou <ID_PROJETO>_<ID_ARTEFATO> ou <ID_ORGANIZAÇÃO>_<ID_ARTEFATO>;

Tabela contendo a identificação dos itens de configuração (<ID_ARTEFATO>);

Exemplos: SISPE_AR_20090514_FecharCronograma SCAM_CDU002_EmitirRelatorio


Versionamento dos Artefatos:

Padrão: X.Y X = Número que representa a versão final do artefato (incrementado quando da aprovação

do documento); Y = Versão draft do documento (incrementado a cada evolução do documento);

Primeira versão: 0.1;

Exemplo:

Data Versão Descrição Autor Aprovado Por

29/05/2009 0.1 Versão inicial do documento Juliana Xavier

29/05/2009 0.2 Alteração na seção 2.1. para inclusão do estado “impedimento”. Laísa Helena

29/05/2009 1.0 Versão aprovada do documento. Arthur Orlando


Versionamento de Scripts de Banco de Dados: Deve seguir o padrão:

SYBASE: NomeBanco_Schema_TipoScript_NomeObjeto[_NumeroSequencia] ORACLE: Schema_TipoScript_NomeObjeto[_NumeroSequencia] NomeBanco: Identificação do Banco de Dados em que o script deverá

rodar (só aplicável ao Sybase); Schema: Identificação do Schema ao qual o script está associado; TipoScript: Identificação do tipo do objeto contido no script.

Pode assumir os valores: Procedure, Create, Alter, Indice, Contraints, View e DML.

NumeroSequencia: Não se aplica a Procedure. Exs.: dbjze01_dbo_Procedure_SpAdvogadoComplemento_D_001.scp dbcor01_dbo_Create_Atendimento_001.scp SCAM_Alter_Ausencia_002.scp


Versionamento de Software:

Deve seguir o padrão: Versão_Maior.Versão_Menor.Revisão

Versão_Maior: Incrementado quando houver mudanças significativas da arquitetura (Compatibilidade com a versão antiga quebrada).

Versão_Menor: Quando houver adição de novas funcionalidades, uma grande correção de bug do sistema ou alguma melhoria for implementada;

Revisão: Correções de Bug, Pequenas Mudanças de Layout ou qualquer correção de baixo esforço;

Versão inicial: v1.0.0


Política de Commits:

Todos os commits devem ser comentados; Os comentários devem seguir o padrão:

[MXXX – SXXX] – Breve Descrição. Onde: MXXX = Identificação do caso do Mantis a que se refere a mudança. SXXX = Identificação da Sprint Breve Descrição = Uma descrição sucinta do que trata a mudança.

Ex.: [M2581– S019] – Script de criação da coluna codg_documento nas tabelas Atendimento e SolucaoAdotada.

Não deve ser realizado commit para mais de um caso do Mantis; Não deve ser realizado commit de código que não compile


Política de Tags: Devem ser criadas Tags para cada entrega do software (Teste,

Homologação e Produção); Devem ser seguidos os padrões para Tags:

Teste: <Versão>TXX Homologação: <Versão>HXX Produção: <Versão> Exs.: v1.4.5H1, v3.0.1T2, v2.3.1

O comentário na criação da Tag deve seguir o padrão: Criação de Tag de <Tipo> <Nome> - <SXXX>. Onde: <Tipo> define a destinação da Tag (Teste, Homologação ou

Produção); <Nome> é o nome da Tag; Ex.: Criação de Tag de Homologação v1.2.0H2 – S011


Política de Branches:

Deve ser criado um Branch para possíveis correções nas mudanças implementadas ao final da sprint .

Branch gerada a partir da TAG de Teste ou Homologação 1; A Branch deve ter o mesmo nome da Versão; O comentário na criação da Branch deve seguir o padrão:

Criação de Branch <Nome>: <Motivo> - <SXXX>. Onde: <Nome> é o nome da Branch; <Motivo> é uma breve descrição da finalidade da Branch . Ex.: Criação de Branch v1.11.4: Correção de Erros de

Homologação – S022


Política de Merge:

Deve ser realizado após a homologação da versão se houve alterações na Branch desta versão;

O comentário do commit do Merge deve seguir o padrão: Merge entre: <Origem> e <Destino> - <SXXX>. Onde: <Origem> é o local de onde as mudanças serão obtidas (em geral

Branch vX.X.X); <Destino> é o local que receberá as mudanças (em geral Trunk); <SXXX> - Identificação da sprint que gerou as mudanças;


Níveis de Acesso (trunk):

UNs: Escrita nas pastas de documentação do projeto (01-Requisitos, 02-AnaliseProjeto, 05-Homologacao e 08-OutrosDocumentos);

UES: Escrita na pasta 03-Implementacao; UTS: Escrita na pasta 04-Teste; UGAPL = Leitura na pasta 03-Implementacao; UGBD = Leitura na pasta 03-Implementacao\02-Db UGCPD = Leitura na pasta 03-Implementacao\03-Build

Tabela completa se encontra no Plano de Gerência de Configuração

Auditoria:Gerência de Configuração

Serão realizadas auditorias de Gerência de Configuração sistematicamente: Periodicidade: A cada sprint (Quinzenalmente); Realizador: EGC sob o acompanhamento da EQD; Público Alvo: GEDES e Fábricas Externas (Desenvolvedores, Analista de

Negócios ou qualquer pessoa que venha a produzir/modificar os itens de configurações associados aos sistemas do TJPE);

Metodologia: Aplicação de checklist com questões referentes ao Processo e o Plano de Gerência de Configuração;

Relatório: Elaboração de mensal de relatório de Gerência de Configuração e apresentação dos resultados na reunião mensal de qualidade (Chefias da GEDES).

Melhoria Contínua: Verificação de oportunidades de melhoria a partir da reunião de qualidade e sugestões realizadas a partir do Mantis (Processo de Desenvolvimento de software);


Checklist (Itens de Configuração):

A nomenclatura dos itens de configuração respeitam o plano de gerência de configuração?

Os itens de configuração foram incluídos/alterados nos locais corretos?

Os scripts de banco de dados estão sendo incluídos/alterados no repositório?


Checklist (Política de Commit):

Os commits contém apenas um caso do Mantis?

Os comentários seguem o padrão descrito no plano de gerência de configuração?


Checklist (Política para Branches):

A Branch para retornos (correções) de teste e/ou homologação foi criada?

A nomenclatura das Branches respeitam o plano de gerência de configuração?

Os retornos (erros) de teste e/ou homologação foram corrigidos na Branch criada para este fim?


Checklist (Política para Tags):

Foram criadas as Tags de teste e/ou homologação?

Foi criada Tag de produção?

A nomenclatura das Tags respeita o plano de Gerência de Configuração?


Checklist (Política para Merge):

Para os casos em que houve implementações em Branches, foram realizados merge após a homologação do sistema?

O comentário do Merge atende o especificado no plano de Gerência de Configuração?


Checklist (Builds):

Para os sistemas em Delphi e Java, os builds estão sendo armazenados no repositório?

Para sistemas em Delphi, o desenvolvedor está incluindo o executável do sistema após a conclusão de um caso do Mantis?


Checklist (Liberação de Software):

Foram criados casos do Mantis para a liberação dos sistemas?

Os casos do Mantis criados para liberação dos sistemas atendem as especificações do Guia Mantis?


Categorização das observações da Auditoria:

Ocorrências: Não conformidades que ainda valem a pena serem corrigidas;

Desvios: não-conformidades que não fazem mais sentido serem corrigidas por não agregarem mais valor ao projeto/sprint;

Recomendações: sugestões de melhoria que ainda não fazem parte do processo institucionalizado;

Dúvidas e Esclarecimentos

Documents

Gerência de Configuração Processo, Mantis, Plano e Auditoria. Equipe de Gerência de Configuração/UES 03/2010 Diretoria de Informática Gerência de Desenvolvimento