Plano de gerência de configuração

O plano de gerência de configuração da gerência de desenvolvimento do sistema PJe compreende as informações pertinentes à padronização de repositório para armazenamento de código fonte e documentação do sistema, assim como nomenclatura dos itens de configuração e informações relativas ao versionamento de itens e do próprio sistema.
Esse plano será aplicado no âmbito da gerência geral do projeto e das equipes de desenvolvimento prevista no plano de projeto em sua versão mais recente.

Público-Alvo

O presente documento se destina aos envolvidos no desenvolvimento do sistema PJe, seja no próprio Conselho Nacional de Justiça, seja nas equipes de desenvolvimento formadas por órgãos ou tribunais participantes do projeto.
Este documento não se destina ao desenvolvimento feito dentro de fábricas de software terceirizadas, desde que, nas entregas de artefatos, essas fábricas apresentem o produto dentro das presentes especificações, termos e abreviações.

Convenções deste documento

Para melhor apreensão deste manual, serão adotadas algumas convenções de conceitos e exibição de informações.

Conceitos, termos e abreviações

Esta seção apresenta o conceito ou a abreviação de alguns termos importantes que serão mencionados no documento, todos relacionados ao processo de gerência de configuração de software.

Termo/Abreviação	Termo/Abreviação
Artefato	Qualquer produto do ciclo de produção do projeto, podendo ser arquivos eletrônicos de código fonte, arquivos eletrônicos de código compilado, a reunião desses arquivos, arquivos de documentação ou mesmo objetos físicos, como manuais impressos ou discos de instalação.
Baseline	Conjunto de artefatos aprovados e revisados que serão utilizados para atividades posteriores. É definida pela gerência de projeto como base para evoluções e desenvolvimento futuro.
Branch	Linha de desenvolvimento paralela à linha principal do repositório de código fonte e documentação.
Build	Versão ainda incompleta do sistema em desenvolvimento, capaz de ser executada em um ambiente regularmente configurado. Contém arquivos de instalação, código fonte, arquivos de dados, programas ou scripts de instalação e documentação básica.
CG	Comitê gestor do projeto.
GCS	Gerência de configuração de software.
Gerente de configuração	Responsável pelas atividades relacionadas ao respeito das regras estabelecidas no presente documento, assim como à revisão dessas regras conforme definido pelos comitês pertinentes.
GG	Gerência geral do projeto.
GM	Grupo de mudanças do projeto.
Item de configuração	Qualquer artefato produzido durante o ciclo de vida do projeto cuja mudança será controlada por um processo formal.
JIRA/CNJ	Ferramenta WEB de controle de demandas de projetos de elaboração ou evolução de software utilizada pelo CNJ.
Merge	Operação de integração de alterações de um determinado branch (ramo) ao trunk ou a outro branch.
PGCS	Plano de gerência de configuração de software – a versão mais atualizada deste documento.
Ramo	Ver branch.
Release	Versão do sistema validada para instalação, seja em produção, seja para homologação. Conjunto de itens enviado a um tribunal ou a um departamento para instalação, que não deve conter o código fonte do sistema. Cada release pode encerrar novas funcionalidades ou mudanças decorrentes de evolução do sistema.
Repositório	Sistema de controle de versões de artefatos eletrônicos em que os itens de configuração eletrônicos são armazenados com a garantia de possibilidade de reversão a uma versão anterior do item.
Tag	Rótulo de identificação de um conjunto de itens de configuração que representa um todo de interesse. Ordinariamente, as versões de release e as baselines são identificadas com tags para melhor referência.
Trunk	Linha principal de desenvolvimento existente no repositório.

Dado de entrada

Ao fazer referência a um dado a ser inserido pelo usuário, será utilizado o seguinte formato: dado a ser inserido pelo usuário.

Gerenciamento de configuração de software

Responsabilidades

A gerência de configuração é atividade exercida por três papéis, cujas responsabilidades são descritas na tabela abaixo.

Papel	Responsabilidades
Gerente de configuração ou integrador de configuração	i. elaborar e ajustar o PGCS; ii. controlar as baselines dos produtos; iii. realizar a integração (merge) junto às equipes de desenvolvimento; iv. realizar auditorias para garantir o cumprimento das atividades de GCS pelas equipes de trabalho; v. informar o status da configuração; vi. definir permissões de acesso aos repositórios; vii. gerar tags; viii. gerar branchs; ix. gerar builds; x. gerar releases.
desenvolvedor	i. respeitar as definições do PGCS quando da elaboração ou modificação dos artefatos afetados pela GCS (itens de configuração) a eles atribuídos; ii. realizar a integração (merge) com a gerência de configuração; iii. gerar builds a pedido da gerência de configuração; iv. gerar releases a pedido da gerência de configuração.
Analista de sistema	i. respeitar as definições do PGCS quando da elaboração ou modificação dos artefatos afetados pela GCS (itens de configuração) a eles atribuídos.

Ferramentas, ambiente e infraestrutura

As seguintes ferramentas são utilizadas para manter o controle da gerência de configuração:

• subversion <versão>
• <cliente de SVN para Windows>
• subversive team integration sobre Eclipse IDE
• Atlassian Connector sobre Eclipse IDE
• redmine
• mediawiki

Identificação da configuração

Esta seção aborda os temas referentes à identificação dos itens de configuração eletrônicos, assim como, a identificação de itens de configuração físicos referenciados por itens de configuração eletrônicos.
Qualquer artefato produzido durante o ciclo de vida do projeto cuja mudança será controlada por um processo formal é um item de configuração.

Identificação dos itens de configuração

Código fonte

A identificação dos arquivos de código fonte seguirá regras específicas definidas em documento de desenvolvimento.

Demais itens de configuração

Os demais itens de configuração devem ser identificados com caracteres minúsculos e não especiais, podendo-se utilizar as regras de capitalização de letras dos JavaBeans para descritores. A estrutura de identificação é:

                                              pje_<idartefato>

, onde <idartefato> é a identificação do item de configuração. Na tabela a seguir estão expostos os itens de configuração afetados pela presente regra com o formato de seus identificadores.

Item	Identificador	Descritor	Exemplo do descritor
ata de reunião	arAAAAMMDD_<descritor>	assunto principal	ar20110506_PlanoProjeto
caso de teste	cdt_<descritor>	nome do caso	cdt_AutuarProcesso
caso de teste de integração	cti_<descritor>	nome do caso	cti_AutuarProcesso
caso de uso	cdu_<descritor>	nome do caso	cdu1001_AutuarProcesso
cronograma	cr_<descritor>	versão	cr_1.0.0
diagrama de classes	dc_<descritor> - nome do caso de referência - identificação do conjunto de funcionalidades - “geral”	dc_AutuarProcesso dc_AutuacaoDistribuicao dc_geral
diagrama de sequência	ds_<descritor>	idem	ds_AutuarProcesso ds_AutuacaoDistribuicao ds_geral
documento de arquitetura do sistema	das_<descritor>	versão	das_1.0.0
documento de visão	dv_<descritor>	versão	dv_1.0.0
especificação de mensagens do sistema	ems_<descritor>	- nome do caso de referência - identificação do conjunto de funcionalidades - “geral”	ems_AutuarProcesso ems_AutuacaoDistribuicao ems_geral
especificação de regras de negócio	ern_<descritor>	- nome do caso de referência - identificação do conjunto de funcionalidades - “geral”	ern_AutuarProcesso ern_AutuacaoDistribuicao ern_geral
especificação suplementar	esu_<descritor>	- nome do caso de referência - identificação do conjunto de funcionalidades - “geral”	esu_AutuarProcesso esu_AutuacaoDistribuicao esu_geral
guia de instalação e configuração	gic_<descritor>	versão	gic_1.1.2
glossário	glo_<descritor>	versão	glo_1.0.0
manual de instalação	mai_<descritor>	versão	mai_1.0.0
manual de usuário	mdu__<descritor>	versão	mdu_advogado_1.0.0
modelo conceitual de dados	mcd_<descritor>	versão	mcd_1.0.0
modelo lógico de dados	mld_<descritor>	versão	mld_1.0.0
planilha de acompanhamento de ciclo	pac_<descritor>	número do ciclo projetado	pac_0230
planilha de riscos	plr_<descritor>	versão	plr_1.0.0
plano de garantia de qualidade do projeto	pgqp_<descritor>	versão	pgqp_1.0.0
plano de gerência de configuração do projeto	pgcp_<descritor>	versão	pgcp_1.0.0
plano de projeto	pp_<descritor>	versão	pp_1.0.0
plano de testes	pt_<descritor>	- nome do caso de referência - identificação do conjunto de funcionalidades -versão	pt_AutuarProcesso pt_AutuacaoDistribuicao pt_1.0.0
relação de casos de uso	rcdu_<descritor>	- identificação do conjunto de funcionalidades - versão	rcdu_AutuacaoDistribuicao rcdu_1.0.0
relatório de análise de impacto	rai_<descritor>	identificação da demanda analisada	rai_pje112
notas de versão	notasversao_<descritor>	versão	notasversao_1.0.10
termo de aceite	ta_<descritor>	- identificador da ordem de serviço - identificador da demanda repassada	ta_os123 ta_pje112

Localização dos itens de configuração

Esta seção descreve o modo e a estrutura de armazenamento dos itens de configuração.
Os itens de configuração são divididos em duas classes

• Artefatos de gerência: artefatos gerais, que demandam controle de versão, mas cujas alterações não são diretamente vinculadas aos lançamentos de versões do sistema. Fazem parte desse grupo os seguintes artefatos:
  • Ata de reunião;
  • Cronograma;
  • Documento de arquitetura do sistema;
  • Documento de visão do negócio;
  • Documento de visão do sistema;
  • Glossário;
  • Planilha de acompanhamento de ciclo;
  • Planilha de riscos;
  • Plano de garantia de qualidade do projeto;
  • Plano de gerência de configuração do projeto;
  • Plano do projeto.
• Artefatos de desenvolvimento: artefatos diretamente ligados ao desenvolvimento, englobando todo o código fonte, os scripts de bancos de dados, os dumps de bancos de dados e todos os documentos listados na tabela da seção anterior e não identificados como documentos de gerência.

Localização dos documentos de gerência

Os artefatos de gerência são mantidos na ferramenta Redmine no endereço:

• http://colaboracao.cnj.jus.br/projects/sisprocessual

A manutenção desses artefatos na ferramenta de colaboração será feita de duas formas:

• Versões dinâmicas: mantidos na área de Wiki;
• Versões estáticas: extraídos ou elaborados a partir dos documentos constantes na área de Wiki, armazenados na área de repositório de documentos com numeração de versão, conforme regras adiante.
  

A regra geral é manter os artefatos na área de Wiki. Em razão da natureza multidirecional de páginas Web tais como as wiki’s, as referências de estruturação a seguir apresentadas são as mínimas, ou seja, são aquelas essenciais e dirigidas à apreensão direta dos conhecimentos envolvidos nos artefatos. Desse modo, o gráfico a seguir se limita a indicar os artefatos essenciais e as ligações mínimas existentes entre eles em uma estrutura de árvore, ainda que, na realidade, essa estrutura se assemelhe mais com uma teia.
Esses documentos devem ser mantidos sempre atualizados e, ao se concluir pela aprovação de uma determinada versão segundo os critérios abaixo, deverão ser produzidas versões em formato de documento portável (PDF) ou formato de documento aberto (ODT), que serão gravadas nas áreas homônimas da documentação.

Localização dos documentos de desenvolvimento

As presentes regras tomam por base um diretório raiz <RAIZ> no servidor que hospeda a solução de software de controle de versionamento, a partir da qual são definidos os caminhos do sistema.
O acesso externo ao repositório do sistema de controle de versionamento será efetivado por meio do endereço:

• https://wwwh.cnj.jus.br/svn/projeto_pje

Haverá um único repositório para o projeto, o trunk. Cada um dos branchs e cada uma das tags deve ter a seguinte estrutura interna. Nela, estão representados os arquivos:

raiz	trunk	aplicacao	Projeto na IDE
		documentacao	analise	casosdeuso
				modelosartefatos
				regrasdenegocio
				requisitos
				rcdu (arquivo)
			bancodedados	conversao
				dumps
				importacao
			qualidade	homologacao
				testes
	branches	nome do branch/ramo	Estrutura idêntica à do trunk
	tags	nome da tag	Estrutura idêntica à do trunk

Os projetos em ambiente de desenvolvimento integrado devem ser estruturados seguindo os padrões definidos no documento de regras de desenvolvimento, respeitando, ainda, a versão pertinente.
É importante lembrar que, nos projetos em ambiente de desenvolvimento integrados, as pastas de destino do código compilado não devem ser mantidas sob o controle de versão, assim como arquivos de configuração locais.

Histórico

O controle de versões do código fonte será feito exclusivamente por meio do sistema de controle de versões, sobre cada um dos projetos de desenvolvimento. Os demais artefatos deverão ser controlados tanto por esse sistema quanto por indicações textuais contidas no identificador de versão do nome do arquivo e em seção específica de histórico de alterações. O controle de histórico de versões de artefatos de gerência e de artefatos de desenvolvimento diversos do código fonte será feito pela descrição das alterações havidas entre cada uma das versões.
Cada um desses documentos deve conter uma seção denominada “Histórico” em que está contida uma tabela contendo número da versão, data da versão, responsável e uma descrição das alterações havidas, seguindo o seguinte modelo:

Versão	Data	Autor	Descrição
0.1.0	01/01/2011	Paulo C. Araújo Silva Filho Raphael D'Castro (TJPE)	Versão inicial
0.2.0	01/02/2011	Marivaldo Dantas de Araújo	Inclusão da seção 5
0.2.1	03/02/2011	Marivaldo Dantas de Araújo	Correções ortográficas

Versionamento

Regras de versionamento de artefatos de gerência

Os artefatos de gerência devem ser versionados seguindo o seguinte padrão:

X.Y.Z

, onde:

X	Número principal da versão, somente alterado quando há uma significativa mudança na estrutura do documento após o lançamento da primeira versão principal. Por significativa mudança, compreenda-se a inclusão de novas seções, a inclusão de novas estruturas ou regras não decorrentes das regras originais. Esse número deve ser 0 para versões em rascunho originárias.
Y	Número intermediário de versão, modificado sempre que houver inclusão ou supressão de parágrafos dentro de seções antes existentes, mas que não representam a modificação de uma estrutura já existente. Esse número deve iniciar em 0 e reiniciado quando da troca do número principal.
Z	Número menor de versão, modificado sempre que houver modificação da versão em razão de correção ortográfica ou esclarecimento de regra já estabelecida no documento. Esse número deve iniciar em 0, para as versões em rascunho de uma versão principal 0, ou 0rN, para versões em rascunho de uma versão principal superior à 1. Esse número deve ser zerado quando da troca do número intermediário ou do número principal.

A partir de tais regras, um artefato de gerência em rascunho originário deverá ser numerado como 0.1.0, evoluindo esse número até sua aprovação como documento válido, caso em que receberá a numeração 1.0.0. A partir daí, correções ortográficas implicarão em acréscimo no número menor, evoluindo a versão para a numeração 1.0.1, inserção de novos parágrafos ou supressão de novos parágrafos implicarão em acréscimo de número intermediário (1.1.0) e a inserção de novas seções ou substituição de estruturas deverá resultar na criação de uma versão principal maior (2.0.0). Caso haja mera preparação de uma versão nova superior à primeira versão principal já tornada válida (1.0.0), dever-se-á adotar a numeração X.0.0r0 (2.0.0r0, no exemplo).

5.2 Regras de versionamento de software

As regras estabelecidas no presente tópico tratam das versões liberadas do sistema, quer a liberação seja para uso em homologação, quer a liberação seja para uso em produção. Também se define as regras para a nomeação das versões, quando elas apresentarem um número.

Números das versões do sistema

O sistema terá versões numeradas seguindo o seguinte padrão:

X.Y.Z

, onde:

X	Número principal da versão, somente alterado quando: a) há modificação de arquitetura do sistema, ainda que não tenha havido modificação da estrutura de dados; b) há modificação da estrutura de dados que demande uma migração significativa de uma base para outra base de dados, não sendo suficiente a mera concretização de scripts de migração de dados entre tabelas de um mesmo banco de dados. Esse número deve ser 0 para a versão anterior à primeira.
Y	Número intermediário de versão, modificado sempre que houver inclusão de um ou mais conjuntos de novas funcionalidades. Esse número deve iniciar em 0 e reiniciado quando da troca do número principal.
Z	Número menor de versão, modificado sempre que liberada versão de correção de erros ou de comportamento esperado na versão do sistema. Esse número deve iniciar em 0 e reiniciado quando da troca do número intermediário ou do número principal. Para versões intermediárias ou principais novas, antes da homologação, esse número deverá ser acrescido do milestone de liberação (M1, M2, M3 etc.) até que a versão seja homologada, quando receberá o número menor.

Nomes das versões do sistema

As versões intermediárias do sistema receberão o nome de município brasileiro iniciado na letra de referência da versão, estas na ordem alfabética, que não contenha espaços ou caracteres especiais, obtidos a partir do nome das unidades federativas, essas na ordem alfabética inversa. Assim, por exemplo, temos:

Versão	Letra de referência	Unidade Federativa	Município existente na letra de referência
1.0	A	Tocantins	Alvorada
1.1	B	Sergipe	Balbinos
1.2	C	São Paulo	Capela
1.4	D	Santa Catarina	Descanso
2.0	E	Roraima	Esmeralda

Versões de bibliotecas ou projetos utilitários do sistema

As bibliotecas ou projetos utilitários do sistema receberão sua numeração seguindo as seguintes regras:

X.Y.Z

, onde:

X	Número principal da versão, a ser alterada quando:a) opcionalmente, os desenvolvedores incluíram na versão substanciais alterações que melhoram as funcionalidades existentes; b) obrigatoriamente, quando a nova versão não é compatível, em nível de interface, com a versão de produção atual. A compatibilidade em nível de interface existe quando, substituída uma versão por outra em um projeto que somente faz uso das interfaces públicas da biblioteca, não há erro de compilação. Esse número deve ser 0 para a versão anterior à primeira.
Y	Número intermediário de versão, a ser alterado quando há acréscimos de funcionalidades em relação à versão anterior e não foi mantida a compatibilidade em nível de interface. Esse número deve iniciar em 0 e reiniciado quando da troca do número principal.
Z	Número menor de versão, modificado sempre que liberada versão de correção de erros ou de comportamento esperado na versão do sistema. Esse número deve iniciar em 0 e reiniciado quando da troca do número intermediário ou do número principal. Para versões intermediárias ou principais novas, antes da homologação, esse número deverá ser acrescido do milestone de liberação (M1, M2, M3 etc.) até que a versão seja homologada, quando receberá o número menor.

Versões de banco de dados

Os dumps de bancos de dados seguirão a nomenclatura da versão a que estão vinculadas, acrescido de descritor de seu conteúdo, quando necessário.
Exemplos:

• pjedb_1.0.1_treinamento.backup
• pjedb_1.0.1_treinamentobin.backup
• pjedb_1.0.1_limpa.backup
• pjedb_1.0.1_limpabin.backup
• pjedb_1.2.0_limpa.backup

No caso de scripts de bancos de dados, deverá ser seguida a seguinte regra de nomenclatura:

• pjescript_importacao_<versaodestino>_<descricao>.sql
• pjescript_conversao_<vorigem>-<vdestino>_descricao.sql

, onde a descrição é opcional.

Exemplos: • pjescript_importacao_1.0.1_cep.sql • pjescript_conversao_1.0.1-1.0.1.sql • pjescript_importacao_1.0.1_cnae.sql

Política de criação de versões

As versões principais e intermediárias dependem, para sua criação, de definição da gerência geral do projeto, que também deverá delimitar o escopo da versão a ser elaborada.
As versões menores serão criadas à medida que forem liberadas as versões menores, devendo sempre haver a previsão de uma futura versão menor assim que liberada a imediatamente anterior, com vistas a permitir a elaboração de versão de correção de urgência.

Política de criação de branches

O desenvolvimento principal da versão atual do sistema será feito no trunk do projeto, exceto quando houver desenvolvimento concomitante entre duas versões principais, caso em que o trunk será utilizado para o desenvolvimento da versão principal de maior número e será aberto um branch da versão principal de menor número no formato X.Y.x.
Em um cenário de desenvolvimento normal, ele será efetivado no trunk do projeto até a liberação da primeira versão menor, quando deverá ser criado um branch ou ramo designado principal.intermediário.x. Assim, liberada a versão 1.0.0, devem ser adotadas as seguintes providências:

• criar uma tag com o número da versão liberada (1.0.0);
• criar um branch com o número da versão liberada, substituindo o número menor por “x” (1.0.x);
• o trunk deverá passar a ser utilizado para a elaboração da versão intermediária ou principal seguinte;
• o branch da versão liberada será utilizado para formação das tags de versões menores dessa versão (1.0.1, 1.0.2 etc.)

Adotadas tais providências, a manutenção da versão liberada deverá ser feita no branch da versão, sem prejuízo de essas manutenções serem integradas com o trunk, que deverá passar a ser utilizado exclusivamente com o objetivo de liberar a versão intermediária subsequente (1.1.0).
Caso haja desenvolvimento concomitante de uma versão intermediária e de uma versão principal, além dos passos descritos acima, dever-se-á criar um branch da nova versão intermediária (no exemplo, 1.1.x), do qual será extraído a tag da versão homologada, deixando o trunk para desenvolvimento da versão principal nova (2.0)
Ao criar um branch o usuário deverá comentar a operação com o padrão:

Criação do BRANCH PJe <versão intermediária> (<nome>)

Funcionalides novas

A critério da gerência geral do projeto poderão ser criados branchs para desenvolvimento de conjuntos de funcionalidades novas que, por suas características, possam implicar em significativa modificação do código fonte. Nesses casos, o branch deverá ser identificado com o número da versão de origem seguido de “_<descricao>”. Exemplo: 1.0.x_criminal; 1.0.x_revisao; 1.0.x_oracle. Esses branches deverão ser utilizados exclusivamente para posterior integração com o trunk ou com o branch específico da versão de origem.

Política de criação de tags

As tags serão criadas sempre que houver nova liberação do sistema para implantação em órgão diverso do CNJ. A nova tag deverá ser extraída:
a) do trunk do sistema, quando da liberação de versão principal ou intermediária, em um ciclo de desenvolvimento normal;
b) do branch da versão intermediária, quando da liberação de versão menor; ou
c) do branch da versão intermediária, quando da liberação de versão intermediária originária se ela estiver em desenvolvimento concomitante com uma versão principal superior.
As tags serão identificadas pelo número da versão do sistema, inclusive o número menor, acrescentando-se:

• Mn: a letra “M” seguida de um número sequencial, enquanto não iniciado o processo de homologação da primeira versão intermediária daquela versão;
• Hn: a letra “H” seguida de um número sequencial, enquanto não finalizada a homologação da primeira versão intermediária.

As tags M deverão ser apagadas quando liberada a primeira versão de homologação e as tags H quando liberada a primeira versão homologada.
Ao ser criada uma tag, o usuário deverá comentar a operação com o padrão:

Criação da TAG PJe <versãotag> (<nome>

Política de realização de integração

Homologadas alterações realizadas em um branch elas devem ser integradas com o trunk ou com a branch de versão intermediária vinculada ao branch das alterações.
As submissões de códigos fonte decorrentes de tais integrações deverão ser feitos com a inclusão do comentário padronizado a seguir:

Merge entre: <tag/branch origem> e <branch/trunk destino>

Política de submissões (commits)

A operação de submissão de códigos fonte deverá ser sempre precedida de uma atualização da cópia de trabalho do desenvolvedor, que deverá assegurar que eventuais conflitos de código não impeçam a compilação ou inicialização do sistema.
Os commits deverão ser realizados diariamente ou sempre que concluída a elaboração de uma funcionalidade ou correção de um erro designados como demanda no JIRA.
Ao submeter o código, o desenvolvedor deverá mencionar, em alguma parte do comentário, o identificador da demanda no JIRA no formato de sua apresentação nesse sistema (PJE-NNN...).
Também deverá indicar se a submissão conclui seu trabalho na demanda. Jamais deve ser feita submissão de código fonte que impeça a compilação ou a inicialização do sistema.

Os diretórios de compilação dos projetos devem ser excluídos do controle de versões.

Versões previstas

O PJe será elaborado e liberado em versões periódicas, com ciclos de desenvolvimento por versões em que há acréscimos de conjuntos de funcionalidades entre elas. Uma versão prevista pode ser suprimida do ciclo de desenvolvimento se constatada a inviabilidade de sua liberação tempestiva.

As versões previstas são:

Versão	Nome	Descrição
0	Marco Zero	Primeira versão integrada do sistema, elaborada a partir do código fonte fornecido pelo Tribunal Regional Federal da 5ª Região.
1.0	Alvorada	Primeira versão de produção integrada para uso por tribunais em homologação e produção diretamente controlada pelo Conselho Nacional de Justiça.
1.2	Capela	Primeira versão de produção integrada com funcionalidades de instâncias de revisão.
1.4	Descanso	Versão do sistema incluindo características de interoperabilidade, replicação nacional e complementação das funcionalidades criminais
2.0	Esmeralda	Versão do sistema em nova arquitetura com novas funcionalidades.

Política de acesso

O PJe encerra um desenvolvimento colaborativo intenso que envolve múltiplas fábricas de software e analistas de sistemas, muitas vezes não localizados no mesmo ponto geográfico brasileiro. Em razão disso e da intensa necessidade de controle do código fonte com vistas a evitar um desenvolvimento não controlado, o acesso aos artefatos do sistema deve ser bem controlado.
Deve-se identificar esses acessos segundo os seguintes papéis:

Papel	Sigla	Descrição
Membro do CG	CG	Magistrado membro do comitê gestor nacional.
Gerente geral	GG	Servidor diretamente ligado ao CNJ que gerencia o projeto.
Gerente de configuração	GC	Servidor diretamente ligado ao CNJ que procura assegurar o respeito ao plano de gerência de configuração.
Gerente de desenvolvimento	GD	Servidor diretamente ligado ao CNJ que lidera o desenvolvimento do sistema, assegurando que os desenvolvedores respeitem as regras de configuração, de desenvolvimento e os requisitos especificados.
Gerente de qualidade	GQ	Servidor diretamente ligado ao CNJ que lidera as atividades de testes e homologação de uma versão do sistema.
Analista de requisitos	AR	Pessoa, servidor ou não, responsável por receber, analisar e formalizar os requisitos de uma determinada funcionalidade do sistema.
Analista de bancos de dados	ABD	Servidor responsável por avaliar a estrutura de bancos de dados do sistema, com vistas a assegurar sua otimização quando necessário.
Desenvolvedor	DES	Pessoa, servidor ou não, responsável por implementar um determinado requisito ou caso de uso no sistema.
Membro de grupo de requisitos	ER	Servidor especialista em um determinado tópico que dará insumos para a preparação dos requisitos e dos casos de uso pertinentes.
Fábrica	FAB	Tribunal ou terceiro contratado responsável por desenvolver uma determinada funcionalidade ou manter um determinado branch. Cabendo a ela realizar os commits na periodicidade definida neste documento respeitadas as regras estabelecidas de desenvolvimento e qualidade.

Tomando por base tais papéis, os acessos devem ser concedidos seguindo a seguinte tabela:

Recurso	CG	GG	GC	GD	GQ	AR	ABD	DES	ER	FAB
Wiki – artefatos de gerência	L	LG	LG	LG	LG	L	L	L	L	L
/aplicacao	-	L	L	LG	L	L	L	LG	-	LG*
/documentacao/analise/rcdu	L	L	LG	L	L	LG	L	L	L	LG*
/aplicacao/analise/casosdeuso	L	L	LG	L	LG	LG	L	L	L	LG*
/aplicacao/analise/modelosartefatos	L	LG	LG	L	LG	L	L	L	L	L
/aplicacao/analise/regrasdenegocio	L	L	LG	L	LG	LG	L	L	L	LG*
/aplicacao/requisitos	L	L	LG	L	LG	LG	L	L	L	LG*
/aplicacao/bancodedados/*	L	L	LG	LG	L	L	LG	L	L	LG*
/aplicacao/qualidade/*	L	LG	LG	L	LG	LG	L	L	L	LG*

, onde:

• L = leitura
• LG = leitura e gravação
• LG* = leitura e gravação limitadas ao branch afetado a essa fábrica, ou no trunk, se atuando no trunk, devendo ela assegurar que os papéis correspondentes internos, nesses casos, respeitem iguais regras de permissão.