- Plano de projeto e 5W2H
- Cronograma e marcos
- Riscos e governanca de sprint
CENTRO UNIVERSITARIO DE BRASILIA
FACULDADE DE TECNOLOGIA E CIENCIAS SOCIAIS APLICADAS
CURSO DE CIENCIA DA COMPUTACAO
PROJETO INTEGRADOR III - TURMA A INFORMAR
PROFESSORA ORIENTADORA: KADIDJA VALERIA REGINALDO DE OLIVEIRA
FastInBox
Documento principal do projeto
- RA a informar | Thiago L. C. Alves
- RA a informar | Joao Vitor
- RA a informar | Gabriel
- RA e Nome
- RA e Nome
BRASILIA, abril de 2026
FastInBox | Documento principal academico
Documento Principal do Projeto
Versao: 1.0 | Data-base: 2026-04-14 | Artefato mestre para PI III
Esta pagina consolida, em formato academico, os blocos exigidos para apresentacao do projeto FastInBox, preservando o estilo neo-brutal preto e branco do hub oficial de documentacao.
Sumario
- Glossario
- 1. Descricao do Projeto
- 2. Escopo do Projeto (EAP)
- 3. Problema/Oportunidade
- 4. Modelo de Negocio (BMC)
- 5. Cenarios de Negocio
- 6. Beneficios da Solucao
- 7. Publico Alvo
- 8. Cronograma de Marcos
- 9. Requisitos Funcionais
- 10. Requisitos Nao Funcionais
- 11. Prototipo Visual
- 12. Requisito dos MVPs
- 12.1 Aplicativo Movel
- 12.2 Web Application
- 13. Modelo de Dados (Web Application / Backoffice)
- 14. Resultados de Teste
- 14.1 Testes Internos
- 14.2 Testes Alfa / Fechados
- 14.3 Testes Beta
- 15. Marketing Digital
- 16. Bibliografia
- Apendice I - Tecnologias Utilizadas
Glossario
Lista alfabetica de termos, siglas e conceitos essenciais para leitura do projeto.
| Termo/Sigla | Definicao aplicada ao projeto |
|---|---|
| API | Camada de servicos responsavel por autenticar usuarios, persistir pedidos e expor regras de negocio para o FastInBox. |
| BMC | Business Model Canvas usado para descrever proposta de valor, canais, clientes, receitas e custos. |
| Docs as Code | Abordagem de documentacao versionada em repositorio GitHub Pages, tratada como parte do produto. |
| EAP | Estrutura Analitica do Projeto que decompoe o trabalho em pacotes gerenciaveis. |
| MVP | Produto minimo viavel usado para validar a jornada ponta a ponta do FastInBox. |
| PWA/Responsive Web | Recorte mobile baseado em interface web responsiva, sem app nativo nesta fase. |
| RF | Requisito funcional diretamente observavel nas jornadas do sistema. |
| RNF | Requisito nao funcional relacionado a performance, usabilidade, seguranca e manutencao. |
| SaaS | Modelo de entrega de software como servico adotado como horizonte de negocio do FastInBox. |
| White label | Modelo em que a experiencia do paciente prioriza a marca da clinica e nao a marca operacional da plataforma. |
1. Descricao do Projeto
Objetivo
O objetivo do projeto e planejar, construir, validar e documentar um MVP academico do FastInBox capaz de demonstrar, com evidencias tecnicas e de negocio, a viabilidade de digitalizar o fluxo de venda, pagamento, producao e acompanhamento de marmitas personalizadas operadas por nutricionistas e clinicas parceiras.
Descricao
O projeto contempla frentes integradas de gestao e de engenharia de software: levantamento e priorizacao de requisitos, modelagem de negocio, definicao de personas e jornadas, arquitetura de software, modelagem de dados, implementacao de interface web responsiva, preparacao da camada backend, governanca de sprint, controle de risco, validacao por testes e consolidacao da documentacao formal em GitHub Pages.
No escopo academico do PI III, o projeto exercita disciplinas de gestao do projeto, planejamento incremental, documentacao tecnica, engenharia de requisitos, arquitetura de software, IHC, prototipacao, qualidade de software, rastreabilidade, publicacao e sustentacao de um produto demonstravel para banca.
2. Escopo do Projeto (EAP)
A EAP abaixo organiza o trabalho em pacotes de entrega coerentes com o backlog ja publicado no hub tecnico.
- Documento de visao
- Business Model Canvas
- Personas e publico-alvo
- Front-end responsivo
- Baseline backend
- Modelo de dados e arquitetura
- Testes internos
- Review de sprint
- Deploy publico e demonstracao
- Documento principal
- Bibliografia e apendices
- Preparacao para PI IV
3. Problema/Oportunidade
O problema central identificado no FastInBox e a fragmentacao da operacao entre nutricionista, paciente e cozinha. O processo tradicional costuma combinar WhatsApp, planilhas, links de pagamento avulsos e comunicacao manual com a fabrica, o que aumenta retrabalho, risco de erro e perda de rastreabilidade. Os documentos de visao, requisitos e plano de projeto do proprio repositorio convergem para esse mesmo ponto: o fluxo atual do mercado e funcionalmente possivel, mas operacionalmente fragil.
Existe tambem uma oportunidade objetiva do lado da demanda. O Ministerio da Saude registrou no Vigitel Brasil 2023 que, no conjunto das 27 capitais, a frequencia de excesso de peso atingiu 61,4% da populacao adulta, enquanto a obesidade chegou a 24,3%. Esses numeros reforcam o espaco para solucoes que facilitem aderencia a rotinas alimentares personalizadas, com melhor previsibilidade e acompanhamento.
Do lado digital, o contexto e favoravel. A PNAD Continua TIC 2023 do IBGE apontou que a internet estava presente em 92,5% dos domicilios do pais, com 72,5 milhoes de lares conectados. Ja a Pesquisa Anual do Comercio 2023 mostrou que a comercializacao pela internet respondeu por 8,8% da receita bruta de revenda do varejo brasileiro, alem de registrar crescimento expressivo do numero de empresas que vendem por canais digitais em comparacao ao periodo pre-pandemia. Em outras palavras, o consumidor ja esta habituado a pesquisar, comparar e comprar por meios digitais.
No pagamento, a oportunidade e ainda mais clara. O Relatorio Anual do SPI 2024 do Banco Central registrou recordes sucessivos de uso do Pix, incluindo pico superior a 250 milhoes de transacoes liquidadas em um unico dia. Para um produto como o FastInBox, isso significa menor barreira comportamental para checkout rapido e maior chance de concluir o pedido sem redirecionamentos e conciliacoes manuais.
Assim, a oportunidade do projeto nao esta apenas em criar uma interface bonita, mas em consolidar uma trilha unica e auditavel onde a clinica preserva sua marca, o paciente entende o pedido com clareza, a cozinha recebe apenas pedidos aptos e a gestao passa a operar com dados estruturados em vez de controles paralelos.
4. Modelo de Negocio (BMC)
Canvas consolidado a partir do MVP Canvas, do Business Model Canvas tecnico e do Documento de Visao.
Parcerias Chave
- Nutricionistas e clinicas parceiras.
- Cozinhas responsaveis pela producao.
- Gateway de pagamento e meios instantaneos.
- Infraestrutura cloud e hospedagem.
- Equipe academica e orientacao docente.
Atividades Chave
- Cadastro de pacientes e criacao de pedidos.
- Validacao de pagamento e status.
- Operacao white label e governanca.
- Documentacao e melhoria continua.
Recursos Chave
- Frontend Next.js e baseline backend NestJS.
- Schema de dados e contratos tipados.
- Hub tecnico em GitHub Pages.
- Marca white label da clinica.
Proposta de Valor
- Transformar um fluxo manual e disperso em uma trilha unica de pedido, pagamento, producao e acompanhamento.
- Permitir que a clinica opere com sua propria marca, sem perder controle operacional.
- Reduzir retrabalho na cozinha ao liberar apenas pedidos pagos e claros.
Relacionamento
- Fluxos guiados por perfil.
- Checkout simples e transparente.
- Acompanhamento em tempo real.
- Suporte orientado por status.
Canais
- Web application responsiva.
- GitHub Pages para documentacao e confianca.
- Indicacao do nutricionista para o paciente.
- Conteudo digital e demonstracoes PI IV.
Clientes
- Nutricionistas e clinicas que desejam vender marmitas personalizadas com marca propria.
- Pacientes que precisam revisar, confirmar e pagar com clareza.
- Cozinhas parceiras que dependem de fila operacional qualificada.
- Gestao FastInBox, que precisa de visao consolidada da operacao.
Estrutura de Custos
- Desenvolvimento front-end, back-end e documentacao.
- Hospedagem, deploy e infraestrutura de dados.
- Custos de gateway e eventos financeiros.
- QA, suporte, onboarding e marketing digital.
Fontes de Receita
- Comissao por pedido processado.
- Assinatura SaaS por clinica.
- Servicos premium de analytics.
- Taxa de implantacao/onboarding.
5. Cenarios de Negocio
Analise PEST orientada por referencias de governo, Banco Central, IBGE, Banco Mundial e saude digital. O foco esta em como cada cenario pode favorecer ou pressionar a adocao da solucao.
| Dimensao | Pessimista | Realista | Otimista |
|---|---|---|---|
| Politica | Ambiente regulatorio mais rigido para dados de saude e pagamentos eleva custo de conformidade e retarda integracoes para clinicas menores. | LGPD, governanca de dados e iniciativas como SUS Digital pressionam o mercado a formalizar processos, favorecendo plataformas mais organizadas que chat e planilha. | Maior maturidade institucional em saude digital e interoperabilidade reduz resistencia de parceiros e acelera contratos com clinicas e operacoes B2B. |
| Economica | Crescimento fraco e orcamento comprimido nas clinicas fazem o mercado adiar investimentos em software, mesmo quando a dor operacional existe. | Com crescimento moderado, as clinicas tendem a priorizar ferramentas que reduzam retrabalho, custo oculto e tempo administrativo, o que favorece um MVP enxuto com ROI rapido. | Com melhora do ambiente economico e maior previsibilidade, o FastInBox pode escalar de piloto para assinatura recorrente e servicos premium por clinica. |
| Social | Parte dos usuarios pode manter preferencia por processos informais, principalmente quando ainda confia em WhatsApp e pagamentos manuais. | A combinacao de alta conectividade, busca por conveniencia e maior preocupacao com alimentacao personalizada sustenta a adocao gradual de uma jornada digital simples. | Aumento da consciencia preventiva em saude e valorizacao de acompanhamento nutricional elevam a propensao de pacientes e clinicas a usar experiencias white label especializadas. |
| Tecnologica | Integracoes, observabilidade e dados podem ficar caras ou dispersas se o projeto crescer sem consolidar a base transacional e de auditoria. | Cloud, Pix, front-end responsivo, GitHub Pages e stack TypeScript permitem construir um produto demonstravel e evolutivo com custo controlado. | Maior acesso a analytics, IA aplicada, automacao e integracao server-side abre espaco para previsao de demanda, telemetria e inteligencia operacional no PI IV e alem. |
6. Beneficios da Solucao
Reducao de retrabalho
O pedido deixa de depender de troca manual de mensagens, planilhas paralelas e confirmacoes fora do fluxo.
Maior confianca do paciente
A jornada apresenta pedido, valor, confirmacao, pagamento e status no mesmo ambiente, sob a marca da clinica.
Fila operacional qualificada
A cozinha recebe apenas pedidos aprovados, com itens e observacoes acessiveis, diminuindo erro de execucao.
Visao de governanca
Administracao e equipe passam a acompanhar pedidos, status, excecoes e backlog com evidencias tecnicas versionadas.
Base para escala
O MVP organiza front, backend, dados, deploy e docs de modo que a plataforma possa evoluir para SaaS multi-clinica.
Valor para banca e continuidade
O projeto gera artefatos formais que sustentam avaliacao academica e reduzem dependencia de memoria individual da equipe.
7. Publico Alvo
Nutricionista / clinica parceira
Persona primaria do negocio. Precisa cadastrar pacientes, gerar pedidos e manter sua propria identidade visual com menos retrabalho administrativo.
Paciente final
Usuario B2C que acessa o pedido por codigo, revisa composicao, confirma, paga e acompanha o andamento em ambiente responsivo, geralmente pelo celular.
Cozinha parceira
Perfil operacional que precisa de leitura rapida, status claros e acesso somente a pedidos pagos e aptos para producao.
Administracao FastInBox
Perfil de governanca que monitora saude da operacao, usuarios, pedidos, riscos e evidencias para tomada de decisao.
Em termos de recorte mercadologico, o ICP do projeto nesta fase e formado por clinicas e nutricionistas que ja operam marmitas personalizadas ou desejam estruturar esse servico com mais padrao, previsibilidade e marca propria, sem implantar uma operacao de software excessivamente complexa logo no primeiro ciclo.
8. Cronograma de Marcos
Cronograma de alto nivel alinhado aos artefatos versionados e ao backlog incremental do projeto.
| Marco | Data |
|---|---|
| Consolidacao inicial da ERS | 20/03/2026 |
| MVP Canvas fechado para validacao tecnica | 27/03/2026 |
| Baseline do fluxo E2E do MVP em desenvolvimento | 03/04/2026 |
| Publicacao da biblioteca de documentos no GitHub Pages | 10/04/2026 |
| Documento principal do projeto publicado | 14/04/2026 |
| Inicio da Sprint 2 com foco em API e persistencia | 18/04/2026 |
| Entrega do schema relacional e contratos principais do backend | 25/04/2026 |
| Persistencia de pacientes e pedidos no servidor | 09/05/2026 |
| Smoke test da jornada principal automatizado | 23/05/2026 |
| Rodada de testes fechados / alfa com convidados e orientacao | 06/06/2026 |
| Rodada beta com stakeholders reais | 20/06/2026 |
| Pacote PI IV: marketing, video e analytics | 27/06/2026 |
9. Requisitos Funcionais
| Codigo | Descricao |
|---|---|
| RF001 | Permitir autenticacao por perfil, com acesso segregado entre nutricionista, paciente, cozinha e administracao. |
| RF002 | Permitir cadastro, consulta e atualizacao de pacientes vinculados ao nutricionista autenticado. |
| RF003 | Permitir criacao de pedidos com uma ou mais marmitas, calculo de valor e geracao de codigo unico compartilhavel. |
| RF004 | Permitir ao paciente acessar o pedido por codigo, revisar dados e confirmar a solicitacao antes do pagamento. |
| RF005 | Registrar pagamento integrado e liberar o pedido para producao somente quando houver aprovacao financeira valida. |
| RF006 | Disponibilizar painel operacional da cozinha com fila de pedidos pagos e atualizacao de status da producao ate a entrega. |
| RF007 | Disponibilizar painel administrativo com visao consolidada de usuarios, pedidos, configuracoes e indicadores minimos da operacao. |
10. Requisitos Nao Funcionais
| Codigo | Tipo | Descricao |
|---|---|---|
| RNF001 | Performance | O fluxo principal deve responder com navegacao fluida em dispositivos desktop e mobile, evitando paginas pesadas e interacoes que comprometam a leitura operacional. |
| RNF002 | Usabilidade | A interface deve manter linguagem objetiva, forte contraste, hierarquia visual clara e feedback imediato para acoes criticas como salvar, confirmar, pagar e atualizar status. |
| RNF003 | Seguranca | Dados sensiveis devem respeitar segregacao por perfil, minimizacao de exposicao, autenticacao coerente e trilha auditavel de eventos financeiros e operacionais. |
| RNF004 | Manutenibilidade | O codigo deve permanecer modular, tipado e documentado o suficiente para permitir evolucao de front, back e docs sem acoplamento excessivo. |
11. Prototipo Visual
Na fase atual, o prototipo visual do FastInBox esta implementado como prototipo funcional navegavel no frontend publicado. Como o repositorio nao contem um link publico de Figma compartilhado, a sequencia abaixo representa o fluxo visual padrao efetivamente construido no produto.
01. Home e entrada por perfil
- Proposta de valor.
- Entrada para login.
- Acesso a documentos legais.
02. Dashboard do nutricionista
- Pacientes e pedidos recentes.
- Metricas do fluxo.
- Atalho para novo pedido.
03. Cadastro de paciente e novo pedido
- Dados do paciente.
- Itens, valores e observacoes.
- Geracao de codigo unico.
04. Revisao do paciente
- Acesso por codigo.
- Conferencia do pedido.
- Confirmacao antes do checkout.
05. Pagamento e sucesso
- Pagamento integrado.
- Feedback de sucesso.
- Transicao para status do pedido.
06. Cozinha e acompanhamento
- Fila de pedidos pagos.
- Atualizacao de status.
- Leitura rapida da operacao.
12. Requisito dos MVPs
O MVP do FastInBox foi definido para provar valor operacional antes de ampliar o escopo. Por isso, os requisitos abaixo distinguem o recorte mobile, centrado na experiencia do paciente, e o recorte web, centrado na operacao de clinica, cozinha e administracao.
12.1 Aplicativo Movel
Recorte funcional
- Acesso por codigo do pedido.
- Revisao e confirmacao do pedido.
- Pagamento simplificado.
- Acompanhamento de status.
Implementacao prevista
Nesta fase, o MVP movel sera atendido por web responsiva/PWA, e nao por aplicativo nativo. O foco e garantir experiencia clara no celular, que e o dispositivo dominante da jornada do paciente.
12.2 Web Application
Recorte funcional
- Painel do nutricionista com pacientes e pedidos.
- Painel da cozinha com status operacional.
- Dashboard administrativo com governanca minima.
- Hub documental em GitHub Pages.
Criterio de validacao
O web application sera considerado aderente ao MVP se demonstrar o fluxo E2E de criar pedido, revisar, pagar, produzir e acompanhar sem ruptura entre os perfis envolvidos.
13. Modelo de Dados (Web Application / Backoffice)
O modelo de dados do FastInBox foi estruturado para migrar da persistencia local do MVP para uma base relacional no backend, preservando rastreabilidade comercial, financeira e operacional.
Entidades centrais
- clinics: identidade, branding e dados da clinica.
- users: perfis, credenciais e permissao.
- patients: cadastro clinico do paciente.
- orders: cabecalho do pedido e codigo unico.
- order_items: composicao detalhada das marmitas.
- payments: status financeiro e conciliacao.
- production_events: historico de producao e entrega.
Relacionamentos principais
- clinics 1:N users
- users 1:N patients
- patients 1:N orders
- orders 1:N order_items
- orders 1:N payments
- orders 1:N production_events
| Elemento | Visao de backend / backoffice | Objetivo no negocio |
|---|---|---|
| Codigo do pedido | Campo unico em orders.order_code | Permitir entrada simples do paciente sem ambiguidade. |
| Status do pedido | Enum controlado em orders.status | Bloquear avancos invalidos e sustentar a timeline. |
| Status de pagamento | Enum em payments.payment_status | Garantir que somente pedido aprovado siga para producao. |
| Historico operacional | Tabela production_events com data e autor | Auditoria e visibilidade do andamento. |
| Ligacao com clinica | FK entre usuarios, pacientes e clinicas | Suportar white label e governanca por parceiro. |
14. Resultados de Teste
Os resultados abaixo separam a validacao efetivamente realizada no PI III daquelas etapas previstas para PI IV. O objetivo foi manter integridade documental: nao foram inventados resultados inexistentes, mas nenhuma secao foi omitida.
14.1 Testes Internos (equipe de desenvolvimento)
Quadro resumo
| Item | Metodo | Resultado |
|---|---|---|
| Build baseline | Scripts de build front e back | Validado no baseline da sprint |
| Fluxo E2E do MVP | Navegacao manual guiada | Disponivel para demonstracao |
| Publicacao | Deploy Vercel + GitHub Pages | Disponivel |
| Coerencia documental | Revisao cruzada dos artefatos | Atualizada ate 14/04/2026 |
Evidencias e links
- Sprint 1 Review com consolidacao das evidencias.
- Tasks Sprint 1 com backlog executado.
- Aplicacao publicada.
- GitHub Pages com biblioteca de documentos.
14.2 Testes Alfa / Fechados (Equipe de Teste, Convidados Academicos e Orientador) (PI IV)
| Aspecto | Planejamento | Status em 14/04/2026 |
|---|---|---|
| Publico | Equipe de teste, convidados academicos e orientacao. | Nao iniciado. |
| Objetivo | Validar clareza da jornada, compreensao do pedido e leitura do status operacional. | Planejado para PI IV. |
| Instrumento | Roteiro de tarefas + questionario estruturado. | A definir na rodada alfa. |
| Evidencia esperada | Relatorio resumido com incidentes, severidade e acoes corretivas. | Pendente de execucao. |
14.3 Testes Beta (Stakeholders) (PI IV)
| Aspecto | Planejamento | Status em 14/04/2026 |
|---|---|---|
| Publico | Nutricionistas parceiros, pacientes piloto e stakeholders da operacao. | Nao iniciado. |
| Objetivo | Observar uso em contexto mais proximo do real, incluindo confirmacao, pagamento e producao. | Planejado para PI IV. |
| Metricas | Taxa de confirmacao, conversao de pagamento, tempo de pedido e ocorrencias por status. | Pendente de execucao. |
| Evidencia esperada | Painel de insights e backlog de melhoria priorizado. | Pendente de execucao. |
15. Marketing Digital (PI IV)
Plano de Marketing
Posicionar o FastInBox como infraestrutura digital white label para nutricionistas e clinicas venderem marmitas personalizadas com mais controle, confianca e visibilidade operacional.
Estrategia de Monetizacao
- Comissao por pedido.
- Assinatura mensal por clinica.
- Pacotes premium de analytics e governanca.
Estrategia de Divulgacao do Produto
- Landing page com video curto e CTA para piloto.
- Conteudos em redes sociais com foco em produtividade da clinica.
- Demonstracao guiada para nutricionistas parceiros.
Estrategia de Aquisicao de Clientes
- Piloto com clinicas de referencia.
- Indicacao entre nutricionistas.
- Prova de valor centrada em tempo poupado e reducao de erro.
Estrategia de Formacao de Precos
Modelo hibrido: ticket de implantacao reduzido para entrada, assinatura por faixa de volume e fee variavel por pedido quando a operacao estiver validada em producao.
Desdobramento dos 4 Ps para os 4 Cs
| 4 Ps | 4 Cs equivalentes |
|---|---|
| Produto | Cliente: jornada white label clara e confiavel. |
| Preco | Custo: assinatura + fee alinhados ao ganho operacional. |
| Praca | Conveniencia: acesso web, mobile e checkout simplificado. |
| Promocao | Comunicacao: prova de valor por demonstracao e casos piloto. |
Video Promocional
Planejado para PI IV em formato de 45 a 60 segundos, mostrando a dor atual, o fluxo FastInBox e a proposta de valor para clinicas e nutricionistas.
Video de Instrucao de uso do Produto
Planejado para PI IV em formato tutorial, cobrindo login, criacao de pedido, revisao do paciente, pagamento e fluxo da cozinha.
Insights de Mercado (Google Looker ou similar)
Planejada modelagem analitica com funil de pedido, taxa de conversao, lead time pago->pronto, ticket medio, pedidos por clinica e principais pontos de abandono.
16. Bibliografia
- FASTINBOX. Documento de Visao. GitHub Pages, 2026. Acesso em: 14 abr. 2026.
- FASTINBOX. Business Model Canvas Tecnico. GitHub Pages, 2026. Acesso em: 14 abr. 2026.
- FASTINBOX. Plano de Projeto Tecnico. GitHub Pages, 2026. Acesso em: 14 abr. 2026.
- FASTINBOX. Especificacao de Requisitos de Software. GitHub Pages, 2026. Acesso em: 14 abr. 2026.
- FASTINBOX. Arquitetura UML da Plataforma. GitHub Pages, 2026. Acesso em: 14 abr. 2026.
- FASTINBOX. Esquema de Banco de Dados. GitHub Pages, 2026. Acesso em: 14 abr. 2026.
- FASTINBOX. MVP Canvas. Repositorio docs, 2026. Acesso em: 14 abr. 2026.
- BRASIL. Ministerio da Saude. Vigitel Brasil 2023: vigilancia de fatores de risco e protecao para doencas cronicas por inquerito telefonico. Brasilia, 2024. Acesso em: 14 abr. 2026.
- IBGE. PNAD Continua TIC 2023. Rio de Janeiro, 2025. Acesso em: 14 abr. 2026.
- IBGE. Pesquisa Anual do Comercio 2023 - Informativo. Rio de Janeiro, 2025. Acesso em: 14 abr. 2026.
- BANCO CENTRAL DO BRASIL. SPI - Sistema de Pagamentos Instantaneos: Relatorio anual 2024. Brasilia, 2024. Acesso em: 14 abr. 2026.
- BRASIL. Ministerio da Saude. 3o relatorio de monitoramento da Estrategia de Saude Digital para o Brasil 2020-2028. Brasilia, 2026. Acesso em: 14 abr. 2026.
- WORLD BANK. Global Economic Prospects. Washington, DC, janeiro de 2025. Acesso em: 14 abr. 2026.
APENDICE I - TECNOLOGIAS UTILIZADAS
(Links das ferramentas e status de acesso para compartilhamento com kadidja.oliveira@ceub.edu.br)
Gestao
| Frente | Ferramenta / Link | Status de acesso |
|---|---|---|
| Gestao do Projeto | Trello | Quadro do projeto deve ser compartilhado com a orientadora na consolidacao PI IV. |
| Gestao da Configuracao | GitHub Organization | Acesso publico aos repositorios e artefatos publicados. |
Desenvolvimento Front-End
| Frente | Ferramenta / Link | Status de acesso |
|---|---|---|
| Prototipacao | Figma | Link publico do arquivo nao localizado no repositorio; compartilhar com a orientadora na PI IV. |
| Frontend - Aplicativo | Aplicacao publicada | Acesso publico para demonstracao. |
| Frontend - Aplicacao Web | Repositorio front | Acesso publico ao codigo e historico. |
Desenvolvimento Backend
| Frente | Ferramenta / Link | Status de acesso |
|---|---|---|
| API Management | Repositorio back | Acesso publico ao baseline backend. |
| Servidor de Aplicacao | Guia de deployment | Render previsto para a API e Vercel para o front. |
| Sistema Gerenciador de Banco de Dados | Neon / PostgreSQL | Planejado para Sprint 2 e PI IV. |
Testes e gestao de demandas
| Frente | Ferramenta / Link | Status de acesso |
|---|---|---|
| Automacao de testes | QASE.IO | Ferramenta prevista; instancia do projeto ainda nao publicada. |
| Bug Tracking | GitHub Issues | Pode concentrar incidentes e backlog tecnico. |
Analitica
| Frente | Ferramenta / Link | Status de acesso |
|---|---|---|
| Extracao, Transformacao e Carga | Google Drive / scripts | Fluxo analitico previsto para PI IV; pasta compartilhada ainda nao publicada. |
| Visualizacao de dados | Google Looker Studio | Painel planejado para acompanhar funil e lead time. |
Marketing e Publicacao
| Frente | Ferramenta / Link | Status de acesso |
|---|---|---|
| Editoracao de video | Ferramenta a confirmar no PI IV | Definicao pendente. |
| Publicacao | GitHub Pages | Acesso publico ativo. |
| Redes Sociais | Canais institucionais a abrir | Planejado para PI IV. |
Tecnologias Habilitadoras Digitais
| Tecnologia | Uso no FastInBox |
|---|---|
| IoT | Nao aplicavel ao MVP atual. |
| 5G | Suporte indireto a melhor conectividade mobile, sem dependencia arquitetural especifica. |
| Blockchain | Nao aplicavel ao recorte atual. |
| Realidade Aumentada | Nao aplicavel ao recorte atual. |
| Realidade Virtual | Nao aplicavel ao recorte atual. |
| Robotic Process Automation | Possivel uso futuro em conciliacao e rotinas administrativas. |
| Machine Learning | Planejado para previsao de demanda e recomendacoes operacionais em fases futuras. |
| Deep Learning | Fora do escopo do MVP. |
| Inteligencia Artificial | Aplicacao futura em analytics, previsao e apoio a decisao. |
| Business Intelligence | Previsto via Looker Studio no PI IV. |
| Big Data | Fora do escopo do MVP; pode se tornar relevante apenas em fase de escala multi-clinica. |