5. CRONOGRAMA E ENTREGAS
Considerando a estratégia ScrumXP, iterativa e incremental, o cronograma foi estruturado em sprints com entregas funcionais associadas às User Stories planejadas no Story Map do projeto. Cada sprint busca entregar uma fatia funcional do sistema que possa ser demonstrada, verificada pela equipe e validada com o cliente, evitando a organização das entregas apenas por camadas técnicas isoladas.
O sequenciamento das sprints segue a jornada principal do usuário no sistema, partindo da base de acesso e cadastros iniciais, avançando para registros assistenciais, consulta de histórico, governança de acesso e visão consolidada do residente.
Em todas as sprints, as atividades de Engenharia de Requisitos ocorrem de forma contínua, incluindo refinamento das User Stories planejadas, revisão dos critérios de aceitação, atualização da rastreabilidade, aplicação de DoR e DoD, validação com o cliente e revisão dos Requisitos Não Funcionais aplicáveis.
Para apoiar as evidências de execução, cada sprint deve manter seus registros nos artefatos correspondentes de Planning, Dailys, Review e Retrospectiva. Esses artefatos servem como referência para demonstrar o que foi planejado, executado, validado e ajustado ao longo do projeto.
Nota sobre a cadência: embora o ciclo de desenvolvimento seja pautado em sprints quinzenais, a Sprint 0 correspondeu a uma fase estendida de concepção e alinhamento. Esse período foi necessário para compreender o domínio do Lar dos Velhinhos, negociar o escopo inicial com a organização parceira e preparar a equipe para as sprints de execução.
| Sprint | Período | Objetivo principal | Entregas esperadas | Atividades de ER na sprint | Validação com o cliente |
|---|---|---|---|---|---|
| Sprint 0 (Concluída) | 31/03 – 02/05 | Compreensão do problema e alinhamento de escopo | • Identificação das principais dores do cliente. • Definição inicial do escopo do produto. • Documento de Visão e Diagrama de Ishikawa entregues. • Alinhamento inicial sobre o problema central e o contexto da instituição. |
• Entrevistas semiestruturadas. • Mapeamento inicial do fluxo de trabalho. • Levantamento preliminar de stakeholders. • Discussão inicial das oportunidades de solução. |
• Alinhamento com o cliente sobre o problema central. • Validação inicial do foco em uma solução digital para apoiar os registros assistenciais. |
| Sprint 1 (Concluída) | 03/05 – 16/05 | Levantamento inicial de requisitos e estruturação do produto | • Escopo inicial estruturado. • Primeiras User Stories documentadas. • Requisitos funcionais e não funcionais iniciais organizados. • Estrutura inicial da documentação no MkDocs. • DoR inicial definido para apoiar as próximas sprints. |
• Brainstorm para levantamento e refinamento inicial das funcionalidades. • Escrita e revisão inicial das User Stories. • Aplicação inicial de DoR às primeiras histórias. • Registro das evidências de acompanhamento da sprint em planning, dailys, review e retrospectiva. |
• Validação do entendimento inicial do problema. • Validação das principais funcionalidades esperadas para o produto. • Aprovação da direção geral do sistema pela equipe e pelo cliente. |
| Sprint 2 (Concluída) | 17/05 – 30/05 | Criar a base de acesso, usuários e residentes | • Tela de autenticação do usuário (US08). • Cadastro de novos usuários pelo gestor (US10). • Cadastro dos dados cadastrais de residentes (US01). • Encerramento de sessão do usuário (US09). • Fluxo demonstrável: login → cadastro de usuário → cadastro de residente → logout. |
• Refinamento do escopo da sprint. • Validação do DoR das US08, US10, US01 e US09. • Revisão dos critérios de aceitação das histórias da sprint. • Wireframes das telas de login, cadastro de usuário e cadastro de residente. • DoR e DoD aplicados às histórias da sprint. • Atualização da rastreabilidade entre User Stories, RFs, RNFs e Regras de Negócio associadas. |
• Demonstração do fluxo inicial de acesso e administração do sistema. • Cliente valida se os dados solicitados para cadastro de usuário e residente são suficientes para iniciar o uso do sistema. • Verificação do encerramento de sessão em dispositivo compartilhado. |
| Sprint 3 (Encerrada com débito técnico) | 31/05 – 13/06 | Iniciar o ciclo de registro e consulta assistencial | • Registro de sinais vitais do residente (US04). • Registro de rotinas assistenciais do residente (US05). • Consulta ao histórico cronológico de registros do residente (US14). • Fluxo demonstrável: selecionar residente → registrar sinais vitais/rotina assistencial → consultar histórico. |
• Revisão dos critérios de aceitação das US04, US05 e US14. • Validação dos campos dos formulários assistenciais. • Revisão das Regras de Negócio associadas aos registros assistenciais. • Revisão dos RNFs de usabilidade, rastreabilidade, integridade, operação offline e sincronização aplicáveis aos registros assistenciais. • DoR e DoD aplicados às histórias da sprint. • Atualização da rastreabilidade. |
• Validação prevista do fluxo assistencial em tablet. • Ao final da sprint, não houve incremento funcional concluído para validação com o cliente. |
| Sprint 4 (Planejada) | 14/06 – 27/06 | Consolidar cadastros, medicação e consulta por período | • Atualização de dados cadastrais de usuários (US11). • Edição de dados pessoais e clínicos de residentes (US02). • Registro de administração de medicamentos (US06). • Filtro do histórico assistencial por período (US15). |
• Refinamento dos critérios de aceitação das US11, US02, US06 e US15. • Revisão das regras de negócio relacionadas à medicação, edição de dados e integridade do histórico. • Revisão dos RNFs de segurança, rastreabilidade, desempenho e operação offline quando aplicáveis. • DoR e DoD aplicados às histórias da sprint. • Atualização da rastreabilidade. |
• Demonstração de atualização de usuário, edição de residente, registro de medicação e filtro do histórico por período. • Cliente valida se o fluxo permite atualizar informações e localizar registros de forma segura e compreensível. |
| Sprint 5 (Planejada) | 28/06 – 11/07 | Ampliar governança de acesso e registros assistenciais | • Redefinição de senha de acesso de usuário (US12). • Revogação de acesso de usuário (US13). • Inativação do cadastro de residente (US03). • Registro de ocorrências clínicas do residente (US07). |
• Revisão das regras de negócio sobre acesso, inativação, preservação de histórico e ocorrências clínicas. • Refinamento dos critérios de aceitação das US12, US13, US03 e US07. • Revisão dos RNFs de segurança, rastreabilidade, integridade dos dados e controle de acesso. • DoR e DoD aplicados às histórias da sprint. • Atualização da rastreabilidade. |
• Demonstração do controle de acesso administrativo. • Cliente valida o fluxo de redefinição de senha e revogação de acesso. • Cliente valida se a inativação de residente remove o cadastro do fluxo operacional sem apagar seu histórico. • Validação do registro de ocorrências clínicas relevantes. |
| Sprint 6 (Planejada) | 12/07 – 16/07 | Consolidar a visão assistencial, homologação e aceite do incremento final | • Visualização do resumo assistencial do residente (US16). • Revisão dos principais fluxos planejados. • Treinamento dos usuários. • Teste de Aceite do Usuário (UAT). • Documentação de uso. |
• Validação final da rastreabilidade. • Revisão dos RNFs de segurança, usabilidade, desempenho, operação offline e confiabilidade. • Revisão final dos critérios de aceitação. • DoR e DoD aplicados à história da sprint e aos principais fluxos validados. • Retrospectiva final do processo de Engenharia de Requisitos. • Consolidação das lições aprendidas. |
• Cliente valida o resumo assistencial do residente. • Cliente executa os principais fluxos planejados em ambiente de homologação. • Realização de treinamento com usuários. • Aceite do incremento final e validação da documentação de uso. |
Novo cronograma (Pós debito técnico):
Atualização do status da Sprint 3 e realocação operacional das histórias pendentes para a Sprint 4
Após o encerramento da Sprint 3, as US04, US05 e US14 foram mantidas como débito técnico e realocadas operacionalmente para a Sprint 4. O cronograma atualizado preserva as entregas originalmente previstas para a Sprint 4 e registra a inclusão das histórias realocadas como ajuste de planejamento.
| Sprint | Período | Objetivo principal | Entregas esperadas | Atividades de ER na sprint | Validação com o cliente |
|---|---|---|---|---|---|
| Sprint 0 (Concluída) | 31/03 – 02/05 | Compreensão do problema e alinhamento de escopo | • Identificação das principais dores do cliente. • Definição inicial do escopo do produto. • Documento de Visão e Diagrama de Ishikawa entregues. • Alinhamento inicial sobre o problema central e o contexto da instituição. |
• Entrevistas semiestruturadas. • Mapeamento inicial do fluxo de trabalho. • Levantamento preliminar de stakeholders. • Discussão inicial das oportunidades de solução. |
• Alinhamento com o cliente sobre o problema central. • Validação inicial do foco em uma solução digital para apoiar os registros assistenciais. |
| Sprint 1 (Concluída) | 03/05 – 16/05 | Levantamento inicial de requisitos e estruturação do produto | • Escopo inicial estruturado. • Primeiras User Stories documentadas. • Requisitos funcionais e não funcionais iniciais organizados. • Estrutura inicial da documentação no MkDocs. • DoR inicial definido para apoiar as próximas sprints. |
• Brainstorm para levantamento e refinamento inicial das funcionalidades. • Escrita e revisão inicial das User Stories. • Aplicação inicial de DoR às primeiras histórias. • Registro das evidências de acompanhamento da sprint em planning, dailys, review e retrospectiva. |
• Validação do entendimento inicial do problema. • Validação das principais funcionalidades esperadas para o produto. • Aprovação da direção geral do sistema pela equipe e pelo cliente. |
| Sprint 2 (Concluída) | 17/05 – 30/05 | Criar a base de acesso, usuários e residentes | • Tela de autenticação do usuário (US08). • Cadastro de novos usuários pelo gestor (US10). • Cadastro dos dados cadastrais de residentes (US01). • Encerramento de sessão do usuário (US09). • Fluxo demonstrável: login → cadastro de usuário → cadastro de residente → logout. |
• Refinamento do escopo da sprint. • Validação do DoR das US08, US10, US01 e US09. • Revisão dos critérios de aceitação das histórias da sprint. • Wireframes das telas de login, cadastro de usuário e cadastro de residente. • DoR e DoD aplicados às histórias da sprint. • Atualização da rastreabilidade entre User Stories, RFs, RNFs e Regras de Negócio associadas. |
• Demonstração do fluxo inicial de acesso e administração do sistema. • Cliente valida se os dados solicitados para cadastro de usuário e residente são suficientes para iniciar o uso do sistema. • Verificação do encerramento de sessão em dispositivo compartilhado. |
| Sprint 3 (Encerrada com débito técnico) | 31/05 – 13/06 | Iniciar o ciclo de registro e consulta assistencial | • Registro de sinais vitais do residente (US04). • Registro de rotinas assistenciais do residente (US05). • Consulta ao histórico cronológico de registros do residente (US14). • Fluxo demonstrável: selecionar residente → registrar sinais vitais/rotina assistencial → consultar histórico. |
• Revisão dos critérios de aceitação das US04, US05 e US14. • Validação dos campos dos formulários assistenciais. • Registro do débito técnico ao final da sprint. • Encaminhamento das histórias pendentes para a Sprint 4. |
• Não houve validação funcional do ciclo assistencial. • As histórias planejadas para a sprint foram realocadas para a Sprint 4. |
| Sprint 4 (Planejada) | 14/06 – 27/06 | Consolidar cadastros, medicação e consulta por período, incorporando as histórias realocadas da Sprint 3 | • Histórias realocadas: US04, US05 e US14. • Escopo originalmente previsto: US11, US02, US06 e US15. |
• Refinamento dos critérios de aceitação das histórias da Sprint 4. • Revisão das histórias realocadas da Sprint 3. • Revisão de capacidade da equipe. • DoR e DoD aplicados às histórias da sprint. • Atualização da rastreabilidade conforme execução da Sprint 4. |
• Validação prevista do fluxo assistencial inicial e das funcionalidades de cadastro, medicação e consulta por período, conforme conclusão das entregas da sprint. |
| Sprint 5 (Planejada) | 28/06 – 11/07 | Ampliar governança de acesso e registros assistenciais | • Redefinição de senha de acesso de usuário (US12). • Revogação de acesso de usuário (US13). • Inativação do cadastro de residente (US03). • Registro de ocorrências clínicas do residente (US07). |
• Revisão das regras de negócio sobre acesso, inativação, preservação de histórico e ocorrências clínicas. • Refinamento dos critérios de aceitação das US12, US13, US03 e US07. • Revisão dos RNFs de segurança, rastreabilidade, integridade dos dados e controle de acesso. • DoR e DoD aplicados às histórias da sprint. • Atualização da rastreabilidade. |
• Demonstração do controle de acesso administrativo. • Cliente valida o fluxo de redefinição de senha e revogação de acesso. • Cliente valida se a inativação de residente remove o cadastro do fluxo operacional sem apagar seu histórico. • Validação do registro de ocorrências clínicas relevantes. |
| Sprint 6 (Planejada) | 12/07 – 16/07 | Consolidar a visão assistencial, homologação e aceite do incremento final | • Visualização do resumo assistencial do residente (US16). • Revisão dos principais fluxos planejados. • Treinamento dos usuários. • Teste de Aceite do Usuário (UAT). • Documentação de uso. |
• Validação final da rastreabilidade. • Revisão dos RNFs de segurança, usabilidade, desempenho, operação offline e confiabilidade. • Revisão final dos critérios de aceitação. • DoR e DoD aplicados à história da sprint e aos principais fluxos validados. • Retrospectiva final do processo de Engenharia de Requisitos. • Consolidação das lições aprendidas. |
• Cliente valida o resumo assistencial do residente. • Cliente executa os principais fluxos planejados em ambiente de homologação. • Realização de treinamento com usuários. • Aceite do incremento final e validação da documentação de uso. |
Execução Geral do Projeto
| Situação | Percentual | Observação |
|---|---|---|
| Execução geral registrada até a Unidade 3 | 43% | O percentual considera as entregas consolidadas da Sprint 0, Sprint 1 e Sprint 2. A Sprint 3 permanece como débito técnico, pois as funcionalidades planejadas para US04, US05 e US14 não foram concluídas no período. |
5.1 Evidências de Execução e Resultados
A execução do cronograma deve ser comprovada pela combinação entre artefatos de Engenharia de Software, artefatos de Engenharia de Requisitos e registros dos ritos de sprint. A tabela abaixo indica onde as evidências já registradas podem ser verificadas e quais resultados do cronograma elas sustentam.
| Sprint | Evidências de Engenharia de Software | Evidências de Engenharia de Requisitos | Resultado evidenciado |
|---|---|---|---|
| Sprint 0 | Estratégias de Engenharia de Software e reunião de alinhamento com o monitor. | Reunião de elicitação, reunião de alinhamento com o cliente, cenário atual e solução proposta. | Problema, contexto operacional, restrições do cliente, escopo inicial e processo ScrumXP definidos. |
| Sprint 1 | Planning, Dailys, Review, Retrospectiva, gravação da Review e gravação da Retrospectiva. | Requisitos, User Stories, DoR/DoD e Story Map. | Brainstorm inicial, requisitos funcionais e não funcionais, primeiras User Stories e DoR registrados como base para as sprints seguintes. |
| Sprint 2 | Planning, Execução, Resumo, Dailys, Review e Retrospectiva. | User Stories, Requisitos, DoR/DoD e Story Map, usados como base para selecionar e validar US08, US10, US01 e US09. | Fluxo base de acesso, cadastro de usuários, cadastro de residentes e encerramento de sessão implementado e verificado tecnicamente. |
| Sprint 3 | Planning, Dailys, Review e Retrospectiva. | User Stories, Requisitos, DoR/DoD e Story Map, com foco em US04, US05 e US14. | Sprint encerrada com débito técnico. Não houve incremento funcional concluído para US04, US05 e US14, que foram realocadas para a Sprint 4. |
| Sprints 4 a 6 | Artefatos de Planning, Dailys, Review e Retrospectiva devem ser preenchidos conforme cada sprint for executada. | Requisitos, critérios de aceitação, RNFs, regras de negócio e rastreabilidade devem ser atualizados conforme o refinamento de cada sprint. | Consolidação progressiva dos cadastros, medicação, governança de acesso, ocorrências clínicas, resumo assistencial, treinamento e aceite final. |
Histórico de Revisão
| Data | Versão | Descrição | Autor |
|---|---|---|---|
| 03/04/2026 | 1.0 | Criação do documento de cronograma e entregas. | Alberto Côrtes, João Pedro Sampaio, Ana Carolina, Enzo Menali e Gustavo Xavier |
| 10/04/2026 | 1.1 | Finalização e correção do documento para primeira entrega. | Alberto Côrtes, Ana Carolina, Enzo Menali e Gustavo Xavier |
| 12/04/2026 | 1.2 | Ajustes no cronograma para melhor sincronização com o Plano de Ensino. | Alberto Côrtes |
| 13/04/2026 | 1.3 | Correção de ambiguidades de ER, distinção entre verificação e validação e ajustes arquiteturais PWA. | Gustavo Xavier, Alberto Côrtes |
| 23/05/2026 | 1.4 | Reestruturação do cronograma para alinhamento com o Story Map oficial, reorganizando as entregas por User Stories de cada sprint e adequando as atividades de DoR e DoD. | Enzo Menali |
| 05/06/2026 | 1.5 | Atualização do status das sprints, explicitação dos artefatos usados como evidências de execução, inclusão da rastreabilidade das evidências e alinhamento das atividades de ER às técnicas realizadas. | Enzo Menali |
| 15/06/2026 | 1.6 | Correção do escopo cadastral da Sprint 2 e ampliação das referências às evidências disponíveis. | Enzo Menali |
| 16/06/2026 | 1.7 | Inclusão do percentual geral de execução do projeto, encerramento da Sprint 3 com débito técnico e realocação operacional das US04, US05 e US14 para a Sprint 4. | Enzo Menali |