Plano de gerência de configuração

De PJe
Edição feita às 17h22min de 4 de fevereiro de 2013 por Renata.catao (disc | contribs)

(dif) ← Edição anterior | ver versão atual (dif) | Versão posterior → (dif)
Ir para: navegação, pesquisa

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.

Conteúdo

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:

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. Teiaversoes.jpg
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:

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
                        Arvorepastas.jpg

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.
Ferramentas pessoais
Espaços nominais

Variantes
Ações
Navegação
Informações Gerais
Aplicativos PJe
Manuais
Suporte
Ferramentas