Merge pull request #13 from mdsreq-fga-unb/10-adicionando-novos-tópic…

…os-para-a-entrega-2

10 adicionando novos tópicos para a entrega 2

docs/Entregas/Entrega2.md

@@ -0,0 +1 @@
+# Apresentação Unidade 2

docs/FasesOpenUP/Concepcao.md

@@ -0,0 +1,102 @@
+# Concepção
+
+A fase de Concepção do projeto foi fundamental para estabelecer a base e os direcionamentos necessários para o desenvolvimento contínuo. Nessa fase, foram realizados os seguintes marcos importantes:
+
+## Planejamento do Projeto
+A equipe estabeleceu os objetivos, cronograma e recursos necessários para o desenvolvimento do projeto. A definição das etapas e marcos foi fundamental para garantir um alinhamento contínuo durante todo o ciclo de vida do projeto.
+
+## Definição do Escopo
+O escopo do projeto foi detalhadamente definido, incluindo as funcionalidades principais, as necessidades do cliente e os resultados esperados. Isso ajudou a garantir que o time tivesse clareza sobre as entregas e a visão do produto.
+
+## Decisão dos Cargos
+Atribuição dos papéis e responsabilidades dentro da equipe, garantindo a organização e fluidez do processo de desenvolvimento, com a definição dos membros chave para as funções: 
+
+- Gerente de Projeto: Manoela.
+- Desenvolvedor FrontEnd: Alexandre, com participação da Manoela.
+- Desenvolvedor BackEnd: Enrico, com participação do Kaio e Pedro Henrique.
+- Desenvolvedor CI/CD / Testes: Gustavo.
+- Analista de Requisitos: Pedro Henrique, com a participação de toda a equipe.
+
+## Organização da Documentação
+A documentação do projeto foi organizada de forma estruturada, incluindo todos os arquivos e artefatos necessários. Isso facilitou o acompanhamento do progresso do projeto.
+
+## Capacitações
+Realização de sessões de capacitação para garantir que todos os membros da equipe estivessem atualizados e capacitados nas tecnologias, ferramentas e metodologias que seriam utilizadas durante o projeto.
+
+## Definição do MVP
+O MVP foi definido, contendo as funcionalidades essenciais necessárias para que o produto fosse lançado e pudesse ser utilizado pelos primeiros usuários. Maior detalhamento pode ser encontrado na Visão de Produto e Projeto, na aba Backlog do Produto.
+
+<center>
+![mvp](../assets/imgs/mvp.png)
+Autores: [Alexandre Júnior](https://github.com/AlexandreLJr), [Gustavo Haubert](https://github.com/GustavoHaubert), [Manoela Garcia](https://github.com/manu-sgc)
+</center>
+
+## Definição do DoR e DoD
+O DoR foi estabelecido, garantindo que cada item do backlog estivesse claramente definido, sem ambiguidades, e pronto para ser trabalhado pela equipe, com todos os critérios de aceitação e requisitos alinhados.
+O DoD foi estabelecido para garantir que as funcionalidades entregues estivessem completas e atendendo a todos os critérios de qualidade acordados, como testes unitários, integração e validação com os stakeholders.
+Maior detalhamento de ambos pode ser encontrado na Visão de Produto e Projeto, na aba DoR e DoD.
+
+## Declaração de Requisitos Funcionais e Não Funcionais
+Foram definidos os requisitos funcionais e não funcionais, abordando tanto as funcionalidades do sistema quanto as qualidades que ele deve possuir para garantir um produto de alta qualidade e que atenda às necessidades dos usuários. Maior detalhamento pode ser encontrado na Visão de Produto e Projeto, na aba Requisitos de Software.
+
+## User Story
+User Stories foram criadas para representar as funcionalidades do sistema de forma clara e objetiva, ajudando a equipe a entender as necessidades do cliente. A priorização e maior detalhamento pode ser encontrado na Visão de Produto e Projeto, na aba Backlog do Produto.
+
+**US01** - Como cliente, quero me cadastrar no sistema para poder agendar serviços para meus pets.
+
+**US02** - Como cliente, quero cadastrar meus pets com informações como nome, idade e raça, para facilitar a escolha dos serviços mais adequados.
+
+**US03** - Como cliente, quero agendar serviços de banho e tosa para meus pets, especificando detalhes como o tipo de tosa desejada, para garantir que recebam os cuidados necessários.
+
+**US04** - Como cliente, quero visualizar os horários disponíveis para agendamentos, para escolher o momento mais conveniente para mim e para meus pets.
+
+**US05** - Como cliente, quero cancelar ou reagendar serviços com antecedência, caso surjam imprevistos, para evitar transtornos.
+
+**US06** - Como cliente, quero consultar o histórico dos serviços realizados para meus pets, para acompanhar os cuidados prestados e os custos envolvidos.
+
+**US07** - Como cliente, quero acessar o Instagram do pet shop pelo sistema, para acompanhar novidades e promoções.
+
+**US08** - Como cliente, quero enviar fotos do meu pet ao sistema, para usar como referência em pedidos de tosa personalizada ou para ter salvo em seu cadastro.
+
+**US09** - Como cliente, quero avaliar os serviços prestados com uma nota e comentários, para ajudar a melhorar a qualidade do atendimento.
+
+**US10** - Como administrador, quero visualizar e analisar as avaliações fornecidas pelos clientes, para identificar melhorias nos serviços oferecidos.
+
+**US11** - Como administrador, quero acessar os dados cadastrais dos clientes, para entrar em contato com eles e atender melhor suas demandas.
+
+**US12** - Como administrador, quero visualizar informações detalhadas sobre os pets dos clientes, para oferecer um atendimento de qualidade.
+
+**US13** - Como funcionário, quero vizualizar as informações dos pets cadastrados, como nome, idade, raça e nome do dono, para prestar os serviços com mais eficiência.
+
+**US14** - Como administrador, quero ajustar os preços dos serviços sempre que necessário, para acompanhar custos e promoções.
+
+**US15** - Como administrador, quero acessar um calendário com todos os agendamentos organizados por data e horário, para gerenciar melhor os atendimentos.
+
+**US16** - Como administrador, quero mover ou reagendar horários no calendário, para acomodar ajustes necessários nos atendimentos.
+
+**US17** - Como administrador, quero cancelar agendamentos quando preciso, notificando os clientes de forma clara e imediata, para liberar a agenda quando não for possível receber o pet.
+
+**US18** - Como funcionário, quero acessar o calendário com os agendamentos do dia organizados por horário, para gerenciar melhor o fluxo de trabalho e atender os clientes conforme programado.
+
+**US19** - Como administrador, quero acessar relatórios financeiros detalhados, para entender melhor os lucros e despesas do pet shop.
+
+## Regras de Negócio
+As regras de negócio foram estabelecidas, descrevendo as condições, processos e lógicas essenciais que o sistema deve seguir para garantir que os objetivos de negócio sejam atendidos corretamente.
+
+1. Um cliente pode cadastrar múltiplos pets, mas cada pet deve ter informações como nome, idade, raça e tamanho obrigatoriamente preenchidas.
+
+2. Raça e tamanho dos pets influenciam na escolha dos serviços e preços.
+
+3. Clientes podem cancelar ou reagendar um serviço até 24 horas antes do horário marcado sem penalidades.
+
+4. O administrador pode cancelar agendamentos, mas precisa notificar os clientes com antecedência de 2 horas.
+
+5. Serviços agendados devem ser organizados por ordem cronológica no calendário.
+
+6. Dias e horários de atendimento devem ser configuráveis pelo administrador (ex.: feriados, dias sem expediente).
+
+7. O sistema deve gerar relatórios financeiros detalhados (ex.: lucro mensal, serviços mais solicitados) com base nos agendamentos concluídos.
+
+8. Clientes podem avaliar os serviços prestados apenas após a conclusão do atendimento.
+
+9. Notas e comentários de avaliação devem estar vinculados ao agendamento específico e visíveis apenas para o administrador.

docs/FasesOpenUP/Construcao.md

@@ -0,0 +1,16 @@
+# Construção
+A Fase de Construção é o momento em que o sistema começa a tomar forma através do desenvolvimento de código, integração de componentes e validação com os stakeholders. As principais atividades planejadas para essa fase incluem:
+
+## Desenvolvimento do Código
+- Implementação do banco de dados, estruturando tabelas, relacionamentos e otimizando consultas para atender aos requisitos funcionais e não funcionais.
+- Desenvolvimento do backend utilizando Java e o framework Spring Boot, garantindo o funcionamento dos serviços, regras de negócio e integração com o banco de dados.
+- Construção do frontend, seguindo o design aprovado no protótipo do Figma e garantindo a responsividade e usabilidade do sistema.
+
+## Testes
+- Realização de testes unitários para validar as funcionalidades individuais do backend e do frontend.
+- Execução de testes de integração, verificando a comunicação entre os módulos e componentes do sistema.
+- Aplicação de testes de usabilidade para garantir que a interface do usuário esteja clara, funcional e eficiente.
+
+## Validação com o Cliente
+- Apresentação de versões intermediárias do sistema ao cliente, com o objetivo de validar as funcionalidades implementadas, ajustar detalhes e obter feedback.
+- Garantia de que as entregas atendam aos critérios de aceite definidos no DoR e no DoD, priorizando a satisfação do cliente.

docs/FasesOpenUP/Elaboracao.md

@@ -0,0 +1,96 @@
+# Elaboração
+Na fase de Elaboração, a equipe focou em desenvolver as funcionalidades e validar a arquitetura, enquanto continuava a capacitação da equipe e a análise de riscos para garantir a entrega de um produto de alta qualidade. Os marcos cumpridos nessa fase foram:
+
+## Capacitações
+Capacitações contínuas foram realizadas com foco nas tecnologias utilizadas no projeto, garantindo que a equipe estivesse atualizada e equipada para lidar com as necessidades de desenvolvimento, como o uso do Spring Boot, Java, e outras ferramentas necessárias para o backend e frontend.
+
+## Prototipagem
+Protótipos interativos foram desenvolvidos no **Figma**, permitindo que a equipe visualizasse e testasse o fluxo de navegação do sistema e a experiência do usuário antes da implementação. Isso facilitou a comunicação com o cliente, ajudando a validar o design e as funcionalidades propostas.
+
+[Link do figma](https://www.figma.com/design/35bsz8P6wMWnZAo6fzlmDj/Prot%C3%B3tipo---pet-shop-guar%C3%A1?node-id=0-1&t=WOYEH2ExE34RqevI-1)
+
+## Análise de Riscos
+A análise de riscos foi realizada para identificar possíveis obstáculos no desenvolvimento, como desafios técnicos, limitações de recursos, e riscos de mercado. A equipe definiu estratégias de mitigação para lidar com os riscos identificados, minimizando a chance de imprevistos durante as fases seguintes do desenvolvimento.
+
+**1. Riscos Técnicos**
+
+| **Risco**                             | **Probabilidade** | **Impacto**  | **Mitigação**                                  |
+|---------------------------------------|-------------------|--------------|------------------------------------------------|
+| Falhas na integração entre o sistema de agendamento e o backend | Média             | Alta         | Realizar testes contínuos durante o desenvolvimento e usar ferramentas confiáveis para integração. |
+| Lentidão no sistema devido ao volume de agendamentos | Baixa             | Média        | Monitorar desempenho e otimizar consultas ao banco de dados. |
+| Dificuldades no acesso ao sistema por dispositivos móveis | Média             | Alta         | Implementar design responsivo e realizar testes em diferentes dispositivos. |
+| Erros no cálculo de receitas mensais | Alta              | Alta         | Validar o cálculo financeiro com casos de teste e revisão pelo cliente. |
+
+**2. Riscos Humanos**
+
+| **Risco**                             | **Probabilidade** | **Impacto**  | **Mitigação**                                  |
+|---------------------------------------|-------------------|--------------|------------------------------------------------|
+| Falta de engajamento do cliente no acompanhamento do projeto | Média             | Alta         | Agendar reuniões e manter comunicação clara sobre o progresso e decisões importantes. |
+| Falta de habilidade técnica em alguma área crítica (ex.: backend ou design) | Média             | Alta         | Fazer treinamentos rápidos e capacitações. |
+
+**3. Riscos de Requisitos**
+
+| **Risco**                             | **Probabilidade** | **Impacto**  | **Mitigação**                                  |
+|---------------------------------------|-------------------|--------------|------------------------------------------------|
+| Alteração nos requisitos após o início do desenvolvimento | Média              | Alta         | Usar ciclos curtos de desenvolvimento (ex.: Sprints) e validar funcionalidades com o cliente. |
+| Requisitos incompletos ou mal definidos | Média             | Alta         | Realizar sessões detalhadas de levantamento e revisão dos requisitos. |
+
+**4. Riscos de Cronograma**
+
+| **Risco**                             | **Probabilidade** | **Impacto**  | **Mitigação**                                  |
+|---------------------------------------|-------------------|--------------|------------------------------------------------|
+| Atraso na entrega do MVP | Média             | Alta         | Estabelecer prazos realistas e priorizar funcionalidades essenciais para o MVP. |
+| Sobrecarga de tarefas na equipe | Alta              | Média        | Dividir as tarefas igualmente e evitar escopo excessivo. |
+
+**5. Riscos de Negócio**
+
+| **Risco**                             | **Probabilidade** | **Impacto**  | **Mitigação**                                  |
+|---------------------------------------|-------------------|--------------|------------------------------------------------|
+| Falta de aceitação do sistema pelos usuários (dono e clientes do pet shop) | Média             | Alta         | Incluir o cliente nas decisões de design e realizar testes com usuários finais antes do lançamento. |
+| O sistema não atender totalmente às expectativas do cliente | Média             | Alta         | Recolher feedback e ajustar o escopo quando necessário. |
+
+**Plano de Monitoramento de Riscos**
+
+1. **Periodicidade**: Revisar os riscos a cada Sprint ou semanalmente.
+2. **Indicadores**:  
+
+    - Taxa de erros no sistema durante os testes.  
+    - Adesão do cliente às reuniões.  
+    - Progresso das tarefas no cronograma.
+
+
+## Arquitetura
+
+O projeto adota uma arquitetura em camadas, com o frontend em React.js, o backend em Spring Boot com PostgreSQL e a comunicação entre eles feita por meio de uma API RESTful.  Essa estrutura proporciona maior organização, manutenibilidade e escalabilidade.
+
+<center>
+![Arquitetura em Camadas](../assets/imgs/Arquitetura.jpg)
+Autores: [Pedro Henrique Fernandino](https://github.com/PedroHenrique061),  [Kaio Enzo Salgado](https://github.com/kaioenzo), [Enrico  Zoratto](https://github.com/sidts)
+</center>
+
+
+**Frontend (React.js - Camada de Apresentação):**
+
+A camada de apresentação, construída com React.js, é responsável por interagir diretamente com o usuário.  Ela lida com a interface, exibindo informações e capturando as ações do usuário.  O React.js, com sua estrutura baseada em componentes, facilita a criação de interfaces dinâmicas e reutilizáveis.
+
+**Backend (Spring Boot com PostgreSQL - Camadas de Negócio e Dados):**
+
+O backend é dividido em duas camadas principais:
+
+* **Camada de Negócio (Spring Boot):**  Esta camada contém a lógica de negócios da aplicação, processando as requisições do frontend, aplicando regras de negócio e gerenciando as interações com a camada de dados.
+
+* **Camada de Dados (PostgreSQL):**  Responsável pelo armazenamento e recuperação dos dados da aplicação. O PostgreSQL, um sistema de gerenciamento de banco de dados relacional. A camada de negócio interage com a camada de dados por meio de abstrações, permitindo que o banco de dados seja alterado sem impactar a lógica de negócios.
+
+**Comunicação (API REST - Camada de Integração):**
+
+A API REST atua como uma camada de integração entre o frontend e o backend. Ela define um conjunto de endpoints que o frontend pode acessar para interagir com a aplicação.
+
+**Infraestrutura(AWS, Vercel, GitHub Actions):**
+
+O backend e o banco de dados é hospedado na AWS (Amazon Web Services), enquanto o frontend é hospedado na Vercel. A integração contínua e a entrega contínua (CI/CD) são realizadas por meio do GitHub Actions.
+
+## Histórico de Revisão - Arquitetura
+
+| Data       | Versão | Descrição                                             | Autor      |
+|------------|--------|-------------------------------------------------------|------------|
+| 29/10/2024 | 1.0    | Criação do documento | Kaio Enzo    |

docs/FasesOpenUP/Transicao.md

@@ -0,0 +1,12 @@
+# Transição
+A Fase de Transição é dedicada à entrega final do sistema, garantindo que ele esteja pronto para uso pelo cliente. Nesta etapa, o foco principal é a disponibilização do produto em ambiente de produção e a validação final com o cliente por meio de demonstrações e ajustes, se necessários.
+
+## Hospedagem
+- Configuração do ambiente de produção para hospedagem do sistema.
+- Implantação do sistema em um servidor ou serviço de hospedagem apropriado, garantindo acessibilidade ao cliente e usuários finais, no caso Vercel.
+- Testes finais em ambiente de produção para verificar a funcionalidade, desempenho e segurança do sistema.
+
+## Walkthrough
+- Realização de um walkthrough detalhado com o cliente, apresentando todas as funcionalidades do sistema.
+- Demonstração de como cada funcionalidade atende aos requisitos estabelecidos durante a concepção e construção.
+- Recolhimento de feedback do cliente para pequenos ajustes ou melhorias necessárias antes da entrega oficial.

docs/Unidades/Unidade2.md

@@ -0,0 +1 @@
+# Lições Aprendidas na Unidade 2