Fluxos por Tipo de Demanda (B)

Ponto de vista: SIS — Sistemas em Sustentação

Encaixe com atendimento de chamado {#encaixe-com-atendimento-de-chamado}

Os fluxos numerados abaixo permanecem a fonte normativa do SIS. Em operações de chamado (service desk ou equivalente), costuma-se encadear assim — sem substituir classificação de demanda, artefatos nem gates de promoção:

Triagem: registrar problema relatado, módulo, evidência (log, tela, ambiente), impacto e urgência.
Análise assistida (opcional): uso de IA ou ferramentas no repositório para localizar causas e dependências, com restrições de uso — idealmente sem alterar código até diagnóstico humano.
Diagnóstico humano: confirmar ou refutar hipóteses; decidir se a demanda permanece corretiva, adaptativa ou se há escopo evolutivo (nova história).
Evidência de verificação: testes automatizados quando existirem; quando não existirem, ver evidência quando automação for limitada na IMP.
Correção mínima (corretiva/adaptativa) ou implementação via IMP (evolutiva): alterações rastreáveis, PR/revisão conforme política do órgão.
Promoção: respeitar a cadeia Dev → Teste → Homologação → Produção e aprovações dos gates; atualizar RUN / OBS quando a sustentação exigir.

Fluxo Corretivo

Objetivo: corrigir defeito, falha ou comportamento divergente.

Antes do passo 1, registrar a decisão de reabrir a história ESP existente ou de manter o fechamento documental com vínculo ao ID da história — conforme História ESP: reabertura ou nova história.

1. Classificar a demanda como Corretiva
2. Delimitar o módulo afetado e coletar evidências do comportamento atual
3. Montar LKP com contexto do módulo
4. Identificar causa raiz (IA agêntica + revisão humana)
5. Revisão cruzada da causa identificada (segunda engine)
6. Aplicar correção
7. Validar ausência de impacto lateral (IRA simplificado)
8. Registrar evidência da correção
9. Atualizar documentação afetada (BRM, OBS, RUN se aplicável)

Fluxo Evolutivo

Objetivo: introduzir melhoria, mudança funcional ou adequação normativa.

Capacidade nova ou mudança de “esperado” exige nova história H* (não reutilizar o ID de uma história já aceita para outro escopo) — alinhar com a mesma política de história.

1. Classificar a demanda como Evolutiva
2. Delimitar objetivo, escopo e sistemas impactados
3. Montar LKP com contexto dos módulos afetados
4. Levantar regra atual (BRM) e regra pretendida
5. Produzir IRA — análise de impacto e ripple effect
6. Revisão cruzada do IRA (segunda engine + Validador Técnico)
7. Implementar via IMP (com histórias HS/HRD geradas a partir do BRM/IRA)
8. Validar comportamento esperado e impacto lateral
9. Atualizar artefatos (BRM, DIM, ASR, documentação)

Fluxo de Sustentação

Objetivo: preservar continuidade, estabilizar, monitorar, manter dependências.

1. Classificar a demanda como Sustentação
2. Identificar ativo impactado
3. Consultar OBS (estado de observabilidade) e RUN (procedimentos existentes)
4. Montar LKP com contexto operacional relevante
5. Aplicar ação de sustentação (patch, atualização, configuração)
6. Registrar evidências da ação
7. Atualizar RUN / OBS / base de conhecimento

Adaptativo — nota

O fluxo adaptativo segue o modelo de sustentação, com a diferença de que o escopo é sempre mudança de ambiente, não de comportamento. Exige IRA simplificado para confirmar que nenhum comportamento funcional foi alterado.

← Modos de Atuação · Critérios de Modernização →