diff --git a/docs/documentoVisao.md b/docs/documentoVisao.md index 58bfc0e..4c2189c 100644 --- a/docs/documentoVisao.md +++ b/docs/documentoVisao.md @@ -2,9 +2,9 @@ | **Data** | **Versão** | **Descrição** | **Autor** | | ---------- | ---------- | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | -| 08/04/2024 | 1\.0 | Criação do documento | Carlos Eduardo; Eric Rabelo; Paulo Henrique; Samara Letícia; Sunamita Vitória; Wolfgang Stein | -| 16/04/2024 | 2\.0 | Preenchendo seções de visão geral do projeto e de lições aprendidas| Eric Rabelo; Paulo Henrique; Wolfgang Stein | -| 17/04/2024 | 2\.1 | Criação do Gerenciamento de Riscos e planejamento das fases e/ou Iterações do Projeto, critérios de replanejamento, lições aprendidas e material sobre processos ESW | Carlos Eduardo; Júlia Takaki; Samara Letícia, Paulo Henrique, Suanmita Vitória, Eric Rabelo| Wolfgang Stein +| 08/04/2024 | 1\.0 | Criação do documento | Carlos Eduardo; Eric Rabelo; Paulo Henrique; Samara Letícia; Sunamita Vitória; Wolfgang Friedrich | +| 16/04/2024 | 2\.0 | Preenchendo seções de visão geral do projeto e de lições aprendidas| Eric Rabelo; Paulo Henrique; Wolfgang Friedrich | +| 17/04/2024 | 2\.1 | Criação do Gerenciamento de Riscos e planejamento das fases e/ou Iterações do Projeto, critérios de replanejamento, lições aprendidas e material sobre processos ESW | Carlos Eduardo; Júlia Takaki; Samara Letícia, Paulo Henrique, Suanmita Vitória, Eric Rabelo| ## 1. **Visão do Produto e Projeto** @@ -17,9 +17,6 @@ Foi identificado que o cliente está utilizando planilhas e, por vezes, até pap
Imagem 1 - Diagrama de Ishikawa
- -- **Solução de Software Proposta**: Nosso software representa uma aplicação web que oferece uma abordagem prática e em tempo real para pesquisar e avaliar os professores da FGA. A proposta nasce em um contexto de ineficácia da avaliação e consulta de outras avaliações dos docentes da FGA, como pode ser contemplado no diagrama de ishikawa acima. O propósito central desta ferramenta é criar um ambiente seguroe anônimo onde estudantes, tanto novos quanto veteranos, possam compartilhar suas opiniões sobre os professores e as disciplinas ministradas na Faculdade do Gama (FGA). - ### 1.2 **Declaração de Posição do Produto** Tabela 1 - Visão do Produto @@ -66,7 +63,6 @@ Tabela 3 – Planejamento e Sprint | **_Sprint_**|**_Produto (entrega)_**|**_Data Inicio_**|**_Data Fim_** |**_Entregaveis_** |**_Responsáveis_**|**_Conclusão_**| |-|-|-|-|-|-|-| -| | | | | | | | |Sprint 0 | Definição do projeto.| 01/04| 08/04 | Escolha do tema e definição do escopo do projeto.| TODOS | 100% | |Sprint 1 |Revisão dos fundamentos de Engenharia de Software. |08/04 |15/04 | Apresentação sobre os processos e fundamentos de engenharia de software |TODOS | 100% | |Sprint 2 | Definição do processo de ER.|15/04 |22/04 | Visão do produto e projeto |TODOS | | @@ -121,7 +117,7 @@ Tabela 4 – Comunicação do grupo ![Diagrama de Processo de Desinvolvimento de Software](images/diagramaProcesso.png){width=1000} -Imagem 2 - Diagrama de Processo de Desinvolvimento de Software
+Imagem 2 - Diagrama de Processo de Desenvolvimento de Software
Tabela 4 – Comunicação do grupo @@ -147,6 +143,4 @@ Durante a reunião com o cliente, houve um erro na forma que abordamos o cliente ## 5.0 **Referências Bibliográficas** -PMI - PROJECT MANAGEMENT INSTITUTE. Guia PMBOK®: Um Guia do Conhecimento em Gerenciamento de Projetos. 6. ed. Newtown Square, Pensilvânia: PMI, 2017. - Audy, Jorge. Scrum 360: Um guia completo e prático de agilidade. São Paulo: Casa do Código, 2015. diff --git a/site/404.html b/site/404.html deleted file mode 100644 index 23d49bb..0000000 --- a/site/404.html +++ /dev/null @@ -1,389 +0,0 @@ - - - - - - - - - - - - - - - - - - -Esse markdown serve para verificar como contribuir
-O modelo que vamos seguir se baseia em duas branches principais, a "main" e "development", além das ramificações secundárias para features ou correções de bugs. Essa estrutura torna mais claro o ciclo de vida do desenvolvimento, desde a criação de novas funcionalidades até a implantação de versões estáveis.
-Primeiramente, cada nova mudança deve ser desenvolvida em uma branch exclusiva, o que facilita o gerenciamento de mudanças e a colaboração da equipe.
-Uma vez que a mudança está pronta para ser incorporada ao projeto, um "Merge Request" (MR) deve ser aberto para a branch "development". Isso permite que a equipe revise a alteração, compartilhe feedback e assegure a aderência aos padrões de qualidade e ao objetivo do projeto.
-Após a aprovação e testes bem-sucedidos em um ambiente de teste ou "stage", a alteração está pronta para ser mesclada na branch "development". Somente após ter sido testada e aprovada nesse ambiente que um commit de "development" para "main" deve ser realizado. Essa abordagem ajuda a manter a branch "main" como uma representação estável e confiável do código do projeto, garantindo que apenas as alterações devidamente validadas sejam incorporadas à versão principal.
-A nomeclatura de branches que segue o padrão "tipo-da-mudança/descrição" é uma abordagem estruturada e informativa para gerenciar branches em repositórios de controle de versão, especialmente no contexto de commits convencionais. Essa convenção de nomenclatura utiliza tokens derivados dos tipos de mudanças definidos no padrão de commits convencionais para categorizar as branches de forma clara e compreensível.
-A estrutura "tipo-da-mudança/nome-descritivo" pode ser desdobrada da seguinte maneira:
-Tipo da Mudança (Token): O tipo da mudança é um token que descreve a natureza da alteração que está sendo realizada na branch. Esses tokens são extraídos dos tipos descritos no Conventional Commits, e estão descritos na seção Politica de Commits.
descrição: É uma breve descrição que esclarece o propósito da branch de forma clara e concisa. Deve explicar o que está sendo desenvolvido na branch, para que outras pessoas da equipe possam entender facilmente a sua finalidade.
-Por exemplo, se você estiver criando uma branch para adicionar um novo recurso de pesquisa em um projeto de software, a nomeclatura pode seguir o formato "feat/relatorio-mobilizacao" ou "feat/busca." Isso torna evidente que a branch se destina à implementação de um novo recurso de pesquisa.
-A nossa política de commits adota o padrão Conventional Commits como diretriz fundamental para o registro de alterações no nosso código. Este padrão incentiva a clareza e consistência nas mensagens de commit, facilitando a compreensão e rastreamento das mudanças ao longo do tempo.
-Padrão de commit
-Exemplo:
-docs(dag-notificacao-proposta): documentação inicial da dag de envio de mensagem de novas propostas.
-
-No sufixo, deve estar em parentese aonde que está sendo feita a mudança, seguido de dois pontos e sua mensagem.
-Para manter a qualidade do código, adotamos uma série de medidas automatizadas e de padrão de código.
-- ***Justificativa:*** Incorporar testes unitários e análise estática com o MyPy é crucial para assegurar a robustez do código. O MyPy, ao realizar verificações estáticas de tipo, ajuda a identificar potenciais bugs antes que o código entre em produção, aumentando a confiança na qualidade do software.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-