Planejamento e Organização
Esta página consolida os principais quadros de acompanhamento do VitalTech. Ela não substitui os documentos de visão, requisitos, sprints ou PRs; seu objetivo é servir como ponto de entrada para localizar rapidamente planejamento, evidências, status do MVP, rastreabilidade e prints das User Stories implementadas.
Síntese do Projeto
| Item | Registro |
|---|---|
| Cliente | Lar dos Velhinhos Bezerra de Menezes |
| Problema central | Registros assistenciais feitos em papel, transcrição posterior para planilhas/Microsoft Access, dificuldade de consulta rápida ao histórico e risco de perda ou atraso de informação. |
| Solução proposta | VitalTech, um PWA para registro e consulta assistencial com controle de acesso, persistência local e histórico por residente. |
| Estratégia de Engenharia de Software | ScrumXP, com sprints, planning, review, retrospectiva, revisão por pares, testes e incrementos funcionais. |
| Processo de Engenharia de Requisitos | Processo de ER, com elicitação, análise, especificação, validação, priorização e rastreabilidade. |
| Critérios de prontidão e conclusão | DoR e DoD, aplicados às User Stories planejadas e entregues. |
| Execução das User Stories do MVP | 100% do escopo funcional final planejado e evidenciado, considerando as User Stories entregues, replanejadas e registradas no recorte final do projeto. |
| Software disponível | Aplicação VitalTech |
Critérios Cobrados e Onde Estão Evidenciados
| Critério solicitado | Como está evidenciado |
|---|---|
| Quadro de planejamento com cronograma e evidências | Seção Quadro de Planejamento, com links para cronograma, planning, execução, review, retrospectiva e PRs. |
| Quadro de MVP com evidências e status | Seção Quadro MVP, com status por User Story, evidência, PR, teste e validação. |
| Rastreabilidade Problema > Objetivos > CPs > RFs > US/CA/UC | Seção Rastreabilidade, com links para problema, objetivos, características, RFs, RNs, RNFs, critérios de aceitação e casos de uso. |
| Prints por User Story | Seção US > Protótipo > Aplicação, com imagem e link de aplicação para cada US. |
| Processo ESW e ER com evidências | Quadros de planejamento, sprints, DoR/DoD, reviews, retrospectivas e links para Engenharia de Software e Engenharia de Requisitos. |
| Software funcional e disponível | Seção Software Disponível, com frontend publicado, API, Swagger e banco de dados. |
| Feedback do cliente | Review da Sprint 4, com registro textual da validação e referência ao formulário externo usado pela equipe. |
Quadro de Planejamento: Cronograma + Evidências
O cronograma completo permanece documentado em Cronograma. A tabela abaixo resume a execução e aponta para as evidências de cada ciclo.
| Sprint | Período | Objetivo | Status | Evidências principais | Resultado |
|---|---|---|---|---|---|
| Sprint 0 | 31/03 a 02/05 | Compreensão do problema e alinhamento de escopo. | Concluída | Reunião 1, Reunião 2, Cenário Atual, Solução Proposta. | Problema, cliente, contexto e oportunidade definidos. |
| Sprint 1 | 03/05 a 16/05 | Levantamento inicial de requisitos e estruturação do produto. | Concluída | Planning, Dailys, Review, Retrospectiva. | Base inicial de requisitos, visão do produto e documentação MkDocs. |
| Sprint 2 | 17/05 a 30/05 | Criar a fundação do sistema: login, usuários, residentes e logout. | Concluída | Planning, Execução, Review, Retrospectiva, PR #43. | US08, US09, US10 e US01 implementadas e evidenciadas. |
| Sprint 3 | 31/05 a 13/06 | Iniciar ciclo assistencial: sinais vitais, rotinas e histórico. | Encerrada com débito técnico | Planning, Dailys, Review, Retrospectiva. | US04, US05 e US14 foram realocadas para Sprint 4 por falta de incremento funcional concluído no período. |
| Sprint 4 | 14/06 a 27/06 | Recuperar débito da Sprint 3 e consolidar cadastros, medicamentos e filtro de histórico. | Concluída | Planning, Review, Retrospectiva, PR #83, PR #84, PR #85, PR #90, PR #91, PR #92, PR #93. | US04, US05, US14, US11, US02, US06 e US15 concluídas dentro do recorte entregue; para US04 e US05, edição de registros assistenciais fica como evolução posterior. |
| Sprint 5 | 28/06 a 01/07 | Finalizar governança de acesso, inativação, ocorrências clínicas e resumo assistencial. | Concluída tecnicamente | Planning, Review, Retrospectiva, PR #110, testes de serviços. | US12, US13, US03, US07 e US16 implementadas no código, cobertas por testes automatizados e registradas na Review/Retrospectiva da sprint. |
Linha do Tempo Visual do MVP
flowchart LR
S2["Sprint 2<br/>Concluída<br/>US08, US09, US10 e US01"] --> S3["Sprint 3<br/>Débito técnico registrado<br/>US04, US05 e US14 realocadas"]
S3 --> S4["Sprint 4<br/>Concluída<br/>Débito recuperado e escopo da sprint entregue"]
S4 --> S5["Sprint 5<br/>Concluída tecnicamente<br/>US12, US13, US03, US07 e US16"]
S5 --> DEP["Deploy<br/>Disponível<br/>Frontend, API e Swagger"]
Diagrama. Linha do tempo visual da evolução do MVP do VitalTech, consolidando as sprints de concepção, execução, recuperação de débito técnico, fechamento técnico e publicação do sistema.
Evidências Visuais por Sprint
| Sprint | Evidência visual | Registro textual |
|---|---|---|
| Sprint 0 | ![]() |
Reunião 1, Reunião 2, Cenário Atual e Solução Proposta. |
| Sprint 1 | ![]() |
Planning, Dailys, Review e Retrospectiva. |
| Sprint 2 | ![]() |
Planning, Execução, Review, Retrospectiva e PR #43. |
| Sprint 3 | ![]() |
Planning, Dailys, Review e Retrospectiva. |
| Sprint 4 | ![]() |
Planning, Review, Retrospectiva e PRs #83, #84, #85, #90, #91, #92 e #93. |
| Sprint 5 | ![]() |
Planning, Review, Retrospectiva e PR #110. |
Evidências do Processo de Execução
| Processo | Evidências |
|---|---|
| Scrum: Planning | Sprint 1, Sprint 2, Sprint 3, Sprint 4, Sprint 5. |
| Scrum: Dailys | Sprint 1, Sprint 2, Sprint 3, Sprint 4, Sprint 5. |
| Scrum: Review | Sprint 1, Sprint 2, Sprint 3, Sprint 4, Sprint 5. |
| Scrum: Retrospectiva | Sprint 1, Sprint 2, Sprint 3, Sprint 4, Sprint 5. |
| XP: revisão técnica e testes | PRs por entrega, revisão por pares e testes automatizados em services.test.js. |
| Engenharia de Requisitos | User Stories, Requisitos, Story Map, Matriz de Priorização, DoR/DoD. |
Software Disponível: Deploy e Ambientes
O VitalTech possui frontend publicado, API em produção e documentação automática da API. Esses links complementam as evidências de execução local e demonstram que o produto pode ser acessado fora do ambiente de desenvolvimento.
| Camada | Tecnologia | Evidência |
|---|---|---|
| Frontend | Vue 3, Vite e PWA na Vercel | Aplicação VitalTech |
| API | Python e FastAPI no Fly.io | API VitalTech |
| Documentação da API | Swagger gerado pelo FastAPI | Swagger da API |
| Banco de dados | MySQL no Railway | Instância privada acessada pela API. |
Rotas Principais da API
| Método | Rota | Finalidade |
|---|---|---|
| POST | /auth/login |
Autenticar usuário no sistema. |
| POST | /auth/logout |
Encerrar sessão do usuário. |
| POST | /usuarios |
Cadastrar novo usuário. |
| GET | /usuarios |
Listar usuários, com filtro opcional por login. |
| PUT | /usuarios/{id} |
Atualizar usuário, redefinir senha ou revogar acesso. |
| POST | /residentes |
Cadastrar novo residente. |
| GET | /residentes |
Listar residentes, com filtro opcional por CPF. |
| PUT | /residentes/{id} |
Atualizar ou inativar residente. |
| POST | /sinaisVitais |
Registrar sinais vitais. |
| GET | /sinaisVitais |
Consultar sinais vitais. |
| POST | /rotinasAssistenciais |
Registrar rotinas assistenciais. |
| GET | /rotinasAssistenciais |
Consultar rotinas assistenciais. |
| POST | /ocorrencias |
Registrar ocorrência clínica. |
| PUT | /ocorrencias/{id} |
Editar ocorrência clínica. |
| GET | /ocorrencias |
Consultar ocorrências clínicas. |
Quadro MVP: Evidências + Status
O quadro visual acima apresenta a organização do MVP. A tabela abaixo registra o status por User Story com evidências objetivas.
| User Story | Sprint | Status | Evidência visual/processual | PR/Commit | Teste | Validação/observação |
|---|---|---|---|---|---|---|
| US08 - Autenticar usuário | Sprint 2 | Concluída | Execução Sprint 2, Review Sprint 2, print US08. | PR #43 | Testes de autenticação e regressão da Sprint 2. | Login válido, erro genérico e bloqueio de rota sem sessão. |
| US09 - Encerrar sessão | Sprint 2 | Concluída | Review Sprint 2, print US09. | PR #43 | Testes de sessão e logout. | Logout, limpeza de sessão e redirecionamento. |
| US10 - Cadastrar usuário | Sprint 2 | Concluída | Execução Sprint 2, print US10. | PR #43 | Testes de cadastro e login de usuário recém-criado. | Cadastro de usuário com backend mock e IndexedDB. |
| US01 - Cadastrar residente | Sprint 2 | Concluída | Execução Sprint 2, print US01. | PR #43 | Testes de campos obrigatórios e CPF duplicado. | Cadastro de residente com foto e dados básicos. |
| US04 - Sinais vitais | Sprint 3 > Sprint 4 | Concluída no recorte MVP | Review Sprint 3, Planning Sprint 4, Review Sprint 4, print US04. | PR #83, PR #85 | Testes de persistência e build registrados nos PRs. | O recorte final do MVP cobriu registro, persistência, validação e consulta via histórico; edição de registros assistenciais permanece como evolução posterior. |
| US05 - Rotinas assistenciais | Sprint 3 > Sprint 4 | Concluída no recorte MVP | Review Sprint 3, Planning Sprint 4, Review Sprint 4, print US05. | PR #83, PR #84, PR #85 | Testes de persistência e validação manual registrados nos PRs. | O recorte final do MVP cobriu registro, persistência, validação e consulta via histórico; edição de registros assistenciais permanece como evolução posterior. |
| US14 - Histórico assistencial | Sprint 3 > Sprint 4 | Concluída | Review Sprint 4, print US14. | PR #83, PR #85 | Testes do assistenciaService para histórico por residente. |
PR específico #82 foi fechado; entrega absorvida por PRs integrados da Sprint 4. |
| US11 - Atualizar usuário | Sprint 4 | Concluída | Review Sprint 4, print US11. | PR #90, PR #93 | Testes e build registrados nos PRs. | Validação de campos, permissão e preservação de dados. |
| US02 - Editar residente | Sprint 4 | Concluída | Review Sprint 4, print US02. | PR #90, PR #93 | Testes e build registrados nos PRs. | Edição de residente preservando vínculos e dados existentes. |
| US06 - Medicamentos | Sprint 4 | Concluída | Review Sprint 4, print US06. | PR #91 | Testes unitários, build e validação local registrados no PR. | Registro de administração/não administração integrado ao fluxo assistencial. |
| US15 - Filtrar histórico | Sprint 4 | Concluída | Review Sprint 4, print US15. | PR #92 | Testes e build registrados no PR. | Filtro por período integrado ao histórico. |
| US12 - Redefinir senha | Sprint 5 | Concluída | Planning Sprint 5, print US12. | PR #110 | Teste US12. | Senha antiga rejeitada, nova senha aceita e perfil sem permissão bloqueado. |
| US13 - Revogar acesso | Sprint 5 | Concluída | Planning Sprint 5, print US13. | PR #110 | Teste US13. | Usuário inativo não gera nova sessão e registros históricos são preservados. |
| US03 - Inativar residente | Sprint 5 | Concluída como incremento adicional fora do MVP formal | Planning Sprint 5, print US03. | PR #110 | Teste US03. | Residente inativo sai da lista operacional e histórico é preservado; permanece fora do recorte formal do MVP definido na priorização. |
| US07 - Ocorrências clínicas | Sprint 5 | Concluída | Planning Sprint 5, print US07. | PR #110 | Teste US07. | Registro, consulta, edição, rastreabilidade e sinalização de notificação. |
| US16 - Resumo assistencial | Sprint 5 | Concluída | Planning Sprint 5, print US16. | PR #110 | Teste US16. | Consolidação do último registro por módulo e estados vazios explícitos. |
Observação de escopo: A US04 e a US05 foram mantidas com a numeração original para preservar a rastreabilidade com RF04, RF05, critérios de aceite, Story Map, cronograma e PRs. Para o MVP final, a equipe considerou concluído o recorte de registro, persistência, validação e consulta via histórico. A edição de registros assistenciais permanece documentada como evolução posterior.
Rastreabilidade: Problema > Objetivos > Características > RFs > US/CA
O quadro visual acima apresenta a hierarquia do Figma. A tabela abaixo registra a rastreabilidade clicável conforme a documentação oficial do repositório.
Regras e RNFs Transversais
| Tipo | Evidência |
|---|---|
| Regras de negócio | RN-01 a RN-09, com destaque para operação offline, preservação de histórico, campos obrigatórios, validação clínica e confirmação de salvamento. |
| Requisitos não funcionais | RNF01 a RNF16, cobrindo integridade, usabilidade, desempenho, rastreabilidade, sessão, permissões e legibilidade do histórico. |
| Matriz operacional | Matriz US > RF > RN > RNF > CA. |
| Story Map | Story Map, com organização por jornada, característica de produto, sprint e status de execução. |
| Casos de uso | Especificação de Casos de Uso, derivada dos RFs e das características de produto. |
US > Protótipo > Aplicação
As imagens abaixo foram adicionadas para evidenciar a ligação entre User Story, protótipo/tela e aplicação. A numeração usada nos títulos segue a lista oficial de User Stories.
US01 - Cadastrar dados do residente

- RF relacionado: RF01
- Critérios de aceitação: CA01.1 a CA01.3
- Aplicação: Cadastro de residente
US02 - Editar dados pessoais e clínicos do residente

- RF relacionado: RF02
- Critérios de aceitação: CA02.1 a CA02.4
- Aplicação: Editar residente
US03 - Inativar o cadastro do residente

- RF relacionado: RF03
- Critérios de aceitação: CA03.1 e CA03.2
- Aplicação: Lista de residentes
US04 - Registrar, editar e consultar sinais vitais do residente

- RF relacionado: RF04
- Critérios de aceitação: CA04.1 a CA04.6
- Aplicação: Registro assistencial
US05 - Registrar, editar e consultar rotinas assistenciais do residente

- RF relacionado: RF05
- Critérios de aceitação: CA05.1 a CA05.5
- Aplicação: Registro assistencial
US06 - Registrar, editar e consultar administração de medicamentos

- RF relacionado: RF06
- Critérios de aceitação: CA06.1 a CA06.6
- Aplicação: Registro assistencial
US07 - Registrar, editar e consultar ocorrências clínicas do residente

- RF relacionado: RF07
- Critérios de aceitação: CA07.1 a CA07.6
- Aplicação: Registro assistencial
US08 - Autenticar usuário no sistema

- RF relacionado: RF08
- Critérios de aceitação: CA08.1 a CA08.3
- Aplicação: Login
US09 - Encerrar sessão do usuário

- RF relacionado: RF09
- Critérios de aceitação: CA09.1 a CA09.3
- Aplicação: Painel após autenticação
US10 - Cadastrar usuário

- RF relacionado: RF10
- Critérios de aceitação: CA10.1 a CA10.4
- Aplicação: Cadastro de usuário
US11 - Atualizar dados cadastrais do usuário

- RF relacionado: RF11
- Critérios de aceitação: CA11.1 a CA11.4
- Aplicação: Editar usuário
US12 - Redefinir senha de acesso do usuário

- RF relacionado: RF12
- Critérios de aceitação: CA12.1 a CA12.3
- Aplicação: Lista de usuários
US13 - Revogar acesso do usuário

- RF relacionado: RF13
- Critérios de aceitação: CA13.1 a CA13.3
- Aplicação: Lista de usuários
US14 - Consultar histórico de registros do residente

- RF relacionado: RF14
- Critérios de aceitação: CA14.1 a CA14.4
- Aplicação: Histórico assistencial
US15 - Filtrar histórico por período

- RF relacionado: RF15
- Critérios de aceitação: CA15.1 a CA15.3
- Aplicação: Histórico assistencial
US16 - Visualizar resumo assistencial do residente

- RF relacionado: RF16
- Critérios de aceitação: CA16.1 a CA16.3
- Aplicação: Resumo assistencial
Observações Técnicas
| Item | Situação |
|---|---|
| RN-01 e RNF09 | O MVP implementa preservação local e sincronização oportunista: os registros são salvos localmente e, quando a API está disponível no momento da operação, são enviados ao backend e vinculados por identificador remoto. A fila completa de reenvio automático após reconexão e o indicador visual de estados de sincronização permanecem como evolução técnica. |
| US04 e US05 | Concluídas no recorte do MVP: registro, persistência, validação e consulta via histórico. A edição de registros assistenciais permanece registrada como evolução posterior. |
Histórico de Revisão
| Data | Versão | Descrição | Autor |
|---|---|---|---|
| 01/07/2026 | 1.0 | Consolidação do quadro de planejamento, MVP, rastreabilidade e prints por User Story em página única de Planejamento e Organização. | Equipe VitalTech |
| 02/07/2026 | 1.1 | Ajuste do status de US04 e US05 para concluídas no recorte do MVP, mantendo edição de registros assistenciais como evolução posterior. | Enzo Menali |
| 02/07/2026 | 1.2 | Alinhamento da Sprint 5 com Review, Retrospectiva, PR #110 e testes automatizados. | Enzo Menali |
| 02/07/2026 | 1.3 | Inclusão das evidências visuais das sprints e da seção de software disponível com frontend, API e Swagger. | Enzo Menali |





