Ir para o conteúdo

CRONOGRAMA E ENTREGAS DA UNIDADE 2

O planejamento da Unidade 2 dá continuidade à abordagem ágil, ao ciclo de vida ágil e ao processo Feature-Driven Development (FDD) adotados na Unidade 1. O cronograma compreende o período de 15/09/2026 a 13/10/2026, organizado em dois ciclos (ver Unidade 1, Seção 6.2), e as atividades podem ser refinadas após as revisões, validações com a Faculdade Brasília (FBr) e demonstrações de features.

Ciclo 1 (15/09 a 29/09) — Elicitação, declaração e validação cruzada dos requisitos

Período Fase / Processo FDD Atividades Desenvolvidas Atividade de ER / Resultado Entregáveis / Produtos
15/09 a 17/09 Kick-off e triagem de issues Análise rápida das issues abertas pelo professor e definição do que precisa ser corrigido com urgência. Organização e atualização: separação das CPs para decomposição em features. Evidência: Reunião de divisão de tarefas e requisitos Grupo de issues de correção urgente definido; divisão das 12 CPs entre a equipe.
16/09 a 21/09 Construir a Lista de Features / Declarar Requisitos Prioridade máxima: decomposição das CPs em features e elaboração dos Requisitos Funcionais (RFs) e Requisitos Não Funcionais (RNFs) para as 12 CPs; resolução das issues de correção urgente. Elicitação e descoberta (necessidades, regras e restrições por CP); declaração (features e critérios de aceitação). Lista de features por CP e primeira versão dos RFs e RNFs.
21/09 a 22/09, às 12h Revisão e publicação Revisão interna da primeira versão dos RFs e RNFs. Verificação e validação (revisão técnica interna). Primeira versão dos RFs e RNFs publicada no site.
22/09, às 12h, a 24/09, às 12h Verificação e validação cruzada Avaliação da equipe Umbra e registro dos feedbacks. Verificação e validação (checklist e validação cruzada entre stakeholders da disciplina). Artefato de feedback recebido.
24/09 a 26/09 Ajuste e correção dos requisitos Análise dos feedbacks recebidos e correção dos RFs e RNFs. Em paralelo, agendamento com o cliente da sessão de avaliação de valor de negócio. Análise e consenso (decisões negociadas a partir do feedback recebido). RFs e RNFs corrigidos; reunião de avaliação de valor de negócio agendada.
26/09 a 27/09 Avaliação técnica e validação interna Validação interna da lista corrigida de RFs e RNFs e avaliação técnica de cada RF (esforço, complexidade e lacuna de capacidade), com critérios e escalas previamente documentados. Verificação e validação (revisão técnica e checklist de esforço/complexidade). Lista de RFs e RNFs validada; avaliação técnica registrada.
27/09 a 28/09 Priorização e definição do escopo Consolidação da tabela de avaliações, construção da matriz 4×4 (valor de negócio × esforço técnico) e seleção/confirmação dos RFs e RNFs priorizados, com o cliente. Análise e consenso (prioridades e matriz negociadas com a equipe). Matriz 4×4 e escopo priorizado consolidado.
28/09 até 29/09, início da aula Publicação e validação com o cliente Publicação da versão final dos RFs e RNFs e validação do escopo priorizado com o cliente. Verificação e validação (validação com o stakeholder/cliente). Versão final dos RFs e RNFs, matriz, lista do escopo priorizado e justificativas publicadas no site.

Ciclo 2 (29/09 a 13/10) — DoR, DoD e consolidação da entrega

Período Fase / Processo FDD Atividades Desenvolvidas Atividade de ER / Resultado Entregáveis / Produtos
24/09 a 05/10 (iniciada em paralelo ao Ciclo 1) Correção de issues (em paralelo) Correção das issues da Unidade 1, em paralelo após a entrega de 22/09, e atualização do Modelo de Domínio. Representação (atualização do modelo de domínio). Issues da Unidade 1 corrigidas; Modelo de Domínio atualizado.
29/09 a 05/10 Definir DoR e DoD Definição do DoR e do DoD a partir do escopo já priorizado. Organização e atualização (critérios de prontidão e conclusão registrados). DoR e DoD publicados.
06/10 a 10/10 Consolidação da documentação Atualização do site com as demais seções, consolidação da Visão de Produto e Projeto e organização das evidências de execução dos processos de ESW e ER. Organização e atualização (lista de features, rastreabilidade e relatórios de progresso). Documentação da Unidade 2 consolidada.
11/10 a 12/10 Preparação da entrega Revisão final da rastreabilidade, atualização das evidências do cronograma, inclusão das Lições Aprendidas, preparação dos slides e gravação do vídeo de apresentação. Organização e atualização (rastreabilidade final). Slides, vídeo e Lições Aprendidas prontos.
13/10 Entrega Publicação do GitHub Pages, conferência dos artefatos e entrega oficial da Unidade 2. Organização e atualização (publicação final). Unidade 2 entregue.

Escopo de requisitos: as 14 CPs

O escopo de requisitos da Unidade 2 cobre, na numeração final adotada pela equipe, as 14 Características de Produto (CP1 a CP14). A divisão original de responsabilidades (Evidência: divisão das características de produto) foi feita com uma numeração provisória de 12 CPs, anterior à decomposição em features (issues #33, #34, #36, #37 e #38) e à criação da CP13. A tabela abaixo relaciona essa divisão original à cobertura efetiva, já na numeração final:

Integrante CP(s) na divisão original (numeração provisória) CP(s) cobertas (numeração final)
Jônatas CP1 e CP3 CP1 e CP3
Maria Clara CP5 e CP9 (declaração de comparecimento) CP5; CP10 (parte — declaração de comparecimento)
Luís Henrique CP2 e CP6 (prontuário, evolução e relatório final) CP2, CP6, CP7 e CP8
Joaquim CP11 (segurança) e CP8 (contribuição social) CP12; CP10 (parte — contribuição social)
Nicolas CP4 e CP7 (controle de assiduidade e alertas) CP4; CP9 — ver observação abaixo
Gabriel CP12 (acessibilidade) e CP10 (indicadores) CP14 e CP11
não fazia parte da divisão original CP13 — nova, incluída nesta unidade

Observação: a CP9 (Controle de assiduidade e alertas), sob responsabilidade original de Nicolas, não teve seus requisitos elicitados por ele neste ciclo — o trabalho de Nicolas concentrou-se na CP7 final (Registro de evolução por sessão), que se sobrepõe à decomposição da antiga CP6 conduzida por Luís Henrique (ver issue #35, reaberta, e PR #58). Para não deixar a lacuna aberta, a CP9 foi declarada (RF33–RF37, RNF32–RNF35) diretamente a partir dos pontos já confirmados com a Clínica Escola na reunião de 26/08/2026, sem passar pelo ciclo normal de elicitação individual; a validação dessa declaração com a FBr e a revisão pela equipe permanecem pendentes, como para as demais CPs.

A priorização entre essas CPs ocorre em 29/09/2026, ao final deste ciclo, por meio de uma avaliação formal de valor de negócio e de esforço técnico junto ao cliente. Apenas as CPs então priorizadas seguem para os ciclos de construção das Unidades 3 e 4 (ver Unidade 1, Seção 6.2).

Entregáveis da Unidade 2

Visão de Produto e Projeto atualizada

  • lista de requisitos funcionais (RFs) e requisitos não funcionais (RNFs);
  • escopo do produto, incluindo backlog, itens de trabalho e mapa do escopo;
  • escopo priorizado e recorte de entregas;
  • Definition of Ready (DoR);
  • Definition of Done (DoD).

Evidências de execução dos processos

  • evidências da execução do processo de Engenharia de Software (ESW);
  • evidências da execução das atividades de Engenharia de Requisitos (ER);
  • registros de reuniões, revisões, validações, inspeções e decisões;
  • registros das alterações realizadas no backlog, nos requisitos e no modelo de domínio.

Rastreabilidade

A entrega deve demonstrar a cadeia de rastreabilidade:

Problema → Objetivo Geral (OG) → Objetivos Específicos (OEs) → Características de Produto (CPs) → Requisitos Funcionais (RFs) e Não Funcionais (RNFs) → declarações de requisitos.

Também devem ser mantidos os vínculos entre requisitos, features, critérios de aceitação, itens de trabalho e entregas priorizadas.

Planejamento e publicação

  • evidências de cumprimento e atualização do cronograma;
  • documentação atualizada no site do projeto (GitHub Pages);
  • vídeo de apresentação da entrega da Unidade 2;
  • Lições Aprendidas da Unidade 2 (Seção 11.2).

Atualização do Planejamento

Ao final de cada ciclo de trabalho, a equipe revisará o andamento das features, as pendências de elicitação, os riscos, as dependências e os entregáveis. Alterações de escopo ou prazo serão registradas no repositório e comunicadas aos stakeholders nas reuniões de acompanhamento. O planejamento deve manter explícita a relação entre cada feature, seus critérios de aceitação e os requisitos não funcionais aplicáveis.