Site oficial do TJRS

Ir para o conteúdo
Carregando...
A consulta de processos de execução criminal deve ser feita via Portal PEC.
Para acessar o Portal PEC clique aqui.
A consulta de processos de execução criminal deve ser feita via Portal PEC.
Para acessar o Portal PEC clique aqui.
Aguarde...

A Metodologia de Desenvolvimento de Sistemas do TJ-RS (MDS-TJRS) tem como objetivo guiar o desenvolvimento de sistemas para entregar aos clientes o melhor resultado com qualidade e agilidade.

É integrada com os processos organizacionais da Direção de Tecnologia da Informação e Comunicação (DITIC), tal como o Processo de Gestão de Demandas e o Processo de Gestão de Incidentes.

Tem como objetivo manter-se um guia organizacional sucinto, flexível, evolutivo, de fácil acesso e entendimento a todos da DITIC. A MDS-TJRS tem em sua estrutura três tipos de ciclos de vida e sete processos.

Clique para baixar o quadro resumo MDS-TJRS em PDF.Créditos:

1. Ciclos de vida

O ciclo de vida representa a forma que os processos são executados. Os tipos são o Preditivo, Iterativo e Incremental, e Fluxo Contínuo.

Ciclo de Vida Preditivo

É a forma de trabalho baseada em alta previsão do projeto. Também é conhecido como Modelo Cascata. Tem como base o PMBOK (Corpo de Conhecimento de Gerenciamento de Projetos).

Para uso desta forma fortemente planejada, deve-se ter muita certeza do que será realizado para que as entregas sejam conforme o que o cliente espera. Como prática recomendada para diminuir os riscos da entrega final, deve-se homologar entregas parciais com o cliente numa frequência máxima de um mês.

Todos os requisitos devem ser documentados e validados com o cliente antes de iniciar as próximas fases de projeto e desenvolvimento.

Ciclo de Vida Iterativo e Incremental

É a forma ágil de trabalho baseada em ciclos semanais de planejamentos e entregas frequentes. É a forma recomendada quando se trabalha em time em desenvolvimento de novas funcionalidades, ou evolução de funcionalidades já existentes.

O projeto é planejado e executado em iterações (sprints) de duração de uma a quatro semanas. Em cada iteração, o time desenvolve as funcionalidades priorizadas do sistema. Uma entrega pode necessitar de mais de uma iteração para ser desenvolvida. Mesmo assim, busca-se dividir a entrega em partes de valor e entregáveis ao cliente.

O framework Scrum e a metodologia ágil eXtreme Programming descrevem as práticas, reuniões e cerimônias desse ciclo iterativo e incremental. No início de cada iteração, o time planeja o que e como as funcionalidades serão desenvolvidas. A cada dia da iteração, o time realiza uma reunião diária para sincronização e replanejamento do trabalho sendo feito. No final de cada iteração, realiza-se a reunião de revisão para ver o que foi concluído como pronto, e a reunião de retrospectiva para criar ações de melhoria no processo do time.

Ciclo de Vida Fluxo Contínuo

É a forma de fluxo contínuo de trabalho, baseada em Kanban. É a forma recomendada para manutenção corretiva de sistemas onde não se necessita de planejamento e o tempo de resposta ao cliente deve ser o mais rápido possível.

As etapas do processo do time são mapeadas no quadro de Kanban. As tarefas priorizadas são desenvolvidas pelo time com um acompanhamento contínuo e diário. Reuniões diárias são realizadas para sincronização do trabalho. Reuniões de retrospectiva são recomendadas para revisar o processo de trabalho. As tarefas a serem realizadas devem ser priorizadas continuamente, de preferência diariamente. Para dar fluidez na realização das tarefas, o ideal é que se limite a uma tarefa por pessoa até que se conclua a tarefa em si.

2. Processos

Um processo define a forma de trabalho específico com artefatos, papéis, técnicas e ferramentas.

  • Artefatos provêm dados e informações tanto na entrada e na saída de processo. Artefatos podem ser requisitos de usuário, código versionado, casos de teste, entre outros.
  • Os papéis são relacionados a quem executa ou auxilia o processo. Papéis são relacionados à atividade de cada indivíduo no processo.
  • As técnicas são formas de trabalho a processar, utilizar e desenvolver artefatos.
  • Ferramentas são formas automatizadas para dar suporte ao trabalho executado no processo.

Os processos que compõem a Metodologia são:

  • Iniciação e Planejamento do Projeto;
  • Análise de Requisitos;
  • Design;
  • Desenvolvimento;
  • Teste;
  • Homologação;
  • Entrega.

Veja a seguir o diagrama dos processos da Metodologia.

Metodologia de Desenvolvimento de Sistemas do Tribunal de Justiça do Rio Grande do Sul

2.1 Processo de Iniciação e Planejamento do Projeto

Na iniciação do projeto, o PMO e o gerente de projeto – ou chefe de equipe – trabalham com o cliente e as partes interessadas para decidir a viabilidade do projeto. Sendo decidida a realização do projeto, segue-se para o Planejamento do Projeto. Senão, segue-se para o Fechamento do Projeto.

Os requisitos do projeto devem ser definidos, tais como requisitos da solução, requisitos de treinamento, documentação de usuário e documentação de atendimento. Até o final desta etapa, a equipe que desenvolverá o projeto também deve ser definida.

O processo de planejamento do projeto depende diretamente do ciclo de vida utilizado:

Planejamento Preditivo

O escopo com todas as funcionalidades é definido e o cronograma com as entregas do projeto é construído e validado para gerar uma alta previsibilidade.

Planejamento Iterativo e Incremental

O planejamento é realizado continuamente a cada iteração (sprint), com foco na próxima entrega, que é um incremento do sistema. Por esta razão, é chamado de iterativo e incremental.

Planejamento em Fluxo Contínuo

O planejamento é realizado continuamente a cada dia, com foco na repriorização das tarefas de acordo com diferentes tarefas corretivas do sistema.

Artefatos

  • Documento do Projeto*;
  • Ideia/Demanda.

Técnicas

  • Visão/Escopo;
  • EAP/WBS;
  • Diagrama de Gantt;
  • Roadmap/Planejamento de Entregas;
  • Reunião de partida / kickoff.

Ferramentas

  • CA Clarity PPM*;
  • SVN;
  • Git.

2.3 Processo de Análise de Requisitos

O Analista de Sistemas descreve os requisitos funcionais (de usuário) e não-funcionais (de sistema). O trabalho pode ser feito inicialmente numa especificação funcional, porém deverá seguir a estrutura de documentação de Casos de Uso ou de Histórias de Usuário.

O Analista de Testes pode auxiliar na definição e revisão dos requisitos, além da escrita de critérios de aceitação.

Artefatos

  • Casos de Uso ou Histórias de Usuário*;
  • Requisitos Não-Funcionais*;
  • Critérios de Aceitação;
  • Cenários de Exemplos;
  • Documentação de requisitos não-funcionais;
  • Protótipo de Interface de Usuário;
  • Modelo de Domínio;
  • Diagramas de Classe.

Técnicas

  • Análise do problema de negócio;
  • Modelagem de processos;
  • Grupos de foco;
  • Entrevistas com o cliente ou usuário;
  • Observação do processo do usuário;
  • Revisão de documentação, leis e diretrizes;
  • Prototipação de interface de usuário;
  • Modelagem de domínio de negócio.

Ferramentas

  • Enterprise Architect*;
  • CA Clarity PPM;
  • GitLab;
  • Redmine;
  • WireframeSketcher;
  • Word / Writer.

2.4 Processo de Design

O design da solução é definido seguindo a arquitetura, tecnologias e padrões estabelecidos. O design contempla o projeto de banco de dados, serviços, algoritmos, componentes, a interface com o usuário, entre outras formas necessárias.

Para algumas tarefas de design mais especializadas ou complexas, pode ser necessário que os desenvolvedores busquem o auxílio de arquitetos ou DBAs.

Artefatos

  • Modelo Entidade-Relacionamento*;
  • Protótipo de UI.

Técnicas

  • Prototipação de interface de usuário;
  • Modelagem Entidade-Relacionamento.

Ferramentas

  • Enterprise Architect*;
  • Erwin;
  • PowerPoint;
  • Pencil;
  • SQL Developer Data Modeler;
  • WireframeSketcher.

2.5 Processo de Desenvolvimento

A solução do requisito é realizada pelo desenvolvedor, gerando-se o código versionado.

Artefatos

  • Código versionado*;

Técnicas

  • Codificação;
  • Refatoração;
  • Depuração (Debugging);
  • Revisão de código;
  • Integração contínua;
  • Teste em ambiente local.

Ferramentas

  • IDEs;
  • Jenkins;
  • Redmine;
  • Pull requests com Git.

2.6 Processo de Teste

Verificação do requisito desenvolvido. Os Planos de Teste e os Casos de Teste são desenvolvidos pelo papel de Analista de Testes, e realizados pelo papel de Testador. A equipe pode auxiliar na definição e na execução dos testes caso necessário.

Os testes podem ser automatizados a partir dos Casos de Teste. O sistema de integração contínua pode verificar o build executando os testes automatizados. O ambiente de testes deve ser o mais idêntico possível ao ambiente de produção. Os defeitos (bugs) encontrados devem ser cadastrados com a informação necessária para reprodução, para que então possam ser corrigidos de acordo com a prioridade e impacto no sistema.

Artefatos

  • Casos de teste*;
  • Planos de teste;
  • Cenários / exemplos;
  • Testes funcionais automatizados.

Técnicas

  • Testes de aceitação*;
  • Testes funcionais*;
  • Testes automatizados;
  • Testes de integração;
  • Testes de unidade;
  • Testes de desempenho;
  • Testes de usabilidade;
  • Testes de regressão.

Ferramentas

  • Codeception;
  • Cucumber;
  • Enterprise Architect;
  • JMeter;
  • JUnit;
  • Selenium;
  • SoapUI.

2.7 Processo de Homologação

Validação dos requisitos pelo cliente ou usuário. O Analista de Sistemas e o Analista de Testes podem auxiliar o cliente ou o usuário na homologação.

Havendo mudanças significativas a pedido do cliente ou usuário, a homologação não ocorre e as mudanças necessárias deverão ser realizadas. Após os requisitos serem validados, o sistema é então entregue em produção.

Artefatos

  • Pacote da versão do sistema*;
  • Critérios de Aceitação.

Técnicas

  • Validação dos Critérios de Aceitação;
  • Reunião de Homologação.

Ferramentas

  • N/A.

2.8 Processo de Entrega

Entrega no ambiente de produção do pacote do sistema previamente homologado e versionado, junto aos artefatos resultantes dos requisitos do projeto tais como treinamento, documentação de usuário ou documentação de atendimento.

Artefatos

  • Plano de Implantação*;
  • Documentação para Atendimento ao Usuário;
  • Guia do Usuário;
  • Documentação de Treinamento.

Técnicas

  • Documentação de Release notes;
  • Formalização da Entrega.

Ferramentas

  • SDM*.

Processo Relacionado Gestão de Mudanças

O processo relacionado de Gestão de Mudanças deve ser realizado durante a entrega através de uma Requisição de Mudança (RDM) no SDM.

Subprocesso Fechamento do Projeto

Se a entrega finalizar o projeto, deve-se arquivar todos os artefatos desenvolvidos durante o projeto. Adicionar a referência do local na ferramenta Clarity PPM.