diff --git a/search/search_index.json b/search/search_index.json
index 2ca219b..1965d25 100644
--- a/search/search_index.json
+++ b/search/search_index.json
@@ -1 +1 @@
-{"config":{"lang":["pt"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Dida's Bistro","text":""},{"location":"#equipe","title":"Equipe","text":"Foto Nome Github Matr\u00edcula Benjamim Lacerda Santos @benlacerda 200062123 Iderlan J\u00fanio Cardoso da Silva @IderlanJ 211062947 Mateus Henrique Queiroz Magalh\u00e3es Sousa @Mateushqms 222025950 Pedro Gois Marques Monteiro @Goizzz 222026386 Pedro Henrique dos Santos Ferreira @Pedro-hsf 211063229"},{"location":"Apresenta%C3%A7%C3%B5es/Unidade1/unidade1/","title":"Apresenta\u00e7\u00f5es","text":""},{"location":"Apresenta%C3%A7%C3%B5es/Unidade1/unidade1/#unidade-1","title":"Unidade 1","text":""},{"location":"Apresenta%C3%A7%C3%B5es/Unidade1/unidade1/#video-da-apresentacao","title":"V\u00eddeo da Apresenta\u00e7\u00e3o","text":""},{"location":"Apresenta%C3%A7%C3%B5es/Unidade1/unidade1/#slides-para-apresentacao","title":"Slides para apresenta\u00e7\u00e3o","text":"Hist\u00f3rico de Revis\u00e3o
Data Vers\u00e3o Descri\u00e7\u00e3o Autor 11/11/2024 0.0 Cria\u00e7\u00e3o do documento Benjamim Lacerda"},{"location":"item2.4/item2.4/","title":"Tabela","text":""},{"location":"item2.4/item2.4/#24-engenharia-de-requisitos-e-rad-scrum","title":"2.4 Engenharia de Requisitos e RAD SCRUM","text":"tabela:
Fases do RAD SCRUM Atividades da Engenharia de Requisitos (ER) Pr\u00e1tica T\u00e9cnica Resultados Esperados Planejamento da Release Elicita\u00e7\u00e3o e Descoberta Levantamento de Requisitos Entrevista, Brainstorming, Lean Inception Descoberta dos requisitos e defini\u00e7\u00e3o da Release An\u00e1lise e Consenso Prioriza\u00e7\u00e3o de Requisitos Product Backlog Building (PBB) Defini\u00e7\u00e3o das funcionalidades a serem implementadas Declara\u00e7\u00e3o Registro dos Requisitos User Story Mapping, Snow Cards Especifica\u00e7\u00e3o das hist\u00f3rias de usu\u00e1rio Planejamento da Sprint Elicita\u00e7\u00e3o e Descoberta Alinhamento com os Stakeholders Entrevista, Workshop de Requisitos Identifica\u00e7\u00e3o das necessidades do usu\u00e1rio para o desenvolvimento da sprint An\u00e1lise e Consenso Refinamento de Backlog An\u00e1lise de Custo e Benef\u00edcio, An\u00e1lise de Tarefas Prioriza\u00e7\u00e3o do Backlog Execu\u00e7\u00e3o da Sprint (RAD) Representa\u00e7\u00e3o Desenvolvimento das Interfaces Prototipagem Prot\u00f3tipos para Valida\u00e7\u00e3o Verifica\u00e7\u00e3o e Valida\u00e7\u00e3o Revis\u00e3o de Implementa\u00e7\u00f5es DoD e DoR, Feedback, Checklist de Valida\u00e7\u00e3o Requisitos validados e revisados de acordo com as tarefas designadas na etapa de planejamento Revis\u00e3o da Sprint Verifica\u00e7\u00e3o e Valida\u00e7\u00e3o Apresenta\u00e7\u00e3o e Avalia\u00e7\u00e3o Coleta de Feedback, Inspe\u00e7\u00e3o, Backlog de Requisitos Valida\u00e7\u00e3o dos Resultados Entregues Organiza\u00e7\u00e3o e Atualiza\u00e7\u00e3o Atualiza\u00e7\u00e3o de Documenta\u00e7\u00e3o Registro de novos Requisitos e Ajustes Registro de novos Requisitos e Ajustes Retrospectiva da Sprint An\u00e1lise e Consenso Identifica\u00e7\u00e3o de Melhores Pr\u00e1ticas Brainstorming, Resolu\u00e7\u00e3o de Conflitos Melhorias identificadas para o pr\u00f3ximo ciclo Organiza\u00e7\u00e3o e Atualiza\u00e7\u00e3o Registro de Li\u00e7\u00f5es Aprendidas Feedback, DoD Aprendizado cont\u00ednuo documentado Planejamento da Pr\u00f3xima Release Elicita\u00e7\u00e3o e Descoberta Alinhamento de Novos Requisitos Entrevista, Workshop de Requisitos Novos requisitos e ajustes a serem implementados Organiza\u00e7\u00e3o e Atualiza\u00e7\u00e3o Atualiza\u00e7\u00e3o do Backlog Reavalia\u00e7\u00e3o de Requisitos Prioriza\u00e7\u00e3o dos requisitos para a nova release"},{"location":"reunioes/fase_inicial/fase_inicial/","title":"Reuni\u00f5es","text":""},{"location":"reunioes/fase_inicial/fase_inicial/#unidade-1","title":"Unidade 1","text":""},{"location":"reunioes/fase_inicial/fase_inicial/#28102024","title":"28/10/2024","text":""},{"location":"reunioes/fase_inicial/fase_inicial/#31102024","title":"31/10/2024","text":""},{"location":"reunioes/fase_inicial/fase_inicial/#04112024","title":"04/11/2024","text":""},{"location":"reunioes/fase_inicial/fase_inicial/#10112024-desenvolvimento-da-lean-inception","title":"10/11/2024 - Desenvolvimento da Lean Inception","text":""},{"location":"reunioes/fase_inicial/fase_inicial/#11112024-desenvolvimento-da-lean-inception","title":"11/11/2024 - Desenvolvimento da Lean Inception","text":"Hist\u00f3rico de Revis\u00e3o
Data Vers\u00e3o Descri\u00e7\u00e3o Autor 11/11/2024 0.0 Cria\u00e7\u00e3o do documento Benjamim Lacerda"},{"location":"visao_produto/CronogramaEntregas/","title":"Calend\u00e1rio de Sprints","text":"Sprint In\u00edcio Fim Objetivo Principal Entregas Esperadas Valida\u00e7\u00e3o do Cliente Sprint 1 28/10/23 11/11/23 - Planejamento do projeto Defini\u00e7\u00e3o inicial do escopo Valida\u00e7\u00e3o do escopo Sprint 2 12/11/23 25/11/23 - Prot\u00f3tipo da interface principal - Cria\u00e7\u00e3o do ambiente de desenvolvimento - Prot\u00f3tipo da tela inicial Valida\u00e7\u00e3o do prot\u00f3tipo Sprint 3 26/11/23 09/12/23 - Funcionalidades do estoque - L\u00f3gica de controle de estoque - Alerta de baixa disponibilidade Valida\u00e7\u00e3o do fluxo e alertas do estoque Sprint 4 10/12/23 23/12/23 Fluxo financeiro e eventos - Fluxo de caixa com entradas e sa\u00eddas - Cadastro de eventos Valida\u00e7\u00e3o das funcionalidades financeiras e de eventos Sprint 5 07/01/24 20/01/24 Gest\u00e3o de funcion\u00e1rios e vendas em eventos - L\u00f3gica de controle de funcion\u00e1rios - Registro de vendas vinculadas a eventos Valida\u00e7\u00e3o de cadastro de funcion\u00e1rios e fluxo financeiro em eventos Sprint 6 21/01/24 03/02/24 Aloca\u00e7\u00e3o de funcion\u00e1rios e revis\u00e3o geral - Inser\u00e7\u00e3o de funcion\u00e1rios a eventos - Revis\u00e3o e ajuste das funcionalidades implementadas Valida\u00e7\u00e3o do processo de aloca\u00e7\u00e3o e ajustes realizados Sprint 7 04/02/24 17/02/24 Revis\u00e3o final e entrega do sistema - Revis\u00e3o Completa do sistema - Prepara\u00e7\u00e3o para o lan\u00e7amento Aprova\u00e7\u00e3o final e prepara\u00e7\u00e3o para entrega Hist\u00f3rico de Revis\u00e3o
Data Vers\u00e3o Descri\u00e7\u00e3o Autor 08/11/2024 0.0 Cria\u00e7\u00e3o do documento Benjamim Lacerda 11/11/2024 0.1 Atualiza\u00e7\u00e3o do Documento Pedro Henrique 11/11/2024 1.0 Primeira vers\u00e3o do documento Benjamim Lacerda Santos, Iderlan Junio Cardoso da Silva, Mateus Henrique Queiroz Magalh\u00e3es Sousa, Pedro Gois Marques Monteiro, Pedro Henrique 22/11/2024 1.1 Atualiza\u00e7\u00e3o do documento Benjamim Lacerda Santos 27/11/2024 1.2 Ajustes no documento Benjamim Lacerda Santos"},{"location":"visao_produto/EstrategiasEngSoftware/","title":"Estrat\u00e9gias de Engenharia de Software","text":""},{"location":"visao_produto/EstrategiasEngSoftware/#31-estrategia-priorizada","title":"3.1 Estrat\u00e9gia Priorizada","text":"Abordagem: \u00c1gil
Ciclo de vida: Iterativo e Incremental.
Processo: RAD(Rapid Application Development) e SCRUM.
"},{"location":"visao_produto/EstrategiasEngSoftware/#32-quadro-comparativo","title":"3.2 Quadro Comparativo","text":"O quadro a seguir apresenta caracter\u00edsticas dos processos RAD e SCRUM que ser\u00e3o utilizados e tamb\u00e9m do OpenUp para compara\u00e7\u00e3o, buscando justificar a escolha do processo adequado ao Dida\u2019s Bistr\u00f4.
Caracter\u00edsticas RAD SCRUM OpenUP Abordagem Geral Iterativo e incremental com \u00eanfase em entregas r\u00e1pidas por meio de prototipagem. Iterativo e incremental, com foco em entregas frequentes e feedback cont\u00ednuo. Iterativo, incremental e baseado em arquitetura s\u00f3lida. Foco em Arquitetura Arquitetura geralmente evolui durante o processo, com foco inicial na prototipagem. Menor foco em arquitetura no in\u00edcio; evolui conforme a necessidade ao longo do projeto. Forte \u00eanfase no desenvolvimento orientado a uma arquitetura s\u00f3lida e flex\u00edvel desde o in\u00edcio do projeto. Estrutura de Processos Dividido em fases (requisitos, prototipa\u00e7\u00e3o, constru\u00e7\u00e3o e testes). Cada fase \u00e9 chamada de timebox que duram de 1-4 semanas. Focado em sprints curtos e flex\u00edveis (2-4 semanas) com entregas incrementais e adapta\u00e7\u00e3o cont\u00ednua durante o projeto. Estrutura clara de fases: Inicia\u00e7\u00e3o, Elabora\u00e7\u00e3o, Constru\u00e7\u00e3o e Transi\u00e7\u00e3o. Flexibilidade de Requisitos Alta flexibilidade para altera\u00e7\u00f5es r\u00e1pidas nos requisitos, facilitada pela prototipagem e os feedbacks. Alta flexibilidade para mudan\u00e7as cont\u00ednuas de requisitos a cada sprint. Adapt\u00e1vel a feedback frequente do cliente. Flexibilidade para adapta\u00e7\u00f5es iterativas, com a arquitetura principal definida cedo. Colabora\u00e7\u00e3o com Cliente Envolvimento frequente do cliente para valida\u00e7\u00e3o de prot\u00f3tipos e ajustes r\u00e1pidos. Envolvimento cont\u00ednuo do cliente com feedback ao final de cada sprint. Requer envolvimento cont\u00ednuo do cliente, especialmente nas fases de valida\u00e7\u00e3o. Complexidade do Processo Mais leve, com foco na prototipagem e desenvolvimento r\u00e1pido; menos formalidade. Estrutura leve, focada na entrega funcional e adapta\u00e7\u00e3o cont\u00ednua; menos documenta\u00e7\u00e3o. Mais formal, com documenta\u00e7\u00e3o e fases estruturadas, requerendo disciplina e pap\u00e9is claros. Qualidade T\u00e9cnica Garantida pela r\u00e1pida constru\u00e7\u00e3o e teste de prot\u00f3tipos; ajustes s\u00e3o feitos conforme feedback. Alta \u00eanfase na qualidade t\u00e9cnica, com pr\u00e1ticas como TDD (Test-Driven Development), pair programming e integra\u00e7\u00e3o cont\u00ednua para garantir um c\u00f3digo limpo e funcional. Qualidade assegurada pela defini\u00e7\u00e3o de arquitetura e valida\u00e7\u00e3o incremental. Pr\u00e1ticas de Desenvolvimento Foco na prototipagem e valida\u00e7\u00e3o r\u00e1pida; menos pr\u00e1ticas t\u00e9cnicas estruturadas. Inclui pr\u00e1ticas t\u00e9cnicas robustas como TDD, refatora\u00e7\u00e3o cont\u00ednua, integra\u00e7\u00e3o cont\u00ednua e pair programming, promovendo alta qualidade no c\u00f3digo. Estrutura mais formal com foco em arquitetura e controle de progresso. Menos pr\u00e1ticas t\u00e9cnicas espec\u00edficas dentro do processo de desenvolvimento. Adapta\u00e7\u00e3o ao Projeto do Dida\u2019s Bistr\u00f4 Ideal em projetos que precisam de prot\u00f3tipos r\u00e1pidos e ajustes com o cliente. Ideal para projetos onde a intera\u00e7\u00e3o constante com o cliente e a evolu\u00e7\u00e3o cont\u00ednua do produto s\u00e3o fundamentais. Adapt\u00e1vel a mudan\u00e7as frequentes e r\u00e1pidos ciclos de feedback. Ideal para projetos que exigem uma arquitetura bem definida, mas flexibilidade incremental. Documenta\u00e7\u00e3o M\u00ednima documenta\u00e7\u00e3o. O foco em comunica\u00e7\u00e3o direta com o cliente para ajustes r\u00e1pidos. Minimiza a documenta\u00e7\u00e3o formal, priorizando comunica\u00e7\u00e3o r\u00e1pida e feedback. Requer documenta\u00e7\u00e3o formal para cada fase, com \u00eanfase em requisitos e arquitetura. Controle de Qualidade Baseado em revis\u00f5es de prot\u00f3tipos e ajustes ao longo do desenvolvimento. Controle de qualidade embutido nas pr\u00e1ticas do XP, como TDD e integra\u00e7\u00e3o cont\u00ednua. Controle de qualidade atrav\u00e9s de valida\u00e7\u00f5es incrementais e revis\u00f5es de arquitetura. Escalabilidade Escal\u00e1vel para projetos de pequena a m\u00e9dia complexidade, em fun\u00e7\u00e3o da prototipagem r\u00e1pida. Escal\u00e1vel, mas mais indicado para equipes menores e m\u00e9dias devido \u00e0 sua abordagem colaborativa e interativa constante. Escal\u00e1vel para projetos maiores e mais complexos, com equipes m\u00e9dias a grandes. Suporte a Equipes de Desenvolvimento Suporta equipes menores, com foco na colabora\u00e7\u00e3o e menos formalidade nos papeis. Suporta equipes menores e mais colaborativas, com papeis mais flex\u00edveis, permitindo maior adapta\u00e7\u00e3o ao ritmo do projeto. Suporta equipes maiores e com mais papeis definidos, pois requer mais controle sobre o progresso e as fases do projeto."},{"location":"visao_produto/EstrategiasEngSoftware/#33-justificativa","title":"3.3 Justificativa","text":"Baseado nos crit\u00e9rios proposto por Gupta para a escolha de processos, respondemos uma s\u00e9rie de quest\u00f5es sobre os t\u00f3picos abordados pelos crit\u00e9rios para definir o modelo de desenvolvimento que ser\u00e1 utilizado ao longo do projeto. Optamos pelo RAD como framework mostrou e adaptamos algumas caracter\u00edsticas do SCRUM para melhor adequa\u00e7\u00e3o ao Dida\u2019s Bistr\u00f4.
Watterfall: 10 Prototype: 10 Iterative Enhancement: 6 Evolutionary development: 7 Spiral: 9 RAD: 11
Rapidez: O RAD visa acelerar o processo de desenvolvimento. Isso \u00e9 alcan\u00e7ado atrav\u00e9s de ciclos de desenvolvimento curtos, permitindo que os produtos sejam entregues mais rapidamente.
Flexibilidade: Incentiva a adapta\u00e7\u00e3o r\u00e1pida \u00e0s mudan\u00e7as. O RAD permite ajustes no decorrer do projeto sem grandes impactos nos prazos gra\u00e7as \u00e0 constante prototipagem e os feedbacks.
Prototipagem: O uso de prot\u00f3tipos \u00e9 central no RAD, permitindo que desenvolvedores testem e ajustem funcionalidades, de acordo com os requisitos do cliente, o que ser\u00e1 de extrema import\u00e2ncia para o Dida\u2019s Bistr\u00f4.
Organiza\u00e7\u00e3o: A organiza\u00e7\u00e3o \u00e9 baseada na realiza\u00e7\u00e3o de fases com timebox de 15 dias, as reuni\u00e7oes s\u00e3o as de planejamento e retrospectiva e revis\u00e3o. A gest\u00e3o das hist\u00f3rias de usu\u00e1rios \u00e9 realizada atrav\u00e9s do ZenHub, a comunica\u00e7\u00e3o interna \u00e9 com a utiliza\u00e7\u00e3o de aplicativo de mensagem instant\u00e2nea e a comunica\u00e7\u00e3o com o cliente \u00e9 utilizando o Microsoft Teams como reuni\u00f5es gravadas.
Cliente Ativo: Nosso cliente tem disponibilidade para estar presente em quase todas as nossas reuni\u00f5es, por isso escolhemos a metodologia RAD, permitindo constantes feedbacks durante o processo de prototipa\u00e7\u00e3o.
Hist\u00f3rico de Revis\u00e3o
Data Vers\u00e3o Descri\u00e7\u00e3o Autor 08/11/2024 0.0 Cria\u00e7\u00e3o do documento Benjamim Lacerda 11/11/2024 0.1 Atualiza\u00e7\u00e3o do Documento Pedro Henrique 11/11/2024 1.0 Primeira vers\u00e3o do documento Benjamim Lacerda Santos, Iderlan Junio Cardoso da Silva, Mateus Henrique Queiroz Magalh\u00e3es Sousa, Pedro Gois Marques Monteiro, Pedro Henrique"},{"location":"visao_produto/InteracaoEquipeCliente/","title":"Intera\u00e7\u00e3o Entre Equipe e Cliente","text":""},{"location":"visao_produto/InteracaoEquipeCliente/#51-composicao-da-equipe","title":"5.1 Composi\u00e7\u00e3o da Equipe","text":""},{"location":"visao_produto/InteracaoEquipeCliente/#papeis-e-responsabilidades","title":"Pap\u00e9is e Responsabilidades","text":"Papel Descri\u00e7\u00e3o Respons\u00e1vel Participantes Gerente de Projeto Coordena o projeto, garante a comunica\u00e7\u00e3o entre cliente e equipe, controla prazos e entregas. Benjamin Lacerda Santos Desenvolvedor Frontend Respons\u00e1vel pela interface do usu\u00e1rio, design e implementa\u00e7\u00e3o das funcionalidades no lado do cliente. Iderlan J\u00fanio Cardoso da Silva Benjamin Lacerda, Mateus Henrique, Pedro Henrique dos Santos Ferreira, Felipe Fernandes Brandim Desenvolvedor Backend Implementa a l\u00f3gica de neg\u00f3cios, integra\u00e7\u00e3o com banco de dados e APIs. Pedro Henrique dos Santos Ferreira Pedro Gois, Mateus Henrique, Benjamin Lacerda, Felipe Fernandes Brandim Analista de QA Garante a qualidade do produto, executando testes de funcionalidade, performance e usabilidade. Mateus Henrique Queiroz Magalh\u00e3es Sousa Pedro Gois Analista de Requisitos Define os requisitos funcionais e n\u00e3o funcionais do sistema e garante que eles sejam atendidos. Pedro Gois Monteiro Marques Mateus Henrique, Pedro Henrique dos Santos Ferreira, Benjamin Lacerda Santos, Iderlan J\u00fanio Cardoso da Silva, Felipe Fernandes Brandim"},{"location":"visao_produto/InteracaoEquipeCliente/#52-comunicacao","title":"5.2 Comunica\u00e7\u00e3o","text":"Ferramentas de Comunica\u00e7\u00e3o
Aplicativo de mensagem instant\u00e2nea: Ser\u00e1 utilizado para a comunica\u00e7\u00e3o dos membros da equipe diariamente. Est\u00e1 ferramenta \u00e9 necess\u00e1ria por conta da facilidade ao envio r\u00e1pido de mensagens, enquetes, arquivos e canais de comunica\u00e7\u00e3o espec\u00edficos.
Microsoft Teams: Todas as reuni\u00f5es semanais de planejamento, revis\u00e3o e discuss\u00f5es com os membros e cliente ser\u00e3o realizadas no canal de comunica\u00e7\u00e3o do Microsoft Teams. com isso, buscamos otimizar o acompanhamento das entregas, os feedbacks e os planejamentos futuros.
ZenHub: Ser\u00e1 utilizado para a gest\u00e3o do projeto oferecendo suporte para a equipe no gerenciamento de fluxos, na visualiza\u00e7\u00e3o em tempo real das tarefas em andamento e projetar o fluxo de trabalho.
M\u00e9todo e Frequ\u00eancia de Reuni\u00f5es
Reuni\u00e3o de Revis\u00e3o e Retrospectiva: As reuni\u00f5es de conclus\u00e3o da fase, ser\u00e1 revisado com o cliente, nessas reuni\u00f5es, todas as funcionalidades desenvolvidas durante a fase ser\u00e3o apresentadas. Com isso, garantindo que o cliente teste e realize a valida\u00e7\u00e3o. Tamb\u00e9m ser\u00e1 realizada uma retrospectiva entre a equipe para entender quais foram as dificuldades, desafios e li\u00e7\u00f5es aprendidas durante o processo.
Reuni\u00e3o de Planejamento: Ao \u00ednicio de cada fase ser\u00e1 decidido junto ao cliente quais ser\u00e3o os pr\u00f3ximos passos, criando um planejamento para a fase que se inicia.
Frequ\u00eancia de Intera\u00e7\u00f5es com o cliente
Revis\u00f5es de Sprint (a cada 2 semanas): Durante as reuni\u00f5es de revis\u00e3o o cliente, ser\u00e1 respons\u00e1vel por validar as entregas e apontar o feedback. Se tornando diretamente ligado ao processo de conclus\u00e3o da sprint.
Intera\u00e7\u00f5es Adicionais pelo Microsoft Teams: O cliente ter\u00e1 acesso a um canal de discuss\u00e3o no Microsoft Teams, em que todos os membros participar\u00e3o, onde ser\u00e1 poss\u00edvel tirar d\u00favidas ou se necess\u00e1rio, ajustes.
"},{"location":"visao_produto/InteracaoEquipeCliente/#53-processo-de-validacao","title":"5.3 Processo de Valida\u00e7\u00e3o","text":"Valida\u00e7\u00e3o de Requisitos Antes de iniciar o desenvolvimento da funcionalidade ou itera\u00e7\u00e3o, os requisitos do cliente ser\u00e3o revisados e validados com ele. Isso ocorrer\u00e1 atrav\u00e9s da planning, onde o cliente ter\u00e1 a oportunidade de revisar os requisitos.
Testes de Funcionalidade Ao longo do desenvolvimento, ser\u00e3o realizados testes para garantir que a entrega seja de qualidade e com o menor n\u00famero de erros.
Valida\u00e7\u00e3o do Prot\u00f3tipo Ap\u00f3s a valida\u00e7\u00e3o dos requisitos, a prototipa\u00e7\u00e3o ser\u00e1 feita e, posteriormente, haver\u00e1 outra valida\u00e7\u00e3o com o cliente, observando se os requisitos foram atendidos.
Hist\u00f3rico de Revis\u00e3o
Data Vers\u00e3o Descri\u00e7\u00e3o Autor 08/11/2024 0.0 Cria\u00e7\u00e3o do documento Benjamim Lacerda 11/11/2024 0.1 Atualiza\u00e7\u00e3o do Documento Pedro Henrique 11/11/2024 1.0 Primeira vers\u00e3o do documento Benjamim Lacerda Santos, Iderlan Junio Cardoso da Silva, Mateus Henrique Queiroz Magalh\u00e3es Sousa, Pedro Gois Marques Monteiro, Pedro Henrique"},{"location":"visao_produto/LicoesAprendidas/","title":"Li\u00e7\u00f5es Aprendidas","text":""},{"location":"visao_produto/LicoesAprendidas/#61-unidade-1","title":"6.1 Unidade 1","text":"As li\u00e7\u00f5es aprendidas inclu\u00edram uma compreens\u00e3o mais profunda dos processos e ciclos de vida da Engenharia de Requisitos, o que trouxe uma vis\u00e3o clara sobre as etapas necess\u00e1rias para alcan\u00e7ar o objetivo final proposto ao projeto. A equipe tamb\u00e9m aprimorou o entendimento sobre os diferentes tipos de requisitos e a entender melhor as expectativas e necessidades do cliente garantindo que suas demandas fossem compreendidas e incorporadas no projeto.
A equipe do projeto demonstrou uma boa sinergia desde o in\u00edcio, com a defini\u00e7\u00e3o de reuni\u00f5es semanais para garantir o alinhamento e a evolu\u00e7\u00e3o do trabalho. No entanto a falta de clareza em rela\u00e7\u00e3o \u00e0s tarefas e pr\u00f3ximos passos resultou em reuni\u00f5es que, embora focadas, n\u00e3o levavam \u00e0 execu\u00e7\u00e3o completa das atividades planejadas. Isso gerou um ciclo de discuss\u00f5es produtivas, mas com uma baixa efetividade na implementa\u00e7\u00e3o, impactando o progresso do projeto.
Para melhorar isso, a equipe pode come\u00e7ar a registrar atas das reuni\u00f5es, com as decis\u00f5es e a\u00e7\u00f5es a serem tomadas. Ter esses registros facilitam lembrar o que deve ser feito e quem \u00e9 respons\u00e1vel por cada tarefa. Al\u00e9m disso, a defini\u00e7\u00e3o do backlog do produto e a utiliza\u00e7\u00e3o de um quadro KanBan para acompanhar o progresso, ajuda a transformar as conversas em resultados concretos.
Hist\u00f3rico de Revis\u00e3o
Data Vers\u00e3o Descri\u00e7\u00e3o Autor 08/11/2024 0.0 Cria\u00e7\u00e3o do documento Benjamim Lacerda 11/11/2024 0.1 Atualiza\u00e7\u00e3o do Documento Pedro Henrique 11/11/2024 1.0 Primeira vers\u00e3o do documento Benjamim Lacerda Santos, Iderlan Junio Cardoso da Silva, Mateus Henrique Queiroz Magalh\u00e3es Sousa, Pedro Gois Marques Monteiro, Pedro Henrique"},{"location":"visao_produto/ReferenciaBibliografica/","title":"Refer\u00eancias Bibliogr\u00e1ficas","text":" Rapid application development model (RAD) \u2013 Software Engineering. GeeksforGeeks, 2024. Dispon\u00edvel em: Rapid application development model (RAD) \u2013 Software Engineering
RAJA, Gupta. Fundamentals of Software Engineering. Engineering Handbook. 2019.
MARSICANO, George. Slides da mat\u00e9ria Requisitos. 2024.
Hist\u00f3rico de Revis\u00e3o
Data Vers\u00e3o Descri\u00e7\u00e3o Autor 08/11/2024 0.0 Cria\u00e7\u00e3o do documento Benjamim Lacerda 11/11/2024 0.1 Atualiza\u00e7\u00e3o do Documento Pedro Henrique 11/11/2024 1.0 Primeira vers\u00e3o do documento Benjamim Lacerda Santos, Iderlan Junio Cardoso da Silva, Mateus Henrique Queiroz Magalh\u00e3es Sousa, Pedro Gois Marques Monteiro, Pedro Henrique"},{"location":"visao_produto/SolucaoProposta/","title":"Solu\u00e7\u00e3o Proposta","text":""},{"location":"visao_produto/SolucaoProposta/#21-objetivos-do-produto","title":"2.1 Objetivos do Produto","text":"Nosso objetivo \u00e9 resolver os problemas causados pela perda de dados, criando um meio de armazen\u00e1-los e acess\u00e1-los. Isso vai auxiliar na tomada de decis\u00f5es no Didas Bistr\u00f4, facilitando o acompanhamento de eventos anteriores, o controle de estoque e o planejamento para futuros eventos. Com o intuito de alcan\u00e7ar esse objetivo, a plataforma ser\u00e1 desenvolvida para:
Centralizar o registro de dados em uma plataforma digital, substituindo o uso exclusivo do papel. Permitindo acesso a informa\u00e7\u00f5es cruciais sobre eventos passados, como lucro, n\u00famero de funcion\u00e1rios necess\u00e1rios e quantidade de ingredientes utilizados.
Implementar um sistema de gest\u00e3o financeira, permitindo que os usu\u00e1rios possam analisar gastos, faturamento e lucros de cada evento.
Criar um sistema de gerenciamento de estoque, para monitorar a quantidade de ingredientes dispon\u00edveis em tempo real.
Prover acesso a registro de eventos passados, facilitando o planejamento futuro.
Objetivos secund\u00e1rios:
Criar uma interface voltada para usu\u00e1rios que n\u00e3o possuem experi\u00eancia com tecnologias.
Assegurar que a plataforma seja responsiva, adaptando para dispositivos m\u00f3veis.
"},{"location":"visao_produto/SolucaoProposta/#22-caracteristicas-da-solucao","title":"2.2 Caracter\u00edsticas da Solu\u00e7\u00e3o","text":"Interface intuitiva: A plataforma vai possuir uma interface de f\u00e1cil entendimento que busca apresentar ao usu\u00e1rio que a sua navega\u00e7\u00e3o ser\u00e1 autoexplicativa, desde os bot\u00f5es e menus, o intuito \u00e9 demonstrar a sua acessibilidade ao usu\u00e1rio.
Sistema de Contabilidade Integrado: Ser\u00e1 poss\u00edvel registrar e categorizar todas as transa\u00e7\u00f5es financeiras, como vendas, pagamentos de fornecedores, sal\u00e1rios e outros custos. Cada transa\u00e7\u00e3o ser\u00e1 registrada com a data, categoria e valor.
Gerenciamento de Estoque: O sistema de estoque ser\u00e1 automatizado e acompanhar\u00e1 a entrada e sa\u00edda de mercadorias em tempo real, registrando a quantidade de ingredientes dispon\u00edveis, al\u00e9m disso, o usu\u00e1rio poder\u00e1 analisar o hist\u00f3rico de entradas e sa\u00eddas, ajudando na programa\u00e7\u00e3o dos pr\u00f3ximos eventos.
Registro dos Eventos: Ser\u00e1 poss\u00edvel acessar informa\u00e7\u00f5es sobre eventos anteriores, como custos, lucros, quantidades de ingredientes usados, e n\u00famero de funcion\u00e1rios necess\u00e1rios.
Plataforma Responsiva: A plataforma ter\u00e1 a capacidade de ser utilizada em dispositivos m\u00f3veis, n\u00e3o sendo exclusiva para computadores. Qualquer usu\u00e1rio com um celular poder\u00e1 utiliz\u00e1-la.
"},{"location":"visao_produto/SolucaoProposta/#23-tecnologias-a-serem-utilizadas","title":"2.3 Tecnologias a Serem Utilizadas","text":""},{"location":"visao_produto/SolucaoProposta/#24-pesquisa-de-mercado-e-analise-competitiva","title":"2.4 Pesquisa de Mercado e An\u00e1lise Competitiva","text":"MarketMan
Pontos Fortes: Sistema robusto de controle de estoque e integra\u00e7\u00e3o com fornecedores, o que permite otimizar o gerenciamento de insumos e reduzir desperd\u00edcios. Ideal para neg\u00f3cios focados em reduzir custos operacionais.
Diferencia\u00e7\u00e3o da Nossa Solu\u00e7\u00e3o: Nossa solu\u00e7\u00e3o prioriza a facilidade de uso e a comunica\u00e7\u00e3o intuitiva com a cliente, oferecendo uma interface simplificada que atender\u00e1 especificamente \u00e0s necessidades de gest\u00e3o de eventos e adapta\u00e7\u00e3o r\u00e1pida do estoque conforme o tipo de evento.
Toast
Pontos Fortes: Plataforma completa para opera\u00e7\u00f5es de restaurantes, abrangendo vendas, estoque e relat\u00f3rios, com suporte para integra\u00e7\u00e3o de pedidos online e ferramentas de POS.
Diferencia\u00e7\u00e3o da Nossa Solu\u00e7\u00e3o: Ao inv\u00e9s de uma plataforma gen\u00e9rica e complexa, nossa solu\u00e7\u00e3o ser\u00e1 projetada especificamente para o Dida\u2019s Bistr\u00f4, oferecendo um sistema voltado para o fluxo financeiro e controle de mercadorias apenas para eventos, facilitando o planejamento financeiro e a usabilidade da cliente.
A solu\u00e7\u00e3o proposta \u00e9 divergente devido:
Nossa solu\u00e7\u00e3o tem como ponto principal uma curva de aprendizado iniciante, pois toda a plataforma ser\u00e1 feita com o intuito de ser o mais autoexplicativo o poss\u00edvel que atender\u00e1 especificamente \u00e0s necessidades de gest\u00e3o de eventos adaptando rapidamente o estoque conforme o tipo de evento.
Diferenciando das solu\u00e7\u00f5es apresentadas que por mais que est\u00e3o consolidadas no mercado, o produto \u00e9 projetado especificamente para o Dida's Bistr\u00f4, oferecendo um sistema voltado para gerenciar as entradas e sa\u00eddas de mercadorias e transa\u00e7\u00f5es financeiras. Por n\u00e3o exigir um hardware ou aparelho espec\u00edfico, tornaremos nosso produto a escolha ideal para o cliente, que ser\u00e1 necess\u00e1rio apenas um aparelho celular ou computador.
"},{"location":"visao_produto/SolucaoProposta/#25-analise-de-viabilidade","title":"2.5 An\u00e1lise de Viabilidade","text":"A viabilidade t\u00e9cnica do projeto \u00e9 alta, uma vez que boa parte da equipe de desenvolvimento possui experi\u00eancia nas tecnologias que ser\u00e3o utilizadas, como Python para o backend e Node.js e React.js para o frontend. Ser\u00e1 utilizado um sistema de gerenciamento de banco de dados relacional, o MySQL, que permitir\u00e1 armazenar, organizar e consultar grandes volumes de dados.
O projeto ser\u00e1 conduzido por meio de sprints divididas em ciclos quinzenais. Cada sprint ter\u00e1 entregas incrementais de funcionalidades, o que permitir\u00e1 valida\u00e7\u00f5es constantes por parte do cliente e ajustes r\u00e1pidos baseados no feedback do mesmo. O cronograma \u00e9 considerado vi\u00e1vel, dado que a equipe j\u00e1 teve contato com projetos semelhantes anteriormente e conta com os recursos tecnol\u00f3gicos necess\u00e1rios para realizar a integra\u00e7\u00e3o e implementa\u00e7\u00e3o das funcionalidades dentro do prazo estipulado.
Em termos de viabilidade financeira, o desenvolvimento do sistema \u00e9 totalmente sustent\u00e1vel, com custos alinhados aos recursos dispon\u00edveis para a equipe. Dessa forma, o cliente n\u00e3o enfrentar\u00e1 problemas futuros relacionados a custos extras, pois n\u00e3o depender\u00e1 de solu\u00e7\u00f5es externas. O Dida\u2019s Bistr\u00f4 contar\u00e1 com um sistema personalizado, garantindo maior controle e efici\u00eancia em todos os processos.
Do ponto de vista de mercado, a viabilidade \u00e9 favor\u00e1vel, pois h\u00e1 uma certa demanda por solu\u00e7\u00f5es de gest\u00e3o em pequenos estabelecimentos como o Dida's Bistr\u00f4. Com isso, ser\u00e1 poss\u00edvel atender ao cliente de forma eficaz, atendendo diretamente \u00e0s suas necessidades para gerir seu neg\u00f3cio.
"},{"location":"visao_produto/SolucaoProposta/#26-impacto-da-solucao","title":"2.6 Impacto da Solu\u00e7\u00e3o","text":"A solu\u00e7\u00e3o trar\u00e1 ao Dida\u2019s Bistr\u00f4 uma opera\u00e7\u00e3o mais eficiente e transparente. Ao otimizar o controle de estoque, o fluxo de caixa e o pagamento de funcion\u00e1rios, o sistema fortalecer\u00e1 a capacidade de o restaurante operar de forma rent\u00e1vel e bem-organizada. Esses benef\u00edcios permitir\u00e3o que o Dida\u2019s Bistr\u00f4 melhore sua efici\u00eancia operacional, reduza custos e adapte-se de maneira \u00e1gil aos diversos tipos de eventos que realiza, aumentando a lucratividade e assegurando uma gest\u00e3o mais tranquila e profissional.
Hist\u00f3rico de Revis\u00e3o
Data Vers\u00e3o Descri\u00e7\u00e3o Autor 08/11/2024 0.0 Cria\u00e7\u00e3o do documento Benjamim Lacerda 11/11/2024 0.1 Atualiza\u00e7\u00e3o do Documento Pedro Henrique 11/11/2024 1.0 Primeira vers\u00e3o do documento Benjamim Lacerda Santos, Iderlan Junio Cardoso da Silva, Mateus Henrique Queiroz Magalh\u00e3es Sousa, Pedro Gois Marques Monteiro, Pedro Henrique"},{"location":"visao_produto/VisaoProdutoProjeto/","title":"Vis\u00e3o do Produto e Projeto","text":""},{"location":"visao_produto/VisaoProdutoProjeto/#11-introducao-ao-negocio-e-contexto","title":"1.1 Introdu\u00e7\u00e3o ao Neg\u00f3cio e Contexto","text":"O Dida's Bistr\u00f4 \u00e9 um restaurante que realiza eventos privados, como festas e shows, com o objetivo de proporcionar experi\u00eancias gastron\u00f4micas para seus clientes. Com um card\u00e1pio variado, adapta suas op\u00e7\u00f5es conforme a ocasi\u00e3o. Al\u00e9m disso, o Dida's Bistr\u00f4 tamb\u00e9m atua como vendedor ambulante em shows e eventos em Bras\u00edlia.
Fundado em 2012, o neg\u00f3cio teve in\u00edcio com a venda de churros ambulante. Com o tempo, expandiu seu card\u00e1pio para incluir op\u00e7\u00f5es como hamb\u00farguer, cachorro-quente, churrasquinho e macarr\u00e3o. Hoje, o card\u00e1pio \u00e9 flex\u00edvel, permitindo que os pratos sejam ajustados conforme a demanda do evento.
A partir de 2016, o Dida's Bistr\u00f4 passou a organizar eventos privados, focando em festas juninas. Em 2022, recebeu o pr\u00eamio Sesc Comerci\u00e1rio Destaque, em reconhecimento pelas festas juninas realizadas nos Sesc de Bras\u00edlia.
"},{"location":"visao_produto/VisaoProdutoProjeto/#12-identificacao-da-oportunidade-ou-problema","title":"1.2 Identifica\u00e7\u00e3o da Oportunidade ou Problema","text":"O principal problema do Didas Bistr\u00f4 \u00e9 a perda ou m\u00e1 interpreta\u00e7\u00e3o dos dados, o que \u00e9 causado pelo uso exclusivo de papel para registro e controle. Isso dificulta o planejamento do neg\u00f3cio, j\u00e1 que, muitas vezes, a equipe n\u00e3o tem acesso a informa\u00e7\u00f5es cruciais sobre eventos passados, como lucro, n\u00famero de funcion\u00e1rios necess\u00e1rios e quantidade de ingredientes utilizados. Como resultado, a contabilidade fica comprometida, dificultando a an\u00e1lise de gastos, faturamento e lucro de cada evento. Al\u00e9m disso, a falta de registros adequados prejudica o planejamento futuro, pois n\u00e3o \u00e9 poss\u00edvel avaliar se vale a pena repetir determinados eventos, j\u00e1 que os dados hist\u00f3ricos est\u00e3o frequentemente perdidos ou inacess\u00edveis.
A falta de um sistema de gerenciamento de estoque tamb\u00e9m \u00e9 um problema significativo. Muitas vezes, a equipe do Didas Bistr\u00f4 n\u00e3o tem controle preciso sobre o gasto com ingredientes estocados, o que dificulta o planejamento para os eventos. Al\u00e9m disso, a falta de um acompanhamento adequado impede que saibam exatamente a quantidade de cada produto dispon\u00edvel, tornando o processo de compra e organiza\u00e7\u00e3o ineficiente e aumentando o risco de desperd\u00edcio ou falta de insumos durante os eventos.
Segue abaixo um diagrama de Ishikawa sobre os problemas do cliente.
"},{"location":"visao_produto/VisaoProdutoProjeto/#13-desafios-do-projeto","title":"1.3 Desafios do Projeto","text":"O principal desafio t\u00e9cnico \u00e9 que o Didas Bistr\u00f4 atualmente n\u00e3o utiliza nenhum software para gerenciar seus processos. N\u00e3o h\u00e1 nenhum sistema existente que atenda aos requisitos espec\u00edficos do neg\u00f3cio. Por isso, ser\u00e1 necess\u00e1rio desenvolver uma solu\u00e7\u00e3o do zero, capaz de atender a todas as necessidades operacionais. Al\u00e9m disso, \u00e9 essencial que o software tenha uma interface intuitiva e de f\u00e1cil usabilidade, para que qualquer pessoa, independentemente de sua experi\u00eancia, consiga utiliz\u00e1-lo, j\u00e1 que, para cada evento, s\u00e3o contratados profissionais diferentes.
"},{"location":"visao_produto/VisaoProdutoProjeto/#14-segmentacao-de-clientes","title":"1.4 Segmenta\u00e7\u00e3o de Clientes","text":"O produto ser\u00e1 destinado a dona e aos funcion\u00e1rios da empresa, na qual podemos dividir em dois segmentos:
Idosos com mais de 60 anos: Usu\u00e1rios com poucas experi\u00eancias tecnol\u00f3gicas e que utilizam celular. Possuem a necessidade de um software com poucas intera\u00e7\u00f5es para realizar o seu objetivo.
Jovens adultos entre 20 e 30 anos: Usu\u00e1rios com experi\u00eancias tecnol\u00f3gicas em computadores e celulares. Capazes de utilizar o software sem dificuldades.
Hist\u00f3rico de Revis\u00e3o
Data Vers\u00e3o Descri\u00e7\u00e3o Autor 08/11/2024 0.0 Cria\u00e7\u00e3o do documento Benjamim Lacerda 11/11/2024 0.1 Atualiza\u00e7\u00e3o do Documento Pedro Henrique 11/11/2024 1.0 Primeira vers\u00e3o do documento Benjamim Lacerda Santos, Iderlan Junio Cardoso da Silva, Mateus Henrique Queiroz Magalh\u00e3es Sousa, Pedro Gois Marques Monteiro, Pedro Henrique"}]}
\ No newline at end of file
+{"config":{"lang":["pt"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Dida's Bistro","text":""},{"location":"#equipe","title":"Equipe","text":"Foto Nome Github Matr\u00edcula Benjamim Lacerda Santos @benlacerda 200062123 Iderlan J\u00fanio Cardoso da Silva @IderlanJ 211062947 Mateus Henrique Queiroz Magalh\u00e3es Sousa @Mateushqms 222025950 Pedro Gois Marques Monteiro @Goizzz 222026386 Pedro Henrique dos Santos Ferreira @Pedro-hsf 211063229"},{"location":"Apresenta%C3%A7%C3%B5es/Unidade1/unidade1/","title":"Apresenta\u00e7\u00f5es","text":""},{"location":"Apresenta%C3%A7%C3%B5es/Unidade1/unidade1/#unidade-1","title":"Unidade 1","text":""},{"location":"Apresenta%C3%A7%C3%B5es/Unidade1/unidade1/#video-da-apresentacao","title":"V\u00eddeo da Apresenta\u00e7\u00e3o","text":""},{"location":"Apresenta%C3%A7%C3%B5es/Unidade1/unidade1/#slides-para-apresentacao","title":"Slides para apresenta\u00e7\u00e3o","text":"Hist\u00f3rico de Revis\u00e3o
Data Vers\u00e3o Descri\u00e7\u00e3o Autor 11/11/2024 0.0 Cria\u00e7\u00e3o do documento Benjamim Lacerda"},{"location":"item2.4/item2.4/","title":"Tabela","text":""},{"location":"item2.4/item2.4/#24-engenharia-de-requisitos-e-rad-scrum","title":"2.4 Engenharia de Requisitos e RAD SCRUM","text":"tabela:
Fases do RAD SCRUM Atividades da Engenharia de Requisitos (ER) Pr\u00e1tica T\u00e9cnica Resultados Esperados Planejamento da Release Elicita\u00e7\u00e3o e Descoberta Levantamento de Requisitos Entrevista, Brainstorming, Lean Inception Descoberta dos requisitos e defini\u00e7\u00e3o da Release An\u00e1lise e Consenso Prioriza\u00e7\u00e3o de Requisitos Product Backlog Building (PBB) Defini\u00e7\u00e3o das funcionalidades a serem implementadas Declara\u00e7\u00e3o Registro dos Requisitos User Story Mapping, Snow Cards Especifica\u00e7\u00e3o das hist\u00f3rias de usu\u00e1rio Planejamento da Sprint Elicita\u00e7\u00e3o e Descoberta Alinhamento com os Stakeholders Entrevista, Workshop de Requisitos Identifica\u00e7\u00e3o das necessidades do usu\u00e1rio para o desenvolvimento da sprint An\u00e1lise e Consenso Refinamento de Backlog An\u00e1lise de Custo e Benef\u00edcio, An\u00e1lise de Tarefas Prioriza\u00e7\u00e3o do Backlog Execu\u00e7\u00e3o da Sprint (RAD) Representa\u00e7\u00e3o Desenvolvimento das Interfaces Prototipagem Prot\u00f3tipos para Valida\u00e7\u00e3o Verifica\u00e7\u00e3o e Valida\u00e7\u00e3o Revis\u00e3o de Implementa\u00e7\u00f5es DoD e DoR, Feedback, Checklist de Valida\u00e7\u00e3o Requisitos validados e revisados de acordo com as tarefas designadas na etapa de planejamento Revis\u00e3o da Sprint Verifica\u00e7\u00e3o e Valida\u00e7\u00e3o Apresenta\u00e7\u00e3o e Avalia\u00e7\u00e3o Coleta de Feedback, Inspe\u00e7\u00e3o, Backlog de Requisitos Valida\u00e7\u00e3o dos Resultados Entregues Organiza\u00e7\u00e3o e Atualiza\u00e7\u00e3o Atualiza\u00e7\u00e3o de Documenta\u00e7\u00e3o Registro de novos Requisitos e Ajustes Registro de novos Requisitos e Ajustes Retrospectiva da Sprint An\u00e1lise e Consenso Identifica\u00e7\u00e3o de Melhores Pr\u00e1ticas Brainstorming, Resolu\u00e7\u00e3o de Conflitos Melhorias identificadas para o pr\u00f3ximo ciclo Organiza\u00e7\u00e3o e Atualiza\u00e7\u00e3o Registro de Li\u00e7\u00f5es Aprendidas Feedback, DoD Aprendizado cont\u00ednuo documentado Planejamento da Pr\u00f3xima Release Elicita\u00e7\u00e3o e Descoberta Alinhamento de Novos Requisitos Entrevista, Workshop de Requisitos Novos requisitos e ajustes a serem implementados Organiza\u00e7\u00e3o e Atualiza\u00e7\u00e3o Atualiza\u00e7\u00e3o do Backlog Reavalia\u00e7\u00e3o de Requisitos Prioriza\u00e7\u00e3o dos requisitos para a nova release"},{"location":"reunioes/fase_inicial/fase_inicial/","title":"Reuni\u00f5es","text":""},{"location":"reunioes/fase_inicial/fase_inicial/#unidade-1","title":"Unidade 1","text":""},{"location":"reunioes/fase_inicial/fase_inicial/#28102024","title":"28/10/2024","text":""},{"location":"reunioes/fase_inicial/fase_inicial/#31102024","title":"31/10/2024","text":""},{"location":"reunioes/fase_inicial/fase_inicial/#04112024","title":"04/11/2024","text":""},{"location":"reunioes/fase_inicial/fase_inicial/#10112024-desenvolvimento-da-lean-inception","title":"10/11/2024 - Desenvolvimento da Lean Inception","text":""},{"location":"reunioes/fase_inicial/fase_inicial/#11112024-desenvolvimento-da-lean-inception","title":"11/11/2024 - Desenvolvimento da Lean Inception","text":"Hist\u00f3rico de Revis\u00e3o
Data Vers\u00e3o Descri\u00e7\u00e3o Autor 11/11/2024 0.0 Cria\u00e7\u00e3o do documento Benjamim Lacerda"},{"location":"visao_produto/BacklogdeProduto/","title":"BacklogdeProduto","text":""},{"location":"visao_produto/BacklogdeProduto/#91-backlog-geral","title":"9.1 Backlog Geral","text":"Nosso backlog foi estruturado utilizando hist\u00f3rias de usu\u00e1rio para garantir clareza e foco nas necessidades do neg\u00f3cio e dos usu\u00e1rios finais. As hist\u00f3rias seguem um formato padronizado, come\u00e7ando pela identifica\u00e7\u00e3o do ator (Como um(a):), o objetivo (Eu quero:) e o benef\u00edcio esperado (Para que:), assegurando que cada item esteja alinhado com o prop\u00f3sito do sistema. Al\u00e9m disso, cada hist\u00f3ria inclui crit\u00e9rios de aceita\u00e7\u00e3o bem definidos, que detalham os comportamentos esperados, como valida\u00e7\u00f5es, respostas a falhas, e condi\u00e7\u00f5es espec\u00edficas de funcionamento. Esse padr\u00e3o facilita a prioriza\u00e7\u00e3o, promove um entendimento comum entre os membros do time e stakeholders, e serve como base para valida\u00e7\u00e3o durante o desenvolvimento, garantindo que as entregas atendam \u00e0s expectativas de qualidade e funcionalidade.
RF1 - Titulo: Realizar Login Como um(a): Dono do Neg\u00f3cio Eu quero:Realizar um login r\u00e1pido e seguro no sistema Para que: Eu confie os meus dados na aplica\u00e7\u00e3o Crit\u00e9rios de aceita\u00e7\u00e3o: 1-No caso de alguma falha o usu\u00e1rio deve receber uma resposta do sistema informando qual campo n\u00e3o foi preenchido corretamente. 2-Os dados de entrada que s\u00e3o CPF e senha devem ser conferidos e devem ser \u00fanicos por usu\u00e1rio. 3-O sistema deve manter o usu\u00e1rio logado por, no m\u00ednimo, 24 horas, a menos que ele escolha explicitamente sair (logout). 4-Ao fazer login com sucesso, o usu\u00e1rio deve ser redirecionado para a p\u00e1gina inicial da aplica\u00e7\u00e3o, com uma mensagem de boas-vindas.
RF2 - Titulo: Cadastro de Produto Como um(a): Dono do Neg\u00f3cio Eu quero:Cadastrar um produto Para que: Eu adicione novos produtos de forma r\u00e1pida e pr\u00e1tica Crit\u00e9rios de aceita\u00e7\u00e3o: 1-O cadastro do produto deve ser conclu\u00eddo em, no m\u00e1ximo, 3 etapas na interface. 2-O sistema deve permitir que o dono do neg\u00f3cio cadastre um produto informando, no m\u00ednimo: nome, quantidade e descri\u00e7\u00e3o . 3-O pre\u00e7o deve aceitar apenas valores num\u00e9ricos positivos, incluindo casas decimais. 4-Deve ser poss\u00edvel representar quantidades fracionadas de algum produto (Meio pacote). 5-Ap\u00f3s o cadastro bem-sucedido, o sistema deve exibir uma mensagem de sucesso. 6-Caso algum campo obrigat\u00f3rio esteja ausente ou inv\u00e1lido, o sistema deve exibir uma mensagem clara indicando o problema.
RF3 - T\u00edtulo: Pesquisa de Produto Como um(a): Dono do Neg\u00f3cio Eu quero:Pesquisar um produto Para que: Eu saiba a quantidade dos produtos e possa me planejar Crit\u00e9rios de aceita\u00e7\u00e3o: 1-O sistema deve permitir a pesquisa de produtos pelo nome completo ou parcial. 2-A pesquisa deve ser acionada ao pressionar a tecla \"Enter\" ou clicar em um bot\u00e3o \"Buscar\". 3-Caso nenhum produto seja encontrado, o sistema deve exibir a mensagem \"Nenhum produto encontrado\".
RF4 - T\u00edtulo: Exclus\u00e3o de Produto Como um(a): Dono do Neg\u00f3cio Eu quero:Excluir um produto Para que: Eu n\u00e3o tenha produtos desnecess\u00e1rios me confundindo na hora de avaliar meu estoque Crit\u00e9rios de aceita\u00e7\u00e3o: 1-O sistema deve exibir uma mensagem de confirma\u00e7\u00e3o antes de excluir o produto. 2-A exclus\u00e3o s\u00f3 deve ocorrer ap\u00f3s o usu\u00e1rio confirmar a a\u00e7\u00e3o.. O pre\u00e7o deve aceitar apenas valores num\u00e9ricos positivos, incluindo casas decimais. 3-O bot\u00e3o de exclus\u00e3o deve ser vis\u00edvel, mas n\u00e3o deve ser facilmente clicado acidentalmente. 4-Ap\u00f3s a exclus\u00e3o do produto, ele n\u00e3o deve mais aparecer na lista de produtos.
RF5 - T\u00edtulo: Atualiza\u00e7\u00e3o de Produto Como um(a): Dono do Neg\u00f3cio Eu quero:Atualizar os dados de um produto Para que: Eu mantenha a quantidade dos produtos correta e n\u00e3o compre nada a mais ou a menos Crit\u00e9rios de aceita\u00e7\u00e3o: 1-O sistema deve permitir que o dono do neg\u00f3cio atualize as informa\u00e7\u00f5es do produto, incluindo: nome, descri\u00e7\u00e3o e quantidade em estoque. 2-A edi\u00e7\u00e3o deve ser feita a partir de uma lista de produtos, onde cada item tenha a op\u00e7\u00e3o \"Editar\". 3-O sistema deve validar os dados atualizados antes de salvar. 4-Ap\u00f3s salvar as altera\u00e7\u00f5es, o sistema deve exibir uma mensagem de sucesso 5-Em caso de erro, uma mensagem clara deve ser exibida, indicando o motivo. 6-O formul\u00e1rio de edi\u00e7\u00e3o deve carregar os dados atuais do produto para facilitar a atualiza\u00e7\u00e3o. 7-Deve haver um bot\u00e3o \"Salvar\" para confirmar a atualiza\u00e7\u00e3o e um bot\u00e3o \"Cancelar\" para descartar as altera\u00e7\u00f5es. 8-As altera\u00e7\u00f5es realizadas devem refletir imediatamente na lista de produtos e no estoque.
RF6 - T\u00edtulo: Ordenar produtos por quantidade Como um(a): Dono do Neg\u00f3cio Eu quero: Ordenar produtos por quantidade Para que: Eu consiga saber quais produtos eu tenha me maior quantidade, facilitando na hora de comprar novos produtos Crit\u00e9rios de aceita\u00e7\u00e3o: 1-O sistema deve permitir ordenar os produtos por quantidade em estoque, tanto em ordem crescente quanto decrescente. 2-A ordena\u00e7\u00e3o deve ser acionada atrav\u00e9s de bot\u00f5es ou op\u00e7\u00f5es claramente identificadas. 3-Ap\u00f3s aplicar a ordena\u00e7\u00e3o, os produtos devem ser exibidos na nova ordem escolhida, sem a necessidade de recarregar a p\u00e1gina. 4-O sistema deve manter a ordena\u00e7\u00e3o selecionada enquanto o usu\u00e1rio estiver navegando na lista de produtos.
RF7 - T\u00edtulo: Cadastro de Evento Como um(a): Dono do Neg\u00f3cio Eu quero: Cadastrar um Evento Para que: Eu fique ciente dos eventos futuros e possa me organizar Crit\u00e9rios de aceita\u00e7\u00e3o: 1-O sistema deve permitir que o dono do neg\u00f3cio cadastre um evento informando, no m\u00ednimo: nome, data, hor\u00e1rio, local, quantidade de pessoas e descri\u00e7\u00e3o. 2-O cadastro deve ser conclu\u00eddo em at\u00e9 3 etapas na interface ou em uma \u00fanica tela. 3-Deve haver um bot\u00e3o \"Salvar\" para confirmar o cadastro e outro \"Cancelar\" para descartar as informa\u00e7\u00f5es. 4-Ap\u00f3s salvar, o evento deve ser exibido em uma lista ou calend\u00e1rio na tela principal dos eventos. 5-Ap\u00f3s o cadastro bem-sucedido, o sistema deve exibir uma mensagem de confirma\u00e7\u00e3o. 6-Em caso de erro, o sistema deve exibir mensagens espec\u00edficas para cada problema.
RF8 - Titulo: Cadastro de Gastos do evento Como um(a): Dono do Neg\u00f3cio Eu quero: Cadastrar os Gastos de um evento Para que: saiba o quanto eu gastei em um evento, seja com funcion\u00e1rio ou com mat\u00e9ria prima Crit\u00e9rios de aceita\u00e7\u00e3o: 1-O sistema deve permitir que o dono do neg\u00f3cio associe gastos a um evento previamente cadastrado. 2-Para cada gasto, devem ser informados: tipo de gasto (ex.: funcion\u00e1rio, mat\u00e9ria-prima), descri\u00e7\u00e3o, valor, e data. 3-O campo \"Valor\" deve aceitar apenas valores num\u00e9ricos positivos, com suporte a casas decimais 4-Ap\u00f3s o cadastro bem-sucedido, o sistema deve exibir uma mensagem de confirma\u00e7\u00e3o. 5-Caso ocorra algum erro, o sistema deve informar claramente o motivo.
RF9 -T\u00edtulo: Cadastro de Ganhos do Evento Como um(a): Dono do Neg\u00f3cio Eu quero:Cadastrar os ganhos de um evento Para que: Eu saiba o quanto eu vendi e possa avaliar a efetividade do evento Crit\u00e9rios de aceita\u00e7\u00e3o: 1-O sistema deve permitir que o dono do neg\u00f3cio registre os ganhos relacionados a um evento espec\u00edfico. 2-Para cada ganho, o sistema deve solicitar: descri\u00e7\u00e3o do ganho (ex.: vendas de ingressos, vendas de produtos), valor arrecadado e data. 3-O campo \"Valor\" deve aceitar apenas valores num\u00e9ricos positivos, com suporte a casas decimais. 4-Ap\u00f3s o cadastro bem-sucedido, o sistema deve exibir uma mensagem de confirma\u00e7\u00e3o. 5-Caso ocorra algum erro, o sistema deve informar claramente o motivo.
RF10 - T\u00edtulo: Gerar Relat\u00f3rio Referente aos Ganhos e Gastos do evento Como um(a): Dono do Neg\u00f3cio Eu quero: Gerar relat\u00f3rios sobre os ganhos e gastos dos eventos Para que: Eu possa avaliar a lucratividade e tomar decis\u00f5es estrat\u00e9gicas Crit\u00e9rios de aceita\u00e7\u00e3o: 1-O sistema deve gerar relat\u00f3rios detalhados contendo:Nome do evento,Total de ganhos, Total de gastos, Balan\u00e7o final (lucro ou preju\u00edzo), Lista detalhada de ganhos e gastos, incluindo data, descri\u00e7\u00e3o e valores. 2-O relat\u00f3rio deve ser exibido na tela em um formato organizado e f\u00e1cil de visualizar (ex.: tabelas ou gr\u00e1ficos). 3-O sistema deve destacar o balan\u00e7o final (lucro ou preju\u00edzo) de forma clara, com cores diferenciadas (ex.: verde para lucro, vermelho para preju\u00edzo). 4-O sistema deve permitir a exporta\u00e7\u00e3o do relat\u00f3rio nos formatos PDF e Excel. 5-Ap\u00f3s a gera\u00e7\u00e3o, o relat\u00f3rio deve ser armazenado na interface do sistema para consulta posterior.
RF11 - T\u00edtulo: Pesquisar Eventos Passados Como um(a): Dono do Neg\u00f3cio Eu quero: Pesquisar eventos passados Para que: Eu possa acessar informa\u00e7\u00f5es relevantes e relacionados a eventos passados Crit\u00e9rios de aceita\u00e7\u00e3o: 1-O sistema deve permitir que o dono do neg\u00f3cio pesquise eventos passados usando tanto nome como per\u00edodos ou datas. 2-A lista de resultados deve exibir: nome, data, local do evento, relat\u00f3rio financeiro (se dispon\u00edvel). 3-A interface deve indicar claramente quando nenhum evento correspondente for encontrado
RF12 - T\u00edtulo: Pesquisar Eventos Futuros Como um(a): Dono do Neg\u00f3cio Eu quero: Pesquisar eventos futuros Para que: Eu possa acessar informa\u00e7\u00f5es relevantes e planejar melhor as a\u00e7\u00f5es relacionadas aos pr\u00f3ximos eventos. Crit\u00e9rios de aceita\u00e7\u00e3o: 1-O sistema deve permitir que o dono do neg\u00f3cio pesquise eventos futuros usando tanto nome como per\u00edodos ou datas. 2-A lista de resultados deve exibir: nome, data, local do evento. 3-A interface deve indicar claramente quando nenhum evento correspondente for encontrado
RF13 - T\u00edtulo: Atualizar dados dos eventos Como um(a): Dono do Neg\u00f3cio Eu quero: Atualizar os dados de eventos cadastrados Para que: Eu possa corrigir informa\u00e7\u00f5es ou refletir altera\u00e7\u00f5es no planejamento Crit\u00e9rios de aceita\u00e7\u00e3o: 1-O sistema deve permitir que o dono do neg\u00f3cio atualize as seguintes informa\u00e7\u00f5es de um evento: nome, data , local, hor\u00e1rio, quantidade de pessoas, gastos e ganhos. 2-Deve haver um bot\u00e3o ou link \"Editar\" ao lado de cada evento listado. 3-O formul\u00e1rio de edi\u00e7\u00e3o deve exibir os dados atuais do evento, permitindo altera\u00e7\u00f5es em campos espec\u00edficos. 4-O sistema deve validar as informa\u00e7\u00f5es atualizadas antes de salvar. 5-Ap\u00f3s salvar as altera\u00e7\u00f5es, o sistema deve exibir uma mensagem de sucesso 6-Se o usu\u00e1rio cancelar a edi\u00e7\u00e3o, o sistema deve descartar as altera\u00e7\u00f5es e manter os dados originais intactos.
RF14 - T\u00edtulo: Cadastro de Funcion\u00e1rio Como um(a): Dono do Neg\u00f3cio Eu quero: Cadastrar novos funcion\u00e1rios no sistema Para que: Eu possa gerenciar informa\u00e7\u00f5es da equipe com efici\u00eancia Crit\u00e9rios de aceita\u00e7\u00e3o: 1-O sistema deve permitir que o dono do neg\u00f3cio cadastre novos funcion\u00e1rios preenchendo os seguintes campos obrigat\u00f3rios: Nome, telefone de contato. 2-O sistema deve permitir que o dono do neg\u00f3cio avalie os funcion\u00e1rios de uma forma simples o desempenho e a pontualidade dos funcion\u00e1rios 3-Ap\u00f3s o cadastro, o sistema deve exibir uma mensagem de sucesso. 4-Caso ocorra um erro, o sistema deve exibir uma mensagem clara com a raz\u00e3o do erro. 5-As informa\u00e7\u00f5es cadastradas devem ser armazenadas corretamente no banco de dados, garantindo a integridade e disponibilidade dos dados. 6-O sistema deve impedir o cadastro de funcion\u00e1rios com informa\u00e7\u00f5es incompletas ou incorretas.
RF15 - T\u00edtulo: Excluir funcion\u00e1rio Como um(a): Dono do Neg\u00f3cio Eu quero: Excluir funcion\u00e1rios que n\u00e3o fazem mais parte da empresa Para que: Eu possa manter o cadastro atualizado Crit\u00e9rios de aceita\u00e7\u00e3o: 1-O sistema deve permitir que o dono do neg\u00f3cio exclua um funcion\u00e1rio selecionado na lista de funcion\u00e1rios cadastrados. 2-Antes de excluir, o sistema deve exibir uma mensagem de confirma\u00e7\u00e3o. 3-Deve haver bot\u00f5es de confirma\u00e7\u00e3o e cancelamento claramente identificados. 4-O sistema n\u00e3o deve permitir a exclus\u00e3o de funcion\u00e1rios vinculados a eventos futuros. 5-Caso o funcion\u00e1rio n\u00e3o possa ser exclu\u00eddo, o sistema deve exibir uma mensagem clara explicando o por que. 6-Ap\u00f3s uma exclus\u00e3o bem-sucedida, o sistema deve exibir uma mensagem de confirma\u00e7\u00e3o.
RF16 - T\u00edtulo: Atualizar dados dos funcion\u00e1rios Como um(a): Dono do Neg\u00f3cio Eu quero: Atualizar as informa\u00e7\u00f5es dos funcion\u00e1rios Para que: Eu possa corrigir dados ou adicionar novas informa\u00e7\u00f5es relevantes. Crit\u00e9rios de aceita\u00e7\u00e3o: 1-O sistema deve permitir que o dono do neg\u00f3cio edite as informa\u00e7\u00f5es de um funcion\u00e1rio previamente cadastrado. 2-O sistema deve permitir a atualiza\u00e7\u00e3o de todos os dados e das avalia\u00e7\u00f5es do funcion\u00e1rio. 3-O sistema deve validar os dados atualizados. 4-Ap\u00f3s salvar as altera\u00e7\u00f5es, o sistema deve exibir uma mensagem de sucesso. 5-Caso ocorra um erro, deve ser exibida uma mensagem clara com o motivo do erro. 6-O sistema deve exibir um bot\u00e3o ou link claramente identificado como \"Editar\" ao lado de cada funcion\u00e1rio na lista.
RF17 - T\u00edtulo: Registro de Pagamento de funcion\u00e1rio Como um(a): Dono do Neg\u00f3cio Eu quero: Registrar pagamentos de funcion\u00e1rios Para que: Eu possa controlar as finan\u00e7as e garantir o hist\u00f3rico de pagamentos. Crit\u00e9rios de aceita\u00e7\u00e3o: 1-O sistema deve permitir que o dono do neg\u00f3cio registre pagamentos realizados para cada funcion\u00e1rio. 2-O sistema deve validar o valor do pagamento, apenas valores positivos decimais ou n\u00e3o. 3-Ap\u00f3s registrar o pagamento, o sistema deve exibir uma mensagem de sucesso. 4-Caso ocorra um erro, deve ser exibida uma mensagem clara com o motivo do erro. 5-O sistema deve permitir que o usu\u00e1rio visualize uma lista de pagamentos realizados, pesquisando por nome ou data.
RF18 - T\u00edtulo: Pesquisar Funcion\u00e1rio Como um(a): Dono do Neg\u00f3cio Eu quero: Pesquisar informa\u00e7\u00f5es de funcion\u00e1rios no sistema Para que: Eu possa acessar dados rapidamente quando necess\u00e1rio Crit\u00e9rios de aceita\u00e7\u00e3o: 1-O sistema deve permitir que o dono do neg\u00f3cio pesquise informa\u00e7\u00f5es de funcion\u00e1rios cadastrados utilizando diferentes crit\u00e9rios. 2-A pesquisa deve aceitar os seguintes par\u00e2metros: nome, telefone de contato, desempenho e pontualidade. 3-O sistema deve exibir uma lista com os funcion\u00e1rios que correspondem aos crit\u00e9rios de busca. 4-Se nenhum funcion\u00e1rio for encontrado, o sistema deve exibir uma mensagem. 5-Caso ocorra um erro, deve ser exibida uma mensagem clara com o motivo do erro.
"},{"location":"visao_produto/CronogramaEntregas/","title":"Calend\u00e1rio de Sprints","text":"Sprint In\u00edcio Fim Objetivo Principal Entregas Esperadas Valida\u00e7\u00e3o do Cliente Sprint 1 28/10/23 11/11/23 - Planejamento do projeto Defini\u00e7\u00e3o inicial do escopo Valida\u00e7\u00e3o do escopo Sprint 2 12/11/23 25/11/23 - Prot\u00f3tipo da interface principal - Cria\u00e7\u00e3o do ambiente de desenvolvimento - Prot\u00f3tipo da tela inicial Valida\u00e7\u00e3o do prot\u00f3tipo Sprint 3 26/11/23 09/12/23 - Funcionalidades do estoque - L\u00f3gica de controle de estoque - Alerta de baixa disponibilidade Valida\u00e7\u00e3o do fluxo e alertas do estoque Sprint 4 10/12/23 23/12/23 Fluxo financeiro e eventos - Fluxo de caixa com entradas e sa\u00eddas - Cadastro de eventos Valida\u00e7\u00e3o das funcionalidades financeiras e de eventos Sprint 5 07/01/24 20/01/24 Gest\u00e3o de funcion\u00e1rios e vendas em eventos - L\u00f3gica de controle de funcion\u00e1rios - Registro de vendas vinculadas a eventos Valida\u00e7\u00e3o de cadastro de funcion\u00e1rios e fluxo financeiro em eventos Sprint 6 21/01/24 03/02/24 Aloca\u00e7\u00e3o de funcion\u00e1rios e revis\u00e3o geral - Inser\u00e7\u00e3o de funcion\u00e1rios a eventos - Revis\u00e3o e ajuste das funcionalidades implementadas Valida\u00e7\u00e3o do processo de aloca\u00e7\u00e3o e ajustes realizados Sprint 7 04/02/24 17/02/24 Revis\u00e3o final e entrega do sistema - Revis\u00e3o Completa do sistema - Prepara\u00e7\u00e3o para o lan\u00e7amento Aprova\u00e7\u00e3o final e prepara\u00e7\u00e3o para entrega Hist\u00f3rico de Revis\u00e3o
Data Vers\u00e3o Descri\u00e7\u00e3o Autor 08/11/2024 0.0 Cria\u00e7\u00e3o do documento Benjamim Lacerda 11/11/2024 0.1 Atualiza\u00e7\u00e3o do Documento Pedro Henrique 11/11/2024 1.0 Primeira vers\u00e3o do documento Benjamim Lacerda Santos, Iderlan Junio Cardoso da Silva, Mateus Henrique Queiroz Magalh\u00e3es Sousa, Pedro Gois Marques Monteiro, Pedro Henrique 22/11/2024 1.1 Atualiza\u00e7\u00e3o do documento Benjamim Lacerda Santos 27/11/2024 1.2 Ajustes no documento Benjamim Lacerda Santos"},{"location":"visao_produto/DoReDoT/","title":"DoReDoT","text":""},{"location":"visao_produto/DoReDoT/#81-definition-of-ready-dor","title":"8.1 Definition of Ready (DoR)","text":"Escolhemos os crit\u00e9rios de Definition of Ready (DoR) para garantir que o fluxo de trabalho seja eficiente e sem interrup\u00e7\u00f5es. Eles permitem que o time tenha uma compreens\u00e3o clara e compartilhada das hist\u00f3rias ou tarefas antes de iniciar o desenvolvimento, evitando ambiguidades ou retrabalho. Esses crit\u00e9rios promovem uma comunica\u00e7\u00e3o mais eficiente entre os envolvidos, reduzem riscos e aumentam a previsibilidade das entregas.
Nossas defini\u00e7\u00f5es s\u00e3o:
1-O requisito cabe em uma sprint?
2-O requisito est\u00e1 representado por uma hist\u00f3ria de usu\u00e1rio?
3-Os crit\u00e9rios de aceita\u00e7\u00e3o est\u00e3o definidos (para ser poss\u00edvel um feedback)?
4-A prototipa\u00e7\u00e3o est\u00e1 pronta para o desenvolvimento.\u00a0
"},{"location":"visao_produto/DoReDoT/#82-definition-of-done-dod","title":"8.2 Definition of Done (DoD)","text":"Escolhemos os crit\u00e9rios de Definition of Done (DoD) para assegurar que as entregas atendam aos padr\u00f5es de qualidade esperados e estejam verdadeiramente completas. Esses crit\u00e9rios ajudam a evitar entregas incompletas, reduzem o risco de erros em produ\u00e7\u00e3o e promovem a confian\u00e7a nas entregas do time, garantindo que os resultados estejam alinhados com as expectativas do projeto e dos stakeholders.
Nossas defini\u00e7\u00f5es s\u00e3o:
1-Foram usadas boas praticas no codigo
2-Comtempla os criterios de aceita\u00e7\u00e3o
3-Gera um incremento no produto
4-Se foi devidamente testada\u00a0
"},{"location":"visao_produto/EstrategiasEngSoftware/","title":"Estrat\u00e9gias de Engenharia de Software","text":""},{"location":"visao_produto/EstrategiasEngSoftware/#31-estrategia-priorizada","title":"3.1 Estrat\u00e9gia Priorizada","text":"Abordagem: \u00c1gil
Ciclo de vida: Iterativo e Incremental.
Processo: RAD(Rapid Application Development) e SCRUM.
"},{"location":"visao_produto/EstrategiasEngSoftware/#32-quadro-comparativo","title":"3.2 Quadro Comparativo","text":"O quadro a seguir apresenta caracter\u00edsticas dos processos RAD e SCRUM que ser\u00e3o utilizados e tamb\u00e9m do OpenUp para compara\u00e7\u00e3o, buscando justificar a escolha do processo adequado ao Dida\u2019s Bistr\u00f4.
Caracter\u00edsticas RAD SCRUM OpenUP Abordagem Geral Iterativo e incremental com \u00eanfase em entregas r\u00e1pidas por meio de prototipagem. Iterativo e incremental, com foco em entregas frequentes e feedback cont\u00ednuo. Iterativo, incremental e baseado em arquitetura s\u00f3lida. Foco em Arquitetura Arquitetura evolui durante o processo, com foco inicial na prototipagem. N\u00e3o prescreve foco espec\u00edfico em arquitetura, a arquitetura evolui conforme as necessidades do projeto. Forte \u00eanfase no desenvolvimento orientado a uma arquitetura s\u00f3lida e flex\u00edvel desde o in\u00edcio do projeto. Estrutura de Processos Dividido em fases (requisitos, prototipa\u00e7\u00e3o, constru\u00e7\u00e3o e testes). Cada fase \u00e9 chamada de timebox que duram de 1-4 semanas. Focado em sprints curtos e flex\u00edveis (2-4 semanas) com entregas incrementais e adapta\u00e7\u00e3o cont\u00ednua durante o projeto. Estrutura clara de fases: Inicia\u00e7\u00e3o, Elabora\u00e7\u00e3o, Constru\u00e7\u00e3o e Transi\u00e7\u00e3o. Flexibilidade de Requisitos Alta flexibilidade para altera\u00e7\u00f5es r\u00e1pidas nos requisitos, facilitada pela prototipagem e os feedbacks. Alta flexibilidade para mudan\u00e7as cont\u00ednuas de requisitos a cada sprint. Adapt\u00e1vel a feedback frequente do cliente. Flexibilidade para adapta\u00e7\u00f5es iterativas, com a arquitetura principal definida cedo. Colabora\u00e7\u00e3o com Cliente Envolvimento frequente do cliente para valida\u00e7\u00e3o de prot\u00f3tipos e ajustes r\u00e1pidos. Envolvimento cont\u00ednuo do cliente com feedback ao final de cada sprint. Requer envolvimento cont\u00ednuo do cliente, especialmente nas fases de valida\u00e7\u00e3o. Complexidade do Processo Mais leve, com foco na prototipagem e desenvolvimento r\u00e1pido; menos formalidade. Estrutura leve, focada na entrega funcional e adapta\u00e7\u00e3o cont\u00ednua; menos documenta\u00e7\u00e3o. Mais formal, com documenta\u00e7\u00e3o e fases estruturadas, requerendo disciplina e pap\u00e9is claros. Qualidade T\u00e9cnica Garantida pela r\u00e1pida constru\u00e7\u00e3o e teste de prot\u00f3tipos, ajustes s\u00e3o feitos conforme feedback. Alta \u00eanfase na qualidade t\u00e9cnica, com pr\u00e1ticas como TDD (Test-Driven Development), pair programming e integra\u00e7\u00e3o cont\u00ednua para garantir um c\u00f3digo limpo e funcional. Qualidade assegurada pela defini\u00e7\u00e3o de arquitetura e valida\u00e7\u00e3o incremental. Pr\u00e1ticas de Desenvolvimento Foco na prototipagem e valida\u00e7\u00e3o r\u00e1pida, com menos pr\u00e1ticas t\u00e9cnicas estruturadas. Inclui pr\u00e1ticas t\u00e9cnicas robustas como TDD, refatora\u00e7\u00e3o cont\u00ednua, integra\u00e7\u00e3o cont\u00ednua e pair programming, promovendo alta qualidade no c\u00f3digo. Estrutura mais formal com foco em arquitetura e controle de progresso. Menos pr\u00e1ticas t\u00e9cnicas espec\u00edficas dentro do processo de desenvolvimento. Adapta\u00e7\u00e3o ao Projeto do Dida\u2019s Bistr\u00f4 Ideal em projetos que precisam de prot\u00f3tipos r\u00e1pidos e ajustes com o cliente. Ideal para projetos onde a intera\u00e7\u00e3o constante com o cliente e a evolu\u00e7\u00e3o cont\u00ednua do produto s\u00e3o fundamentais. Adapt\u00e1vel a mudan\u00e7as frequentes e r\u00e1pidos ciclos de feedback. Ideal para projetos que exigem uma arquitetura bem definida, mas flexibilidade incremental. Documenta\u00e7\u00e3o M\u00ednima documenta\u00e7\u00e3o. O foco em comunica\u00e7\u00e3o direta com o cliente para ajustes r\u00e1pidos. Minimiza a documenta\u00e7\u00e3o formal, priorizando comunica\u00e7\u00e3o r\u00e1pida e feedback. Requer documenta\u00e7\u00e3o formal para cada fase, com \u00eanfase em requisitos e arquitetura. Controle de Qualidade Baseado em revis\u00f5es de prot\u00f3tipos e ajustes ao longo do desenvolvimento. Controle de qualidade embutido nas pr\u00e1ticas do XP, como TDD e integra\u00e7\u00e3o cont\u00ednua. Controle de qualidade atrav\u00e9s de valida\u00e7\u00f5es incrementais e revis\u00f5es de arquitetura. Escalabilidade Escal\u00e1vel para projetos de pequena a m\u00e9dia escala, em projetos maiores, pode enfrentar desafios devido \u00e0 sua natureza menos formal. Escal\u00e1vel, mas mais indicado para equipes menores e m\u00e9dias devido \u00e0 sua abordagem colaborativa e interativa constante. Escal\u00e1vel para projetos maiores e mais complexos, com equipes m\u00e9dias a grandes. Suporte a Equipes de Desenvolvimento Suporta equipes menores, com foco na colabora\u00e7\u00e3o e menos formalidade nos papeis. Suporta equipes menores e mais colaborativas, com papeis mais flex\u00edveis, permitindo maior adapta\u00e7\u00e3o ao ritmo do projeto. Suporta equipes maiores e com mais papeis definidos, pois requer mais controle sobre o progresso e as fases do projeto."},{"location":"visao_produto/EstrategiasEngSoftware/#33-justificativa","title":"3.3 Justificativa","text":"Baseado nos crit\u00e9rios proposto por Gupta para a escolha de processos, respondemos uma s\u00e9rie de quest\u00f5es sobre os t\u00f3picos abordados pelos crit\u00e9rios para definir o modelo de desenvolvimento que ser\u00e1 utilizado ao longo do projeto. Optamos pelo RAD como framework mostrou e adaptamos algumas caracter\u00edsticas do SCRUM para melhor adequa\u00e7\u00e3o ao Dida\u2019s Bistr\u00f4.
Watterfall: 10 Prototype: 10 Iterative Enhancement: 6 Evolutionary development: 7 Spiral: 9 RAD: 11
Rapidez: O RAD visa acelerar o processo de desenvolvimento. Isso \u00e9 alcan\u00e7ado atrav\u00e9s de ciclos de desenvolvimento curtos, permitindo que os produtos sejam entregues mais rapidamente.
Flexibilidade: Incentiva a adapta\u00e7\u00e3o r\u00e1pida \u00e0s mudan\u00e7as. O RAD permite ajustes no decorrer do projeto sem grandes impactos nos prazos gra\u00e7as \u00e0 constante prototipagem e os feedbacks.
Prototipagem: O uso de prot\u00f3tipos \u00e9 central no RAD, permitindo que desenvolvedores testem e ajustem funcionalidades, de acordo com os requisitos do cliente, o que ser\u00e1 de extrema import\u00e2ncia para o Dida\u2019s Bistr\u00f4.
Organiza\u00e7\u00e3o: A organiza\u00e7\u00e3o \u00e9 baseada na realiza\u00e7\u00e3o de fases com timebox de 15 dias, as reuni\u00e7oes s\u00e3o as de planejamento e retrospectiva e revis\u00e3o. A gest\u00e3o das hist\u00f3rias de usu\u00e1rios \u00e9 realizada atrav\u00e9s do ZenHub, a comunica\u00e7\u00e3o interna \u00e9 com a utiliza\u00e7\u00e3o de aplicativo de mensagem instant\u00e2nea e a comunica\u00e7\u00e3o com o cliente \u00e9 utilizando o Microsoft Teams como reuni\u00f5es gravadas.
Cliente Ativo: Nosso cliente tem disponibilidade para estar presente em quase todas as nossas reuni\u00f5es, por isso escolhemos a metodologia RAD, permitindo constantes feedbacks durante o processo de prototipa\u00e7\u00e3o.
Hist\u00f3rico de Revis\u00e3o
Data Vers\u00e3o Descri\u00e7\u00e3o Autor 08/11/2024 0.0 Cria\u00e7\u00e3o do documento Benjamim Lacerda 11/11/2024 0.1 Atualiza\u00e7\u00e3o do Documento Pedro Henrique 11/11/2024 1.0 Primeira vers\u00e3o do documento Benjamim Lacerda Santos, Iderlan Junio Cardoso da Silva, Mateus Henrique Queiroz Magalh\u00e3es Sousa, Pedro Gois Marques Monteiro, Pedro Henrique"},{"location":"visao_produto/InteracaoEquipeCliente/","title":"Intera\u00e7\u00e3o Entre Equipe e Cliente","text":""},{"location":"visao_produto/InteracaoEquipeCliente/#51-composicao-da-equipe","title":"5.1 Composi\u00e7\u00e3o da Equipe","text":""},{"location":"visao_produto/InteracaoEquipeCliente/#papeis-e-responsabilidades","title":"Pap\u00e9is e Responsabilidades","text":"Papel Descri\u00e7\u00e3o Respons\u00e1vel Participantes Gerente de Projeto Coordena o projeto, garante a comunica\u00e7\u00e3o entre cliente e equipe, controla prazos e entregas. Benjamin Lacerda Santos Desenvolvedor Frontend Respons\u00e1vel pela interface do usu\u00e1rio, design e implementa\u00e7\u00e3o das funcionalidades no lado do cliente. Iderlan J\u00fanio Cardoso da Silva Benjamin Lacerda, Mateus Henrique, Pedro Henrique dos Santos Ferreira, Felipe Fernandes Brandim Desenvolvedor Backend Implementa a l\u00f3gica de neg\u00f3cios, integra\u00e7\u00e3o com banco de dados e APIs. Pedro Henrique dos Santos Ferreira Pedro Gois, Mateus Henrique, Benjamin Lacerda, Felipe Fernandes Brandim Analista de QA Garante a qualidade do produto, executando testes de funcionalidade, performance e usabilidade. Mateus Henrique Queiroz Magalh\u00e3es Sousa Pedro Gois Analista de Requisitos Define os requisitos funcionais e n\u00e3o funcionais do sistema e garante que eles sejam atendidos. Pedro Gois Monteiro Marques Mateus Henrique, Pedro Henrique dos Santos Ferreira, Benjamin Lacerda Santos, Iderlan J\u00fanio Cardoso da Silva, Felipe Fernandes Brandim"},{"location":"visao_produto/InteracaoEquipeCliente/#52-comunicacao","title":"5.2 Comunica\u00e7\u00e3o","text":"Ferramentas de Comunica\u00e7\u00e3o
Aplicativo de mensagem instant\u00e2nea: Ser\u00e1 utilizado para a comunica\u00e7\u00e3o dos membros da equipe diariamente. Est\u00e1 ferramenta \u00e9 necess\u00e1ria por conta da facilidade ao envio r\u00e1pido de mensagens, enquetes, arquivos e canais de comunica\u00e7\u00e3o espec\u00edficos.
Microsoft Teams: Todas as reuni\u00f5es semanais de planejamento, revis\u00e3o e discuss\u00f5es com os membros e cliente ser\u00e3o realizadas no canal de comunica\u00e7\u00e3o do Microsoft Teams. com isso, buscamos otimizar o acompanhamento das entregas, os feedbacks e os planejamentos futuros.
ZenHub: Ser\u00e1 utilizado para a gest\u00e3o do projeto oferecendo suporte para a equipe no gerenciamento de fluxos, na visualiza\u00e7\u00e3o em tempo real das tarefas em andamento e projetar o fluxo de trabalho.
M\u00e9todo e Frequ\u00eancia de Reuni\u00f5es
Reuni\u00e3o de Revis\u00e3o e Retrospectiva: As reuni\u00f5es de conclus\u00e3o da fase, ser\u00e1 revisado com o cliente, nessas reuni\u00f5es, todas as funcionalidades desenvolvidas durante a fase ser\u00e3o apresentadas. Com isso, garantindo que o cliente teste e realize a valida\u00e7\u00e3o. Tamb\u00e9m ser\u00e1 realizada uma retrospectiva entre a equipe para entender quais foram as dificuldades, desafios e li\u00e7\u00f5es aprendidas durante o processo.
Reuni\u00e3o de Planejamento: Ao \u00ednicio de cada fase ser\u00e1 decidido junto ao cliente quais ser\u00e3o os pr\u00f3ximos passos, criando um planejamento para a fase que se inicia.
Frequ\u00eancia de Intera\u00e7\u00f5es com o cliente
Revis\u00f5es de Sprint (a cada 2 semanas): Durante as reuni\u00f5es de revis\u00e3o o cliente, ser\u00e1 respons\u00e1vel por validar as entregas e apontar o feedback. Se tornando diretamente ligado ao processo de conclus\u00e3o da sprint.
Intera\u00e7\u00f5es Adicionais pelo Microsoft Teams: O cliente ter\u00e1 acesso a um canal de discuss\u00e3o no Microsoft Teams, em que todos os membros participar\u00e3o, onde ser\u00e1 poss\u00edvel tirar d\u00favidas ou se necess\u00e1rio, ajustes.
"},{"location":"visao_produto/InteracaoEquipeCliente/#53-processo-de-validacao","title":"5.3 Processo de Valida\u00e7\u00e3o","text":"Valida\u00e7\u00e3o de Requisitos Antes de iniciar o desenvolvimento da funcionalidade ou itera\u00e7\u00e3o, os requisitos do cliente ser\u00e3o revisados e validados com ele. Isso ocorrer\u00e1 atrav\u00e9s da planning, onde o cliente ter\u00e1 a oportunidade de revisar os requisitos.
Testes de Funcionalidade Ao longo do desenvolvimento, ser\u00e3o realizados testes para garantir que a entrega seja de qualidade e com o menor n\u00famero de erros.
Valida\u00e7\u00e3o do Prot\u00f3tipo Ap\u00f3s a valida\u00e7\u00e3o dos requisitos, a prototipa\u00e7\u00e3o ser\u00e1 feita e, posteriormente, haver\u00e1 outra valida\u00e7\u00e3o com o cliente, observando se os requisitos foram atendidos.
Hist\u00f3rico de Revis\u00e3o
Data Vers\u00e3o Descri\u00e7\u00e3o Autor 08/11/2024 0.0 Cria\u00e7\u00e3o do documento Benjamim Lacerda 11/11/2024 0.1 Atualiza\u00e7\u00e3o do Documento Pedro Henrique 11/11/2024 1.0 Primeira vers\u00e3o do documento Benjamim Lacerda Santos, Iderlan Junio Cardoso da Silva, Mateus Henrique Queiroz Magalh\u00e3es Sousa, Pedro Gois Marques Monteiro, Pedro Henrique"},{"location":"visao_produto/LicoesAprendidas/","title":"Li\u00e7\u00f5es Aprendidas","text":""},{"location":"visao_produto/LicoesAprendidas/#61-unidade-1","title":"6.1 Unidade 1","text":"As li\u00e7\u00f5es aprendidas inclu\u00edram uma compreens\u00e3o mais profunda dos processos e ciclos de vida da Engenharia de Requisitos, o que trouxe uma vis\u00e3o clara sobre as etapas necess\u00e1rias para alcan\u00e7ar o objetivo final proposto ao projeto. A equipe tamb\u00e9m aprimorou o entendimento sobre os diferentes tipos de requisitos e a entender melhor as expectativas e necessidades do cliente garantindo que suas demandas fossem compreendidas e incorporadas no projeto.
A equipe do projeto demonstrou uma boa sinergia desde o in\u00edcio, com a defini\u00e7\u00e3o de reuni\u00f5es semanais para garantir o alinhamento e a evolu\u00e7\u00e3o do trabalho. No entanto a falta de clareza em rela\u00e7\u00e3o \u00e0s tarefas e pr\u00f3ximos passos resultou em reuni\u00f5es que, embora focadas, n\u00e3o levavam \u00e0 execu\u00e7\u00e3o completa das atividades planejadas. Isso gerou um ciclo de discuss\u00f5es produtivas, mas com uma baixa efetividade na implementa\u00e7\u00e3o, impactando o progresso do projeto.
Para melhorar isso, a equipe pode come\u00e7ar a registrar atas das reuni\u00f5es, com as decis\u00f5es e a\u00e7\u00f5es a serem tomadas. Ter esses registros facilitam lembrar o que deve ser feito e quem \u00e9 respons\u00e1vel por cada tarefa. Al\u00e9m disso, a defini\u00e7\u00e3o do backlog do produto e a utiliza\u00e7\u00e3o de um quadro KanBan para acompanhar o progresso, ajuda a transformar as conversas em resultados concretos.
Hist\u00f3rico de Revis\u00e3o
Data Vers\u00e3o Descri\u00e7\u00e3o Autor 08/11/2024 0.0 Cria\u00e7\u00e3o do documento Benjamim Lacerda 11/11/2024 0.1 Atualiza\u00e7\u00e3o do Documento Pedro Henrique 11/11/2024 1.0 Primeira vers\u00e3o do documento Benjamim Lacerda Santos, Iderlan Junio Cardoso da Silva, Mateus Henrique Queiroz Magalh\u00e3es Sousa, Pedro Gois Marques Monteiro, Pedro Henrique"},{"location":"visao_produto/ReferenciaBibliografica/","title":"Refer\u00eancias Bibliogr\u00e1ficas","text":" Rapid application development model (RAD) \u2013 Software Engineering. GeeksforGeeks, 2024. Dispon\u00edvel em: Rapid application development model (RAD) \u2013 Software Engineering
MARSICANO, George. Slides da mat\u00e9ria Requisitos. 2024.
Schwaber, K., & Sutherland, J. (n.d.). Scrum Guides. 2024. Dispon\u00edvel em : https://scrumguides.org/
Hist\u00f3rico de Revis\u00e3o
Data Vers\u00e3o Descri\u00e7\u00e3o Autor 08/11/2024 0.0 Cria\u00e7\u00e3o do documento Benjamim Lacerda 11/11/2024 0.1 Atualiza\u00e7\u00e3o do Documento Pedro Henrique 11/11/2024 1.0 Primeira vers\u00e3o do documento Benjamim Lacerda Santos, Iderlan Junio Cardoso da Silva, Mateus Henrique Queiroz Magalh\u00e3es Sousa, Pedro Gois Marques Monteiro, Pedro Henrique"},{"location":"visao_produto/SolucaoProposta/","title":"Solu\u00e7\u00e3o Proposta","text":""},{"location":"visao_produto/SolucaoProposta/#21-objetivos-do-produto","title":"2.1 Objetivos do Produto","text":"Nosso objetivo \u00e9 resolver os problemas causados pela perda de dados, criando um meio de armazen\u00e1-los e acess\u00e1-los. Isso vai auxiliar na tomada de decis\u00f5es no Didas Bistr\u00f4, facilitando o acompanhamento de eventos anteriores, o controle de estoque e o planejamento para futuros eventos. Com o intuito de alcan\u00e7ar esse objetivo, a plataforma ser\u00e1 desenvolvida para:
Centralizar o registro de dados em uma plataforma digital, substituindo o uso exclusivo do papel. Permitindo acesso a informa\u00e7\u00f5es cruciais sobre eventos passados, como lucro, n\u00famero de funcion\u00e1rios necess\u00e1rios e quantidade de ingredientes utilizados.
Implementar um sistema de gest\u00e3o financeira, permitindo que os usu\u00e1rios possam analisar gastos, faturamento e lucros de cada evento.
Criar um sistema de gerenciamento de estoque, para monitorar a quantidade de ingredientes dispon\u00edveis em tempo real.
Prover acesso a registro de eventos passados, facilitando o planejamento futuro.
Objetivos secund\u00e1rios:
Criar uma interface voltada para usu\u00e1rios que n\u00e3o possuem experi\u00eancia com tecnologias.
Assegurar que a plataforma seja responsiva, adaptando para dispositivos m\u00f3veis.
"},{"location":"visao_produto/SolucaoProposta/#22-caracteristicas-da-solucao","title":"2.2 Caracter\u00edsticas da Solu\u00e7\u00e3o","text":"Interface intuitiva: A plataforma vai possuir uma interface de f\u00e1cil entendimento que busca apresentar ao usu\u00e1rio que a sua navega\u00e7\u00e3o ser\u00e1 autoexplicativa, desde os bot\u00f5es e menus, o intuito \u00e9 demonstrar a sua acessibilidade ao usu\u00e1rio.
Sistema de Contabilidade Integrado: Ser\u00e1 poss\u00edvel registrar e categorizar todas as transa\u00e7\u00f5es financeiras, como vendas, pagamentos de fornecedores, sal\u00e1rios e outros custos. Cada transa\u00e7\u00e3o ser\u00e1 registrada com a data, categoria e valor.
Gerenciamento de Estoque: O sistema de estoque ser\u00e1 automatizado e acompanhar\u00e1 a entrada e sa\u00edda de mercadorias em tempo real, registrando a quantidade de ingredientes dispon\u00edveis, al\u00e9m disso, o usu\u00e1rio poder\u00e1 analisar o hist\u00f3rico de entradas e sa\u00eddas, ajudando na programa\u00e7\u00e3o dos pr\u00f3ximos eventos.
Registro dos Eventos: Ser\u00e1 poss\u00edvel acessar informa\u00e7\u00f5es sobre eventos anteriores, como custos, lucros, quantidades de ingredientes usados, e n\u00famero de funcion\u00e1rios necess\u00e1rios.
Plataforma Responsiva: A plataforma ter\u00e1 a capacidade de ser utilizada em dispositivos m\u00f3veis, n\u00e3o sendo exclusiva para computadores. Qualquer usu\u00e1rio com um celular poder\u00e1 utiliz\u00e1-la.
"},{"location":"visao_produto/SolucaoProposta/#23-tecnologias-a-serem-utilizadas","title":"2.3 Tecnologias a Serem Utilizadas","text":""},{"location":"visao_produto/SolucaoProposta/#24-pesquisa-de-mercado-e-analise-competitiva","title":"2.4 Pesquisa de Mercado e An\u00e1lise Competitiva","text":"MarketMan
Pontos Fortes: Sistema robusto de controle de estoque e integra\u00e7\u00e3o com fornecedores, o que permite otimizar o gerenciamento de insumos e reduzir desperd\u00edcios. Ideal para neg\u00f3cios focados em reduzir custos operacionais.
Diferencia\u00e7\u00e3o da Nossa Solu\u00e7\u00e3o: Nossa solu\u00e7\u00e3o prioriza a facilidade de uso e a comunica\u00e7\u00e3o intuitiva com a cliente, oferecendo uma interface simplificada que atender\u00e1 especificamente \u00e0s necessidades de gest\u00e3o de eventos e adapta\u00e7\u00e3o r\u00e1pida do estoque conforme o tipo de evento.
Toast
Pontos Fortes: Plataforma completa para opera\u00e7\u00f5es de restaurantes, abrangendo vendas, estoque e relat\u00f3rios, com suporte para integra\u00e7\u00e3o de pedidos online e ferramentas de POS.
Diferencia\u00e7\u00e3o da Nossa Solu\u00e7\u00e3o: Ao inv\u00e9s de uma plataforma gen\u00e9rica e complexa, nossa solu\u00e7\u00e3o ser\u00e1 projetada especificamente para o Dida\u2019s Bistr\u00f4, oferecendo um sistema voltado para o fluxo financeiro e controle de mercadorias apenas para eventos, facilitando o planejamento financeiro e a usabilidade da cliente.
A solu\u00e7\u00e3o proposta \u00e9 divergente devido:
Nossa solu\u00e7\u00e3o tem como ponto principal uma curva de aprendizado iniciante, pois toda a plataforma ser\u00e1 feita com o intuito de ser o mais autoexplicativo o poss\u00edvel que atender\u00e1 especificamente \u00e0s necessidades de gest\u00e3o de eventos adaptando rapidamente o estoque conforme o tipo de evento.
Diferenciando das solu\u00e7\u00f5es apresentadas que por mais que est\u00e3o consolidadas no mercado, o produto \u00e9 projetado especificamente para o Dida's Bistr\u00f4, oferecendo um sistema voltado para gerenciar as entradas e sa\u00eddas de mercadorias e transa\u00e7\u00f5es financeiras. Por n\u00e3o exigir um hardware ou aparelho espec\u00edfico, tornaremos nosso produto a escolha ideal para o cliente, que ser\u00e1 necess\u00e1rio apenas um aparelho celular ou computador.
"},{"location":"visao_produto/SolucaoProposta/#25-analise-de-viabilidade","title":"2.5 An\u00e1lise de Viabilidade","text":"A viabilidade t\u00e9cnica do projeto \u00e9 alta, uma vez que boa parte da equipe de desenvolvimento possui experi\u00eancia nas tecnologias que ser\u00e3o utilizadas, como Python para o backend e Node.js e React.js para o frontend. Ser\u00e1 utilizado um sistema de gerenciamento de banco de dados relacional, o MySQL, que permitir\u00e1 armazenar, organizar e consultar grandes volumes de dados.
O projeto ser\u00e1 conduzido por meio de sprints divididas em ciclos quinzenais. Cada sprint ter\u00e1 entregas incrementais de funcionalidades, o que permitir\u00e1 valida\u00e7\u00f5es constantes por parte do cliente e ajustes r\u00e1pidos baseados no feedback do mesmo. O cronograma \u00e9 considerado vi\u00e1vel, dado que a equipe j\u00e1 teve contato com projetos semelhantes anteriormente e conta com os recursos tecnol\u00f3gicos necess\u00e1rios para realizar a integra\u00e7\u00e3o e implementa\u00e7\u00e3o das funcionalidades dentro do prazo estipulado.
Em termos de viabilidade financeira, o desenvolvimento do sistema \u00e9 totalmente sustent\u00e1vel, com custos alinhados aos recursos dispon\u00edveis para a equipe. Dessa forma, o cliente n\u00e3o enfrentar\u00e1 problemas futuros relacionados a custos extras, pois n\u00e3o depender\u00e1 de solu\u00e7\u00f5es externas. O Dida\u2019s Bistr\u00f4 contar\u00e1 com um sistema personalizado, garantindo maior controle e efici\u00eancia em todos os processos.
Do ponto de vista de mercado, a viabilidade \u00e9 favor\u00e1vel, pois h\u00e1 uma certa demanda por solu\u00e7\u00f5es de gest\u00e3o em pequenos estabelecimentos como o Dida's Bistr\u00f4. Com isso, ser\u00e1 poss\u00edvel atender ao cliente de forma eficaz, atendendo diretamente \u00e0s suas necessidades para gerir seu neg\u00f3cio.
"},{"location":"visao_produto/SolucaoProposta/#26-impacto-da-solucao","title":"2.6 Impacto da Solu\u00e7\u00e3o","text":"A solu\u00e7\u00e3o trar\u00e1 ao Dida\u2019s Bistr\u00f4 uma opera\u00e7\u00e3o mais eficiente e transparente. Ao otimizar o controle de estoque, o fluxo de caixa e o pagamento de funcion\u00e1rios, o sistema fortalecer\u00e1 a capacidade de o restaurante operar de forma rent\u00e1vel e bem-organizada. Esses benef\u00edcios permitir\u00e3o que o Dida\u2019s Bistr\u00f4 melhore sua efici\u00eancia operacional, reduza custos e adapte-se de maneira \u00e1gil aos diversos tipos de eventos que realiza, aumentando a lucratividade e assegurando uma gest\u00e3o mais tranquila e profissional.
Hist\u00f3rico de Revis\u00e3o
Data Vers\u00e3o Descri\u00e7\u00e3o Autor 08/11/2024 0.0 Cria\u00e7\u00e3o do documento Benjamim Lacerda 11/11/2024 0.1 Atualiza\u00e7\u00e3o do Documento Pedro Henrique 11/11/2024 1.0 Primeira vers\u00e3o do documento Benjamim Lacerda Santos, Iderlan Junio Cardoso da Silva, Mateus Henrique Queiroz Magalh\u00e3es Sousa, Pedro Gois Marques Monteiro, Pedro Henrique"},{"location":"visao_produto/VisaoProdutoProjeto/","title":"Vis\u00e3o do Produto e Projeto","text":""},{"location":"visao_produto/VisaoProdutoProjeto/#11-introducao-ao-negocio-e-contexto","title":"1.1 Introdu\u00e7\u00e3o ao Neg\u00f3cio e Contexto","text":"O Dida's Bistr\u00f4 \u00e9 um restaurante que realiza eventos privados, como festas e shows, com o objetivo de proporcionar experi\u00eancias gastron\u00f4micas para seus clientes. Com um card\u00e1pio variado, adapta suas op\u00e7\u00f5es conforme a ocasi\u00e3o. Al\u00e9m disso, o Dida's Bistr\u00f4 tamb\u00e9m atua como vendedor ambulante em shows e eventos em Bras\u00edlia.
Fundado em 2012, o neg\u00f3cio teve in\u00edcio com a venda de churros ambulante. Com o tempo, expandiu seu card\u00e1pio para incluir op\u00e7\u00f5es como hamb\u00farguer, cachorro-quente, churrasquinho e macarr\u00e3o. Hoje, o card\u00e1pio \u00e9 flex\u00edvel, permitindo que os pratos sejam ajustados conforme a demanda do evento.
A partir de 2016, o Dida's Bistr\u00f4 passou a organizar eventos privados, focando em festas juninas. Em 2022, recebeu o pr\u00eamio Sesc Comerci\u00e1rio Destaque, em reconhecimento pelas festas juninas realizadas nos Sesc de Bras\u00edlia.
"},{"location":"visao_produto/VisaoProdutoProjeto/#12-identificacao-da-oportunidade-ou-problema","title":"1.2 Identifica\u00e7\u00e3o da Oportunidade ou Problema","text":"O principal problema do Didas Bistr\u00f4 \u00e9 a perda de dados, causada pelo uso exclusivo de anota\u00e7\u00f5es em papel. Essas anota\u00e7\u00f5es s\u00e3o feitas por diferentes funcion\u00e1rios, sem qualquer padroniza\u00e7\u00e3o, e acabam se perdendo no meio de tantas informa\u00e7\u00f5es, seja durante ou ap\u00f3s os eventos. Al\u00e9m disso, \u00e9 dif\u00edcil armazen\u00e1-las de forma organizada, o que impede o acesso r\u00e1pido e eficiente aos dados de eventos anteriores.
Essa falta de informa\u00e7\u00f5es estruturadas afeta a tomada de decis\u00f5es, pois a equipe muitas vezes n\u00e3o sabe se vale a pena participar novamente de determinados eventos, quantos funcion\u00e1rios foram necess\u00e1rios, a quantidade de ingredientes utilizados ou at\u00e9 mesmo o total de vendas realizadas.
O problema tamb\u00e9m impacta a gest\u00e3o do estoque, j\u00e1 que frequentemente n\u00e3o h\u00e1 um controle preciso das quantidades dispon\u00edveis. Isso compromete o planejamento para eventos futuros, dificultando tanto a organiza\u00e7\u00e3o quanto a efici\u00eancia do neg\u00f3cio.
Segue abaixo um diagrama de Ishikawa sobre os problemas do cliente.
"},{"location":"visao_produto/VisaoProdutoProjeto/#13-desafios-do-projeto","title":"1.3 Desafios do Projeto","text":"O principal desafio t\u00e9cnico \u00e9 que o Didas Bistr\u00f4 atualmente n\u00e3o utiliza nenhum software para gerenciar seus processos. N\u00e3o h\u00e1 nenhum sistema existente que atenda aos requisitos espec\u00edficos do neg\u00f3cio. Por isso, ser\u00e1 necess\u00e1rio desenvolver uma solu\u00e7\u00e3o do zero, capaz de atender a todas as necessidades operacionais. Al\u00e9m disso, \u00e9 essencial que o software tenha uma interface intuitiva e de f\u00e1cil usabilidade, para que qualquer pessoa, independentemente de sua experi\u00eancia, consiga utiliz\u00e1-lo, j\u00e1 que, para cada evento, s\u00e3o contratados profissionais diferentes.
"},{"location":"visao_produto/VisaoProdutoProjeto/#14-segmentacao-de-clientes","title":"1.4 Segmenta\u00e7\u00e3o de Clientes","text":"O produto ser\u00e1 destinado a dona e aos funcion\u00e1rios da empresa, na qual podemos dividir em dois segmentos:
Idosos com mais de 60 anos: Usu\u00e1rios com poucas experi\u00eancias tecnol\u00f3gicas e que utilizam celular. Possuem a necessidade de um software com poucas intera\u00e7\u00f5es para realizar o seu objetivo.
Jovens adultos entre 20 e 30 anos: Usu\u00e1rios com experi\u00eancias tecnol\u00f3gicas em computadores e celulares. Capazes de utilizar o software sem dificuldades.
Hist\u00f3rico de Revis\u00e3o
Data Vers\u00e3o Descri\u00e7\u00e3o Autor 08/11/2024 0.0 Cria\u00e7\u00e3o do documento Benjamim Lacerda 11/11/2024 0.1 Atualiza\u00e7\u00e3o do Documento Pedro Henrique 11/11/2024 1.0 Primeira vers\u00e3o do documento Benjamim Lacerda Santos, Iderlan Junio Cardoso da Silva, Mateus Henrique Queiroz Magalh\u00e3es Sousa, Pedro Gois Marques Monteiro, Pedro Henrique"}]}
\ No newline at end of file
diff --git a/sitemap.xml.gz b/sitemap.xml.gz
index d7119ed..a38f69f 100644
Binary files a/sitemap.xml.gz and b/sitemap.xml.gz differ
diff --git a/visao_produto/BacklogdeProduto/index.html b/visao_produto/BacklogdeProduto/index.html
new file mode 100644
index 0000000..1b1e4e6
--- /dev/null
+++ b/visao_produto/BacklogdeProduto/index.html
@@ -0,0 +1,942 @@
+
+
+
+
+
+ BacklogdeProduto - 2024.2-T01-DidasBistro
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ BacklogdeProduto
+
+9.1 Backlog Geral
+Nosso backlog foi estruturado utilizando histórias de usuário para garantir clareza e foco nas necessidades do negócio e dos usuários finais. As histórias seguem um formato padronizado, começando pela identificação do ator (Como um(a): ), o objetivo (Eu quero: ) e o benefício esperado (Para que: ), assegurando que cada item esteja alinhado com o propósito do sistema. Além disso, cada história inclui critérios de aceitação bem definidos, que detalham os comportamentos esperados, como validações, respostas a falhas, e condições específicas de funcionamento. Esse padrão facilita a priorização, promove um entendimento comum entre os membros do time e stakeholders, e serve como base para validação durante o desenvolvimento, garantindo que as entregas atendam às expectativas de qualidade e funcionalidade.
+RF1 - Titulo: Realizar Login
+RF2 - Titulo: Cadastro de Produto
+RF3 - Título: Pesquisa de Produto
+RF4 - Título: Exclusão de Produto
+RF5 - Título: Atualização de Produto
+RF6 - Título: Ordenar produtos por quantidade
+RF7 - Título: Cadastro de Evento
+RF8 - Titulo: Cadastro de Gastos do evento
+RF9 -Título: Cadastro de Ganhos do Evento
+RF10 - Título: Gerar Relatório Referente aos Ganhos e Gastos do evento
+RF11 - Título: Pesquisar Eventos Passados
+RF12 - Título: Pesquisar Eventos Futuros
+RF13 - Título: Atualizar dados dos eventos
+RF14 - Título: Cadastro de Funcionário
+RF15 - Título: Excluir funcionário
+RF16 - Título: Atualizar dados dos funcionários
+RF17 - Título: Registro de Pagamento de funcionário
+RF18 - Título: Pesquisar Funcionário
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ DoR e DoD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ BACKLOG DO PRODUTO
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/visao_produto/DoReDoT/index.html b/visao_produto/DoReDoT/index.html
new file mode 100644
index 0000000..22cee2c
--- /dev/null
+++ b/visao_produto/DoReDoT/index.html
@@ -0,0 +1,782 @@
+
+
+
+
+
+ DoReDoT - 2024.2-T01-DidasBistro
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ DoReDoT
+
+8.1 Definition of Ready (DoR)
+Escolhemos os critérios de Definition of Ready (DoR) para garantir que o fluxo de trabalho seja eficiente e sem interrupções. Eles permitem que o time tenha uma compreensão clara e compartilhada das histórias ou tarefas antes de iniciar o desenvolvimento, evitando ambiguidades ou retrabalho. Esses critérios promovem uma comunicação mais eficiente entre os envolvidos, reduzem riscos e aumentam a previsibilidade das entregas.
+Nossas definições são:
+1-O requisito cabe em uma sprint?
+2-O requisito está representado por uma história de usuário?
+3-Os critérios de aceitação estão definidos (para ser possível um feedback)?
+4-A prototipação está pronta para o desenvolvimento.
+8.2 Definition of Done (DoD)
+Escolhemos os critérios de Definition of Done (DoD) para assegurar que as entregas atendam aos padrões de qualidade esperados e estejam verdadeiramente completas. Esses critérios ajudam a evitar entregas incompletas, reduzem o risco de erros em produção e promovem a confiança nas entregas do time, garantindo que os resultados estejam alinhados com as expectativas do projeto e dos stakeholders.
+Nossas definições são:
+1-Foram usadas boas praticas no codigo
+2-Comtempla os criterios de aceitação
+3-Gera um incremento no produto
+4-Se foi devidamente testada
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ DoR e DoD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ BACKLOG DO PRODUTO
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -772,8 +814,8 @@ 3.2 Quadro Comparativo
Foco em Arquitetura Arquitetura geralmente evolui durante o processo, com foco inicial na prototipagem.
-Menor foco em arquitetura no início; evolui conforme a necessidade ao longo do projeto.
+Arquitetura evolui durante o processo, com foco inicial na prototipagem.
+Não prescreve foco específico em arquitetura, a arquitetura evolui conforme as necessidades do projeto.
Forte ênfase no desenvolvimento orientado a uma arquitetura sólida e flexível desde o início do projeto.
@@ -802,13 +844,13 @@ 3.2 Quadro Comparativo
Qualidade Técnica Garantida pela rápida construção e teste de protótipos; ajustes são feitos conforme feedback.
+Garantida pela rápida construção e teste de protótipos, ajustes são feitos conforme feedback.
Alta ênfase na qualidade técnica, com práticas como TDD (Test-Driven Development), pair programming e integração contínua para garantir um código limpo e funcional.
Qualidade assegurada pela definição de arquitetura e validação incremental.
Práticas de Desenvolvimento Foco na prototipagem e validação rápida; menos práticas técnicas estruturadas.
+Foco na prototipagem e validação rápida, com menos práticas técnicas estruturadas.
Inclui práticas técnicas robustas como TDD, refatoração contínua, integração contínua e pair programming, promovendo alta qualidade no código.
Estrutura mais formal com foco em arquitetura e controle de progresso. Menos práticas técnicas específicas dentro do processo de desenvolvimento.
@@ -832,7 +874,7 @@ 3.2 Quadro Comparativo
Escalabilidade Escalável para projetos de pequena a média complexidade, em função da prototipagem rápida.
+Escalável para projetos de pequena a média escala, em projetos maiores, pode enfrentar desafios devido à sua natureza menos formal.
Escalável, mas mais indicado para equipes menores e médias devido à sua abordagem colaborativa e interativa constante.
Escalável para projetos maiores e mais complexos, com equipes médias a grandes.
diff --git a/visao_produto/InteracaoEquipeCliente/index.html b/visao_produto/InteracaoEquipeCliente/index.html
index 39d36db..bcfa399 100644
--- a/visao_produto/InteracaoEquipeCliente/index.html
+++ b/visao_produto/InteracaoEquipeCliente/index.html
@@ -16,7 +16,7 @@
+
+
+
+
+ DoR e DoD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ BACKLOG DO PRODUTO
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/visao_produto/LicoesAprendidas/index.html b/visao_produto/LicoesAprendidas/index.html
index a5036d0..36b9c58 100644
--- a/visao_produto/LicoesAprendidas/index.html
+++ b/visao_produto/LicoesAprendidas/index.html
@@ -16,7 +16,7 @@
+
+
+
+
+ DoR e DoD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ BACKLOG DO PRODUTO
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/visao_produto/ReferenciaBibliografica/index.html b/visao_produto/ReferenciaBibliografica/index.html
index 2e2a6ff..4807a6a 100644
--- a/visao_produto/ReferenciaBibliografica/index.html
+++ b/visao_produto/ReferenciaBibliografica/index.html
@@ -16,7 +16,7 @@
+
+
+
+
+ DoR e DoD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ BACKLOG DO PRODUTO
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -658,10 +700,10 @@ Referências Bibliográficas
Rapid application development model (RAD) – Software Engineering. GeeksforGeeks, 2024. Disponível em: Rapid application development model (RAD) – Software Engineering
-RAJA, Gupta. Fundamentals of Software Engineering. Engineering Handbook. 2019.
+MARSICANO, George. Slides da matéria Requisitos. 2024.
-MARSICANO, George. Slides da matéria Requisitos. 2024.
+Schwaber, K., & Sutherland, J. (n.d.). Scrum Guides. 2024. Disponível em : https://scrumguides.org/
Histórico de Revisão
diff --git a/visao_produto/SolucaoProposta/index.html b/visao_produto/SolucaoProposta/index.html
index 5419b46..06450b1 100644
--- a/visao_produto/SolucaoProposta/index.html
+++ b/visao_produto/SolucaoProposta/index.html
@@ -16,7 +16,7 @@
+
+
+
+
+ DoR e DoD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ BACKLOG DO PRODUTO
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/visao_produto/VisaoProdutoProjeto/index.html b/visao_produto/VisaoProdutoProjeto/index.html
index 49e23a6..f273af8 100644
--- a/visao_produto/VisaoProdutoProjeto/index.html
+++ b/visao_produto/VisaoProdutoProjeto/index.html
@@ -16,7 +16,7 @@
+
+
+
+
+ DoR e DoD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ BACKLOG DO PRODUTO
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -776,8 +818,9 @@ 1.1 Introdução ao Negóci
Fundado em 2012, o negócio teve início com a venda de churros ambulante. Com o tempo, expandiu seu cardápio para incluir opções como hambúrguer, cachorro-quente, churrasquinho e macarrão. Hoje, o cardápio é flexível, permitindo que os pratos sejam ajustados conforme a demanda do evento.
A partir de 2016, o Dida's Bistrô passou a organizar eventos privados, focando em festas juninas. Em 2022, recebeu o prêmio Sesc Comerciário Destaque, em reconhecimento pelas festas juninas realizadas nos Sesc de Brasília.
1.2 Identificação da Oportunidade ou Problema
-O principal problema do Didas Bistrô é a perda ou má interpretação dos dados, o que é causado pelo uso exclusivo de papel para registro e controle. Isso dificulta o planejamento do negócio, já que, muitas vezes, a equipe não tem acesso a informações cruciais sobre eventos passados, como lucro, número de funcionários necessários e quantidade de ingredientes utilizados. Como resultado, a contabilidade fica comprometida, dificultando a análise de gastos, faturamento e lucro de cada evento. Além disso, a falta de registros adequados prejudica o planejamento futuro, pois não é possível avaliar se vale a pena repetir determinados eventos, já que os dados históricos estão frequentemente perdidos ou inacessíveis.
-A falta de um sistema de gerenciamento de estoque também é um problema significativo. Muitas vezes, a equipe do Didas Bistrô não tem controle preciso sobre o gasto com ingredientes estocados, o que dificulta o planejamento para os eventos. Além disso, a falta de um acompanhamento adequado impede que saibam exatamente a quantidade de cada produto disponível, tornando o processo de compra e organização ineficiente e aumentando o risco de desperdício ou falta de insumos durante os eventos.
+O principal problema do Didas Bistrô é a perda de dados, causada pelo uso exclusivo de anotações em papel. Essas anotações são feitas por diferentes funcionários, sem qualquer padronização, e acabam se perdendo no meio de tantas informações, seja durante ou após os eventos. Além disso, é difícil armazená-las de forma organizada, o que impede o acesso rápido e eficiente aos dados de eventos anteriores.
+Essa falta de informações estruturadas afeta a tomada de decisões, pois a equipe muitas vezes não sabe se vale a pena participar novamente de determinados eventos, quantos funcionários foram necessários, a quantidade de ingredientes utilizados ou até mesmo o total de vendas realizadas.
+O problema também impacta a gestão do estoque, já que frequentemente não há um controle preciso das quantidades disponíveis. Isso compromete o planejamento para eventos futuros, dificultando tanto a organização quanto a eficiência do negócio.
Segue abaixo um diagrama de Ishikawa sobre os problemas do cliente.
1.3 Desafios do Projeto
