ANEXO III – METODOLOGIA DE DESENVOLVIMENTO E MANUTENÇÃO DE SISTEMAS

1. INTRODUÇÃO

1.1. Esta metodologia visa definir os processos de desenvolvimento e manutenção de software utilizados no desenvolvimento externo da Secretaria de Tecnologia da Informação (STI) do Ministério Público do Distrito Federal e Territórios (MPDFT).

1.2. Esses processos de desenvolvimento e manutenção detalham as fases do ciclo de vida, as principais atividades, os responsáveis envolvidos em cada etapa e os produtos gerados.

2. PROJETO DE DESENVOLVIMENTO

2.1. Para projetos de desenvolvimento e manutenção de sistemas, foram utilizadas como referência conceitos de metodologia ágil e outras práticas do mercado. Nesta metodologia estão presentes as seguintes características:

2.1.1. Desenvolvimento iterativo e incremental;

2.1.2. Entrega contínua de funcionalidades;

2.1.3. Gestão de mudanças;

2.1.4. Verificação da qualidade;

2.1.5. Definição de modelos e padrões;

2.1.6. Visibilidade do planejamento.

2.2. Abaixo estão elencadas algumas diretrizes para a Release:

2.2.1. Para os níveis de mínimos de serviço (NMSE), serão contabilizados os itens do Backlog que estiverem concluídos na Release, os itens que retornarem para o Backlog do Produto ou forem cancelados não serão contabilizados;

2.2.2. O tamanho da Release em Ponto de Função (PF) será a soma da quantidade de PF dos itens concluídos;

2.2.3. O Nível de Serviço Mínimo Exigido (NMSE) de prazo da Release será o definido no contrato;

2.2.4. No encerramento de todo projeto, deve ser elaborado um artefato contendo as Lições Aprendidas.

2.3. FLUXO DE PROJETO DE DESENVOLVIMENTO E MANUTENÇÃO

2.4. VISÃO DO PROJETO

2.4.1. O artefato visão do projeto marca o início do projeto e contempla, dentre outros, as seguintes características:

2.4.1.1. Visão inicial do Backlog do produto;

2.4.1.2. Planejamento inicial do projeto;

2.4.1.3. Descrição dos potenciais riscos relacionados ao projeto;

2.4.1.4. Releases previstas.

2.4.2. O tempo de duração da Visão do Projeto não deve ser longo, a etapa deve durar o prazo máximo de 10 (dez) dias úteis. A função desta etapa é ter uma visão alto nível do projeto, não se deve detalhar os itens do Backlog do Produto nesta etapa.

2.4.3. FLUXO DA VISÃO DO PROJETO

2.4.4. Descrição das atividades

2.4.4.1. Elaborar Visão de Projeto – A CONTRATADA elabora a Visão de Projeto após alinhamento das necessidades de negócio.

2.4.4.2. Aprovar Visão de Projeto – O MPDFT aprova a Visão de Projeto, formalizando assim o início do projeto.

2.4.4.3. Criar repositório – A CONTRATADA cria o repositório do projeto de acordo com o modelo previamente definido.

2.4.4.4. Elaborar backlog do produto – A CONTRATADA realiza reuniões para levantamento de requisitos e, após análise, elabora o backlog do produto, de forma macro.

2.4.4.5. Aprovar backlog do produto – O MPDFT aprova o backlog do produto e autoriza a continuação do projeto.

2.4.4.6. Realizar contagem estimada – A CONTRATADA faz uma contagem estimada do produto baseado no backlog aprovado anteriormente.

2.4.4.7. Validar contagem – O MPDFT valida a contagem estimada do produto.

2.4.4.8. Elaborar planejamento do projeto/release – A CONTRATADA elabora um planejamento do projeto, indicando a quantidade de releases necessárias, definindo o produto de cada release, prazo estimado para finalização, etc.

2.4.4.9. Aprovar planejamento do projeto – O MPDFT aprova o planejamento realizado.

2.5. SPRINT

2.5.1. A quantidade de Sprints será definida na etapa Visão do Projeto e será atualizada ao longo do projeto. Segue abaixo a lista de diretrizes que devem ser seguidas em cada Sprint:

2.5.1.1. Todos os itens do topo do backlog devem estar READY no início da Sprint;

2.5.1.1.1. São considerados READY os itens de backlog que estejam claramente definidos, com os critérios de aceitação registrados e que tenham sido homologados pelo Product Owner.

2.5.1.2. A Sprint deve conter uma versão incremental utilizável do sistema do ponto de vista do usuário;

2.5.1.3. Uma nova Sprint terá início somente após a conclusão da Sprint anterior;

2.5.1.4. Cada Sprint deverá ter duração (time-box) de até 15 (quinze) dias corridos;

2.5.1.5. Uma Sprint pode ser cancelada antes do time-box da Sprint terminar, mas o cancelamento de Sprint deve ocorrer somente como exceção;

2.5.1.6. Somente o Product Owner tem a autoridade para cancelar a Sprint, embora ele possa fazer isso sob influência das partes interessadas, do Time de Desenvolvimento ou do Scrum Master;

2.5.1.7. Caso a Sprint seja cancelada, os itens do Backlog da Sprint que não estiverem concluídos devem retornar ao Backlog do Produto, esses itens não serão considerados cancelados;

2.5.1.8. Após o termino da Sprint, os itens do Backlog da Sprint que não estiverem concluídos devem retornar ao Backlog do Produto, esses itens não serão considerados cancelados.

2.5.2. Reunião de Planejamento da Sprint

2.5.2.1. O trabalho a ser realizado na Sprint é planejado na reunião de planejamento da Sprint. Este plano é criado com o trabalho colaborativo de todo o Time Scrum.

2.5.2.2. A Reunião de planejamento da Sprint deverá ter uma duração de até sete horas. A reunião de planejamento da Sprint responde as seguintes questões:

2.5.2.2.1. O que pode ser entregue como resultado do incremento da próxima Sprint?

2.5.2.2.2. Como o trabalho necessário para entregar o incremento será realizado?

2.5.3. Meta da Sprint

2.5.3.1. A Meta da Sprint é um objetivo definido para a Sprint que pode ser satisfeito através da implementação do Backlog do Produto. Este fornece uma direção para o Time de Desenvolvimento sobre o porquê de estar construindo o incremento.

2.5.3.2. A Meta da Sprint é criada durante a reunião de planejamento da Sprint. A Meta da Sprint dá ao Time de Desenvolvimento alguma flexibilidade a respeito da funcionalidade que será completada dentro dos limites da Sprint. Os itens do Backlog do Produto selecionados entregam uma função coerente, que pode ser a Meta da Sprint.

2.5.4. Revisão da Sprint

2.5.4.1. A Revisão da Sprint é executada no final da Sprint para inspecionar o incremento e adaptar o Backlog do Produto se necessário. Durante a reunião de Revisão da Sprint o Time Scrum e as partes interessadas colaboram sobre o que foi feito na Sprint. Esta não é uma reunião de status, e a apresentação do incremento destina-se a motivar e obter comentários e promover a colaboração. Esta reunião deve ter uma duração (Time-box) de até 4 (quatro) horas.

2.5.4.2. A Reunião de Revisão inclui os seguintes elementos:

2.5.4.2.1. O Product Owner esclarece quais itens do Backlog do Produto estão “Prontos” e quais não estão “Prontos”;

2.5.4.2.2. O Time de Desenvolvimento discute o que foi bem durante a Sprint, quais problemas ocorreram dentro da Sprint, e como estes problemas foram resolvidos;

2.5.4.2.3. O Time de Desenvolvimento demonstra o trabalho que está “Pronto” e responde as questões sobre o incremento;

2.5.4.2.4. Os participantes fazem uma análise da próxima versão esperada do produto;

2.5.4.2.5. Os participantes revisam o Backlog do Produto.

2.5.5. Fluxo da Sprint

2.5.6. Descrição das atividades

2.5.6.1. Planejar sprint – A CONTRATADA coordena o planejamento da Sprint, que conta com a realização da Reunião de Planejamento da Sprint.

2.5.6.2. Gerenciar mudanças – subprocesso que abrange as atividades requeridas para gerenciar mudanças. Ele é acionado sempre que uma mudança no produto é solicitada.

2.5.6.3. Elaborar especificações técnicas – A CONTRATADA elabora as especificações técnicas referentes às funcionalidades priorizadas na Sprint. Um pacote de especificações técnicas deve conter, no mínimo, os seguintes artefatos:

2.5.6.3.1. Itens de backlog detalhados por meio de estórias de usuário, com critérios de aceitação e exemplos

2.5.6.3.2. Modelo de dados

2.5.6.4. Desenvolver itens de backlog – A CONTRATADA desenvolve os incrementos de produto referente às funcionalidades priorizadas na Sprint. Um incremento de produto deve conter, no mínimo, os seguintes artefatos:

2.5.6.4.1. Backlog da Sprint

2.5.6.4.2. Pacote de especificações técnicas

2.5.6.4.3. Relatório de testes exploratórios baseado em sessões

2.5.6.4.4. Testes automatizados

2.5.6.4.5. Código fonte

2.5.6.4.6. Plano de implantação

2.5.6.4.7. Manual de usuário

2.5.6.4.8. Scripts de banco de dados

2.5.6.5. Implantar sprint em submissão – A CONTRATADA implanta o incremento do produto já testado e livre de erros no ambiente de submissão, para homologação técnica pela CONTRATANTE. Essa atividade contempla todas as ações necessárias para garantir que a versão incremental entregue do sistema esteja pronta para ser utilizada no ambiente. Por esse motivo, todos os testes especificados devem ser reexecutados no ambiente.

2.5.6.6. Verificar produtos da sprint – O MPDFT verifica os artefatos do(s) itens de backlog desenvolvidos, do ponto de vista técnico e funcional.

2.5.6.7. Implantar sprint em homologação – A CONTRATADA implanta a sprint já testada e livre de erros no ambiente de homologação, para homologação funcional pela CONTRATANTE. Essa atividade contempla todas as ações necessárias para garantir que a versão incremental entregue do sistema esteja pronta para ser utilizada

no ambiente. Por esse motivo, todos os testes especificados devem ser reexecutados no ambiente.

2.5.6.8. Homologar produtos da sprint – O MPDFT homologa os itens de backlog da sprint. Nesta etapa o MPDFT pode contar com a ajuda da equipe CONTRATADA para dirigir a homologação.

2.5.6.8.1. Em caso de atraso na homologação superior a 2 (dois) dias úteis, a homologação será escalonada para o chefe da unidade. Se não houver atuação em até 2 (dois) dias úteis, o incremento do produto será homologado por decurso de prazo.

2.5.6.8.2. Uma Sprint será considerada falha quando o objetivo principal da Sprint não tiver sido atendido, ou algum artefato não tiver sido entregue dentro das diretrizes estabelecidas neste documento.

2.5.6.9. Realizar revisão da Sprint – A CONTRATADA coordena a revisão da Sprint, mediante realização da Reunião de Revisão da Sprint.

2.5.6.10. Implantar sprint em produção – A CONTRATADA implanta a sprint no ambiente de produção. Essa atividade contempla todas as ações necessárias para garantir que a versão incremental entregue do sistema esteja pronta para ser utilizada no ambiente. Por esse motivo, todos os testes especificados devem ser reexecutados no ambiente.

2.5.6.11. Realizar contagem detalhada – A CONTRATADA realiza a contagem detalhada dos pontos de função da Sprint.

2.5.6.12. Validar contagem – Subprocesso que abrange as atividades requeridas para validar a contagem dos pontos de função.

3. MANUTENÇÃO

3.1. Para o processo de Manutenção, foram utilizados como referência práticas de mercado. Para o ciclo de vida das demandas de Manutenção, foram adotadas as seguintes características:

3.1.1. Desenvolvimento iterativo e incremental;

3.1.2. Entrega contínua de funcionalidades;

3.1.3. Gestão de mudanças;

3.1.4. Verificação da qualidade;

3.1.5. Definição de modelos e padrões;

3.1.6. Visibilidade do planejamento.

3.2. FLUXO DA MANUTENÇÃO

3.2.1. Descrição das atividades

3.2.1.1. Especificar manutenção – O MPDFT descreve, por meio de uma ordem de serviço, os detalhes da manutenção.

3.2.1.2. Detalhar requisitos – vide Elaborar especificações técnicas do Fluxo da Sprint.

3.2.1.3. Desenvolver incremento – vide Desenvolver Itens de Backlog do Fluxo da Sprint.

3.2.1.4. Implantar incremento em submissão – vide Implantar Sprint em Submissão do Fluxo da Sprint.

3.2.1.5. Verificar incremento – vide Verificar Produtos da Sprint do Fluxo da Sprint.

3.2.1.6. Homologar incremento – vide Homologar Produtos da Sprint do Fluxo da Sprint.

3.2.1.7. Implantar incremento em produção – vide Implantar Sprint em produção do Fluxo da Sprint.

3.2.1.8. Realizar contagem detalhada – vide Realizar contagem detalhada do Fluxo da Sprint.

3.2.1.9. Validar contagem – vide Validar contagem do Fluxo da Sprint.

3.3. Caso um sistema possua artefatos que não estejam em conformidade com os modelos vigentes na MDMS, esses artefatos legados deverão ser atualizados para os modelos da MDMS vigente.

3.4. Todas as funcionalidades que forem escopo de manutenção deverão ter sua documentação convertida para modelos de artefatos da MDMS vigente.

4. SUBPROCESSOS

4.1. GERENCIAR MUDANÇAS

4.1.1. O objetivo do subprocesso é assegurar que o controle das mudanças seja tratado adequadamente, de forma que seja possível monitorar as mudanças do projeto e tratar a necessidade de criar novos itens no Backlog do Produto ou realizar a mudança na Sprint corrente.

4.1.2. FLUXO DO SUBPROCESSO

4.1.3. Descrição das atividades

4.1.3.1. Especificar solicitação de mudança – A CONTRATADA elabora a especificação da solicitação de mudança.

4.1.3.2. Aprovar solicitação de mudança – O MPDFT aprova a solicitação de mudança.

4.1.3.3. Acrescentar itens no backlog do produto – O MPDFT acrescenta os itens de mudança no backlog do produto.

4.1.3.4. Acrescentar itens no backlog da Sprint – A CONTRATADA acrescenta os itens no backlog da Sprint.

4.1.3.5. Realizar mudanças – A CONTRATADA realiza as mudanças quando cabem no escopo da Sprint, ou seja, não extrapolam seu prazo máximo.

4.1.3.6. Atualizar planejamento – A CONTRATADA atualiza o planejamento do projeto com base na mudança aprovada.

4.2. VALIDAR CONTAGEM

4.2.1. O objetivo do subprocesso é definir a forma de validação da contagem.

4.2.2. FLUXO DO SUBPROCESSO

4.2.3. Descrição das atividades

4.2.3.1. Realizar contagem – A CONTRATADA realiza a contagem de pontos de função relativa à demanda.

4.2.3.2. Validar contagem – O MPDFT valida a contagem.

4.2.3.3. Realizar réplica da contagem – A CONTRATADA revisa a contagem, baseado nos apontamentos feitos pelo MPDFT.

4.2.3.4. Validar réplica da contagem – O MPDFT valida a réplica da contagem.

4.2.3.5. Coordenar reunião de consenso – O MPDFT coordena uma reunião de consenso, ocasião em que pode ser utilizada a expertise de empresa especialista.

4.2.3.6. Elaborar parecer – O MPDFT elabora um parecer acerca do resultado da reunião de consenso sobre a contagem.

4.2.3.7. Revisar contagem – A CONTRATADA revisa a contagem como resultado da reunião de consenso.

4.2.3.8. Revalidar contagem – O MPDFT revalida a contagem.

5. DIRETRIZES

5.1. As diretrizes a serem utilizadas em conjunto com a MDMS serão as vigentes no momento da execução da Manutenção e do Projeto, conforme estabelecido por portarias, resoluções, decretos, dentre outros.