Pular para o conteúdo principal

IT2 — Resultados de V&V

Registro formal das mudanças de processo e cronograma identificadas durante a IT2, decorrentes do adiamento do prazo final da disciplina comunicado pelo professor em 18/06/2026.

  • Estratégia: Verificação
  • Técnica: Análise de rastreabilidade e Inspeção

Legenda: Aplicado aplicado · Pendente pendente de aplicação · Crítico achado crítico · Atenção achado de atenção


1. Mudanças de Processo

MP.03 Adiamento do prazo final da disciplina — Unidade 4 passa a ser a última entrega Aplicado

MP.03 — Adiamento do Prazo Final da Disciplina

CampoConteúdo
DeCalendário previa entregas acadêmicas até a Unidade 4 (29/06–07/07), com possibilidade de uma IT3 executada em paralelo/sequência ainda dentro da disciplina
ParaO professor adiou o prazo final da disciplina. A Unidade 4 passa a ser a última entrega acadêmica do semestre — não há mais nenhuma unidade prevista além dela
MotivaçãoComunicação do professor George Marsicano em 18/06/2026 sobre adiamento do tempo de entrega da atividade
ImpactoRecalendarização de IT2 (encerramento) e da Unidade 4; pausa da IT3
StatusAplicado em Cronograma 5.2/5.6
MP.04 IT3 — Núcleo Operacional pausada (sem janela dentro da disciplina) Aplicado

MP.04 — Pausa da IT3 — Núcleo Operacional

CampoConteúdo
DeIT3 planejada para iniciar em 29/06, em sequência imediata à IT2, com requisitos não priorizados ("extra")
ParaIT3 pausada — sem data prevista dentro da disciplina. Poderá ser executada pós-disciplina, caso a equipe e o cliente decidam continuar o projeto
MotivaçãoSem janela de tempo remanescente no semestre após o adiamento (MP.03) para iniciar uma terceira iteração
ImpactoCP2, CP3 e CP7 (Núcleo Operacional) não serão entregues nem validados dentro da disciplina
StatusAplicado Atualizado em IT3 — Resumo e Iterações — Visão Geral
MP.05 Extensão da IT2 de 28/06 para 30/06, com remarcação de Validação e Artifact Closure Aplicado

MP.05 — Extensão da IT2

CampoConteúdo
DeIT2 com término em 28/06: Partial + Formal Client Validation em 27/06, Iteration Artifact Closure em 28/06
ParaIT2 estendida até 30/06: Partial Client Validation em 27/06, Formal Client Validation em 29/06, Iteration Artifact Closure em 30/06
MotivaçãoFolga adicional de 2 dias liberada pelo adiamento do prazo final (MP.03), usada para consolidar a entrega da IT2 com mais segurança
StatusAplicado em Cronograma 5.6 — Calendário (Junho)
MP.06 Gravação e apresentações da Unidade 4 remarcadas (gravação 01/07, apresentações 02–09/07) Aplicado

MP.06 — Remarcação da Unidade 4

CampoConteúdo
DeGravação do vídeo em 06/07; apresentações em 07, 08 e 09/07
ParaGravação do vídeo e preparação dos slides em 01/07; apresentações de 02/07 até 09/07
MotivaçãoAlinhamento ao novo prazo final comunicado pelo professor em 18/06/2026
StatusAplicado em Cronograma 5.6 — Calendário (Julho) e em Entrega — Unidade 4

2. Mudanças de Requisitos

Registro da auditoria de rastreabilidade realizada em 01/07/2026 sobre as features F07, F08, F19, F20 e F21 (IT2 — CP1 e CP9), decorrente da conclusão da implementação dessas features. Cobre: status atualizado (Em andamento → Concluída), requisitos funcionais novos identificados a partir de capacidades já implementadas mas não documentadas, um critério de aceite existente revisado, e dois achados de auditoria (itens em aberto) a levar para a próxima reunião de refinamento.

MR.01 Achados de auditoria — ACs marcados concluídos sem implementação/documentação correspondente Concluído

MR.01 — Descasamentos entre AC documentado e comportamento real

CampoConteúdo
Achado 1RF36 (F19) tinha um AC marcado concluído — "Dado cliente/lead inativo, quando reativar, então volta ao fluxo ativo" — mas não existia reativação implementada (nem endpoint, nem UI); só a inativação (soft-delete) existia.
Achado 2RF53 (F21) e RN22 descreviam remoção de interação comercial como exclusão permanente (hard-delete). A implementação real sempre foi remoção lógica (soft-delete, removed=true) — preserva o histórico, comportamento mais seguro, mas divergia do texto documentado.
MotivaçãoAuditoria de rastreabilidade realizada ao atualizar o status de F07/F08/F19/F20/F21 para Concluída — comparação linha a linha entre AC documentado e código implementado.
ResoluçãoAchado 1: reativação de lead implementada em 01/07/2026 — POST /api/admin/crm/clients/:id/reactivate + GET /api/admin/crm/clients/inactive no backend, e um painel "Leads inativos" no CRM (admin/crm) com ação de reativar por lead. Achado 2: optou-se pela correção recomendada — o texto de RF53/RN22 foi corrigido para descrever soft-delete, já que é o comportamento mais seguro e o que está implementado; nenhuma mudança de código foi necessária para este achado.
StatusConcluído em 01/07/2026 — F19 — RF36 e F21 — RF53 atualizados e consistentes com o código
MR.02 RF60–RF62 novos — busca, filtros, exportação CSV, tabela e indicadores do CRM (F19) Aplicado

MR.02 — Novos Requisitos Funcionais de F19

CampoConteúdo
DeF19 cobria apenas CRUD de leads (RF35, RF36, RF37, RF41) — sem nenhum RF de consulta, filtro ou exportação, apesar de o protótipo de alta fidelidade do CRM já prever busca, filtros por produto/pessoa, exportação CSV, visualização em tabela e mini-dashboard.
ParaTrês RFs novos, mesmo nível de abstração dos RFs existentes de F19 (um por capacidade, seguindo o padrão de RF52/RF19 no restante do catálogo): RF60 — Filtrar e buscar leads no CRM · RF61 — Exportar leads do CRM em CSV · RF62 — Visualizar leads em tabela e indicadores do funil. Critérios de aceite BDD completos em F19 — RF60 / RF61 / RF62.
MotivaçãoCapacidades já implementadas e comparadas com o protótipo de alta fidelidade do CRM, mas sem RF correspondente no backlog — gap identificado na auditoria de rastreabilidade.
RastreabilidadeIssue #177 (F19) atualizada · sub-issue #243 criada e fechada · Tabela de Requisitos · Priorização · Árvore de Rastreabilidade
StatusAplicado — implementado, documentado e rastreado
MR.03 RF15 revisado — bloqueio de duplicidade de template substituído por ativação automática (F08) Aplicado

MR.03 — Critério de Aceite Revisado (incremento, não requisito novo)

CampoConteúdo
DeRF15, AC 3: "Dado tipo de evento que já possui template, quando criar outro para o mesmo evento, então o sistema impede a duplicidade" (erro 409, exige remoção manual antes de criar um novo).
Para"Dado tipo de evento que já possui um template ativo, quando criar outro template para o mesmo evento, então o template anterior é desativado automaticamente e o novo passa a ser o único ativo" — ativação automática por substituição. Ver F08 — RF15.
MotivaçãoMelhoria de UX solicitada pelo Product Manager: escolher um tipo já deve deixá-lo ativo imediatamente, sem exigir que o admin remova manualmente o template anterior primeiro.
ClassificaçãoIncremento/refinamento de AC existente — não é requisito novo (RF15 continua sendo "Adicionar template de notificações").
RastreabilidadeIssue #180 (F08) atualizada · Tabela de Requisitos
StatusAplicado
MR.04 RF63 novo — cor e catálogo fixo de tipos para templates de notificação (F08) Aplicado

MR.04 — Novo Requisito Funcional de F08

CampoConteúdo
DeTemplates de notificação tinham tipo_evento como campo de texto livre, sem cor associada — qualquer string era aceita, sem checagem contra os eventos reais do sistema.
ParaRF63 — Personalizar cor e tipo de template de notificação: tipo escolhido a partir de um catálogo fixo (tipos ainda não implementados aparecem desabilitados) + cor personalizável por template, usada para destacar as notificações resultantes na central. Critérios de aceite BDD completos em F08 — RF63.
MotivaçãoNecessidade de diferenciar visualmente notificações por categoria (ex.: segurança e controle) e de impedir tipos de evento inválidos/inexistentes no cadastro de template.
RastreabilidadeIssue #180 (F08) atualizada · sub-issue #244 criada e fechada · Tabela de Requisitos · Priorização · Árvore de Rastreabilidade
StatusAplicado — implementado, documentado e rastreado
MR.05 Status de F07/F08/F19/F20/F21 atualizado para Concluída — impacto na priorização Aplicado

MR.05 — Status e Priorização

CampoConteúdo
DeF07, F08, F19, F20 e F21 marcadas Em andamento em Priorização e com os RFs correspondentes na aba "Planejados (IT2/IT3)" da Tabela de Requisitos, apesar de todas as sub-issues das 5 features estarem fechadas.
ParaAs 5 features marcadas Concluída; RFs movidos para a aba "Implementados (IT1 + IT2)"; badge "Concluída" adicionado nas 5 páginas individuais de feature.
Impacto na priorizaçãoRF60–RF63 (novos) e o AC revisado de RF15 não reduzem a prioridade das features F19 e F08. O cálculo de IP (VB/ES) permanece o registrado originalmente nas issues #177 e #180 — essas capacidades foram um refinamento de escopo dentro de features já priorizadas como Q1/Alta (F19: IP 2,5) e aceita conscientemente fora do Quadrante I por dependência lógica (F08: IP 1,31, depende de F07). Se algo, o valor de negócio entregue por F19 e F08 é maior do que o estimado originalmente — reforça a prioridade já atribuída, não a enfraquece. Nenhum recálculo de VB/ES/IP foi feito; ver nota na Tabela MVP.
RastreabilidadeTabela de Requisitos v2.2 · Priorização v3.3 · Árvore de Rastreabilidade (nós de F19/F08 e RF60–RF63 já apontam para as páginas de feature, não mais para a tabela genérica)
StatusAplicado