Processo de desenvolvimento de software

Em construção

Processo Operacional

O processo operacional define o modelo adotado para execução do ciclo de vida do projeto, ou seja, define a organização do trabalho técnico do projeto, incluindo as atividades, os artefatos e as fases.

Descreveremos aqui o processo operacional do PJe.

Contextualização do PJe

O objetivo principal do CNJ com o PJe é manter um sistema de processo judicial eletrônico capaz de permitir a prática de atos processuais pelos magistrados, servidores e demais participantes da relação processual diretamente no sistema, assim como o acompanhamento desse processo judicial, independentemente de o processo tramitar na Justiça Federal, na Justiça dos Estados, na Justiça Militar dos Estados e na Justiça do Trabalho.

Além disso, o CNJ pretende convergir os esforços dos tribunais brasileiros para a adoção de uma solução única, gratuita para os próprios tribunais e atenta para requisitos importantes de segurança e de interoperabilidade, racionalizando gastos com elaboração e aquisição de softwares e permitindo o emprego desses valores financeiros e de pessoal em atividades mais dirigidas à finalidade do Judiciário: resolver os conflitos.

Estrutura gerencial do PJe

O sistema Processo Judicial eletrônico (PJe) é um software elaborado pelo Conselho Nacional de Justiça (CNJ) a partir da experiência e com a colaboração de diversos tribunais brasileiros.

O projeto é coordenado pela Comissão de Tecnologia da Informação e Infraestrutura do Conselho Nacional de Justiça. Na gestão direta, o projeto conta com um comitê formado por magistrados representando o CNJ e outros segmentos do judiciário.

Sob esse comitê, há a gerência do projeto propriamente dita, com a responsabilidade da gestão do projetos, gestão das mudanças e gestão da interoperabilidade.

O PJe, dentro do CNJ, funciona como uma estrutura virtual vinculada à Coordenação de desenvolvimento de sistemas que, por sua vez, é vinculada ao Departamento de Tecnologia da Informação. Vinculada A denominação estrutura virtual é atribuída à unidade que não possui hierarquia de linha ou de staff e, por outro lado, também não pode ser considerada estrutura informal, uma vez que detém o reconhecimento institucional quanto à exclusividade de suas competências, com delimitações de autoridade e responsabilidade.

O objetivo de se criar o PJe como uma estrutura virtual é aprimorar a gestão do Processo Judicial Eletrônico no âmbito do CNJ, obter um sistema de autoridade flexível (unidade de gestão do Projeto responder a diferentes autoridades) e de compartilhar recursos (sistemas, pessoas, tecnologia). Esta estrutura é exclusivamente competente no âmbito do DTI pela gestão tática e operacional das atividades alusivas ao PJe. Descreveremos, a seguir, a estrutura criada.

Gerente de projetos do PJe

O PJe tem características de projeto, apesar de muitas vezes se parecer a uma operação. Nesse sentido, o Gerente de projetos tem atribuições semelhantes ao papel homônimo de tantas metodologias que utilizam os conceitos do PMBok em suas definições. Dentre as principais, encontram-se a controle de cronogramas, a participação na definição de escopo, a atribuição de responsabilidades e o gerenciamento de comunicações.

Assistência em requisitos do PJe e capacitação

Os insumos para treinamentos e a participação nos planejamentos e execuções de capacitações relacionadas ao PJe é escopo da assistência em requisitos. Ela deve firmar parcerias com outros órgãos que aderiram ao PJe de forma a criar multiplicadores de conhecimento.

A análise de requisitos, envolvendo definição e validação de funcionalidades do sistema está entre suas atribuições. Além disso, a assistência é responsável pelas definições a respeito do processo operacional e da padronização dos artefatos produzidos no desenvolvimento do projeto.

Assistência em desenvolvimento de sistemas do PJe

A assistência em desenvolvimento é responsável pelo desenvolvimento de melhorias do PJe, controlando o cronograma de desenvolvimento a fim de atender ao planejamento de versões.

Assistência em atendimento e qualidade do PJe

A assistência em atendimento e qualidade é responsável pelos testes do PJe, pela centralização do atendimento ao público interno e externo e pelo controle de liberação de versões do sistema.

Assistência em implantação e manutenção do PJe

A assistência em manutenção faz a gerência das atividades de correção de defeitos do PJe, planejando suas versões intermediárias para atendimento dos tribunais que têm PJe instalado.

Organização do projeto

Conceitos sobre versões utilizados no PJe

Para entendimento do processo de desenvolvimento do PJe, são necessárias algumas explanações sobre conceitos de versões utilizados no sistema.

O fluxo de desenvolvimento é iniciado com o cadastro de uma demanda no sistema de controle de demandas adotado. No caso do CNJ, o sistema adotado foi o JIRA. No JIRA, a palavra “issue” significa “demanda”.

Todo o código fonte, assim como artefatos de banco de dados, são mantidos em um repositório GIT de controle de versões sob responsabilidade da equipe do PJe no CNJ. O GIT é um software que permite o controle de versões de forma descentralizada. Dessa forma, fábricas de desenvolvimento fora do CNJ podem participar do desenvolvimento do PJe, mas as alterações deverão sempre ser submetidas ao repositório central, alterações essas avaliadas pela equipe do PJe.

Regras de Versionamento

O esquema de numeração de versões adotado pelo CNJ é baseado no esquema adotado pela organização Apache Foundation. O esquema define que uma versão é composta por quatro números inteiros, MAJOR.MINOR.MICRO.PATCH onde:

MAJOR	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 demanda 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.
MINOR	Número menor 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 deve ser reiniciado quando da troca do número principal.
MICRO	Número micro de versão, modificado sempre que liberada uma versão de correção de erros ou de comportamento esperado na versão do sistema. Esse número deve iniciar em 0 e deve ser 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.
PATCH	Número de correção de versão, modificado sempre que liberada uma versão de correção de erros críticos do sistema.

O repositório GIT tem dois ramos de desenvolvimento principais: o principal (master), que recebe todas as modificações planejadas para a próxima versão, e o versão estabilizada (stable), que representa a versão atual em produção.

A figura abaixo apresenta em detalhes como o processo ocorre. O repositório possui dois branches principais: o master, que recebe todas as modificações planejadas para a próxima versão, e o stable, que representa a versão atual em produção. Praticamente todos os sistemas de controle de versão possuem algum suporte a ramificação (Branching). Ramificação significa que o usuário pode divergir da linha principal de desenvolvimento e continuar a fazer seu trabalho sem mexer com esta linha. Através de ramificação, são criadas as versões minor, micro e os patches.

Geração de versões

Nas reuniões do Comitê Gestor Nacional que ocorrem mensalmente, são discutidas, entre outras questões, as prioridades para lançamentos de novas versões no PJe.

Dado esse direcionamento a partir dessa reunião, uma reunião de planejamento de liberação de versão ocorre envolvendo a fábrica do CNJ e as fábricas que participam do desenvolvimento do sistema, atualmente as da Justiça do Trabalho, da Justiça Eleitoral e do TJDFT.

Nessa segunda reunião são definidas as funcionalidades que entrarão como conteúdo da próxima liberação de versão, devidamente alinhado com a definição do Comitê Gestor Nacional. A partir dessa reunião, agrupam-se as pendências eleitas para serem desenvolvidas em funcionalidades a serem disponibilizadas na versão planejada (principal).

É criada, então, uma versão do PJe considerada uma versão estabilizada, onde não haverá requisições de subida de código, salvo correções de defeitos. Ao mesmo tempo, as novas funcionalidades são desenvolvidas na versão principal (original da estabilizada), onde são duplicadas as requisições de subida de código das correções.

Nesse meio tempo, podem ser lançadas versões de correção de defeitos. Atualmente as correções estão sendo liberadas através de versões patch mas, após migração de todos os tribunais para versão 1.5.0 ou superior, o PJe liberará correções através de versões micro.

Ao final do ciclo, é gerada internamente uma subversão da principal para homologação com um rótulo numerado iniciado pela letra "h" (exemplo:"1.6.0.h0"). São realizados testes durante duas semanas, e outras versões "h" são lançadas internamente com correções dos erros reportados. Se considerada estável, ou seja, se não tem defeitos bloqueadores, é lançada uma possível liberação de versão para os tribunais denominada "rc" (release candidate). Os tribunais terão duas semanas para homologarem a possível versão, votando pela homologação ou não através do Jira. Uma vez aceita, a versão é liberada.

Para versões micro (atualmente, para versões patch), não são lançados os rótulos “h” e “rc”. Após testes internos, a versão é lançada diretamente.

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

Estratégia de evolução do PJe

O PJe é um sistema, assim como tantos, em constante evolução. As correções e melhorias do PJe são propostas partindo das seguintes situações: usuários do sistema que detectam seu mal funcionamento ou necessidade de melhoria testadores do PJe que detectam seu mal funcionamento em testes para liberação de versão e propõem melhorias de acordo com suas experiências de uso gestores ou equipe interna do PJe que, tendo vivência com suas ocorrências e com o sistema em si, vislumbram pontos de melhoria e correção

A partir dessa identificação, seguindo o modelo definido nas instruções de abertura de pendências no Jira, que é a ferramenta de controle de demandas do PJe, uma pendência deve ser aberta contendo a descrição da solicitação e suas principais definições. A partir daí, a demanda flui através dos seguintes passos:

1. Triagem das pendências, abrangendo uma análise prévia validando as informações de preenchimento, especialmente quanto ao cumprimento das instruções para abertura de pendências
   1. Para o caso de pendências do tipo "Melhoria" ou "Nova funcionalidade", encaminhamento para análise da gerência técnica do PJe.
      1. Após avaliação, pendência seguirá para análise de requisitos, e posteriormente para o desenvolvimento, conforme priorização dada pelo comitê.
   2. Para o caso de defeitos ou bugs em produção:
      1. Sendo a pendência aberta por um solicitante da equipe da justiça do trabalho, justiça eleitoral ou TJDFT, encaminhamento para equipe pertinente
      2. Sendo a pendência aberta por um solicitante de outro grupo que não os citados acima, encaminhamento para desenvolvimento na equipe interna do CNJ
2. Desenvolvimento da pendência
3. Homologação técnica da pendência
4. Homologação negocial da pendência
5. Aceite da pendência pelo solicitante

A gerência técnica do PJe é composta pelos gestores da área técnica do PJe e atualmente contém os seguintes membros: o gerente de projetos do PJe(CNJ), o chefe da seção de sistemas de processamento judiciário(CNJ), dois magistrados do comitê gestor (Dr. Paulo e Dr. Carl - CNJ), o coordenador técnico do PJe no CSJT e líder da equipe de TI do PJe no TSE. Todas as pendências abertas no Jira que sejam dos tipos Melhoria ou Nova Funcionalidade que estiverem na situação 'Aberta' devem ser encaminhadas para essa gerência para validação, priorização e planejamento de novas versões do PJe.

A homologação técnica consiste na avaliação da codificação por parte de uma equipe centralizada, de forma que a integração do código desenvolvido à versão do PJe seja controlada.

A homologação negocial consiste no teste da demanda, mas via de regra é realizado também pelo solicitante. Estamos aprovando um novo fluxo de pendências no Jira, mas a alteração não deve mudar o conteúdo do que temos que feito, pelo contrário, visa a adequação do Jira às nossas necessidades.

Segue abaixo um mapeamento das atividades de evolução do PJe iniciadas através de pedidos de melhoria:

Segue abaixo um mapeamento das atividades de evolução do PJe iniciadas através de uma solicitação de correção de defeito:

A seguir, segue um detalhamento das atividades de cada assistência descrita anteriormente com foco no atendimento da estratégia de evolução do PJe.

Descrição detalhada dos papéis das assistências

Assistência em requisitos do PJe e capacitação

Análise de requisitos

A análise de requisitos é, usualmente, acionada pela gerência técnica para detalhamento de requisitos de pendências autorizadas e priorizadas.

A assistência é a principal mantenedora da wiki do projeto, sítio disponível na Internet com restrições de edição que centraliza toda a documentação referente ao projeto.

Na análise de requisitos são produzidos os artefatos para detalhamento dos requisitos, sendo o nosso principal artefato o conjunto de casos de testes no Testlink, ferramenta que auxiliar na manutenção dos casos e na execução dos testes. Nos casos de teste, deverá se fazer referência a conteúdos inseridos na wiki do PJe, especialmente às regras (de negócio, de interface e de domínio) e à descrição da funcionalidade. As funcionalidades (que abrangem os conteúdos do manual de referência) são o conjunto de opções de uso do sistema. Procuramos evitar o termo caso de uso, já que não estamos utilizando desenvolvimento orientado a caso de uso, mas seria o conceito do caso de uso, sem o modelo padrão com todas aquelas seções comuns ao processo unificado. Geralmente as referências citadas aos documentos da wiki são feitas nos passos dos casos de teste, mas uma importante seção do caso de teste são as premissas de teste, que podem tanto referenciar as regras e funcionalidades, como outras seções da wiki, como roteiros de configuração, orientações para desenvolvimento de fluxos, configuração inicial e instalação. Essas últimas seções contém orientações de configuração do PJe. Muitas vezes, para se testar uma aplicação, o testador deve se certificar que o sistema está pronto para realizar o teste, de forma a evitar que mal funcionamento decorrente de configuração equivocada seja confundido com defeito. Além do conjunto de casos de teste, outros artefatos, como diagramas, matrizes e o que mais o analista julgar necessário para o entendimento da demanda. Eles devem ser produzidos, de preferência, em ferramentas de livre utilização, e sua disponibilização vinculada à demanda no Jira deve ser feita em formatos que todos os usuários possam ter acesso.

Ao finalizar a documentação, a pendência deve ser enviada para a assistência em desenvolvimento para que fique pronta e seja posteriormente testada.

Ao iniciarmos a discussão sobre uma demanda, principalmente quando se trata de alguma funcionalidade maior, temos optado por evoluir um pouco mais os requisitos antes de abertura da pendência no Jira fazendo registro em uma área de "rascunho" da wiki denominada Melhorias. Ainda estamos trabalhando na melhor forma de apresentar essa seção, mas seu uso é opcional, apesar de ser recomendado, por facilitar a comunicação entre o "cliente" (solicitante da demanda) e o analista de requisitos.

Capacitação

Como principais detentores do conhecimento negocial a respeito do sistema, a assistência em requisitos também é responsável por construir documentações gerais do sistema, independente da demanda das melhorias. Dessa forma, a assistência auxilia na divulgação do conhecimento sobre o PJe como parte de sua competência de capacitação, além da responsabilidade de produção de materiais de treinamento e auxílio em sua condução.

Assistência em desenvolvimento de sistemas do PJe

A assistência em desenvolvimento é responsável pelo desenvolvimento de melhorias do PJe. Nesse sentido, seu trabalho é direcionado às versões futuras do PJe que estão em desenvolvimento, denominadas de versão principal.

Representamos, abaixo, o funcionamento dessa assistência.

Como colaboradores com as mudanças de código do PJe e principais usuários de sua definição arquitetural, a assistência em desenvolvimento do PJe também agrega às suas responsabilidades a definição e evolução da arquitetura do sistema, sob a coordenação do comitê gestor.

Assistência em implantação e manutenção do PJe

Os comportamentos dissonantes do PJe são tratados como defeitos e bugs em produção. Os defeitos são problemas encontrados, via de regra, na fase de homologação de uma versão, ou seja, em ambiente de testes. Os bugs em produção são problemas encontrados no ambiente de produção. A correção dos bugs em produção, em alguns casos, pode ocorrer através da geração de scripts de banco de dados, de forma a evitar que o tribunal precise evoluir sua versão para obter o funcionamento correto. Para essas situações, deve ser aberto um outro defeito, se for o caso, para mapear a correção da versão que ocasionou o mal comportamento que teve que ser corrigido via script de banco de dados. Nesse último caso, o auxílio da assistência em atendimento e qualidade pode ser acionado. Algumas vezes o mal comportamento não é detectado ou se diagnostica um problema de configuração no PJe que ocasionou o bug, não sendo, dessa forma, necessária a correção através de liberação de versão.

As liberações de versão de correção de defeitos/bugs em produção são realizadas, preferencialmente, de quatro em quatro semanas. As correções são replicadas nas versões em desenvolvimento que, dentro do CNJ, são de responsabilidade da assistência em desenvolvimento.

A assistência em implantação, por vezes, precisa solicitar o auxílio da assistência em requisitos na resolução das pendências, visto que a documentação existente do PJe não abrange todas as funcionalidades disponíveis e o desenvolvedor precisa da definição negocial para saber qual o comportamento esperado do sistema.

Além dessa comunicação, a assistência em implantação, ao finalizar uma versão, repassa a notificação para a assistência em atendimento, que é responsável pelos procedimentos de liberação da versão, tornando-a disponível para os usuários externos.

Assistência em atendimento e qualidade do PJe

A gestão dos ambientes de desenvolvimento, teste e homologação, assim como dos bancos de dados e de tarefas de desenvolvimento relacionadas a bancos está sob a coordenação da assistência em atendimento, assim como a centralização do atendimento dos usuários internos e externos do PJe.

Liberação de versão

A assistência em atendimento, ao ser notificada da finalização de uma versão, realiza os procedimentos de geração da versão para implantação com base nos rótulos criados no GIT. A partir das versões posteriores à 1.4.6.4, pacotes intermediários estarão disponíveis para os tribunais com correções integradas ao código principal do PJe através da utilização de integração contínua. Disponibilizando versões nightly, geradas automaticamente ao final do dia com tudo que foi integrado pelas equipes de desenvolvimento, pretende-se facilitar a acelerar o processo de obtenção de correções por partes dos tribunais. É válido ressaltar que as versões nightly possivelmente não são estáveis, já que não foram realizados testes para garantir seu funcionamento. Apesar disso, as versões nightly são de grande valia para os tribunais, visto que com esse atalho, os tribunais não precisam esperar até o lançamento da versão para obtenção de uma correção prioritária para sua instalação, além de disponibilizar outras correções apontadas pelas notas de liberação da versão nightly gerada.

Testes

O teste do PJe hoje abrange teste manual e testes automatizados, mas são sempre funcionais. Não temos procedimentos de teste de stress ou de performance.

A execução dos testes utiliza os casos de teste definidos pela assistência em requisitos realiza seu registro no Testlink.

Para automação dos testes, o PJe se utiliza do Selenium web driver. Os casos de testes vinculados a testes automatizados devem conter referências às automações de forma a facilitar a publicidade de disponibilização da automação. Além disso, o Selenium foi integrado ao Testlink para que o resultado das execuções de teste no ambiente de automação seja refletido automaticamente no Testlink. Além disso, o JUnit é utilizado em conjunto com o Selenium para auxiliar o Selenium na verificação dos resultados esperados.

Há a pretensão de se utilizar o JMeter para testes de performance. Anteriormente, foram automatizados casos de teste funcionais com o auxílio do JMeter, prioritariamente direcionados aos testes de funcionalidades mais simples do PJe, tais como as disponíveis através do menu de configurações. Como esse não é o objetivo da ferramenta, os casos de teste serão migrados para a migração.