+
+
+
+
+
diff --git a/_sidebar.md b/_sidebar.md
new file mode 100644
index 0000000..79234be
--- /dev/null
+++ b/_sidebar.md
@@ -0,0 +1,91 @@
+
+
+- [Home](/)
+- [Políticas](/docs/Policies/Policies.md)
+
+- **Produto**
+ - [Documento de Visão](/docs/Product/VisionDocument.md)
+
+- **Definação de Tema**
+ - [Questionário](/docs/Product/Questionary.md)
+ - [Entrevistas](/docs/Project/Interview.md)
+
+- **Definição de Escopo**
+ - [**Design Sprint**](/docs/Product/DesignSprint/DesignSprint.md)
+ - [Brainstorming](/docs/Product/DesignSprint/Brainstorming.md)
+ - [Rich Picture](/docs/Product/DesignSprint/RichPicture.md)
+ - [StoryBoard](/docs/Product/DesignSprint/StoryBoard.md)
+ - [Protótipo de Alta Fidelidade](/docs/Product/DesignSprint/HighFidelityPrototype.md)
+ - [Mapa Mental](/docs/Product/MindMap.md)
+ - [5W2H](/docs/Product/5W2H.md)
+ - [Diagrama de Ishikawa](/docs/Product/IshikawaDiagram.md)
+ - [Léxicos](/docs/Product/Lexicons.md)
+ - [Matriz de Relações](/docs/Product/RelationsMatrix.md)
+
+- **Definição de Metodologia**
+ - [Metodologia](/docs/Product/Methodology.md)
+ - [BPMN](/docs/Product/BPMN.md)
+
+- **Projeto**
+ - [Backlog](/docs/Project/ProductBacklog.md)
+ - [Priorização](/docs/Project/BacklogPrioritization)
+ - [Plano de Gerenciamento de Riscos](/docs/Project/RiskManagementPlan.md)
+ - [Plano de Gerenciamento de Custos](/docs/Project/CostManagementPlan.md)
+ - [Plano de Comunicação](/docs/Project/CommunicationManagementPlan.md)
+ - [Documento de Arquitetura](/docs/Project/ArchitectureDocument.md)
+ - [Reutilização de Software](/docs/Project/SoftwareReuse.md)
+
+- **Modelagem**
+ - [Diagrama de Entidade Relacionamento](/docs/Modeling/DatabaseModeling.md)
+ - [Diagrama de Pacotes](/docs/Modeling/PackageDiagram.md)
+ - [Diagrama de Classes](/docs/Modeling/ClassDiagram.md)
+ - [Diagrama de Componentes](/docs/Modeling/ComponentsDiagram.md)
+ - [Diagrama de Sequência](/docs/Modeling/SequenceDiagram.md)
+ - [Diagrama de Atividades](/docs/Modeling/ActivityDiagram.md)
+ - [Diagrama de Colaboração](/docs/Modeling/ColaborationDiagram.md)
+ - [Diagrama de Estados](/docs/Modeling/StateDiagram.md)
+
+- **Estudos**
+ - [Estudo sobre GRASP's](/docs/Studies/GRASP.md)
+ - [Estudo sobre GoFs Estruturais](/docs/Studies/StructuralGofs.md)
+ - [Estudo sobre GoFs Comportamentais](/docs/Studies/BehaviorGoF.md)
+ - [Estudo sobre GoFs Criacionais](/docs/Studies/CreationalGoF.md)
+ - [Estudo sobre Padrões de Projeto Emergentes](/docs/Studies/EmergingDesignPatterns.md)
+ - [Dojo de Flutter](/docs/Studies/DojoFlutter.md)
+
+- **Padrões de Projeto**
+ - [GRASP(s)](/docs/DesignPatterns/GRASP.md)
+ - [GoF(s) Estruturais](/docs/DesignPatterns/StructuralGoFs.md)
+ - [GoF(s) Comportamentais](/docs/DesignPatterns/BehaviorGoFs.md)
+ - [GoF(s) Criacionais](/docs/DesignPatterns/CreationalGoFs.md)
+
+- [**Sprints e Reuniões**](/docs/SprintsAndMeetings/SprintsAndMeetings.md)
+ - [2020-08-21 - Técnicas Elicitação de Requisitos e Tecnologias](/docs/SprintsAndMeetings/2020-08-21-RequirementsElicitationTechniquesAndTechnologies.md)
+ - [2020-08-24 - Abertura da Sprint 0](/docs/SprintsAndMeetings/2020-08-24-Sprint0Opening.md)
+ - [2020-08-29 - Fechamento da Sprint 0](/docs/SprintsAndMeetings/2020-08-29-Sprint0Closure.md)
+ - [2020-08-29 - Abertura da Sprint 1](/docs/SprintsAndMeetings/2020-08-29-Sprint1Opening.md)
+ - [2020-09-02 - Design Sprint e Metodologia](/docs/SprintsAndMeetings/2020-09-02-DesignSprintAndMethodology.md)
+ - [2020-09-05 - Fechamento da Sprint 1](/docs/SprintsAndMeetings/2020-09-05-Sprint1Closure.md)
+ - [2020-09-05 - Abertura da Sprint 2](/docs/SprintsAndMeetings/2020-09-05-Sprint2Opening.md)
+ - [2020-09-12 - Fechamento da Sprint 2](/docs/SprintsAndMeetings/2020-09-12-Sprint2Closure.md)
+ - [2020-09-12 - Abertura da Sprint 3](/docs/SprintsAndMeetings/2020-09-12-Sprint3Opening.md)
+ - [2020-09-19 - Fechamento da Sprint 3](/docs/SprintsAndMeetings/2020-09-19-Sprint3Closure.md)
+ - [2020-09-19 - Abertura da Sprint 4](/docs/SprintsAndMeetings/2020-09-19-Sprint4Opening.md)
+ - [2020-09-26 - Fechamento da Sprint 4](/docs/SprintsAndMeetings/2020-09-26-Sprint4Closure.md)
+ - [2020-09-26 - Abertura da Sprint 5](/docs/SprintsAndMeetings/2020-09-26-Sprint5Opening.md)
+ - [2020-10-03 - Fechamento da Sprint 5](/docs/SprintsAndMeetings/2020-10-03-Sprint5Closure.md)
+ - [2020-10-03 - Abertura da Sprint 6](/docs/SprintsAndMeetings/2020-10-03-Sprint6Opening.md)
+ - [2020-10-10 - Fechamento da Sprint 6](/docs/SprintsAndMeetings/2020-10-10-Sprint6Closure.md)
+ - [2020-10-10 - Abertura da Sprint 7](/docs/SprintsAndMeetings/2020-10-10-Sprint7Opening.md)
+ - [2020-10-10 - Fechamento da Sprint 7](/docs/SprintsAndMeetings/2020-10-17-Sprint7Closure.md)
+ - [2020-10-10 - Abertura da Sprint 8](/docs/SprintsAndMeetings/2020-10-17-Sprint8Opening.md)
+ - [2020-10-10 - Fechamento da Sprint 8](/docs/SprintsAndMeetings/2020-10-26-Sprint8Closure.md)
+ - [2020-10-10 - Abertura da Sprint 9](/docs/SprintsAndMeetings/2020-10-26-Sprint9Opening.md)
+ - [2020-11-02 - Fechamento da Sprint 9](/docs/SprintsAndMeetings/2020-11-02-Sprint9Closure.md)
+ - [2020-11-02 - Abertura da Sprint 10](/docs/SprintsAndMeetings/2020-11-02-Sprint10Opening.md)
+ - [2020-11-09 - Fechamento da Sprint 10](/docs/SprintsAndMeetings/2020-11-09-Sprint10Closure.md)
+ - [2020-11-09 - Abertura da Sprint 11](/docs/SprintsAndMeetings/2020-11-09-Sprint11Opening.md)
+ - [2020-11-16 - Fechamento da Sprint 11](/docs/SprintsAndMeetings/2020-11-16-Sprint11Closure.md)
+ - [2020-11-16 - Abertura da Sprint 12](/docs/SprintsAndMeetings/2020-11-16-Sprint12Opening.md)
+
+
diff --git a/docs/Assets/Audios/BPMN/DesenvolverHistoriaDeUsuario.mp3 b/docs/Assets/Audios/BPMN/DesenvolverHistoriaDeUsuario.mp3
new file mode 100644
index 0000000..a07c820
Binary files /dev/null and b/docs/Assets/Audios/BPMN/DesenvolverHistoriaDeUsuario.mp3 differ
diff --git a/docs/Assets/Audios/BPMN/DesenvolverIdeiaDoProjeto.mp3 b/docs/Assets/Audios/BPMN/DesenvolverIdeiaDoProjeto.mp3
new file mode 100644
index 0000000..efeacc8
Binary files /dev/null and b/docs/Assets/Audios/BPMN/DesenvolverIdeiaDoProjeto.mp3 differ
diff --git a/docs/Assets/Audios/BPMN/DesignSprint.mp3 b/docs/Assets/Audios/BPMN/DesignSprint.mp3
new file mode 100644
index 0000000..ed0cf27
Binary files /dev/null and b/docs/Assets/Audios/BPMN/DesignSprint.mp3 differ
diff --git a/docs/Assets/Audios/BPMN/MetodologiaGeral.mp3 b/docs/Assets/Audios/BPMN/MetodologiaGeral.mp3
new file mode 100644
index 0000000..f5cbf89
Binary files /dev/null and b/docs/Assets/Audios/BPMN/MetodologiaGeral.mp3 differ
diff --git a/docs/Assets/Audios/BPMN/PlanningPoker.mp3 b/docs/Assets/Audios/BPMN/PlanningPoker.mp3
new file mode 100644
index 0000000..eb97d9c
Binary files /dev/null and b/docs/Assets/Audios/BPMN/PlanningPoker.mp3 differ
diff --git a/docs/Assets/Audios/BPMN/RealizarDesenvolvimentoDoProduto.mp3 b/docs/Assets/Audios/BPMN/RealizarDesenvolvimentoDoProduto.mp3
new file mode 100644
index 0000000..5113540
Binary files /dev/null and b/docs/Assets/Audios/BPMN/RealizarDesenvolvimentoDoProduto.mp3 differ
diff --git a/docs/Assets/Audios/BPMN/RealizarSprintPlanning.mp3 b/docs/Assets/Audios/BPMN/RealizarSprintPlanning.mp3
new file mode 100644
index 0000000..4a0bcc8
Binary files /dev/null and b/docs/Assets/Audios/BPMN/RealizarSprintPlanning.mp3 differ
diff --git a/docs/Assets/Audios/BPMN/SprintRetrospective.mp3 b/docs/Assets/Audios/BPMN/SprintRetrospective.mp3
new file mode 100644
index 0000000..ef9e7c0
Binary files /dev/null and b/docs/Assets/Audios/BPMN/SprintRetrospective.mp3 differ
diff --git a/docs/Assets/Audios/BPMN/SprintReview.mp3 b/docs/Assets/Audios/BPMN/SprintReview.mp3
new file mode 100644
index 0000000..b561508
Binary files /dev/null and b/docs/Assets/Audios/BPMN/SprintReview.mp3 differ
diff --git a/docs/Assets/Css/home.css b/docs/Assets/Css/home.css
new file mode 100644
index 0000000..90f73dc
--- /dev/null
+++ b/docs/Assets/Css/home.css
@@ -0,0 +1,76 @@
+.container-img {
+ position: relative;
+ width: 50%;
+}
+
+.image {
+ opacity: 1;
+ display: block;
+ width: 80%;
+ height: auto;
+ transition: .5s ease;
+ backface-visibility: hidden;
+ border-radius: 50%;
+}
+
+.middle {
+ transition: .5s ease;
+ opacity: 0;
+ position: absolute;
+ top: 50%;
+ left: 40%;
+ transform: translate(-50%, -50%);
+ -ms-transform: translate(-50%, -50%);
+ text-align: center;
+}
+
+.container-img:hover .image {
+ opacity: 0.3;
+}
+
+.container-img:hover .middle {
+ opacity: 1;
+}
+
+.text {
+ color: black;
+ font-size: 20px;
+ padding: 32px 32px;
+
+ background-position: 0 75%;
+ background-size: auto 5px;
+ background-repeat: repeat-x;
+ text-decoration: none;
+}
+
+.title-home{
+ font-size: 5em !important;
+ font-family: 'Francois One', sans-serif;
+}
+
+.sub-title{
+ font-size: 3em !important;
+ margin-bottom: 1em !important;
+}
+
+.sub-title2{
+ font-size: 3em !important;
+ margin-bottom: 2em !important;
+ margin-top: 2em !important;
+}
+
+.has-mask {
+ background-attachment: fixed !important;
+ background-position: center !important;
+ background-repeat: no-repeat !important;
+ background-size: cover !important;
+}
+
+.mask {
+ background-color: transparent !important;
+}
+
+body h1{
+font-size: 2.5em !important;
+}
+
diff --git a/docs/Assets/Img/Artefacts/Brainstorming.png b/docs/Assets/Img/Artefacts/Brainstorming.png
new file mode 100644
index 0000000..c6d246d
Binary files /dev/null and b/docs/Assets/Img/Artefacts/Brainstorming.png differ
diff --git a/docs/Assets/Img/Artefacts/BrainstormingColor1.png b/docs/Assets/Img/Artefacts/BrainstormingColor1.png
new file mode 100644
index 0000000..5b7a0c5
Binary files /dev/null and b/docs/Assets/Img/Artefacts/BrainstormingColor1.png differ
diff --git a/docs/Assets/Img/Artefacts/BrainstormingColor2.png b/docs/Assets/Img/Artefacts/BrainstormingColor2.png
new file mode 100644
index 0000000..2b59d5a
Binary files /dev/null and b/docs/Assets/Img/Artefacts/BrainstormingColor2.png differ
diff --git a/docs/Assets/Img/Artefacts/BrainstormingColor3.png b/docs/Assets/Img/Artefacts/BrainstormingColor3.png
new file mode 100644
index 0000000..b75b4f6
Binary files /dev/null and b/docs/Assets/Img/Artefacts/BrainstormingColor3.png differ
diff --git a/docs/Assets/Img/Artefacts/BrainstormingColor4.png b/docs/Assets/Img/Artefacts/BrainstormingColor4.png
new file mode 100644
index 0000000..b3d4a55
Binary files /dev/null and b/docs/Assets/Img/Artefacts/BrainstormingColor4.png differ
diff --git a/docs/Assets/Img/Artefacts/BrainstormingColors.png b/docs/Assets/Img/Artefacts/BrainstormingColors.png
new file mode 100644
index 0000000..a5d87d2
Binary files /dev/null and b/docs/Assets/Img/Artefacts/BrainstormingColors.png differ
diff --git a/docs/Assets/Img/Artefacts/BrainstormingGroup.png b/docs/Assets/Img/Artefacts/BrainstormingGroup.png
new file mode 100644
index 0000000..cc0c813
Binary files /dev/null and b/docs/Assets/Img/Artefacts/BrainstormingGroup.png differ
diff --git a/docs/Assets/Img/Artefacts/IshikawaDiagram.png b/docs/Assets/Img/Artefacts/IshikawaDiagram.png
new file mode 100755
index 0000000..c63e92f
Binary files /dev/null and b/docs/Assets/Img/Artefacts/IshikawaDiagram.png differ
diff --git a/docs/Assets/Img/Artefacts/MindMap.png b/docs/Assets/Img/Artefacts/MindMap.png
new file mode 100644
index 0000000..d8fe313
Binary files /dev/null and b/docs/Assets/Img/Artefacts/MindMap.png differ
diff --git a/docs/Assets/Img/Artefacts/RichPictureGeral.png b/docs/Assets/Img/Artefacts/RichPictureGeral.png
new file mode 100644
index 0000000..930504b
Binary files /dev/null and b/docs/Assets/Img/Artefacts/RichPictureGeral.png differ
diff --git a/docs/Assets/Img/Artefacts/Splash.png b/docs/Assets/Img/Artefacts/Splash.png
new file mode 100644
index 0000000..5e56cee
Binary files /dev/null and b/docs/Assets/Img/Artefacts/Splash.png differ
diff --git a/docs/Assets/Img/DesignPatterns/BehaviorGoFs/IteratorExample.png b/docs/Assets/Img/DesignPatterns/BehaviorGoFs/IteratorExample.png
new file mode 100644
index 0000000..4c1b979
Binary files /dev/null and b/docs/Assets/Img/DesignPatterns/BehaviorGoFs/IteratorExample.png differ
diff --git a/docs/Assets/Img/DesignPatterns/BehaviorGoFs/MementoExample.jpg b/docs/Assets/Img/DesignPatterns/BehaviorGoFs/MementoExample.jpg
new file mode 100644
index 0000000..aad3936
Binary files /dev/null and b/docs/Assets/Img/DesignPatterns/BehaviorGoFs/MementoExample.jpg differ
diff --git a/docs/Assets/Img/DesignPatterns/BehaviorGoFs/StateExample.png b/docs/Assets/Img/DesignPatterns/BehaviorGoFs/StateExample.png
new file mode 100644
index 0000000..59ee008
Binary files /dev/null and b/docs/Assets/Img/DesignPatterns/BehaviorGoFs/StateExample.png differ
diff --git a/docs/Assets/Img/DesignPatterns/BehaviorGoFs/TemplateMethodExample.jpg b/docs/Assets/Img/DesignPatterns/BehaviorGoFs/TemplateMethodExample.jpg
new file mode 100644
index 0000000..17a0241
Binary files /dev/null and b/docs/Assets/Img/DesignPatterns/BehaviorGoFs/TemplateMethodExample.jpg differ
diff --git a/docs/Assets/Img/DesignPatterns/BehaviorGoFs/TemplateMethodExample2.png b/docs/Assets/Img/DesignPatterns/BehaviorGoFs/TemplateMethodExample2.png
new file mode 100644
index 0000000..33b1b08
Binary files /dev/null and b/docs/Assets/Img/DesignPatterns/BehaviorGoFs/TemplateMethodExample2.png differ
diff --git a/docs/Assets/Img/DesignPatterns/BehaviorGoFs/TemplateMethodExample3.png b/docs/Assets/Img/DesignPatterns/BehaviorGoFs/TemplateMethodExample3.png
new file mode 100644
index 0000000..10cd6c8
Binary files /dev/null and b/docs/Assets/Img/DesignPatterns/BehaviorGoFs/TemplateMethodExample3.png differ
diff --git a/docs/Assets/Img/DesignPatterns/CreationalGoFs/FactoryMethodExample.png b/docs/Assets/Img/DesignPatterns/CreationalGoFs/FactoryMethodExample.png
new file mode 100644
index 0000000..cfb1639
Binary files /dev/null and b/docs/Assets/Img/DesignPatterns/CreationalGoFs/FactoryMethodExample.png differ
diff --git a/docs/Assets/Img/DesignPatterns/CreationalGoFs/SingletonExample.png b/docs/Assets/Img/DesignPatterns/CreationalGoFs/SingletonExample.png
new file mode 100644
index 0000000..9c9ccb8
Binary files /dev/null and b/docs/Assets/Img/DesignPatterns/CreationalGoFs/SingletonExample.png differ
diff --git a/docs/Assets/Img/DesignPatterns/GRAPS/BovinePolimorfism.png b/docs/Assets/Img/DesignPatterns/GRAPS/BovinePolimorfism.png
new file mode 100644
index 0000000..af40bb5
Binary files /dev/null and b/docs/Assets/Img/DesignPatterns/GRAPS/BovinePolimorfism.png differ
diff --git a/docs/Assets/Img/DesignPatterns/GRAPS/CohesionModelFarm.png b/docs/Assets/Img/DesignPatterns/GRAPS/CohesionModelFarm.png
new file mode 100644
index 0000000..d78e776
Binary files /dev/null and b/docs/Assets/Img/DesignPatterns/GRAPS/CohesionModelFarm.png differ
diff --git a/docs/Assets/Img/DesignPatterns/GRAPS/ControllerServices.png b/docs/Assets/Img/DesignPatterns/GRAPS/ControllerServices.png
new file mode 100644
index 0000000..159389a
Binary files /dev/null and b/docs/Assets/Img/DesignPatterns/GRAPS/ControllerServices.png differ
diff --git a/docs/Assets/Img/DesignPatterns/GRAPS/DairyCattle.png b/docs/Assets/Img/DesignPatterns/GRAPS/DairyCattle.png
new file mode 100644
index 0000000..81abb96
Binary files /dev/null and b/docs/Assets/Img/DesignPatterns/GRAPS/DairyCattle.png differ
diff --git a/docs/Assets/Img/DesignPatterns/GRAPS/EspecialistService.png b/docs/Assets/Img/DesignPatterns/GRAPS/EspecialistService.png
new file mode 100644
index 0000000..088d1b9
Binary files /dev/null and b/docs/Assets/Img/DesignPatterns/GRAPS/EspecialistService.png differ
diff --git a/docs/Assets/Img/DesignPatterns/GRAPS/OwnInvestmentServices.png b/docs/Assets/Img/DesignPatterns/GRAPS/OwnInvestmentServices.png
new file mode 100644
index 0000000..251ad43
Binary files /dev/null and b/docs/Assets/Img/DesignPatterns/GRAPS/OwnInvestmentServices.png differ
diff --git a/docs/Assets/Img/DesignPatterns/GRAPS/PolimorfismExample.png b/docs/Assets/Img/DesignPatterns/GRAPS/PolimorfismExample.png
new file mode 100644
index 0000000..b5de852
Binary files /dev/null and b/docs/Assets/Img/DesignPatterns/GRAPS/PolimorfismExample.png differ
diff --git a/docs/Assets/Img/DesignPatterns/GRAPS/ReportPolimorfism.png b/docs/Assets/Img/DesignPatterns/GRAPS/ReportPolimorfism.png
new file mode 100644
index 0000000..cb80de1
Binary files /dev/null and b/docs/Assets/Img/DesignPatterns/GRAPS/ReportPolimorfism.png differ
diff --git a/docs/Assets/Img/DesignPatterns/StructuralGoFs/FacadeExample.png b/docs/Assets/Img/DesignPatterns/StructuralGoFs/FacadeExample.png
new file mode 100644
index 0000000..1198441
Binary files /dev/null and b/docs/Assets/Img/DesignPatterns/StructuralGoFs/FacadeExample.png differ
diff --git a/docs/Assets/Img/Logo/Background.png b/docs/Assets/Img/Logo/Background.png
new file mode 100644
index 0000000..d08f3f7
Binary files /dev/null and b/docs/Assets/Img/Logo/Background.png differ
diff --git a/docs/Assets/Img/Logo/Icon.png b/docs/Assets/Img/Logo/Icon.png
new file mode 100644
index 0000000..b6f7818
Binary files /dev/null and b/docs/Assets/Img/Logo/Icon.png differ
diff --git a/docs/Assets/Img/Logo/Logo.png b/docs/Assets/Img/Logo/Logo.png
new file mode 100644
index 0000000..126fcf3
Binary files /dev/null and b/docs/Assets/Img/Logo/Logo.png differ
diff --git a/docs/Assets/Img/Misc/CommitExample.gif b/docs/Assets/Img/Misc/CommitExample.gif
new file mode 100644
index 0000000..6eb960e
Binary files /dev/null and b/docs/Assets/Img/Misc/CommitExample.gif differ
diff --git a/docs/Assets/Img/Modeling/ClassDiagram/ClassDiagramV0.1.png b/docs/Assets/Img/Modeling/ClassDiagram/ClassDiagramV0.1.png
new file mode 100644
index 0000000..2e9f106
Binary files /dev/null and b/docs/Assets/Img/Modeling/ClassDiagram/ClassDiagramV0.1.png differ
diff --git a/docs/Assets/Img/Modeling/ClassDiagram/ClassDiagramV0.2.png b/docs/Assets/Img/Modeling/ClassDiagram/ClassDiagramV0.2.png
new file mode 100644
index 0000000..d88b9a0
Binary files /dev/null and b/docs/Assets/Img/Modeling/ClassDiagram/ClassDiagramV0.2.png differ
diff --git a/docs/Assets/Img/Modeling/ClassDiagram/ClassDiagramV1.2.png b/docs/Assets/Img/Modeling/ClassDiagram/ClassDiagramV1.2.png
new file mode 100644
index 0000000..f7b599a
Binary files /dev/null and b/docs/Assets/Img/Modeling/ClassDiagram/ClassDiagramV1.2.png differ
diff --git a/docs/Assets/Img/Modeling/ClassDiagram/ClassDiagramV1.png b/docs/Assets/Img/Modeling/ClassDiagram/ClassDiagramV1.png
new file mode 100644
index 0000000..c20bd80
Binary files /dev/null and b/docs/Assets/Img/Modeling/ClassDiagram/ClassDiagramV1.png differ
diff --git a/docs/Assets/Img/Modeling/ColaborationDiagram/BovineManagement.png b/docs/Assets/Img/Modeling/ColaborationDiagram/BovineManagement.png
new file mode 100644
index 0000000..ae565cd
Binary files /dev/null and b/docs/Assets/Img/Modeling/ColaborationDiagram/BovineManagement.png differ
diff --git a/docs/Assets/Img/Modeling/ColaborationDiagram/GenerateReport.png b/docs/Assets/Img/Modeling/ColaborationDiagram/GenerateReport.png
new file mode 100644
index 0000000..73f43ab
Binary files /dev/null and b/docs/Assets/Img/Modeling/ColaborationDiagram/GenerateReport.png differ
diff --git a/docs/Assets/Img/Modeling/ColaborationDiagram/Insumos.png b/docs/Assets/Img/Modeling/ColaborationDiagram/Insumos.png
new file mode 100644
index 0000000..6458597
Binary files /dev/null and b/docs/Assets/Img/Modeling/ColaborationDiagram/Insumos.png differ
diff --git a/docs/Assets/Img/Modeling/ComponentsDiagram/ComponentsDiagram.png b/docs/Assets/Img/Modeling/ComponentsDiagram/ComponentsDiagram.png
new file mode 100644
index 0000000..4d9e370
Binary files /dev/null and b/docs/Assets/Img/Modeling/ComponentsDiagram/ComponentsDiagram.png differ
diff --git a/docs/Assets/Img/Modeling/ComponentsDiagram/ComponentsDiagram2.png b/docs/Assets/Img/Modeling/ComponentsDiagram/ComponentsDiagram2.png
new file mode 100644
index 0000000..9f452e6
Binary files /dev/null and b/docs/Assets/Img/Modeling/ComponentsDiagram/ComponentsDiagram2.png differ
diff --git a/docs/Assets/Img/Modeling/ComponentsDiagram/ComponentsDiagramDraft.jpg b/docs/Assets/Img/Modeling/ComponentsDiagram/ComponentsDiagramDraft.jpg
new file mode 100644
index 0000000..690adf7
Binary files /dev/null and b/docs/Assets/Img/Modeling/ComponentsDiagram/ComponentsDiagramDraft.jpg differ
diff --git a/docs/Assets/Img/Modeling/DatabaseModeling/DER_v1.png b/docs/Assets/Img/Modeling/DatabaseModeling/DER_v1.png
new file mode 100644
index 0000000..0a359d9
Binary files /dev/null and b/docs/Assets/Img/Modeling/DatabaseModeling/DER_v1.png differ
diff --git a/docs/Assets/Img/Modeling/DiagramPackage/PackageDiagramBackendV1.png b/docs/Assets/Img/Modeling/DiagramPackage/PackageDiagramBackendV1.png
new file mode 100644
index 0000000..1e4af25
Binary files /dev/null and b/docs/Assets/Img/Modeling/DiagramPackage/PackageDiagramBackendV1.png differ
diff --git a/docs/Assets/Img/Modeling/DiagramPackage/PackageDiagramFrontV2.png b/docs/Assets/Img/Modeling/DiagramPackage/PackageDiagramFrontV2.png
new file mode 100644
index 0000000..f6ad8f9
Binary files /dev/null and b/docs/Assets/Img/Modeling/DiagramPackage/PackageDiagramFrontV2.png differ
diff --git a/docs/Assets/Img/Modeling/DiagramPackage/PackageDiagramFrontendV1.png b/docs/Assets/Img/Modeling/DiagramPackage/PackageDiagramFrontendV1.png
new file mode 100644
index 0000000..e5ff479
Binary files /dev/null and b/docs/Assets/Img/Modeling/DiagramPackage/PackageDiagramFrontendV1.png differ
diff --git a/docs/Assets/Img/Modeling/PackageDiagram/PackageDiagramV2.0.png b/docs/Assets/Img/Modeling/PackageDiagram/PackageDiagramV2.0.png
new file mode 100644
index 0000000..2c0204a
Binary files /dev/null and b/docs/Assets/Img/Modeling/PackageDiagram/PackageDiagramV2.0.png differ
diff --git a/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-CadastroDeBovino.png b/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-CadastroDeBovino.png
new file mode 100644
index 0000000..d8c3b0c
Binary files /dev/null and b/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-CadastroDeBovino.png differ
diff --git a/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-CadastroDeBovinoV2.png b/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-CadastroDeBovinoV2.png
new file mode 100644
index 0000000..af50af3
Binary files /dev/null and b/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-CadastroDeBovinoV2.png differ
diff --git a/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-EstoqueDeInsumos.png b/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-EstoqueDeInsumos.png
new file mode 100644
index 0000000..8af5864
Binary files /dev/null and b/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-EstoqueDeInsumos.png differ
diff --git a/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-EstoqueDeInsumosV2.png b/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-EstoqueDeInsumosV2.png
new file mode 100644
index 0000000..58103c0
Binary files /dev/null and b/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-EstoqueDeInsumosV2.png differ
diff --git a/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-Manejo.png b/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-Manejo.png
new file mode 100644
index 0000000..4bb7398
Binary files /dev/null and b/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-Manejo.png differ
diff --git a/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-ManejoV2.png b/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-ManejoV2.png
new file mode 100644
index 0000000..8d90d8d
Binary files /dev/null and b/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-ManejoV2.png differ
diff --git a/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-RegistroELogin.png b/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-RegistroELogin.png
new file mode 100644
index 0000000..1508df6
Binary files /dev/null and b/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-RegistroELogin.png differ
diff --git a/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-RegistroELoginV2.png b/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-RegistroELoginV2.png
new file mode 100644
index 0000000..99fa6c3
Binary files /dev/null and b/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-RegistroELoginV2.png differ
diff --git "a/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-Relat\303\263rio.png" "b/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-Relat\303\263rio.png"
new file mode 100644
index 0000000..5aa6c9b
Binary files /dev/null and "b/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-Relat\303\263rio.png" differ
diff --git "a/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-Relat\303\263rioV2.png" "b/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-Relat\303\263rioV2.png"
new file mode 100644
index 0000000..f403fcc
Binary files /dev/null and "b/docs/Assets/Img/Modeling/SequenceDiagram/SequenceDiagram-Relat\303\263rioV2.png" differ
diff --git a/docs/Assets/Img/Modeling/StateDiagram/CattleStateDiagramV1.1.png b/docs/Assets/Img/Modeling/StateDiagram/CattleStateDiagramV1.1.png
new file mode 100644
index 0000000..dbce25a
Binary files /dev/null and b/docs/Assets/Img/Modeling/StateDiagram/CattleStateDiagramV1.1.png differ
diff --git a/docs/Assets/Img/Modeling/StateDiagram/CattleStateDiagramV1.png b/docs/Assets/Img/Modeling/StateDiagram/CattleStateDiagramV1.png
new file mode 100644
index 0000000..613eb6a
Binary files /dev/null and b/docs/Assets/Img/Modeling/StateDiagram/CattleStateDiagramV1.png differ
diff --git a/docs/Assets/Img/Modeling/StateDiagram/ReportStateDiagramV1.1.png b/docs/Assets/Img/Modeling/StateDiagram/ReportStateDiagramV1.1.png
new file mode 100644
index 0000000..f5f1d9b
Binary files /dev/null and b/docs/Assets/Img/Modeling/StateDiagram/ReportStateDiagramV1.1.png differ
diff --git a/docs/Assets/Img/Modeling/StateDiagram/ReportStateDiagramV1.png b/docs/Assets/Img/Modeling/StateDiagram/ReportStateDiagramV1.png
new file mode 100644
index 0000000..ff82802
Binary files /dev/null and b/docs/Assets/Img/Modeling/StateDiagram/ReportStateDiagramV1.png differ
diff --git a/docs/Assets/Img/Modeling/StateDiagram/UserAuthStateDiagramV1.1.png b/docs/Assets/Img/Modeling/StateDiagram/UserAuthStateDiagramV1.1.png
new file mode 100644
index 0000000..79f231d
Binary files /dev/null and b/docs/Assets/Img/Modeling/StateDiagram/UserAuthStateDiagramV1.1.png differ
diff --git a/docs/Assets/Img/Modeling/StateDiagram/UserAuthStateDiagramV1.png b/docs/Assets/Img/Modeling/StateDiagram/UserAuthStateDiagramV1.png
new file mode 100644
index 0000000..e9e92f7
Binary files /dev/null and b/docs/Assets/Img/Modeling/StateDiagram/UserAuthStateDiagramV1.png differ
diff --git a/docs/Assets/Img/Product/Team/CaioVinicius.jpg b/docs/Assets/Img/Product/Team/CaioVinicius.jpg
new file mode 100644
index 0000000..19e4cf5
Binary files /dev/null and b/docs/Assets/Img/Product/Team/CaioVinicius.jpg differ
diff --git a/docs/Assets/Img/Product/Team/GuilhermeMendes.jpg b/docs/Assets/Img/Product/Team/GuilhermeMendes.jpg
new file mode 100644
index 0000000..2118b63
Binary files /dev/null and b/docs/Assets/Img/Product/Team/GuilhermeMendes.jpg differ
diff --git a/docs/Assets/Img/Product/Team/IuriSevero.jpg b/docs/Assets/Img/Product/Team/IuriSevero.jpg
new file mode 100644
index 0000000..8682eb7
Binary files /dev/null and b/docs/Assets/Img/Product/Team/IuriSevero.jpg differ
diff --git a/docs/Assets/Img/Product/Team/JoaoPedro.jpg b/docs/Assets/Img/Product/Team/JoaoPedro.jpg
new file mode 100644
index 0000000..2818d61
Binary files /dev/null and b/docs/Assets/Img/Product/Team/JoaoPedro.jpg differ
diff --git a/docs/Assets/Img/Product/Team/LucasFellipe.jpg b/docs/Assets/Img/Product/Team/LucasFellipe.jpg
new file mode 100644
index 0000000..aebc840
Binary files /dev/null and b/docs/Assets/Img/Product/Team/LucasFellipe.jpg differ
diff --git a/docs/Assets/Img/Project/ArchitectureDocument/ArchitecturalRepresentation.png b/docs/Assets/Img/Project/ArchitectureDocument/ArchitecturalRepresentation.png
new file mode 100644
index 0000000..e76b3ac
Binary files /dev/null and b/docs/Assets/Img/Project/ArchitectureDocument/ArchitecturalRepresentation.png differ
diff --git a/docs/Assets/Img/Project/ArchitectureDocument/CattleModule.png b/docs/Assets/Img/Project/ArchitectureDocument/CattleModule.png
new file mode 100644
index 0000000..62d079c
Binary files /dev/null and b/docs/Assets/Img/Project/ArchitectureDocument/CattleModule.png differ
diff --git a/docs/Assets/Img/Project/ArchitectureDocument/ManagementModule.png b/docs/Assets/Img/Project/ArchitectureDocument/ManagementModule.png
new file mode 100644
index 0000000..d350394
Binary files /dev/null and b/docs/Assets/Img/Project/ArchitectureDocument/ManagementModule.png differ
diff --git a/docs/Assets/Img/Project/ArchitectureDocument/ReportModule.png b/docs/Assets/Img/Project/ArchitectureDocument/ReportModule.png
new file mode 100644
index 0000000..27f7824
Binary files /dev/null and b/docs/Assets/Img/Project/ArchitectureDocument/ReportModule.png differ
diff --git a/docs/Assets/Img/Project/ArchitectureDocument/nfr.png b/docs/Assets/Img/Project/ArchitectureDocument/nfr.png
new file mode 100644
index 0000000..631e2ea
Binary files /dev/null and b/docs/Assets/Img/Project/ArchitectureDocument/nfr.png differ
diff --git a/docs/Assets/Img/Project/EAR.jpg b/docs/Assets/Img/Project/EAR.jpg
new file mode 100644
index 0000000..d2dec6a
Binary files /dev/null and b/docs/Assets/Img/Project/EAR.jpg differ
diff --git a/docs/Assets/Img/Project/SoftwareReuse/StatefulWidget.png b/docs/Assets/Img/Project/SoftwareReuse/StatefulWidget.png
new file mode 100644
index 0000000..6409193
Binary files /dev/null and b/docs/Assets/Img/Project/SoftwareReuse/StatefulWidget.png differ
diff --git a/docs/Assets/Img/Sprints/BurdownSprint11.png b/docs/Assets/Img/Sprints/BurdownSprint11.png
new file mode 100644
index 0000000..f1bfd62
Binary files /dev/null and b/docs/Assets/Img/Sprints/BurdownSprint11.png differ
diff --git a/docs/Assets/Img/Sprints/BurnDownSprint10.png b/docs/Assets/Img/Sprints/BurnDownSprint10.png
new file mode 100644
index 0000000..4dcdb82
Binary files /dev/null and b/docs/Assets/Img/Sprints/BurnDownSprint10.png differ
diff --git a/docs/Assets/Img/Sprints/BurnDownSprint2.png b/docs/Assets/Img/Sprints/BurnDownSprint2.png
new file mode 100644
index 0000000..1bcf67d
Binary files /dev/null and b/docs/Assets/Img/Sprints/BurnDownSprint2.png differ
diff --git a/docs/Assets/Img/Sprints/BurnDownSprint3.png b/docs/Assets/Img/Sprints/BurnDownSprint3.png
new file mode 100644
index 0000000..491183e
Binary files /dev/null and b/docs/Assets/Img/Sprints/BurnDownSprint3.png differ
diff --git a/docs/Assets/Img/Sprints/BurnDownSprint4.png b/docs/Assets/Img/Sprints/BurnDownSprint4.png
new file mode 100644
index 0000000..9a6e2d1
Binary files /dev/null and b/docs/Assets/Img/Sprints/BurnDownSprint4.png differ
diff --git a/docs/Assets/Img/Sprints/BurnDownSprint6.png b/docs/Assets/Img/Sprints/BurnDownSprint6.png
new file mode 100644
index 0000000..8f36519
Binary files /dev/null and b/docs/Assets/Img/Sprints/BurnDownSprint6.png differ
diff --git a/docs/Assets/Img/Sprints/BurnDownSprint7.png b/docs/Assets/Img/Sprints/BurnDownSprint7.png
new file mode 100644
index 0000000..1143694
Binary files /dev/null and b/docs/Assets/Img/Sprints/BurnDownSprint7.png differ
diff --git a/docs/Assets/Img/Sprints/BurnDownSprint8.png b/docs/Assets/Img/Sprints/BurnDownSprint8.png
new file mode 100644
index 0000000..8251e52
Binary files /dev/null and b/docs/Assets/Img/Sprints/BurnDownSprint8.png differ
diff --git a/docs/Assets/Img/Sprints/BurnDownSprint9.png b/docs/Assets/Img/Sprints/BurnDownSprint9.png
new file mode 100644
index 0000000..01730fe
Binary files /dev/null and b/docs/Assets/Img/Sprints/BurnDownSprint9.png differ
diff --git a/docs/Assets/Img/Sprints/VelocitySprint10.png b/docs/Assets/Img/Sprints/VelocitySprint10.png
new file mode 100644
index 0000000..0446290
Binary files /dev/null and b/docs/Assets/Img/Sprints/VelocitySprint10.png differ
diff --git a/docs/Assets/Img/Sprints/VelocitySprint11.png b/docs/Assets/Img/Sprints/VelocitySprint11.png
new file mode 100644
index 0000000..fd0605f
Binary files /dev/null and b/docs/Assets/Img/Sprints/VelocitySprint11.png differ
diff --git a/docs/Assets/Img/Sprints/VelocitySprint2.png b/docs/Assets/Img/Sprints/VelocitySprint2.png
new file mode 100644
index 0000000..1c85b7b
Binary files /dev/null and b/docs/Assets/Img/Sprints/VelocitySprint2.png differ
diff --git a/docs/Assets/Img/Sprints/VelocitySprint3.png b/docs/Assets/Img/Sprints/VelocitySprint3.png
new file mode 100644
index 0000000..9378db7
Binary files /dev/null and b/docs/Assets/Img/Sprints/VelocitySprint3.png differ
diff --git a/docs/Assets/Img/Sprints/VelocitySprint4.png b/docs/Assets/Img/Sprints/VelocitySprint4.png
new file mode 100644
index 0000000..737deac
Binary files /dev/null and b/docs/Assets/Img/Sprints/VelocitySprint4.png differ
diff --git a/docs/Assets/Img/Sprints/VelocitySprint6.png b/docs/Assets/Img/Sprints/VelocitySprint6.png
new file mode 100644
index 0000000..2ece39d
Binary files /dev/null and b/docs/Assets/Img/Sprints/VelocitySprint6.png differ
diff --git a/docs/Assets/Img/Sprints/VelocitySprint7.png b/docs/Assets/Img/Sprints/VelocitySprint7.png
new file mode 100644
index 0000000..4bda308
Binary files /dev/null and b/docs/Assets/Img/Sprints/VelocitySprint7.png differ
diff --git a/docs/Assets/Img/Sprints/VelocitySprint8.png b/docs/Assets/Img/Sprints/VelocitySprint8.png
new file mode 100644
index 0000000..136f970
Binary files /dev/null and b/docs/Assets/Img/Sprints/VelocitySprint8.png differ
diff --git a/docs/Assets/Img/Sprints/VelocitySprint9.png b/docs/Assets/Img/Sprints/VelocitySprint9.png
new file mode 100644
index 0000000..f0d842d
Binary files /dev/null and b/docs/Assets/Img/Sprints/VelocitySprint9.png differ
diff --git a/docs/Assets/Img/Studies/DojoFlutter/LoginScreenTree.png b/docs/Assets/Img/Studies/DojoFlutter/LoginScreenTree.png
new file mode 100644
index 0000000..3769c9e
Binary files /dev/null and b/docs/Assets/Img/Studies/DojoFlutter/LoginScreenTree.png differ
diff --git a/docs/Assets/Img/Studies/DojoFlutter/RegisterScreenTree.png b/docs/Assets/Img/Studies/DojoFlutter/RegisterScreenTree.png
new file mode 100644
index 0000000..db9a8a6
Binary files /dev/null and b/docs/Assets/Img/Studies/DojoFlutter/RegisterScreenTree.png differ
diff --git a/docs/Assets/Img/Studies/DojoFlutter/SplashScreenTree.png b/docs/Assets/Img/Studies/DojoFlutter/SplashScreenTree.png
new file mode 100644
index 0000000..2239cb1
Binary files /dev/null and b/docs/Assets/Img/Studies/DojoFlutter/SplashScreenTree.png differ
diff --git a/docs/Assets/Img/Studies/EmergingDesignPatterns/CompositePatternExample.png b/docs/Assets/Img/Studies/EmergingDesignPatterns/CompositePatternExample.png
new file mode 100644
index 0000000..cc12907
Binary files /dev/null and b/docs/Assets/Img/Studies/EmergingDesignPatterns/CompositePatternExample.png differ
diff --git a/docs/Assets/Img/Studies/EmergingDesignPatterns/FactoryMethodPatternExample.png b/docs/Assets/Img/Studies/EmergingDesignPatterns/FactoryMethodPatternExample.png
new file mode 100644
index 0000000..cae5f2c
Binary files /dev/null and b/docs/Assets/Img/Studies/EmergingDesignPatterns/FactoryMethodPatternExample.png differ
diff --git a/docs/Assets/Img/Studies/EmergingDesignPatterns/SingletonPattern.png b/docs/Assets/Img/Studies/EmergingDesignPatterns/SingletonPattern.png
new file mode 100644
index 0000000..8c5543b
Binary files /dev/null and b/docs/Assets/Img/Studies/EmergingDesignPatterns/SingletonPattern.png differ
diff --git a/docs/Assets/Img/Studies/EmergingDesignPatterns/StatePatternExample.png b/docs/Assets/Img/Studies/EmergingDesignPatterns/StatePatternExample.png
new file mode 100644
index 0000000..749cc91
Binary files /dev/null and b/docs/Assets/Img/Studies/EmergingDesignPatterns/StatePatternExample.png differ
diff --git a/docs/Assets/Img/Studies/GoFs/ChainOfResponsibility.png b/docs/Assets/Img/Studies/GoFs/ChainOfResponsibility.png
new file mode 100644
index 0000000..a838dea
Binary files /dev/null and b/docs/Assets/Img/Studies/GoFs/ChainOfResponsibility.png differ
diff --git a/docs/Assets/Img/Studies/GoFs/Command.png b/docs/Assets/Img/Studies/GoFs/Command.png
new file mode 100644
index 0000000..e65d744
Binary files /dev/null and b/docs/Assets/Img/Studies/GoFs/Command.png differ
diff --git a/docs/Assets/Img/Studies/GoFs/Creational/creational.png b/docs/Assets/Img/Studies/GoFs/Creational/creational.png
new file mode 100644
index 0000000..a9fd121
Binary files /dev/null and b/docs/Assets/Img/Studies/GoFs/Creational/creational.png differ
diff --git a/docs/Assets/Img/Studies/GoFs/Creational/creational1.png b/docs/Assets/Img/Studies/GoFs/Creational/creational1.png
new file mode 100644
index 0000000..3578ef7
Binary files /dev/null and b/docs/Assets/Img/Studies/GoFs/Creational/creational1.png differ
diff --git a/docs/Assets/Img/Studies/GoFs/Creational/creational2.png b/docs/Assets/Img/Studies/GoFs/Creational/creational2.png
new file mode 100644
index 0000000..4301f80
Binary files /dev/null and b/docs/Assets/Img/Studies/GoFs/Creational/creational2.png differ
diff --git a/docs/Assets/Img/Studies/GoFs/Creational/creational3.png b/docs/Assets/Img/Studies/GoFs/Creational/creational3.png
new file mode 100644
index 0000000..d0cb6cd
Binary files /dev/null and b/docs/Assets/Img/Studies/GoFs/Creational/creational3.png differ
diff --git a/docs/Assets/Img/Studies/GoFs/Creational/creational4.png b/docs/Assets/Img/Studies/GoFs/Creational/creational4.png
new file mode 100644
index 0000000..51ade8b
Binary files /dev/null and b/docs/Assets/Img/Studies/GoFs/Creational/creational4.png differ
diff --git a/docs/Assets/Img/Studies/GoFs/Creational/creational5.png b/docs/Assets/Img/Studies/GoFs/Creational/creational5.png
new file mode 100644
index 0000000..52395f6
Binary files /dev/null and b/docs/Assets/Img/Studies/GoFs/Creational/creational5.png differ
diff --git a/docs/Assets/Img/Studies/GoFs/Creational/creational6.png b/docs/Assets/Img/Studies/GoFs/Creational/creational6.png
new file mode 100644
index 0000000..7ea429d
Binary files /dev/null and b/docs/Assets/Img/Studies/GoFs/Creational/creational6.png differ
diff --git a/docs/Assets/Img/Studies/GoFs/Iterator.png b/docs/Assets/Img/Studies/GoFs/Iterator.png
new file mode 100644
index 0000000..5851e82
Binary files /dev/null and b/docs/Assets/Img/Studies/GoFs/Iterator.png differ
diff --git a/docs/Assets/Img/Studies/GoFs/Mediator.png b/docs/Assets/Img/Studies/GoFs/Mediator.png
new file mode 100644
index 0000000..086a03d
Binary files /dev/null and b/docs/Assets/Img/Studies/GoFs/Mediator.png differ
diff --git a/docs/Assets/Img/Studies/GoFs/Memento.png b/docs/Assets/Img/Studies/GoFs/Memento.png
new file mode 100644
index 0000000..361e6a2
Binary files /dev/null and b/docs/Assets/Img/Studies/GoFs/Memento.png differ
diff --git a/docs/Assets/Img/Studies/GoFs/Observer.png b/docs/Assets/Img/Studies/GoFs/Observer.png
new file mode 100644
index 0000000..4c6445e
Binary files /dev/null and b/docs/Assets/Img/Studies/GoFs/Observer.png differ
diff --git a/docs/Assets/Img/Studies/GoFs/State.png b/docs/Assets/Img/Studies/GoFs/State.png
new file mode 100644
index 0000000..bbcfba3
Binary files /dev/null and b/docs/Assets/Img/Studies/GoFs/State.png differ
diff --git a/docs/Assets/Img/Studies/GoFs/Strategy.png b/docs/Assets/Img/Studies/GoFs/Strategy.png
new file mode 100644
index 0000000..1226f16
Binary files /dev/null and b/docs/Assets/Img/Studies/GoFs/Strategy.png differ
diff --git a/docs/Assets/Img/Studies/GoFs/TemplateMethod.png b/docs/Assets/Img/Studies/GoFs/TemplateMethod.png
new file mode 100644
index 0000000..5b5236b
Binary files /dev/null and b/docs/Assets/Img/Studies/GoFs/TemplateMethod.png differ
diff --git a/docs/Assets/Img/Studies/GoFs/Visitor.png b/docs/Assets/Img/Studies/GoFs/Visitor.png
new file mode 100644
index 0000000..addf12c
Binary files /dev/null and b/docs/Assets/Img/Studies/GoFs/Visitor.png differ
diff --git a/docs/DesignPatterns/BehaviorGoFs.md b/docs/DesignPatterns/BehaviorGoFs.md
new file mode 100644
index 0000000..1b1c497
--- /dev/null
+++ b/docs/DesignPatterns/BehaviorGoFs.md
@@ -0,0 +1,53 @@
+# Aplicação de GoF(s) Comportamentais
+
+| Data | Versão | Descrição | Autor(es) |
+| :--------: | :----: | :-------------------------------------: | :-------------------------------------------: |
+| 25/10/2020 | 0.1 | Criação do Documento da aplicação dos GoFs Comportamentais | [Caio Vinícius](https://github.com/caiovfernandes), [Guilherme Mendes](https://github.com/guilherme-mendes), [Iuri Severo](https://github.com/iurisevero), [João Guedes](https://github.com/sudjoao) e [Lucas Fellipe](https://github.com/lucasfcm9) |
+| 25/10/2020 | 0.2 | Adição do padrão Iterator | [Caio Vinícius](https://github.com/caiovfernandes), [Guilherme Mendes](https://github.com/guilherme-mendes), [Iuri Severo](https://github.com/iurisevero), [João Guedes](https://github.com/sudjoao) e [Lucas Fellipe](https://github.com/lucasfcm9) |
+| 25/10/2020 | 0.3 | Adição do padrão Memento | [Caio Vinícius](https://github.com/caiovfernandes), [Guilherme Mendes](https://github.com/guilherme-mendes), [Iuri Severo](https://github.com/iurisevero), [João Guedes](https://github.com/sudjoao) e [Lucas Fellipe](https://github.com/lucasfcm9) |
+| 25/10/2020 | 0.4 | Adição do padrão Template Method | [Caio Vinícius](https://github.com/caiovfernandes), [Guilherme Mendes](https://github.com/guilherme-mendes), [Iuri Severo](https://github.com/iurisevero), [João Guedes](https://github.com/sudjoao) e [Lucas Fellipe](https://github.com/lucasfcm9) |
+| 25/10/2020 | 0.5 | Adição do padrão State | [Caio Vinícius](https://github.com/caiovfernandes), [Guilherme Mendes](https://github.com/guilherme-mendes), [Iuri Severo](https://github.com/iurisevero), [João Guedes](https://github.com/sudjoao) e [Lucas Fellipe](https://github.com/lucasfcm9) |
+| 26/10/2020 | 1.0 | Revisão do documento | [Caio Vinícius](https://github.com/caiovfernandes), [Guilherme Mendes](https://github.com/guilherme-mendes), [Iuri Severo](https://github.com/iurisevero), [João Guedes](https://github.com/sudjoao) e [Lucas Fellipe](https://github.com/lucasfcm9) |
+
+## Iterator
+
+
+
+[project/api/resources/user.py](https://github.com/UnBArqDsw/2020.1_G13_iGado_Backend/blob/master/project/api/resources/user.py) 
+
+[lib/screens/register_screen.dart](https://github.com/UnBArqDsw/2020.1_G13_iGado_Frontend/blob/master/lib/screens/register_screen.dart)
+
+## Template Method
+
+
+
+[project/api/factories/report_generator.py](https://github.com/UnBArqDsw/2020.1_G13_iGado_Backend/blob/master/project/api/factories/report_generator.py) +[project/api/factories/management_generator.py](https://github.com/UnBArqDsw/2020.1_G13_iGado_Backend/blob/master/project/api/factories/management_generator.py)
+[project/\_\_init\_\_.py](https://github.com/UnBArqDsw/2020.1_G13_iGado_Backend/blob/master/project/__init__.py) + +## Singleton + +
+
+[lib/services/api.dart](https://github.com/UnBArqDsw/2020.1_G13_iGado_Frontend/blob/master/lib/services/api.dart)
+
+# Referências
+
+* PAX - Dinâmica e Seminário 4. Disponível em 
+ +[project/api/models/bovine.py](https://github.com/UnBArqDsw/2020.1_G13_iGado_Backend/tree/master/project/api/models/bovine.py)
+ +
+ +[project/api/models/dairy_cattle.py](https://github.com/UnBArqDsw/2020.1_G13_iGado_Backend/tree/master/project/api/models/dairy_cattle.py) + +
+
+[Class Diagram](https://unbarqdsw.github.io/2020.1_G13_iGado/#/docs/Modeling/ClassDiagram) + +## Criador +
+
+[project/api/generator_report/generator_report.py](https://github.com/UnBArqDsw/2020.1_G13_iGado_Backend/tree/master/project/api/generator_report/generator_report.py) +[project/api/models/user.py](https://github.com/UnBArqDsw/2020.1_G13_iGado_Backend/tree/master/project/api/models/user.py)
+ +## Especialista +
+
+[lib/services/api.dart](https://github.com/UnBArqDsw/2020.1_G13_iGado_Frontend/tree/master/lib/services/api.dart) +[lib/services/login_service.dart](https://github.com/UnBArqDsw/2020.1_G13_iGado_Frontend/tree/master/lib/services/login_service.dart)
+[lib/services/user_service.dart](https://github.com/UnBArqDsw/2020.1_G13_iGado_Frontend/tree/master/lib/services/user_service.dart) + +## Coesão +
+
+[project/api/models/farm.py](https://github.com/UnBArqDsw/2020.1_G13_iGado_Backend/tree/master/project/api/models/farm.py)+[project/api/models/general_report.py](https://github.com/UnBArqDsw/2020.1_G13_iGado_Backend/tree/master/project/api/models/general_report.py)
+[project/api/models/gmd_report.py](https://github.com/UnBArqDsw/2020.1_G13_iGado_Backend/tree/master/project/api/models/gmd_report.py)
+[project/api/models/report.py](https://github.com/UnBArqDsw/2020.1_G13_iGado_Backend/tree/master/project/api/models/report.py)
+[project/api/models/user.py](https://github.com/UnBArqDsw/2020.1_G13_iGado_Backend/tree/master/project/api/models/user.py)
+[project/api/models/work.py](https://github.com/UnBArqDsw/2020.1_G13_iGado_Backend/tree/master/project/api/models/work.py)
+ +## Invenção Própria +
+
+[lib/services/api.dart](https://github.com/UnBArqDsw/2020.1_G13_iGado_Frontend/tree/master/lib/services/api.dart) +[lib/services/login_service.dart](https://github.com/UnBArqDsw/2020.1_G13_iGado_Frontend/tree/master/lib/services/login_service.dart)
+[lib/services/user_service.dart](https://github.com/UnBArqDsw/2020.1_G13_iGado_Frontend/tree/master/lib/services/user_service.dart) + +## Controller +
+
+[lib/services/api.dart](https://github.com/UnBArqDsw/2020.1_G13_iGado_Frontend/tree/master/lib/services/api.dart) +[lib/services/login_service.dart](https://github.com/UnBArqDsw/2020.1_G13_iGado_Frontend/tree/master/lib/services/login_service.dart)
+[lib/services/user_service.dart](https://github.com/UnBArqDsw/2020.1_G13_iGado_Frontend/tree/master/lib/services/user_service.dart) + +# Referências + +* PAX - Dinâmica e Seminário 4. Disponível em
+
+[project/\_\_init\_\_.py](https://github.com/UnBArqDsw/2020.1_G13_iGado_Backend/blob/master/project/__init__.py) +[project/api/models/user.py](https://github.com/UnBArqDsw/2020.1_G13_iGado_Backend/blob/master/project/api/models/user.py)
+[project/api/models/farm.py](https://github.com/UnBArqDsw/2020.1_G13_iGado_Backend/blob/master/project/api/models/farm.py)
+[project/api/models/work.py](https://github.com/UnBArqDsw/2020.1_G13_iGado_Backend/blob/master/project/api/models/work.py)
+[project/api/models/report.py](https://github.com/UnBArqDsw/2020.1_G13_iGado_Backend/blob/master/project/api/models/report.py)
+ +# Referências + +* PAX - Dinâmica e Seminário 4. Disponível em
O Diagrama de Atividades tem como objetivo mostrar o fluxo de atividades do software, mostrando os objetos envolvidos, como eles se envolvem e quais são as atividades realizadas.
+ + +## Sign in to the App 2.0 + +
+
+ Clique aqui para ampliar
+
+**Autor:** [Guilherme Mendes](https://github.com/guilherme-mendes)
+
+## Sign in to the App 1.0
+
+
+
+ Clique aqui para ampliar
+
+**Autor:** [João Guedes](https://github.com/sudjoao)
+
+
+## View Cattle 2.0
+
+
+
+ Clique aqui para ampliar
+
+**Autor:** [Guilherme Mendes](https://github.com/guilherme-mendes)
+
+## View Cattle 1.0
+
+
+
+ Clique aqui para ampliar
+
+**Autor:** [João Guedes](https://github.com/sudjoao)
+
+## Manage Cattle 2.0
+
+
+
+ Clique aqui para ampliar
+
+**Autor:** [Guilherme Mendes](https://github.com/guilherme-mendes)
+
+## Manage Cattle 1.0
+
+
+
+ Clique aqui para ampliar
+
+**Autor:** [João Guedes](https://github.com/sudjoao)
+
+## Cattle Management 2.0
+
+
+
+ Clique aqui para ampliar
+
+**Autor:** [Guilherme Mendes](https://github.com/guilherme-mendes)
+
+## Cattle Management 1.0
+
+
+
+ Clique aqui para ampliar
+
+**Autor:** [João Guedes](https://github.com/sudjoao)
+
+## Generate Report 2.0
+
+
+
+ Clique aqui para ampliar
+
+**Autor:** [Guilherme Mendes](https://github.com/guilherme-mendes)
+
+## Generate Report 1.0
+
+
+
+ Clique aqui para ampliar
+
+**Autor:** [João Guedes](https://github.com/sudjoao)
+
+## Manage Reports 2.0
+
+
+
+ Clique aqui para ampliar
+
+**Autor:** [Guilherme Mendes](https://github.com/guilherme-mendes)
+
+## Manage Reports 1.0
+
+
+
+ Clique aqui para ampliar
+
+**Autor:** [João Guedes](https://github.com/sudjoao)
+
+
+## View Agricultural Inputs 2.0
+
+
+
+ Clique aqui para ampliar
+
+**Autor:** [Guilherme Mendes](https://github.com/guilherme-mendes)
+
+## View Agricultural Inputs 1.0
+
+
+
+ Clique aqui para ampliar
+
+**Autor:** [João Guedes](https://github.com/sudjoao)
+
+## Manage Agricultural Inputs 2.0
+
+
+
+ Clique aqui para ampliar
+
+**Autor:** [Guilherme Mendes](https://github.com/guilherme-mendes)
+
+## Manage Agricultural Inputs 1.0
+
+
+
+ Clique aqui para ampliar
+
+**Autor:** [João Guedes](https://github.com/sudjoao)
+
+## Referências
+* LUCIDCHART. O que é diagrama de atividades UML? [S. l.]; Disponível em: O Diagrama de Classes é uma representação da estrutura e relações das classes que servem de modelo para os objetos. Consiste em um conjunto de objetos com as mesmas características. Dessa forma, consegue-se identificar os objetos e agrupá-los, de forma a encontrar suas respectivas classes.
+ + +## Diagrama de Classes 1.2 +
+
+**Autor:** [Caio Fernandes](https://github.com/caiovfernandes)
+
+## Diagrama de Classes 1.0
+
+
+**Autores:** [Lucas Fellipe](https://github.com/lucasfcm9) e [João Guedes](https://github.com/sudjoao)
+
+## Diagrama de Classes 0.2
+
+
+**Autores:** [Lucas Fellipe](https://github.com/lucasfcm9) e [João Guedes](https://github.com/sudjoao)
+
+## Diagrama de Classes 0.1
+
+
+**Autores:** [Lucas Fellipe](https://github.com/lucasfcm9) e [João Guedes](https://github.com/sudjoao)
+
+## Referências
+* DEVMEDIA. Orientações básicas na elaboração de um diagrama de classes. [S. l.], 2019. Disponível em: O Diagrama de Comunicação (chamado de Diagrama de Colaboração no UML 1.x) é um tipo de diagrama de interação UML que mostra as interações entre objetos e/ou partes (representadas como lifelines) usando mensagens sequenciadas em um arranjo de forma livre.
+ + +## Diagrama de Manejo Bovino 2.0 +
+
+**Autor(es):** [Guilherme Mendes](https://github.com/guilherme-mendes)
+
+## Diagrama de Manejo Bovino 1.0
+
+
+**Autor(es):** [Caio Fernandes](https://github.com/caiovfernandes)
+
+## Diagrama de Insumos 2.0
+
+
+**Autor(es):** [Guilherme Mendes](https://github.com/guilherme-mendes)
+
+## Diagrama de Insumos 1.0
+
+
+**Autor(es):** [Caio Fernandes](https://github.com/caiovfernandes)
+
+## Diagrama de Relatórios 2.0
+
+
+**Autor(es):** [Guilherme Mendes](https://github.com/guilherme-mendes)
+
+## Diagrama de Relatórios 1.0
+
+
+**Autor(es):** [Caio Fernandes](https://github.com/caiovfernandes)
+
+
+## Referências
+
+* UML Communication Diagrams Overview. Disponível em: O Diagrama de Componentes tem como objetivo apresentar a organização dos componentes de um sistema, os relacionamentos que eles possuem entre si e as interfaces pelas quais se comunincam. A partir desse diagrama, é possível ter uma visão mais modularizada do sistema.
+ +## Versão 1.1 + +
+
+ Clique aqui para ampliar
+
+**Autor(es):** [Lucas Fellipe](https://github.com/lucasfcm9)
+
+## Versão 1.0
+
+
+ Clique aqui para ampliar
+
+**Autor(es):** [Iuri Severo](https://github.com/iurisevero)
+
+## Versão 0.1
+
+
+
+**Autor(es):** [Iuri Severo](https://github.com/iurisevero)
+
+## Referências
+* VisualParadigm. Component Diagram Tutorial. Disponível em: O Diagrama de Entidade-Relacionamento (DER) é um tipo de fluxograma que ilustra como “entidades”, como pessoas, objetos ou conceitos, se relacionam entre si dentro de um sistema. Diagramas de Entidade Relacionamento são mais utilizados para projetar ou depurar bancos de dados relacionais nas áreas de engenharia de software. Também conhecidos como DERs, ou modelos ER, usam um conjunto definido de símbolos, tais como retângulos, diamantes, ovais e linhas de conexão para representar a interconectividade de entidades, relacionamentos e seus atributos. Eles espelham estruturas gramaticais, onde entidades são substantivos e relacionamentos são verbos.
+O objetivo da modelagem de dados é possibilitar a apresentação de uma visão única não redundante e resumida dos dados de um problema. Também nos ajuda a entender a estrutura e o significado destes dados. +
+ +
+ Clique aqui para ampliar
+
+**Autor(es):** [Lucas Fellipe](https://github.com/lucasfcm9) e [Caio Vinícius](https://github.com/caiovfernandes)
+
+
+## Referências
+O que é um Diagrama Entidade Relacionamento. Disponível em: O Diagrama de Pacotes trata-se de um diagrama estático que possibilita a organização mais adequada do sistema representando uma visão em módulos, facilitando o entedimento do projeto durante o desenvolvimento e em possíveis manutenções.
+ +## Diagrama de Pacotes Geral 2.0 + +
+
+**Autor:** [João Guedes](https://github.com/sudjoao)
+
+## Back-end
+Construção utilizando o microframework Flask em Python.
+ +#### Versão 1 +
+
+## Front-end
+Construção utilizando o framework Flutter em Dart.
+ +#### Versão 1 +
+
+
+## **Referências**
+
+- [https://www.uml-diagrams.org/package-diagrams-overview.html](https://www.uml-diagrams.org/package-diagrams-overview.html). Acesso em: 23 set. 2020.
+- Diagramas Estruturais da UML: Diagrama de Pacotes. [S. l.], 2006. Disponível em: http://micreiros.com/diagrama-de-pacotes/. Acesso em: 23 set. 2020. \ No newline at end of file diff --git a/docs/Modeling/SequenceDiagram.md b/docs/Modeling/SequenceDiagram.md new file mode 100644 index 0000000..3486ba2 --- /dev/null +++ b/docs/Modeling/SequenceDiagram.md @@ -0,0 +1,135 @@ +# Diagrama de Sequência + + +| Data | Versão | Descrição | Autores | +| :--------: | :----: | :-------------------------------------: | :-------------------------------------------: | +| 25/09/2020 | 1.0 | Criação do documento Diagrama de Sequência inicial | [Caio Vinícius](https://github.com/caiovfernandes) e [Iuri Severo](https://github.com/iurisevero) | +| 26/09/2020| 1.1 | Colocando a imagem certa no módulo Estoque de Insumos| [João Pedro](https://github.com/sudjoao) | +| 02/11/2020| 1.2 | Adição do Diagrama de Sequencia V2 | [João Pedro](https://github.com/sudjoao) | + +
O Diagrama de Sequência é uma das soluções que a UML oferece, de maneira dinâmica para detalhar os fluxos de vida do sistema em desenvolvimento. O principal foco da elaboração desse diagrama é descrever sobre a interação entre componentes do sistema, processos e módulos que, de alguma maneira, vivem simultaneamente e trocam mensagens entre si.
+ +# Versão 2 +## Cadastro +Detalha o módulo de *Cadastro* do sistema, mostrando como funcionará o cadastro de um usuário, sua fazer e seus funcionários, respectivamente. + +
+
+ Clique aqui para ampliar
+
+**Autor:** [João Guedes](https://github.com/sudjoao)
+
+---
+
+## Cadastro de Bovino
+Detalha o módulo de *Cadastro de Bovino*, demonstrando como este fluxo funcionará no app, com o proprietário podendo cadastrar diferentes tipos de bovinos (de corte, de leite e bezerros).
+
+
+
+ Clique aqui para ampliar
+
+**Autor:** [João Guedes](https://github.com/sudjoao)
+
+---
+
+## Manejo
+Demonstra o módulo de *Manejo Bovino*, detalhando os diferentes tipos de manejo.
+
+
+
+ Clique aqui para ampliar
+
+**Autor:** [João Guedes](https://github.com/sudjoao)
+
+---
+
+## Estoque de Insumos
+Detalha o módulo *Estoque de Insumos*, que será responsável por gerenciar produtos de uma fazenda.
+
+
+
+ Clique aqui para ampliar
+
+**Autor:** [João Guedes](https://github.com/sudjoao)
+
+---
+
+## Relatório
+Demonstra o módulo de *Relatório*, que se trata de uma funcionalidade para auxiliar o Proprietário na tomada de decisão. Trazendo informções a partir de métricas utilizando os dados de seus recursos.
+
+
+
+ Clique aqui para ampliar
+
+**Autor:** [João Guedes](https://github.com/sudjoao)
+
+---
+
+
+
+
+## Referências
+**O que é um diagrama de sequência UML?**. [S. l.]. Disponível em: https://www.lucidchart.com/pages/pt/o-que-e-diagrama-de-sequencia-uml. Acesso em: 25 set. 2020.
+
+**Sequence Diagrams Reference**. Disponível em:
+https://www.uml-diagrams.org/sequence-diagrams-reference.html. Acesso em: 25 de set. 2020.
+
+PIMENTA, Matheus. **Diagramas de Sequência, PAX Wiki**. Acesso em: 25 de set. 2020. Disponível em: https://pax-app.github.io/Wiki/#/docs/DS/dinamica-e-seminario-3/DiagramaSequencia
+
+DEUSDERÁ, Guilherme. **Modelos Dinâmicos: API e Banco de Dados**. Acesso em: 25 de set. 2020. Disponível em: https://ads-unigrade-2019-1.github.io/Wiki/dinamica04/apiebanco/
+
+
diff --git a/docs/Modeling/StateDiagram.md b/docs/Modeling/StateDiagram.md
new file mode 100644
index 0000000..a741690
--- /dev/null
+++ b/docs/Modeling/StateDiagram.md
@@ -0,0 +1,46 @@
+# Diagrama de Estados
+
+| Data | Versão | Descrição | Autor(es) |
+| :--------: | :----: | :-------------------------------------: | :-------------------------------------------: |
+| 24/09/2020 | 1.0 | Criação do documento | [Guilherme Mendes](https://github.com/guilherme-mendes) e [Lucas Fellipe](https://github.com/lucasfcm9) |
+| 25/09/2020 | 1.1 | Adicionando diagramas v1.0 | [Guilherme Mendes](https://github.com/guilherme-mendes) e [Lucas Fellipe](https://github.com/lucasfcm9) |
+| 23/10/2020 | 1.2 | Adicionando diagramas v1.1 | [Iuri Severo](https://github.com/iurisevero) |
+| 23/10/2020 | 1.3 | Ajustando apresentação dos diagramas v1.0 | [Iuri Severo](https://github.com/iurisevero) |
+| 23/10/2020 | 2.0 | Revisão dos diagramas v1.1 |[Guilherme Mendes](https://github.com/guilherme-mendes) |
+
+
+
+
+
+
+O Diagrama de Estado consiste na representação de um estado ou situação em que um objeto se encontra no decorrer da execução dos processos de um sistema. É definido como um diagrama que descreve os comportamentos de um sistema. É uma maneira eficiente e clara de descrever todos os possíveis estados de um sistema, assim como quais eventos levam transição de um estado para o outro.
+ + +## Bovino - v1.1 + +
+ Clique aqui para ampliar+Autor(es): Iuri Severo + + Clique aqui para visualizar a versão 1.0
+Autor(es): Guilherme Mendes e Lucas Fellipe + + +## Autenticação do Usuário - v1.1 + +
+ Clique aqui para ampliar+Autor(es): Iuri Severo + + Clique aqui para visualizar a versão 1.0
+Autor(es): Guilherme Mendes e Lucas Fellipe + +## Relatório - v1.1 + +
+ Clique aqui para ampliar+Autor(es): Iuri Severo + + Clique aqui para visualizar a versão 1.0
+Autor(es): Guilherme Mendes e Lucas Fellipe + +## Referências + +* UML. State Machine Diagrams. [S. l.], 2020. Disponível em:
5W2H é uma ferramenta de gestão empregada no planejamento estratégico de empresas, análise de negócios, elaboração de planos de negócios, planejamento estratégico e outras áreas de gestão. Ela parte de uma meta para organizar as ações e determinar o que será feito para alcançá-la. Essa ferramenta baseia-se na elaboração de uma tabela formada por 7 perguntas: O quê? Por que? Quem? Onde? Quando? Como? Quanto custa?
+ +## Versão 1.0 - 5W2H + +| O quê? | Por que? | Quem? | Onde? | Quando? | Como? | Quanto custa? | +| :------------------------------------------------------: | :----------------------------------------------------------: | :----------------------------------------------------------: | :----------------------------------------------------------: | :----------------------------------------------------------: | :----------------------------------------------------------: | :--------------: | +| Um aplicativo para o gerenciamento e gestão da pecuária. | Hodiernamente, no mercado tem-se uma escassez de aplicativos para a gestão da pecuária. Além do mais, muitos proprietários de fazenda ainda utilizam ferramentas arcaicas, como papel e caneta, para o gerenciamento da fazenda e, principalmente, da pecuária. | Alunos de Engenharia de Software da Universidade de Brasília do Campus FGA-Gama que estão cursando a disciplina Desenho & Arquitetura de Software. Haverá a partipação de 2 stakeholders, que irão auxiliar no processo de desenvolvimento do software. Além disso, poderá ser utilizado por administradores e funcionários rurais, principalmente pecuaristas. | O projeto será realizado de forma remota devido a pandemia. O aplicativo será disponibilizado para dispositivos mobile - iOS e Android.| Será realizado no segundo semestre de 2020, nos meses de Agosto a Dezembro. O usuário poderá acessar o aplicativo em qualquer momento. Quando houver a necessidade de anotar informações, visualizar dados e gerar relatórios. | Por meio do desenvolvimento de um aplicativo mobile - iOS e Android, para facilitar a gestão rural de forma que o proprietário possa ter um controle sobre os dados dos bovinos, além de poder gerar relatórios a respeito da fazenda. O usuário poderá cadastrar as informações dos bovinos dentro do aplicativo, além de ter uma janela para que o usuário gere os relatórios especificados por ele. | ~ R$ 226.551,64 | + +Autor(es): [Lucas Fellipe](https://github.com/lucasfcm9) e [Caio Vinícius](https://github.com/caiovfernandes) + +## Referências +* GOMES, Luciano. 5W2H: Ferramenta para a elaboração de Planos de Ação. [S. l.], 18 jun. 2014. Disponível em: http://blog.iprocess.com.br/2014/06/5w2h-ferramenta-para-a-elaboracao-de-planos-de-acao/. Acesso em: 01 set. 2020. +* Endeavor Brasil. 5W2H: é hora de tirar as dúvidas e colocar a produtividade no seu dia a dia, 08 fev. 2017. Att 17 jun. 2020. Disponível em: https://endeavor.org.br/pessoas/5w2h/ Acesso em: 01 set. 2020. diff --git a/docs/Product/BPMN.md b/docs/Product/BPMN.md new file mode 100644 index 0000000..e4efb01 --- /dev/null +++ b/docs/Product/BPMN.md @@ -0,0 +1,116 @@ +# BPMN + +| Data | Versão | Descrição | Autor(es) | +| :--------: | :----: | :-----------------------: | :---------------------------: | +| 09/09/2020 | 0.5 | Criação do BPMN Geral |[Caio Vinícius](https://github.com/caiovfernandes), [Guilherme Mendes](https://github.com/guilherme-mendes), [Iuri Severo](https://github.com/iurisevero), [João Guedes](https://github.com/sudjoao) e [Lucas Fellipe](https://github.com/lucasfcm9) | +| 09/09/2020 | 0.9 | Criação de Sub-processo |[Iuri Severo](https://github.com/iurisevero) | +| 10/09/2020 | 1.0 | Adição de Sub-processos |[João Pedro José](https://github.com/sudjoao) | + +## Descrição + +A BPMN (Business Process Model and Notation) é uma notação gráfica utilizada para mapear processos utilizando várias simbologias padrões e mostrando de forma completa o que é o processo, quais suas etapas, o que estas etapas geram. O grupo resolveu utilizar essa modelagem para mostrar o fluxo que irá utilizar para o desenvolvimento de seu software e quais são as suas etapas e sub-etapas.
+ +## Processo Geral + +
+
+
+
+**Autor(es):** [Caio Vinícius](https://github.com/caiovfernandes), [Guilherme Mendes](https://github.com/guilherme-mendes), [Iuri Severo](https://github.com/iurisevero), [João Guedes](https://github.com/sudjoao) e [Lucas Fellipe](https://github.com/lucasfcm9)
+
+### Subprocesso - Definição do Projeto
+
+
+
+
+
+**Autor(es):** [Iuri Severo](https://github.com/iurisevero)
+
+### Subprocesso - Design Sprint
+
+
+
+
+
+**Autor(es):** [Iuri Severo](https://github.com/iurisevero)
+
+### Subprocesso - Desenvolvimento do Produto
+
+
+
+
+
+**Autor(es):** [Caio Vinícius](https://github.com/caiovfernandes), [Guilherme Mendes](https://github.com/guilherme-mendes), [Iuri Severo](https://github.com/iurisevero), [João Guedes](https://github.com/sudjoao) e [Lucas Fellipe](https://github.com/lucasfcm9)
+
+### Subprocesso - Planejamento da Sprint
+
+
+
+
+
+**Autor(es):** [Iuri Severo](https://github.com/iurisevero)
+
+### Subprocesso - Desenvolvimento das histórias de usuário
+
+
+
+
+
+**Autor(es):** [Iuri Severo](https://github.com/iurisevero) e [João Guedes](https://github.com/sudjoao)
+
+### Subprocesso - Sprint Review
+
+
+
+
+
+**Autor(es):** [Iuri Severo](https://github.com/iurisevero)
+
+### Subprocesso - Sprint Retrospective
+
+
+
+
+
+**Autor(es):** [Iuri Severo](https://github.com/iurisevero)
+
+### Subprocesso - Planning Poker
+
+
+
+
+
+**Autor(es):** [Iuri Severo](https://github.com/iurisevero)
+
+
+## Referências
+
+* TCU - CURSO DE MAPEAMENTO DE PROCESSOS DE TRABALHO COM BPMN E BIZAGI. Jan, 2019. Acesso em: 9 set. 2020.
+* Marcelo Neves - Curso de BPMN 2.0. Disponível em: O Brainstorming é uma atividade desenvolvida para explorar a potencialidade criativa de um indivíduo ou de um grupo colocando-a a serviço de objetivos pré-determinados. A técnica propõe que o grupo se reúna e utilize a diversidade de pensamentos e experiências para gerar soluções inovadoras, sugerindo qualquer pensamento ou ideia que vier à mente a respeito do tema tratado. Com isso, espera-se reunir o maior número possível de ideias, visões, propostas e possibilidades que levem a um denominador comum e eficaz para solucionar problemas e entraves que impedem um projeto de seguir adiante.
+ +### Realização do Brainstorming pelo grupo +Para a realização deste brainstoming, todos os membros do iGado se reuniram por videoconferência e juntamente com a ferramenta Miro, que é uma plataforma colaborativa online de "quadro branco", desenvolveram o brainstorming, adicionando as ideias em post-its virtuais por 20 minutos. +Após isso, passamos por todos os post-it's, para que os integrantes descrevessem suas ideias e então classificamo-as como:
+ +- Ideias que todos concordam+- Ideias descartadas
+- Ideias aceitas com alteração
+- Ideias repetidas
+ +
E então, por fim, agrupamos as ideias que todos concordam e ideias aceitas com alteração em:
+ +- Gado+- Relatório
+- Gastos
+- Informações de solo
+- Proprietário
+- App
+- Alimentação
+ +## Brainstorming + +
+
+**Autor(es):** [Caio Vinícius](https://github.com/caiovfernandes), [Guilherme Mendes](https://github.com/guilherme-mendes), [Iuri Severo](https://github.com/iurisevero), [João Guedes](https://github.com/sudjoao) e [Lucas Fellipe](https://github.com/lucasfcm9)
+
+### Significado das cores dos *Post-its*
+
+
+
+
+
+
+**Autor(es):** [Caio Vinícius](https://github.com/caiovfernandes), [Guilherme Mendes](https://github.com/guilherme-mendes), [Iuri Severo](https://github.com/iurisevero), [João Guedes](https://github.com/sudjoao) e [Lucas Fellipe](https://github.com/lucasfcm9)
+
+### Agrupamento de ideias por temas
+
+
+
+**Autor(es):** [Caio Vinícius](https://github.com/caiovfernandes), [Guilherme Mendes](https://github.com/guilherme-mendes), [Iuri Severo](https://github.com/iurisevero), [João Guedes](https://github.com/sudjoao) e [Lucas Fellipe](https://github.com/lucasfcm9)
+
+## Referências
+* BRAINSTORMING. In: WIKIPÉDIA: a enciclopédia livre. Wikimedia, 2020. Disponível em: O Design Sprint é um processo de cinco dias para responder a questões críticas de negócios por meio de design, prototipagem e ideias de teste com os clientes. Desenvolvido na GV, se tornou um "grande sucesso" de estratégia de negócios, inovação, ciência do comportamento, design thinking e mais - empacotado em um processo que qualquer equipe pode usar.
+ +Trabalhando juntos em uma sprint, você pode reduzir o ciclo de debates intermináveis e compactar meses de trabalho em uma única semana. Ao invés de esperar para lançar um mvp (produto mínimo) para entender se uma ideia é boa, você obterá dados claros de um protótipo realista. O sprint dá a você um superpoder: você pode avançar no futuro para ver seu produto acabado e as reações do cliente, antes de fazer qualquer compromisso caro.
+ +Resumidamente, as etapas do design sprint ocorrem da seguinte maneira: +- Na segunda-feira, você mapeará o problema e escolherá um lugar importante para enfocar. +- Na terça-feira, você esboçará soluções concorrentes no papel. +- Na quarta-feira, você tomará decisões difíceis e transformará suas ideias em uma hipótese testável. +- Na quinta-feira, você elaborará um protótipo de alta fidelidade. +- E na sexta-feira, você vai testá-lo com humanos vivos reais. + +--- +Para a matéria de Arquitetura e Desenho de software, utilizamos uma abordagem um pouco diferente, adaptando o processo de 5 dias para 2 dias apenas. +O primeiro dia foi composto por: Brainstorming e Rich Picture e o segundo por Storyboard e Protótipo de alta fidelidade
+ + + + +* [Brainstorming](/docs/Product/DesignSprint/Brainstorming.md) +* [Rich Picture](/docs/Product/DesignSprint/RichPicture.md) +* [StoryBoard](/docs/Product/DesignSprint/StoryBoard.md) +* [Protótipo de Alta Fidelidade](/docs/Product/DesignSprint/HighFidelityPrototype.md) + +## Referências +* DESIGN SPRINT. In: WIKIPÉDIA: a enciclopédia livre. Wikimedia, 2020. Disponível em:A partir dos Requisitos coletados durante a execução da Design Sprint, entrevistas e no questionário, o grupo resolveu fazer o primeiro protótipo de alta fidelidade do aplicativo. A ideia do protótipo de alta fidelidade foi realmente saber como o aplicativo funcionará e, também, ter uma base para seguirmos no desenvolvimento dele. Além disso, o grupo optou por fazer um protótipo com algumas animações para que ele se aproxime ao máximo do desejado. + + O protótipo foi feito no framer e ele permite que os campos de texto, botões, animações(como arrastar e as animações de troca de tela) e entre outras coisas possam ser adicionadas, ou seja, o protótipo está completamente funcional como se fosse um aplicativo já feito, na versão 1.0 todas as telas inicias já tinham sido feitas e é possível acessa-las a partir da barra de navegação inferior. + + O grupo planeja mostrar estes protótipos para alguns stakeholder para fazer um teste de usabilidade para que, antes de começar a implementar o software em si, tenham certeza de que o protótipo está de acordo com o esperado. + +
+ +## Versão 1.0 - Protótipo de Alta Fidelidade + +* Clique na imagem para abrir o protótipo de alta fidelidade em funcionamento. Todos os botões, barras de navegações e inputs são funcionais + + +
+
+
+**Autor:** [João Pedro Guedes](https://github.com/sudjoao)
+
+## Telas protótipo Versão 1.0
+* Clique na imagem para abrir todas as telas do protótipo desenhado pelo grupo
+
+
+
+
+## Referências
+* MACEDO, Gabriel. 10 heurísticas de Nilsen para o design de interface. 2 de agosto de 2017. Disponível em: Uma Rich Picture é um desenho de uma situação que ilustra os principais elementos e relacionamentos que precisam ser considerados na tentativa de intervir para criar alguma melhoria. Consiste em figuras, texto, símbolos e ícones, todos usados para ilustrar graficamente a situação. A Rich Picture ilustra a riqueza e a complexidade de uma situação.
+ +## Versão 1.0 - Rich Picture Geral ++ +
+
+**Autor(es):** [Caio Vinícius](https://github.com/caiovfernandes), [Guilherme Mendes](https://github.com/guilherme-mendes), [Iuri Severo](https://github.com/iurisevero), [João Guedes](https://github.com/sudjoao) e [Lucas Fellipe](https://github.com/lucasfcm9)
+
+## Versão 1.0 - Rich Picture Individual
++ +
+
+**Autor:** [Caio Vinícius](https://github.com/caiovfernandes)+ +
+
+**Autor:** [Guilherme Mendes](https://github.com/guilherme-mendes)+ +
+
+**Autor:** [Iuri Severo](https://github.com/iurisevero)+ +
+
+**Autor:** [João Guedes](https://github.com/sudjoao)+ +
+
+**Autor:** [Lucas Fellipe](https://github.com/lucasfcm9)
+
+## Referências
+* *Communicative Art, The Art of Rich Pictures.* Disponível em: A técnica de StoryBoard auxilia a identificação de requisitos utilizando cenários especificos onde é possível identificar os requisitos presentes naquele contexto relacionados ao projeto. São organizadores gráficos tais como uma série de ilustrações ou imagens arranjadas em sequência com o propósito de pré-visualizar um filme, animação ou gráfico animado, incluindo elementos interativos em websites. Assemelha-se a uma história em quadrinho.
+ + +## Versão 1.0 - StoryBoard + +
+
+**Autor:** [Caio Vinícius](https://github.com/caiovfernandes)+ +
+
+**Autor:** [Guilherme Mendes](https://github.com/guilherme-mendes)+ +
+
+**Autor:** [Iuri Severo](https://github.com/iurisevero)+ +
+
+**Autor:** [João Guedes](https://github.com/sudjoao)+ +
+
+**Autor:** [Lucas Fellipe](https://github.com/lucasfcm9)
+
+## Referências
+* Guia de Criatividade, 12 - Cartoon Story Board. Disponível em: O Diagrama de Ishikawa, ou Diagrama de Causa e Efeito, é um artefato utilizado para identificar as causas reais de um problema específico. Ele explora o problema principal de forma a montar uma árvore de subproblemas que são a causa do efeito encontrado, chegando a uma solução mais completa pra questão abordada.
+ +## Versão 1.0 - Diagrama de Ishikawa + +
+ Clique aqui para ampliar
+
+## Referências
+* Suporte Minitab - Visão geral de Diagrama de causa e efeito. Disponível em: Léxico é definido como um conjunto dos vocábulos de uma língua, dispostos em ordem alfabética e com as respectivas significações. Uma notação na modelagem de requisitos que usa a descrição de termos via léxico é o LAL (Léxico Ampliado da Linguagem).
+ +Trata-se de uma técnica que descreve os símbolos de uma linguagem. Esses símbolos são descritos com noções e impactos. A noção significa o símbolo, que pode ser colocado no sentido denotativo da linguagem. Já o impacto descreve o efeito/uso/ocorrência do símbolo na aplicação ou do efeito de algo na aplicação sobre o símbolo, que pode ser colocado no sentido conotativo da linguagem.
+ +Os léxicos podem ser definidos em objetos, estados, sujeitos e verbos.
+ +| **Nome** |Um [funcionário](/docs/Product/Lexicons?id=funcionário) pode aplicar a vacina em um determinado [bovino](/docs/Product/Lexicons?id=bovino)
O [proprietário](/docs/Product/Lexicons?id=proprietário) pode gerenciar o controle da quantidade de [vacinas](/docs/Product/Lexicons?id=vacina) por meio dos [insumos](/docs/Product/Lexicons?id=insumo) | + +### Bovino +| **Nome** | Bovino | +| ----------------- | ------------------------------------------------------------ | +| **Classificação** | Objeto | +| **Sinônimos** | Boi, Vaca, Gado, Animal, Rebanho | +| **Noção** | Objeto que será cadastrado no banco de dados do qual as suas informações serão extraídas | +| **Impacto** | Um [bovino](/docs/Product/Lexicons?id=bovino) pode ser cadastrado no aplicativo
O cadastro do [bovino](/docs/Product/Lexicons?id=bovino) será realizado por um [funcionário](/docs/Product/Lexicons?id=funcionário) ou pelo [proprietário](/docs/Product/Lexicons?id=proprietário)
As informações do [bovino](/docs/Product/Lexicons?id=bovino) poderão ser visualizadas a qualquer momento
As informações do [bovino](/docs/Product/Lexicons?id=bovino) poderão ser alteradas
Geração de [relatórios](/docs/Product/Lexicons?id=relatório) com os dados referentes aos [bovinos](/docs/Product/Lexicons?id=bovino) | + +### Funcionário +| **Nome** | Funcionário | +| ----------------- | ------------------------------------------------------------ | +| **Classificação** | Sujeito | +| **Sinônimos** | Empregado rural, Caseiro | +| **Noção** | [Funcionário](/docs/Product/Lexicons?id=funcionário) que trabalha na [fazenda](/docs/Product/Lexicons?id=fazenda), responsável por gerenciar o [gado](/docs/Product/Lexicons?id=bovino) e os [insumos](/docs/Product/Lexicons?id=insumo) | +| **Impacto** | O [funcionário](/docs/Product/Lexicons?id=funcionário) poderá coletar dados dos [bovinos](/docs/Product/Lexicons?id=bovino)
O [funcionário](/docs/Product/Lexicons?id=funcionário) poderá inserir informações sobre os [bovinos](/docs/Product/Lexicons?id=bovino) e os [insumos](/docs/Product/Lexicons?id=insumo) no aplicativo
Um [funcionário](/docs/Product/Lexicons?id=funcionário) pode cadastrar [bovinos](/docs/Product/Lexicons?id=bovino) e [insumos](/docs/Product/Lexicons?id=insumo)
Um [funcionário](/docs/Product/Lexicons?id=funcionário) pode editar seus dados, dados do [bovino](/docs/Product/Lexicons?id=bovino) e do [insumo](/docs/Product/Lexicons?id=insumo)
Um [funcionário](/docs/Product/Lexicons?id=funcionário) pode gerar [relatórios](/docs/Product/Lexicons?id=relatório) referentes aos [bovinos](/docs/Product/Lexicons?id=bovino) | + +### Proprietário +| **Nome** | [Proprietário](/docs/Product/Lexicons?id=proprietário) | +| ----------------- | ------------------------------------------------------------ | +| **Classificação** | Sujeito | +| **Sinônimos** | Fazendeiro, Dono da [fazenda](/docs/Product/Lexicons?id=fazenda), Pecuarista, Produtos Rural | +| **Noção** | Responsável por gerenciar a [fazenda](/docs/Product/Lexicons?id=fazenda) | +| **Impacto** | [Proprietário](/docs/Product/Lexicons?id=proprietário) pode coletar dados dos [bovinos](/docs/Product/Lexicons?id=bovino) e dos [insumos](/docs/Product/Lexicons?id=insumo)
[Proprietário](/docs/Product/Lexicons?id=proprietário) pode inserir e remover esses dados no aplicativo
[Proprietário](/docs/Product/Lexicons?id=proprietário) pode visualizar seus gastos e ter um controle sobre eles
[Proprietário](/docs/Product/Lexicons?id=proprietário) pode editar seus dados, dados dos [bovinos](/docs/Product/Lexicons?id=bovino) e dos [insumos](/docs/Product/Lexicons?id=insumo)
[Proprietário](/docs/Product/Lexicons?id=proprietário) pode gerar [relatórios](/docs/Product/Lexicons?id=relatório) referentes aos [bovinos](/docs/Product/Lexicons?id=bovino) e aos seus gastos
[Proprietário](/docs/Product/Lexicons?id=proprietário) pode adicionar mais de uma [fazenda](/docs/Product/Lexicons?id=fazenda) | + +### Relatório +| **Nome** | Relatório | +| ----------------- | ------------------------------------------------------------ | +| **Classificação** | Objeto | +| **Sinônimos** | Informações, Exposição de dados | +| **Noção** | Conjunto de informações utilizado para reportar resultados coletados da [fazenda](/docs/Product/Lexicons?id=fazenda) | +| **Impacto** | Gerar [relatórios](/docs/Product/Lexicons?id=relatório) sobre o estoque de alimentos, água, [vacinas](/docs/Product/Lexicons?id=vacina), etc...
Gerar [relatórios](/docs/Product/Lexicons?id=relatório) sobre os [bovinos](/docs/Product/Lexicons?id=bovino)
Gerar [relatórios](/docs/Product/Lexicons?id=relatório) sobre os gastos | + +### Manejar +| **Nome** | Manejar | +| ----------------- | ------------------------------ | +| **Classificação** | Verbo | +| **Sinônimos** | Manipular o [gado](/docs/Product/Lexicons?id=bovino), Manusear. | +| **Noção** | Transportar os [animais](/docs/Product/Lexicons?id=bovino) | +| **Impacto** | Gerar [relatórios](/docs/Product/Lexicons?id=relatório) a respeito dos vários tipos de [manejo](/docs/Product/Lexicons?id=manejar) realizados
O [funcionário](/docs/Product/Lexicons?id=funcionário) e o [proprietário](/docs/Product/Lexicons?id=proprietário) são capazes de [manejar](/docs/Product/Lexicons?id=manejar) o [gado](/docs/Product/Lexicons?id=bovino)
O [gado](/docs/Product/Lexicons?id=bovino) pode ser [manejado](/docs/Product/Lexicons?id=manejar)| + +### Fazenda +| **Nome** | Fazenda | +| ----------------- | ------------------------------------------------------------ | +| **Classificação** | Objeto | +| **Sinônimos** | [Propriedade rural](/docs/Product/Lexicons?id=proprietário), rancho, sítio | +| **Noção** | [Propriedade rural](/docs/Product/Lexicons?id=proprietário) de lavoura ou de criação de gado | +| **Impacto** | Cadastrar uma [fazenda](/docs/Product/Lexicons?id=fazenda)
Editar os dados referentes a uma [fazenda](/docs/Product/Lexicons?id=fazenda)
Adicionar um [proprietário](/docs/Product/Lexicons?id=proprietário) para a [fazenda](/docs/Product/Lexicons?id=fazenda) | + + +### Pasto +| **Nome** | Pasto | +| ----------------- | ------------------------------------------------------------ | +| **Classificação** | Objeto | +| **Sinônimos** | Alimento [bovino](/docs/Product/Lexicons?id=bovino), ração | +| **Noção** | Vegetação utilizada para a alimentação do [gado](/docs/Product/Lexicons?id=bovino) e extensão ou terreno onde o [gado](/docs/Product/Lexicons?id=bovino) é deixado para se alimentar | +| **Impacto** | Cadastrar uma [fazenda](/docs/Product/Lexicons?id=fazenda)
Editar os dados referentes a uma [fazenda](/docs/Product/Lexicons?id=fazenda)
Cadastrar um [bovino](/docs/Product/Lexicons?id=bovino)
Coletar dados do [bovino](/docs/Product/Lexicons?id=bovino)
Geração de [relatórios](/docs/Product/Lexicons?id=relatório) | + +### GMD +| **Nome** | GMD | +| ----------------- | ------------------------------------------------------------ | +| **Classificação** | Objeto | +| **Sinônimos** | [Ganho de Massa Diária](/docs/Product/Lexicons?id=gmd) | +| **Noção** | Índice referente ao ganho de massa diário de um [bovino](/docs/Product/Lexicons?id=bovino) | +| **Impacto** | A partir do [manejo](/docs/Product/Lexicons?id=manejar) de pesagem realizado no [bovino](/docs/Product/Lexicons?id=bovino) é possível calcular seu [Ganho de Massa Diário](/docs/Product/Lexicons?id=gmd)
[GMD](/docs/Product/Lexicons?id=gmd) é uma métrica para a geração de [relatórios](/docs/Product/Lexicons?id=relatório)
O [proprietário](/docs/Product/Lexicons?id=proprietário) da [fazenda](/docs/Product/Lexicons?id=fazenda) pode optar por vender um [gado](/docs/Product/Lexicons?id=bovino) por conta do seu [GMD](/docs/Product/Lexicons?id=gmd) | + +### RGD +| **Nome** | RGD | +| ----------------- | ------------------------------------------------------------ | +| **Classificação** | Objeto | +| **Sinônimos** | Registro genealógico definitivo | +| **Noção** | Condição para que os filhos desse [gado](/docs/Product/Lexicons?id=bovino) não apresentem nenhuma desclassificação racial | +| **Impacto** | [RGD](/docs/Product/Lexicons?id=rgd) é uma métrica para a geração de [relatórios](/docs/Product/Lexicons?id=relatório)
O [gado](/docs/Product/Lexicons?id=bovino) pode possuir o [RGD](/docs/Product/Lexicons?id=rgd) ao ser cadastrado no aplicativo
O [fazendeiro](/docs/Product/Lexicons?id=proprietário) pode deixar de comprar um [gado](/docs/Product/Lexicons?id=bovino) por ele não possuir [RGD](/docs/Product/Lexicons?id=rgd)
O [Registro genealógico definitivo](/docs/Product/Lexicons?id=rgd) do [gado](/docs/Product/Lexicons?id=bovino) pode ser adicionado após seu cadastro no aplicativo| + +### Hectare +| **Nome** | Hectare | +| ----------------- | ------------------------------------------------------------ | +| **Classificação** | Objeto | +| **Sinônimos** | Área, unidade de medida | +| **Noção** | Unidade de medida de área equivalente a 100 ares ou a 10 000 metros quadrados | +| **Impacto** | Ao cadastrar uma [fazenda](/docs/Product/Lexicons?id=fazenda) é necessário informar quantos [Hectares](/docs/Product/Lexicons?id=hectare) ela possui
A geração de [relatórios](/docs/Product/Lexicons?id=relatório) considera a [área](/docs/Product/Lexicons?id=hectare) da [fazenda](/docs/Product/Lexicons?id=fazenda) nos cálculos
Lucro Por [Hectare](/docs/Product/Lexicons?id=hectare) Por Ano | + +### Taxa de Lotação +| **Nome** | Taxa de Lotação | +| ----------------- | ------------------------------------------------------------ | +| **Classificação** | Objeto | +| **Sinônimos** | - | +| **Noção** | A [taxa de lotação](/docs/Product/Lexicons?id=taxa-de-lotação) é definida pelo número de animais dividido pela área do [pasto](/docs/Product/Lexicons?id=pasto) | +| **Impacto** | A [taxa de lotação](/docs/Product/Lexicons?id=taxa-de-lotação) depende da [fazenda](/docs/Product/Lexicons?id=fazenda) para ser calculada
Cadastrar [gado](/docs/Product/Lexicons?id=bovino) altera o valor da [taxa de lotação](/docs/Product/Lexicons?id=taxa-de-lotação)
Geração de [relatórios](/docs/Product/Lexicons?id=relatório) utiliza a [taxa de lotação](/docs/Product/Lexicons?id=taxa-de-lotação) como um dos dados | + +### Prenhez +| **Nome** | Prenhez | +| ----------------- | ------------------------------------------------------------ | +| **Classificação** | Estado | +| **Sinônimos** | Gravidez, fetação, gestação | +| **Noção** | Estado em que a [vaca](/docs/Product/Lexicons?id=bovino) está prenha | +| **Impacto** | Adicionar esse dado como verdadeiro se a [vaca](/docs/Product/Lexicons?id=bovino) estiver [prenha](/docs/Product/Lexicons?id=prenhez)
O [proprietário](/docs/Product/Lexicons?id=proprietário) pode saber se a vaca está [prenha](/docs/Product/Lexicons?id=prenhez) ou não
A [prenhez](/docs/Product/Lexicons?id=prenhez) pode trazer um custo benefício vantajoso ao [produtor rural](/docs/Product/Lexicons?id=proprietário) | + +### Gado de Corte +| **Nome** | Gado de Corte | +| ----------------- | ------------------------------------------------------------ | +| **Classificação** | Objeto | +| **Sinônimos** | Pecuária de corte | +| **Noção** | O [gado](/docs/Product/Lexicons?id=bovino) de corte é o [gado](/docs/Product/Lexicons?id=bovino) criado para a produção de carne | +| **Impacto** | Adicionar [gado](/docs/Product/Lexicons?id=bovino) de corte para obter metricas na geracão de [relatórios](/docs/Product/Lexicons?id=relatório) e lucros | + +### Gado de Leite +| **Nome** | Gado de Leite | +| ----------------- | ------------------------------------------------------------ | +| **Classificação** | Objeto | +| **Sinônimos** | Pecuária de leite | +| **Noção** | O [gado](/docs/Product/Lexicons?id=bovino) de leite é o [gado](/docs/Product/Lexicons?id=bovino) criado para a produção de leite | +| **Impacto** | Adicionar [gado](/docs/Product/Lexicons?id=bovino) de leite para obter métricas na geração de [relatórios](/docs/Product/Lexicons?id=relatório) e lucros com a venda de produtos lácteos
O [gado de leite](/docs/Product/Lexicons?id=gado-de-leite) pode entrar em estado de [prenhez](/docs/Product/Lexicons?id=prenhez) após sofrer um [manejo](/docs/Product/Lexicons?id=manejar) de reprodução| + +### Taxa de Desmama +| **Nome** | Taxa de Desmama | +| ----------------- | ------------------------------------------------------------ | +| **Classificação** | Objeto | +| **Sinônimos** | - | +| **Noção** | Representa o total de [bovinos](/docs/Product/Lexicons?id=bovino) desmamados em relação às [vacas](/docs/Product/Lexicons?id=bovino) expostas em reprodução dentro de um determinado período | +| **Impacto** | A geração de [relatórios](/docs/Product/Lexicons?id=relatório) utilizará a [Taxa de Desmama](/docs/Product/Lexicons?id=taxa-de-desmama) como um dos dados para cálculo| + +### Insumo +| **Nome** | Insumo | +| ----------------- | ------------------------------------------------------------ | +| **Classificação** | Objeto | +| **Sinônimos** | Matéria-prima, Material | +| **Noção** | Os insumos pecuários compreendem os produtos de uso veterinário, os produtos destinados à alimentação [animal](/docs/Product/Lexicons?id=bovino), o material genético [animal](/docs/Product/Lexicons?id=bovino) e do registro genealógico dos [animais](/docs/Product/Lexicons?id=bovino) | +| **Impacto** | O [fazendeiro](/docs/Product/Lexicons?id=proprietário) e o [funcionário](/docs/Product/Lexicons?id=funcionário) podem adicionar novos [insumos](/docs/Product/Lexicons?id=insumo), editar os [insumos](/docs/Product/Lexicons?id=insumo) já cadastrados ou apagá-los| + +## Referências +* Julio Leite. A Strategy for Conceptual Model Acquisition. IEEE 1992. +* Requisitos de Software - Wire, Léxicos. Disponível em:
A partir dos estudos realizados na disciplina, o grupo percebeu que não era possível ficar preso a apenas conceitos de uma metodologia em específico e, devido a isso, o grupo resolveu adaptar as principais partes de várias metodologias diferentes e fazer uma nova metodologia.
+ +## **Metodologia** + + + +**Autor:** [João Pedro Guedes](https://github.com/sudjoao) + +## **Scrum:** + +- **Burn-down Chart:** Um gráfico que relaciona o tempo com o trabalho planejado no backlog da sprint. O tempo é representado no eixo X e o trabalho restante no eixo Y. Conforme o tempo avança e os itens são retirados do backlog e concluídos, a linha traçada decai conforme o trabalho é realizado. A quantidade de trabalho pode ser avaliada de diversas maneiras, como pontos de história de usuário ou horas de trabalho. O gráfico de Burn-down foi escolhido pela equipe para ajudar a **avaliar o desempenho durante as sprints**. +- **Daily Scrum:** É um evento de aproximadamente 15 minutos que deve acontecer todos os dias da sprint. Nele, a equipe inspeciona o que foi realizado desde o último encontro e planeja o que será feito nas próximas 24 horas. A Daily acontece sempre no mesmo horário e local, para que sua complexidade seja reduzida. Por ser um evento que **melhora a comunicação dos membros** , o grupo optou por utilizar durante o desenvolvimento do projeto. +- **Planning Poker:** Planning Poker é um jogo de cartas com objetivo de auxiliar times de desenvolvimento scrum e ágil a escolher, de forma efetiva, seus objetivos para sprint, por meio de planejamento colaborativo e estimativas baseadas em consenso. +- **Product Backlog:** Artefato que consiste em uma lista ordenada do trabalho que precisa ser feito para que seja possível criar, manter e sustentar um produto. Foi escolhido pela equipe para uma **melhor organização das tarefas que serão realizadas**. +- **Sprint Backlog:** Artefato que providencia uma visão geral do trabalho de desenvolvimento que será realizado durante uma sprint. Auxilia na **organização das tarefas** e na visualização do objetivo da sprint e, devido a isso, foi adotado pela equipe. +- **Sprint Planning:** Evento onde o Backlog do Produto é revisado e as tarefas de maior valor são definidas para serem feitas na sprint seguinte, sendo adicionadas no Backlog da Sprint. +- **Sprint Retrospective:** Evento onde o time inspeciona a sprint passada e planeja possíveis melhorias que podem ser feitas na sprint seguinte. Um dos meios de se realizar a Sprint Restrospective é a partir do levantamento de pontos positivos, negativos e melhorias encontrados na sprint passada. +- **Sprint Review:** Momento onde o time se reúne para conclusão da sprint. Serve para todos envolvidos perceberem tudo o que foi feito durante a sprint e o quão de incremento isso trouxe para o produto. +- **Velocity** : Este artefato é utilizado para mostrar o quanto do backlog do produto foi realmente incrementando durante àquela sprint pelo time. O time resolveu utilizar isso, pois essa métrica ajuda bastante o **controle do escopo com o tempo limitado** existente devido ao desenvolvimento dentro de uma disciplina. + +## **XP:** + +- **Pair Programming:** Uma das mais, ou até a mais, técnica existente dentro da metodologia XP. Ela sugere que todo o código desenvolvido no projeto seja sempre implementado por 2 pessoas, onde a ideia é que as duas pessoas estejam juntas desenvolvendo e estejam utilizando apenas 1 computador. Esta técnica é utilizada, pois a programação por pares tem vários benefícios, como por exemplo, a **detecção de bugs**, pois fica mais fácil de ver quando os 2 estão juntos e **simplicidade** , pois existe a oportunidade de conversar e trocar ideias de qual o melhor jeito daquilo ser desenvolvido, entre vários outros benefícios; +- **Código coletivo:** A ideia desta técnica é que exista um revezamento nos pares do pair programming e que todos os desenvolvedores tenham liberdade para alterar o que quiser e a qualquer momento, isso faz com que as pessoas não precisem ficar esperando alguém autorizar ela para editar certa coisa que está errada fazendo elas ganharem tempo. O principal benefício desta prática é a **refatoração constante**. +- **Baby steps:** Esta prática se concentra muito na ideia de desenvolver o software incrementalmente, onde o grupo irá focar somente naquilo que é necessário naquele momento em específico e a cada iteração ele vai aumentando cada vez mais, até chegar no código final em si; +- **Equipe integral:** O conceito de equipe integral no XP significa a inserção de todos envolvidos no projeto em uma equipe em si, pois para um projeto ser bem sucedido é necessário escutar todas as pessoas que estão envolvidas nele. A principal ideia é conseguir algum tempo disponível onde todos os envolvidos consigam se encontrar para discutir sobre o projeto, e isso entra muito em alguns dos princípios do XP, que é a **comunicação** e o **feedback**. + +## **OpenUp:** + +- **Documento de Visão:** segundo a IBM, _"O documento de visão define o escopo de alto nível e o propósito de um programa, produto ou projeto. Uma instrução clara do problema, solução proposta e os recursos de alto nível do produto ajudam a estabelecer expectativas e a reduzir riscos. Este tópico fornece uma estrutura de tópicos de conteúdo potencial para o documento de visão."_ + +- **Glossário:** Lista de termos especiais utilizados no projeto e suas definições. O grupo escolheu utilizar pois existem vários termos técnicos utilizados na área de gestão rural. +- **Léxicos**: É definido como um conjunto dos vocábulos de uma língua, dispostos em ordem alfabética e com as respectivas significações. Uma notação na modelagem de requisitos que usa a descrição de termos via léxico é o LAL (Léxico Ampliado da Linguagem). +- **Protótipos:** Serão utilizados para planejar a interface visual e validar o escopo do software; +- **Modelo de Dados:** Modelagem de dados para auxiliar o desenvolvimento e definir as relações existentes dentro do projeto; +- **Disciplinas e Fases:** O grupo planeja utilizar as disciplinas e fases do OpenUP, porém, com a possibilidade de retornar uma fase, caso seja necessário. + +## **Kanban:** + +- **Visualização do fluxo de trabalho**: Consiste em ter um modelo visual do fluxo de trabalho da equipe, onde é possível identificar todas as tarefas e em qual etapa do processo ela se encontra. Diversos benefícios são resultantes dessa prática, como **transparência** e **identificação de desperdícios**, além do **aumento da comunicação** e **colaboração;** +- A equipe utilizará o **ZenHub** para o Kanban. + +## **Testes** + +O grupo trabalhará com testes unitários, além de testar as funcionalidades do aplicativo com stakeholders que demonstrarem interesse em participar. + +## **Papéis** + +Não serão adotados papéis, cada membro da equipe realizará as tarefas conforme preferir, o que permitirá uma maior experiência de todos em cada uma das áreas. + +## **Referências** + +- [https://www.scrum.org/resources/scrum-glossary](https://www.scrum.org/resources/scrum-glossary). Acesso em: 08 set. 2020. +- [https://www.planningpoker.com/about/](https://www.planningpoker.com/about/). Acesso em: 08 set. 2020. +- [http://www.desenvolvimentoagil.com.br/xp/praticas](http://www.desenvolvimentoagil.com.br/xp/praticas/programacao_par). Acesso em: 08 set. 2020. +- [https://www.culturaagil.com.br/kanban-do-inicio-ao-fim/](https://www.culturaagil.com.br/kanban-do-inicio-ao-fim/). Acesso em: 08 set. 2020. +- RAYA Rodolfo, Glossary Markup Language. Acesso em: 08 set. 2020. +- RAZAFINDRAMINSTA Jean et. al, ELABORATE LEXICON EXTENDED LANGUAGE WITH A LOT OF CONCEPTUAL INFORMATION. Acesso em: 08 set. 2020. \ No newline at end of file diff --git a/docs/Product/MindMap.md b/docs/Product/MindMap.md new file mode 100644 index 0000000..dd06d82 --- /dev/null +++ b/docs/Product/MindMap.md @@ -0,0 +1,21 @@ +# Mapa Mental +| Data | Versão | Descrição | Autor(es) | +| :--------: | :----: | :-----------------------: | :---------------------------: | +| 01/09/2020 | 1.0 | Criação do mapa mental baseado no Brainstormin feito durante a utilização do Design Sprint modificado | [Guilherme Mendes](https://github.com/guilherme-mendes) e [João Guedes](https://github.com/sudjoao) | +| 01/09/2020 | 1.1 | Aprimoramento do mapa mental | [João Guedes](https://github.com/sudjoao) | +| 03/10/2020 | 1.2 | Revisão do documento | [Iuri Severo](https://github.com/iurisevero) | + +Mapa Mental é uma técnica de memorização. O seu principal objetivo é associar ideias e pensamentos não lineares. Na etapa de elicitação de requisitos, ele foi utilizado como ideia de mostrar, de forma visual, quais serão os principais requisitos e as principais categorias que seriam abordadas no projeto. + + Este artefato foi elaborado a partir dos dados levantados no [Brainstorming](docs/Product/DesignSprint/Brainstorming.md) onde para facilitar a visualização, e seguindo as recomendações da professora, o grupo resolveu optar por fazer a documentação dessas informações utilizando este artefato. +
+ +## Versão 1.0 - Mapa Mental + +
+
+ Clique aqui para ampliar
+
+## Referências
+* FERNANDES, Wagner. Aprendar a criar um mapa mental efetivo, 04 nov. 2019. Disponível em:
+
+
+
+
+
+
+
+
+**Autor(es):** [Iuri Severo](https://github.com/iurisevero) e [João Guedes](https://github.com/sudjoao)
+
+## Respostas
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/docs/Product/RelationsMatrix.md b/docs/Product/RelationsMatrix.md
new file mode 100644
index 0000000..c2fac85
--- /dev/null
+++ b/docs/Product/RelationsMatrix.md
@@ -0,0 +1,44 @@
+# Matriz de Relações
+
+| Data | Versão | Descrição | Autor(es) |
+| :--------: | :----: | :-----------------------: | :---------------------------: |
+| 25/09/2020 | 1.0 | Criação do documento de Matriz de Relações|[Guilherme Mendes](https://github.com/guilherme-mendes) |
+| 26/09/2020 | 1.1 | Adição de requisitos funcionais baseados nas técnicas|[Guilherme Mendes](https://github.com/guilherme-mendes) |
+
+
+
+
+
+
+
+
+
+
+Durante o projeto foram utilizadas algumas técnicas (Brainstorming, Entrevista, Storyboard, Questionário e 5W2H) que contribuiram para a definição dos requisitos funcionais e não funcionais, que irão auxiliar futuramente na definição das funcionalidades do sistema.
+ +## Requisitos Funcionais +| ID | Descrição | Backward From | +| ---- | ------------------------------------------------------------ | ---------------------------------------------------------- | +| RF01 | Realização de cadastro e login como proprietário. | [Brainstorming](docs/Product/DesignSprint/Brainstorming) | +| RF02 | Realização de cadastro e login como funcionário. | [Brainstorming](docs/Product/DesignSprint/Brainstorming) | +| RF03 | Cadastro de gados de corte. | [Brainstorming](docs/Product/DesignSprint/Brainstorming)[Entrevista](/docs/Project/Interview)
[Storyboard](docs/Product/DesignSprint/StoryBoard)
[5W2H](/docs/Product/5W2H) | +| RF04 | Cadastro de gados de leite. | [Brainstorming](docs/Product/DesignSprint/Brainstorming)
[Entrevista](/docs/Project/Interview)
[5W2H](/docs/Product/5W2H) | +| RF05 | Adição de imagens dos bovinos. | [Brainstorming](docs/Product/DesignSprint/Brainstorming) | +| RF06 | Visualizar informações dos bovinos cadastrados. | [Brainstorming](docs/Product/DesignSprint/Brainstorming)
[Storyboard](docs/Product/DesignSprint/StoryBoard) | +| RF07 | Editar dados de bovinos cadastrados. | [Brainstorming](docs/Product/DesignSprint/Brainstorming)
[Entrevista](/docs/Project/Interview) | +| RF08 | Remover dados de bovinos cadastrados. | [Brainstorming](docs/Product/DesignSprint/Brainstorming)
[Entrevista](/docs/Project/Interview) | +| RF09 | Classificar bovinos, para filtrá-los de acordo com as métricas estabelecidas. | [Brainstorming](docs/Product/DesignSprint/Brainstorming)
[Entrevista](/docs/Project/Interview) | +| RF10 | Incluir informações de manejos obtendo uma melhor organização dos animais. | [Brainstorming](docs/Product/DesignSprint/Brainstorming)
[Entrevista](/docs/Project/Interview)
[Storyboard](docs/Product/DesignSprint/StoryBoard) | +| RF11 | Gerenciar nascimento de animais. | [Brainstorming](docs/Product/DesignSprint/Brainstorming)
[Entrevista](/docs/Project/Interview) | +| RF12 | Cadastro de vacinas, vermífugos e medicamentos aplicados nos bovinos. | [Brainstorming](docs/Product/DesignSprint/Brainstorming)
[Storyboard](docs/Product/DesignSprint/StoryBoard)
[Entrevista](/docs/Project/Interview) | +| RF13 | Inserções de gastos da propriedade de acordo com suas causas. | [Brainstorming](docs/Product/DesignSprint/Brainstorming)
[Questionário](docs/Product/Questionary) | +| RF14 | Inserções de lucros da propriedade de acordo com suas causas. | [Brainstorming](docs/Product/DesignSprint/Brainstorming)
[Questionário](docs/Product/Questionary) | +| RF15 | Visualizar gastos e lucros da propriedade. | [Brainstorming](docs/Product/DesignSprint/Brainstorming)
[Questionário](docs/Product/Questionary) | +| RF16 | Geração de relatórios mensais. | [Brainstorming](docs/Product/DesignSprint/Brainstorming)
[Entrevista](/docs/Project/Interview)
[Storyboard](docs/Product/DesignSprint/StoryBoard)
[5W2H](/docs/Product/5W2H) | +| RF17 | Geração de relatórios com as métricas IABCZ, PMGZ, GMD. | [Brainstorming](docs/Product/DesignSprint/Brainstorming)
[Entrevista](/docs/Project/Interview) | +| RF18 | Geração de relatórios sobre tipos de manejos. | [Brainstorming](docs/Product/DesignSprint/Brainstorming)
[Entrevista](/docs/Project/Interview)
[Storyboard](docs/Product/DesignSprint/StoryBoard) | +| RF19 | Geração de relatórios a respeito da produtividade de gados de corte. | [Brainstorming](docs/Product/DesignSprint/Brainstorming)
[Entrevista](/docs/Project/Interview)
[Storyboard](docs/Product/DesignSprint/StoryBoard) | +| RF20 | Geração de relatórios a respeito da produtividade de gados de leite. | [Brainstorming](docs/Product/DesignSprint/Brainstorming)
[Entrevista](/docs/Project/Interview)
[Storyboard](docs/Product/DesignSprint/StoryBoard) | +| RF21 | Inserção da quantidade de insumos para os bovinos. | [Brainstorming](docs/Product/DesignSprint/Brainstorming)
[Entrevista](/docs/Project/Interview)
[Storyboard](docs/Product/DesignSprint/StoryBoard)
[5W2H](/docs/Product/5W2H) | +| RF22 | Editar quantidade de insumos para os bovinos. | [Brainstorming](docs/Product/DesignSprint/Brainstorming)
[Entrevista](/docs/Project/Interview) | + +## Requisitos Não Funcionais + +| ID | Descrição | Backward From | +| ---- | ------------------------------------------------------------ | ---------------------------------------------------------- | +|RNF01| Deve possuir uma interface prática e intuitiva. | [Brainstorming](docs/Product/DesignSprint/Brainstorming)
[Entrevista](/docs/Project/Interview)
[Questionário](docs/Product/Questionary) | +| RNF02 | Disponível em multiplataformas independentes. | [Brainstorming](docs/Product/DesignSprint/Brainstorming)
[Storyboard](docs/Product/DesignSprint/StoryBoard) | +| RNF03 | Disponibilidade off-line. | [Brainstorming](docs/Product/DesignSprint/Brainstorming) | +| RNF04 | Relatórios de fácil entedimento. | [Entrevista](/docs/Project/Interview) | + diff --git a/docs/Product/VisionDocument.md b/docs/Product/VisionDocument.md new file mode 100644 index 0000000..e3c352c --- /dev/null +++ b/docs/Product/VisionDocument.md @@ -0,0 +1,249 @@ +# Documento de Visão + + +| Data | Versão | Divisão | Autor(es) | +| ---------- | ------ | ------------------------------------------------------------ | ------------------------ | +| 05/09/2020 | 1.0 | Abertura do documento | [Caio Vinícius](https://github.com/caiovfernandes) | +| 10/09/2020 | 1.1 | Tópico 4 - Visão Geral do Produto | [Iuri Severo](https://github.com/iurisevero) e [João Guedes](https://github.com/sudjoao) | +| 10/09/2020 | 1.2 | Tópico 3 e Tópico 6 - Descrição dos Envolvidos e dos Usuários e Restrições | [Lucas Fellipe](https://github.com/lucasfcm9) | +| 11/09/2020 | 1.3 | Tópico 7 – Outros Requisitos do Produto | [Caio Vinícius](https://github.com/caiovfernandes) | +| 11/09/2020 | 1.4 | Tópico 5 – Recursos do Produto | [Guilherme Mendes](https://github.com/guilherme-mendes) | +| 11/09/2020 | 1.5 | Tópico 1.2 – Escopo
Tópico 1.5 - Visão Geral
Tópico 2.1 - Oportunidade de Negócios | [Guilherme Mendes](https://github.com/guilherme-mendes), [João Guedes](https://github.com/sudjoao) e [Lucas Fellipe](https://github.com/lucasfcm9) | + + +## 1. Introdução + +#### 1.1 Propósito + +
A finalidade desse documento é informar ao leitor a respeito da aplicação de gerenciamento de campo, com foco em bovino e de gastos iGado. Para isso, serão apresentados diversos aspectos relacionados a esse software de forma a expressar claramente a visão dele.
+ +#### 1.2 Escopo + +O aplicativo iGado visa contribuir para o gerenciamento e gestão dos bovinos que se concentram em propriedades rurais. Nele será possível coletar informações dos bovinos e seus respectivos manejos. Também será possível ter um controle financeiro sobre os gastos e lucros advindos da fazenda e um maior controle do estoque de insumos. Além disso, o aplicativo terá a opção de extrair relatórios com índices e métricas definidas pelo usuário, com o inituito de facilitar tomadas de decisão além de gerar uma produtividade mais eficaz.
+ + +#### 1.3 Definições, acrônimos e abreviações + +| **Sigla** | **Definição** | +| --------- | ------------------------------------------------------------ | +| iGado | Nome do aplicativo que está sendo desenvolvido pela equipe de Desenho & Arquitetura de Software | +| FGA | Faculdade do Gama | +| Git | Sistema de controle de versão de código-fonte. Usado no desenvolvimento de software. | +| Telegram | Aplicativo de mensagens instantâneas | +| TI | Tecnologia da Informação | +| UnB | Universidade de Brasília | + + + +#### 1.4 Referências + +- IBM Knowledge Center - Documento de Visão: A estrutura de tópicos do documento de visão. Disponível em:Esse é um documento informativo sobre o Software iGado que está organizado no formato de tópicos e subtópicos sequenciais numerados. A ordem desses tópicos começa em 1 e termina em 7, sendo eles: introdução; posicionamento; descrições dos envolvidos e dos usuários; visão geral do produto; recursos do produto; restrições; e outros requisitos do produto.
+ +O documento de visão têm por objetivo representar de forma explicativa todas as informações sobre o projeto, para que os membros e os interessados do projeto sejam capazes de entender melhor do que se trata e ter noção de todas as funcionalidades, as restrições, os fatores de qualidade, entre outros, que serão descritos subsequentemente.
+ + +## 2. Posicionamento + +#### 2.1 Oportunidade de negócios + +A agropecuária desempenha um papel muito grande na economia brasileira. Ela é responsável por 30% do PIB e o Brasil é um dos maiores países quando se fala nesta área.
+A partir de entrevistas e questionários, o grupo percebeu que, atualmente, no mercado, existe a falta de um software simples e eficiente para gestão rural e, devido a isso, o grupo viu uma grande oportunidade de fazer um software que realmente seja simples e resolva o problema das pessoas envolvidas a isso.
+Nesse sentido, o iGado é um aplicativo que facilitará e automatizará os processos de gestão pecuária facilitando as tomadas de decisão e gerando uma produtividade mais eficaz, trazendo benefícios para os proprietários rurais e seus funcionários.
+ +#### 2.2 Descrição do problema +| O quê? | Por que? | Quem? | Onde? | Quando? | Como? | Quanto custa? | +| :------------------------------------------------------: | :----------------------------------------------------------: | :----------------------------------------------------------: | :----------------------------------------------------------: | :----------------------------------------------------------: | :----------------------------------------------------------: | :--------------: | +| Um aplicativo para o gerenciamento e gestão da pecuária. | Hodiernamente, no mercado tem-se uma escassez de aplicativos para a gestão da pecuária. Além do mais, muitos proprietários de fazenda ainda utilizam ferramentas arcaicas, como papel e caneta, para o gerenciamento da fazenda e, principalmente, da pecuária. | Alunos de Engenharia de Software da Universidade de Brasília do Campus FGA-Gama que estão cursando a disciplina Desenho & Arquitetura de Software. Haverá a partipação de 2 stakeholders, que irão auxiliar no processo de desenvolvimento do software. Além disso, poderá ser utilizado por administradores e funcionários rurais, principalmente pecuaristas. | O projeto será realizado de forma remota devido a pandemia. O aplicativo será disponibilizado para dispositivos mobile - iOS e Android.| Será realizado no segundo semestre de 2020, nos meses de Agosto a Dezembro. O usuário poderá acessar o aplicativo em qualquer momento. Quando houver a necessidade de anotar informações, visualizar dados e gerar relatórios. | Por meio do desenvolvimento de um aplicativo mobile - iOS e Android, para facilitar a gestão rural de forma que o proprietário possa ter um controle sobre os dados dos bovinos, além de poder gerar relatórios a respeito da fazenda. O usuário poderá cadastrar as informações dos bovinos dentro do aplicativo, além de ter uma janela para que o usuário gere os relatórios especificados por ele. | ~ R$ 226.551,64 | + +| **Informações do Produto** | | +| -------------------------- | ------------------------------------------------------------ | +| **O problema de** | Falta de uma aplicação que facilite o manejo e administração do campo e do gado. Além de organizar e armazenar dados. | +| **Afeta** | Fazendeiros e Administradores rurais. | +| **Cujo impacto é** | Facilitar a organização das informações dos bovinos. | +| **Uma boa solução seria** | Uso prático de uma aplicação de gerenciamento bovino e de custos. Que traz insights e relatórios para uma melhor tomada de decisão. | + + + +#### 2.3 Instrução de posição do produto //Fazer + + +## 3. Descrição dos Envolvidos e dos Usuários + +#### 3.1 Resumo dos Envolvidos + +| **Nome** | **Descrição** | **Responsabilidades** | +| --------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | +| Equipe de desenvolvimento de software | Estudantes da disciplina Arquitetura & Desenho de software da Universidade de Brasília. | Criar todos os artefatos referente ao produto, desenvolver e implementar o software descrito. Além disso, gerenciar tempo, escopo, riscos e tomadas de decisões para garantir a viabilidade do projeto. | +| Equipe de avaliação e suporte | Professora Milene e monitores da disciplina de Arquitetura & Desenho desoftware | Auxiliar a equipe durante a criação da documentação e no desenvolvimento do software. | + +#### 3.2 Resumo dos Usuários + +| **Nome** | **Descrição** | **Função** | +| -------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | +| Administradores e funcionários rurais. | Administradores e funcionários rurais que querem coletar dados de suas respectivas fazendas para um melhor gerenciamento. | Utilizar o aplicativo, manter a base de dados e realizar uma gestão mais eficiente de suas fazendas. | + + + +#### 3.3 Ambiente dos Usuários + +O aplicativo *mobile* poderá ser usado pelos usuários a partir dos sistemas operacionais Android e iOS. + +#### 3.4 Perfis do Envolvidos + +##### 3.4.1 Equipe de Desenvolvimento + + + +| **Representantes** | Caio Vinícius Fernandes de AraújoGuilherme Mendes Pereira
Iuri de Souza Severo Alves
João Pedro José Santos da Silva Guedes
Lucas Fellipe Carvalho Moreira | +| ---------------------------- | ------------------------------------------------------------ | +| **Descrição** | Equipe responsável pelo desenvolvimento e gerenciamento da aplicação | +| **Tipo** | Estudantes da disciplina de Arquitetura & Desenho de Software na Universidade de Brasília - FGA UnB/Gama | +| **Responsabilidades** | Desenvolver o software e gerenciar tempo, escopo, riscos e tomadas de decisões para garantir a viabilidade do projeto. Além disso, aplicar as metodologias definidas pela equipe | +| **Critérios de sucesso** | Entregar a documentação e o software com todas as funcionalidades definidas pela equipe e desejadas pelo público alvo dentro do prazo da disciplina | +| **Envolvimento** | Alto | +| **Comentários ou Problemas** | Inexperiência da equipe com as linguagens e tecnologias utilizadas para desenvolver o software | + +##### 3.4.2 Equipe de orientação + +| **Representante** | Prof. Milene Serrano | +| ---------------------------- | ------------------------------------------------------------ | +| **Descrição** | Equipe responsável pela avaliação e direcionamento do projeto | +| **Tipo** | Professora da disciplina Arquitetura & Desenho de Software | +| **Responsabilidades** | Direcionar e dar suporte a equipe de Desenho & Arquitetura de Software no desenvolvimento do produto | +| **Critérios de sucesso** | A entrega do produto juntamente com uma documentação coerente e coesa, a partir das orientações dadas ao decorrer do semestre | +| **Envolvimento** | Alto | +| **Comentários ou Problemas** | -- | + +#### 3.5 Perfis dos Usuários + +##### 3.5.1 Administradores e funcionários rurais + +| **Representantes** | Administradores e funcionários rurais | +| ------------------------- | ------------------------------------------------------------ | +| **Descrição** | Administradores e funcionários rurais que precisam coletar e gerenciar dados que são emitidos em relatórios | +| **Tipo** | Usuários com baixo ou médio conhecimento técnico | +| **Responsabilidades** | Coletar e gerenciar os dados, adicioná-los no aplicativo, cadastrar os bovinos e emitir relatórios dentro do aplicativo, facilitando o seu trabalho | +| **Critérios de sucesso** | O aplicativo deverá ser útil para adicionar os dados coletados de forma prática e intuitiva, contribuindo para um melhor gerenciamento, além de emitir relatórios específicos definidos pelo usuário. | +| **Comentários/Problemas** | Usuários com baixo conhecimento técnico em gestão de propriedades rurais e desafios de lidar com informações variadas. Além disso, não possuir celular com o sistema Android ou iOS | + +#### 3.6 Principais Necessidades dos Usuários ou dos Envolvidos + +| **Representantes** | **Necessidade** | **Prioridade** | **Solução Atual** | **Soluções propostas** | +| ------------------------------------- | ------------------------------------------------------------ | -------------- | ------------------------------------------------------- | ---------------------------------------------------------- | +| Administradores e funcionários rurais | Necessidade de armazenar os dados coletados, emissão de relatórios específicos de cada área da propriedade rural e cadastro dos bovinos de forma fácil e intuitiva | Alta | Armazenar os dados em planilhas físicas de forma manual | Automatizaresse processo para que seja algo fácil e rápido | + +#### 3.7 Alternativas e Concorrências + +##### 3.7.1 MultBovinos: Software de Gestão pecuária + +##### 3.7.2 BovControl: Gestão e controle do rebanho bovino + +##### 3.7.3 Suplemento Certo: Aplicativo destinado ao produtor de carne bovina + +##### 3.7.4 uBoi: Aplicativo com funções de compra e venda de gado + +## 4. Visão geral do Produto + +#### 4.1 Perspectiva do produto + +Os principais diferenciais do produto para os outros no mercado são: + +- Interface simples e intuitiva. A partir do questionário deu para perceber que um dos principais problemas dos aplicativos existentes é que são muito complicados de utilizar; +- Geração de relatórios que ajudam o proprietário e os funcionários a saberem como está o andamento da fazenda; +- Parte informativa no aplicativo para ajudar as pessoas que estão começando a gerenciar gados e não sabem o que fazer. + +#### 4.2 Funções do produto + +| **Benefício para o Cliente** | **Recursos de Suporte** | +| ------------------------------------------------------------ | ------------------------------------------------------------ | +| Cadastro e controle de gados pelo aplicativo | Eliminação do controle de dados utilizando papéis e planilhas | +| Compartilhamento de informações entre todos os funcionários da fazenda de maneira fácil | Todos que tiverem o aplicativo e conseguem ver as informações cadastradas sobre a fazenda a qual estão registrados | +| Relatórios informativos sobre a situação dos gados | A partir das informações inseridas pelos clientes será possível analisar os dados do animais. A partir disso serão feitos cálculos de alguns índices que ajudarão ao fazendeiro ver a produtividade de seus gados | +| Controle de gastos | Parte do aplicativo será voltada para o proprietário ver quanto gastou em um certo período de tempo e quanto lucrou com seus gados | +| Interface simples e intuitiva | Muitos dos funcionários das fazendas muitas vezes não tem uma educação muito estruturada então é necessário que o aplicativo seja o mais simples possível | +| Controle de insumos | Parte do aplicativo será voltada para mostrar o quanto de comida, capim e água ainda estão disponíveis na fazenda | + +#### 4.3 Suposições e dependências + +
Para o devido funcionamento do software é suposto que a equipe conseguirá desenvolvê-lo durante o período da disciplina de Arquitetura e Desenho de Software. Outro ponto são os custos do projeto, que a equipe não tem como arcar sem ajuda, o que possivelmente impedirá o lançamento final do produto, principalmente na App Store que cobra anuidade.
+ +#### 4.4 Custo e precificação + +O produto será disponibilizado gratuitamente na Play Store e na App Store, tendo como custo as despesas relacionadas às equipes de desenvolvimento e gerenciamento do projeto, ao lançamento do produto nos aplicativos de distribuição e aos valores pagos para manter seus servidores em funcionamento.
+ +#### 4.5 Licenciamento e instalação + +###### 4.5.1 Licenciamento + +O licenciamento do produto será do tipo GNU General Public License v3.0, que permite outras pessoas copiarem os arquivos deste software, porém com algumas condições. Essas são:
+ +- Divulgar fonte: O código-fonte deve ser disponibilizado quando o material licenciado for distribuído; +- Licença e aviso de direitos autorais: Uma cópia da licença e aviso de direitos autorais deve ser incluída com o material licenciado; +- Mesma licença (biblioteca): As modificações devem ser liberadas sob a mesma licença ao distribuir o material licenciado. Em alguns casos, uma licença semelhante ou relacionada pode ser usada; +- Mudanças de estado: As alterações feitas no material licenciado devem ser documentadas; + +###### 4.5.2 Instalação + +O produto será disponibilizado na Play Store e na App Store, e sua instalação seguirá os padrões apresentados por essas empresas. Bastará pesquisá-lo na loja referente ao seu sistema operacional e instalá-lo a partir dela.
+ +## 5. Recursos do Produto + +#### 5.1 Cadastro de usuário + +Proprietários e funcionários devem realizar o cadastro de seus respectivos perfis para acesso ao aplicativo, contendo suas informações básicas. O perfil de proprietário terá acesso à todos os relatórios de gestão do rebanho, lucros e gastos e os funcionários serão restritos de ver todos os dados.
+ +#### 5.2 Cadastro de bovinos + +Será possível cadastrar gados de corte/leite com todas as informações necessárias para obter resultados efetivos no gerenciamento do rebanho.
+ +#### 5.3 Relatórios + +O usuário poderá gerar diferentes tipos de relatórios com informações, indices e métricas que contribuirá para organização, gestão e administração dos bovinos.
+ +#### 5.4 Controle de insumos + +A aplicação permitirá a inserção e edição da quantidade de insumos disponível para ter o controle da quantidade de insumos no estoque.
+ +## 6. Restrições + +- O aplicativo deve estar em funcionamento até dezembro; +- Ter um aparelho celular com o sistema Android ou iOS; + + + +#### 6.1 Restrições Externas + +Dentre as restrições externas, as que mais podem influenciar são a inexperiência com as linguagens e tecnlogias definidas pela equipe, além de possíveis transtornos entre a equipe.
+ + + +#### 6.2 Restrições de Design + +Toda a interação com o software deve ser feita de forma natural, de modo que o usuário não tenha dúvidas sobre como realizar determinada tarefa dentro do aplicativo. Os recursos cujo usuários têm acesso devem ser de fácil entendimento, de modo que o usuário não desista durante alguma ação. Para alcançar um maior público, o aplicativo será desenvolvido para Android e iOS.
+ + +#### 6.3 Restrições de Confiabilidade + +Visando uma maior manutenibilidade e confiabilidade do projeto pela comunidade, a equipe tem um comprometimento de manter uma cobertura de testes mínima de 90%.
+ +## 7. Outros Requisitos do Produto + +#### 7.1 Requisitos do Sistema + +Nós ofereceremos suporte e recomendamos o uso dos seguintes sistemas operacionais: + +- Android 4.0.3 e versões posteriores +- iPhone iOS 9 e versões posteriores + +#### 7.2 Requisitos de Desempenho + +O sistema será dimensionado para suprir a necessidade de uma aplicação acessível à grande maioria dos aparelhos. Sendo assim, o desempenho do aparelho será um fator de mínima importância para o acesso, porém de alta relevância para a obtenção de um melhor desempenho do iGado. \ No newline at end of file diff --git a/docs/Project/ArchitectureDocument.md b/docs/Project/ArchitectureDocument.md new file mode 100644 index 0000000..ee3171b --- /dev/null +++ b/docs/Project/ArchitectureDocument.md @@ -0,0 +1,356 @@ +# **Documento de Arquitetura de Software** + +## **Histórico de Revisão** + +| **Data** | **Versão** | **Descrição** | **Autor(es)** | +| --- | --- | --- | --- | +| 04/11/2020 | 0.1 | Criação do Documento | [Caio Vinícius](https://github.com/caiovfernandes), [Guilherme Mendes](https://github.com/guilherme-mendes), [Iuri Severo](https://github.com/iurisevero), [João Guedes](https://github.com/sudjoao) e [Lucas Fellipe](https://github.com/lucasfcm9) | +| 04/11/2020 | 0.2 | Tópico 1 - Introdução | [Caio Vinícius](https://github.com/caiovfernandes), [Guilherme Mendes](https://github.com/guilherme-mendes), [Iuri Severo](https://github.com/iurisevero), [João Guedes](https://github.com/sudjoao) e [Lucas Fellipe](https://github.com/lucasfcm9) | +| 04/11/2020 | 0.3 | Tópico 2 - Representação Arquitetural | [Caio Vinícius](https://github.com/caiovfernandes), [Guilherme Mendes](https://github.com/guilherme-mendes), [Iuri Severo](https://github.com/iurisevero), [João Guedes](https://github.com/sudjoao) e [Lucas Fellipe](https://github.com/lucasfcm9) | +| 04/11/2020 | 0.4 | Tópico 3 – Metas e Restrições de Arquitetura | [Caio Vinícius](https://github.com/caiovfernandes), [Guilherme Mendes](https://github.com/guilherme-mendes), [Iuri Severo](https://github.com/iurisevero), [João Guedes](https://github.com/sudjoao) e [Lucas Fellipe](https://github.com/lucasfcm9) | +| 05/11/2020 | 0.5.1 | Tópico 4 – Casos de Uso - Diagramas e Fluxos Básicos | [Iuri Severo](https://github.com/iurisevero), [João Guedes](https://github.com/sudjoao) | +| 05/11/2020 | 0.5.2 | Tópico 4 – Casos de Uso - Descrição dos Casos de Uso e Fluxos Alternativos | [Iuri Severo](https://github.com/iurisevero), [João Guedes](https://github.com/sudjoao) | +| 09/11/2020 | 0.6 | Tópico 5 – Lógico: Diagrama de Pacotes | [Caio Fernandes](https://github.com/caiovfernandes), [Lucas Fellipe](https://github.comlucasfcm9)| +| 09/11/2020 | 0.7 | Tópico 6 - Visão de Processos | [Guilherme Mendes](https://github.com/guilherme-mendes) | +| 05/11/2020 | 0.8 | Tópico 4 – Casos de Uso - Adição de Todos os Fluxos Alternativos | [Iuri Severo](https://github.com/iurisevero), [João Guedes](https://github.com/sudjoao) | +| 09/11/2020 | 0.9 | Tópico 9 - Qualidade | [Guilherme Mendes](https://github.com/guilherme-mendes) | +| 11/11/2020 | 1.0 | Tópico 7 - Visão de Implementação - Diagrama de Classes e Diagrama Entidade Relacionamento | [Caio Fernandes](https://github.com/caiovfernandes), [Lucas Fellipe](https://github.comlucasfcm9) | +| 11/11/2020 | 1.1 | Tópico 8 - Tamanho e Desempenho | [Lucas Fellipe](https://github.comlucasfcm9) | +| 16/11/2020 | 1.2 | Revisão do Documento | [Lucas Fellipe](https://github.comlucasfcm9) | +| 17/11/2020 | 1.3 | Revisão dos artefatos do Documento de Arquitetura | [Guilherme Mendes](https://github.com/guilherme-mendes) | + +### **1. Introdução** + +#### **1.1. Finalidade** + +Este documento oferece uma visão geral arquitetural abrangente do sistema, usando diversas visões arquiteturais para representar diferentes aspectos do sistema. O objetivo deste documento é capturar e comunicar as decisões arquiteturais significativas que foram tomadas em relação ao sistema.
+ +#### **1.2. Escopo** + +iGado é um aplicativo que visa contribuir o gerenciamento e gestão dos bovinos que se concentram em propriedades rurais. Neste documento será detalhado os padrões arquiteturais relacionados ao aplicativo iGado desenvolvido durante a disciplina de Arquitetura e Desenho de Software, da Universidade de Brasília (UnB).
+ +#### **1.3. Referências** + +- [https://pax-app.github.io/Wiki/#/docs/DS/dinamica-e-seminario-4-b/DAS](https://pax-app.github.io/Wiki/#/docs/DS/dinamica-e-seminario-4-b/DAS) +- [https://desenhosoftware-2018-2.github.io/wiki/docArquitetura](https://desenhosoftware-2018-2.github.io/wiki/docArquitetura) +- [https://octa-bit.github.io/ForceGamaAttack/das.html](https://octa-bit.github.io/ForceGamaAttack/das.html) +- [https://fga-eps-mds.github.io/2019.1-ADA/#/docs/project/architecture\_doc?id=documento-de-arquitetura](https://fga-eps-mds.github.io/2019.1-ADA/#/docs/project/architecture_doc?id=documento-de-arquitetura) +- https://fga-eps-mds.github.io/2019.1-Aix/projeto/2019/03/29/documento-de-arquitetura/ +- Conceitos Fundamentais – Testes de Software, Semestre 1/2020 +- [https://requisitos-de-software.github.io/2019.2-Wire/#/docs/modeling/user\_cases/user\_cases?id=m%c3%b3dulos-dos-casos-de-uso](https://requisitos-de-software.github.io/2019.2-Wire/#/docs/modeling/user_cases/user_cases?id=m%C3%B3dulos-dos-casos-de-uso) + +#### **1.4. Visão Geral** + +Esse é um documento informativo sobre o Software iGado que está organizado no formato de tópicos e subtópicos sequenciais numerados. A ordem desses tópicos começa em 1 e termina em 9, sendo eles: Introdução; Representação Arquitetural; Metas e Restrições da Arquitetura; Visão de Casos de Uso; Visão Lógica; Visão da Implementação; Tamanho e Desempenho e Qualidade.
+ +### **2. Representação Arquitetural** + +Modelo de representação da arquitetura e as interações estabelecidas entre os módulos, bem como a natureza dessas interações.
+ +#### **2.1 - Visão Geral** + +
+ + +#### **2.2 - Tecnologias** + +#### 2.2.1 Front End + + - **Flutter:** Flutter é o kit de ferramentas da Google para desenvolvimento de interfaces de usuário bonitas, com aplicações compiladas nativamente para mobile, web e desktop a partir de uma única base de código. A linguagem Dart é utilizada como base para essas ferramentas. + - **Dart:** Dart é uma linguagem de programação otimizada para desenvolvimento. Será utilizada no front-end para desenvolvimento de algoritmos lógicos e conexões com o back-end. + +#### 2.2.2 Back End + + - **Flask:** O Flask é um micro framework para Python baseado em Werkzeug, Jinja 2 e good intentions. Ao contrário de outros web frameworks, o Flask não tem uma camada adicional de acesso ao banco de dados, com isso, a integração com toolkits de banco de dados facilita o seu uso. + + Essa arquitetura será utilizada para a construção da API, que vai ser um dos pontos principais do projeto. Através da API, a aplicação irá se comunicar com a camada de front-end sem o conhecimento ou intervenção dos usuários, definindo comportamentos específicos de determinado objeto em uma interface. + + - **Python –** Python é uma linguagem de programação que permite você desenvolver mais rapidamente e de uma forma mais efetiva, ela será utilizada para desenvolvimento de algoritmos lógicos no back-end. + - **Docker:** Ferramenta utilizada para gerar um ambiente isolado a partir da criação de contêineres que suprem as dependências do projeto, o que facilita a utilização de serviços distintos. + +#### 2.2.3 Banco de Dados + + - **PostgreSQL:** É um sistema gerenciador de banco de dados open-source (código aberto) de objeto relacional que possui uma forte reputação de confiabilidade, robustez e desempenho. Será utilizado para armazenar os dados provenientes da API. + +### **3. Metas e Restrições da Arquitetura** + +#### **3.1 - Restrições** + + - O software deve ser desenvolvido nas tecnologias definidas no tópico 2; + - O software deve rodar tanto em Android quanto em iOS; + - O ambiente de desenvolvimento do software deve funcionar tanto em Windows, Linux e MacOS; + - Para utilizar o software é necessário ter internet; + - O escopo do projeto deve ser concluído até o final da disciplina. + +#### **3.2 - Metas** + +As metas planejadas para o aplicativo são: + + - **Portabilidade** – Deve ser possível utilizar o aplicativo tanto em sistemas Android quanto iOS. + - **Usabilidade** - O software deve possuir alta aprendibilidade e inteligibilidade, para que atenda aos requisitos elicitados no formulário criado pelo grupo; + - **Manutenibilidade –** O código e as documentações realizadas pelo grupo devem estar num nível de qualidade, seguindo os padrões de projeto e bibliografia, onde a sua manutenção seja fácil de ser realizada. + +### **4. Visão de Casos de Uso** + +Para representação dos Casos de Uso do sistema especificado, foram criados três diagramas referentes a módulos distintos do aplicativo, o módulo de bovinos, o módulo de manejos e o módulo de relatórios. Esses módulos serão apresentados a seguir: + +#### **4.1 - Módulo de Bovinos** + +**Diagrama de Casos de Uso** + +
+
+**Especificação dos Casos de Uso**
+
+| Caso de Uso | Ator | Descrição |
+| --- | --- | --- |
+| **UC01 –** Register Cattle | User | Este caso de uso ocorre quando o usuário registra um novo gado |
+| **UC02 –** Visualize Cattle | User | Este caso de uso ocorre quando o usuário seleciona um gado para visualizar os dados |
+| **UC03 –** Perform Management | User | Este caso de uso permite o usuário realizar uma manejo no bovino |
+| **UC04 –** Edit Cattle | User | Este caso de uso permite o usuário editar os dados do bovino |
+| **UC05 –** Delete Cattle | User | Este caso de uso permite o usuário deletar um bovino |
+
+**Fluxo de Eventos**
+
+**UC01** - Register Cattle
+
+**Fluxo básico**
+
+O usuário registra um novo gado e visualiza os dados cadastrados na tela do bovino.
+
+**Fluxos alternativos**
+
+**FA1 –** Perform Management
+
+O usuário seleciona um bovino para visualizar e, após isso, seleciona a opção de realizar um manejo.
+
+**FA2 –** Edit Cattle
+
+O usuário seleciona um bovino para visualizar e, após isso, edita os dados daquele bovino.
+
+**FA3 –** Delete Cattle
+
+O usuário seleciona um bovino para visualizar e, após isso, deleta o bovino.
+
+**4.2 - Módulo de Manejos**
+
+**Diagrama de Casos de Uso**
+
+
+
+**Especificação dos Casos de Uso**
+
+| Caso de Uso | Ator | Descrição |
+| --- | --- | --- |
+| **UC03 –** Perform Management | User | Este caso de uso permite o usuário realizar uma manejo no bovino |
+| **UC06 –** Select desired management | User | Este caso de uso ocorre quando o usuário seleciona um manejo para realizar |
+| **UC07 –** Perform reproduction management | User | Este caso de uso se refere a realização dos manejos de reprodução |
+| **UC08** – Select reproduction type | User | Este caso de uso ocorre quando o usuário seleciona o tipo de reprodução realizado no manejo de reprodução |
+| **UC09** – Perform weighing management | User | Este caso de uso se refere a realização dos manejos de pesagem |
+| **UC10** – Inform Cattle actual status | User | Este caso de uso se refere ao usuário inserir as informações necessárias para o manejo de pesagem |
+| **UC11** – Get average weight per Cattle | User | Este caso de uso se refere ao usuário gerar o manejo para um bovino específico |
+| **UC12** – Get average weight per batch | User | Este caso de uso se refere ao usuário gerar o manejo para todo um lote de bovinos |
+| **UC13** – Perform sanitary management | User | Este caso de uso se refere a realização dos manejos sanitários |
+| **UC14** – Select medicine | User | Este caso de uso ocorre quando o usuário seleciona o tipo de medicamento aplicado no manejo sanitário |
+
+**Fluxo de Eventos**
+
+**UC03** - Perform Management
+
+**Fluxo básico**
+
+O usuário decide realizar um manejo e seleciona o manejo que ele deseja realizar
+
+**Fluxos alternativos**
+
+**FA1 –** Perform reproduction management
+O usuário seleciona o manejo de reprodução e então insere as informações sobre que tipo de reprodução está sendo realizada.
+
+**FA2 –** Perform sanitary management
+O usuário seleciona o manejo sanitário e então insere as informações do medicamento que será utilizado no manejo.
+
+**FA3 –** Perform weighing management
+O usuário seleciona o manejo de pesagem e então insere as informações relacionadas ao peso atual do bovino.
+
+**FA4 –** Perform weighing management
+O usuário seleciona o manejo de pesagem e então insere as informações relacionadas ao peso atual do bovino.
+
+**FA5 –** Perform weighing management
+O usuário seleciona o manejo de pesagem e então insere as informações relacionadas ao peso atual do bovino.
+
+**FA6 –** Get average weight per cattle
+O usuário durante o manejo de pesagem seleciona a opção de pegar informações de manejo de apenas um bovino.
+
+**FA7 –** Get average weight per batch
+O usuário durante o manejo de pesagem seleciona a opção de pegar informações de manejo de um lote de bovinos.
+
+**4.3 - Módulo de Relatórios**
+
+**Diagrama de Casos de Uso**
+
+
+
+**Especificação dos Casos de Uso**
+
+| Caso de Uso | Ator | Descrição |
+| --- | --- | --- |
+| **UC15 –** Generate report | User | Este caso de uso permite o usuário gerar um relatório|
+| **UC16** – Select data report | User | Este caso de uso se refere ao usuário selecionar qual tipo de relatório quer gerar |
+| **UC17** – Generate general report | User | Este caso de uso se refere ao usuário gerar o relatório geral da fazenda |
+| **UC18** – Generate GMD report | User | Este caso de uso se refere ao usuário gerar o relatório com as informações do ganho de massa diário do bovino|
+| **UC19** – Generate IABCZ report | User | Este caso de uso se refere ao usuário gerar o relatório com as informações indice ABCZ|
+| **UC20** – Generate PMGZ report | User | Este caso de uso se refere ao usuário gerar o relatório com as informações do índice PMGZ|
+| **UC21** – Select management report | User | Este caso de uso se refere ao usuário selecionar um relatório do tipo manejo |
+| **UC22** – Generate reproductive management report | User | Este caso de uso se refere ao usuário gerar o relatório com as informações do manejo reprodutivo |
+| **UC23** – Generate weighing management report | User | Este caso de uso se refere ao usuário gerar o relatório com as informações do manejo de pesagem|
+| **UC24** – Generate sanitary management report | User | Este caso de uso se refere ao usuário gerar o relatório com as informações do manejo sanitário |
+
+**Fluxo de Eventos**
+
+**UC15** - Generate report
+
+**Fluxo básico**
+
+O usuário decide gerar um relatório e seleciona o tipo de relatório que será gerado
+
+**Fluxos alternativos**
+
+**FA1 –** Generate geral report
+O usuário seleciona a opção de gerar o relatório geral com todas as informações da fazenda.
+
+**FA2 –** Generate GMD report
+O usuário seleciona a opção de gerar o relatório com informações da métrica GMD (Ganho de Massa Diária).
+
+**FA3 –** Generate IABCZ report
+O usuário seleciona a opção de gerar o relatório com informações do índice ABCZ.
+
+**FA4 –** Generate PMGZ report
+O usuário seleciona a opção de gerar o relatório com informações do índice PMGZ.
+
+**FA5 –** Select management reprot
+O usuário seleciona a opção de gerar relatório de manejos e pode selecionar um dos relatórios disponíveis.
+
+**FA6 –** Generate reproductive management report
+O usuário seleciona a opção de gerar o relatório com as informações do manejo de reprodução.
+
+**FA7 –** Generate weighing management report
+O usuário seleciona a opção de gerar o relatório com as informações do manejo de pesagem.
+
+**FA8 –** Generate sanitary management report
+O usuário seleciona a opção de gerar o relatório com as informações do manejo sanitário.
+
+### **5. Visão Lógica**
+
+A visão lógica descreve como o sistema é estruturado, em termos de unidade e implementação. Mostra como está a organização conceitual do sistema em termos de camadas, pacotes, classes e interfaces. O relacionamento entre os elementos mostra as dependências, as realizações de interface, os relacionamento parte-todo e assim por diante. + +#### **5.1 Diagrama de Pacotes** + +
Os diagramas de pacotes mostram a interação entre as relações das pastas e seus arquivos. Tem como objetivo estruturar hierarquicamente as pastas que compõem o projeto.
+
+A sua rastreabilidade pode ser acompanhada [aqui](https://unbarqdsw.github.io/2020.1_G13_iGado/#/docs/Modeling/PackageDiagram).
+
+
+
+
+
+
+
+
+
+### **6. Visão de Processos**
+
+#### **6.1 Visão Geral**
+
+
A Visão de Processos tem como objetivo descrever a estrutura de processos do sistema. Tendo como base uma visualização em sequência para mostrar como será feito o modelo do projeto.
+ +#### **6.2 Diagrama de Sequência** + +O Diagrama de Sequência é uma das soluções que a UML oferece, de maneira dinâmica para detalhar os fluxos de vida do sistema em desenvolvimento. O principal foco da elaboração desse diagrama é descrever sobre a interação entre componentes do sistema, processos e módulos que, de alguma maneira, vivem simultaneamente e trocam mensagens entre si. Os ciclos de vida podem ser classes, atores ou até mesmo abstrações que ocorrem entre as classes.
+ +#### **6.2.1 Cadastro de Usuário** + +Detalha o módulo de Cadastro de Usuário do sistema, mostrando como funcionará o cadastro de um usuário, sua fazer e seus funcionários, respectivamente.
+ +
+
+ Clique aqui para ampliar
+
+#### **6.2.2 Cadastro de Bovino**
+
+Detalha o módulo de Cadastro de Bovino, demonstrando como este fluxo funcionará no app, com o proprietário podendo cadastrar diferentes tipos de bovinos (de corte, de leite e bezerros).
+ +
+
+ Clique aqui para ampliar
+
+#### **6.2.3 Manejo**
+
+Demonstra o módulo de Manejo Bovino, detalhando os diferentes tipos de manejo.
+ +
+
+ Clique aqui para ampliar
+
+#### **6.2.4 Estoque de Insumos**
+
+Detalha o módulo Estoque de Insumos, que será responsável por gerenciar produtos de uma fazenda.
+ +
+
+ Clique aqui para ampliar
+
+#### **6.2.5 Relatório**
+Demonstra o módulo de *Relatório*, que se trata de uma funcionalidade para auxiliar o Proprietário na tomada de decisão. Trazendo informções a partir de métricas utilizando os dados de seus recursos.
+ +
+
+ Clique aqui para ampliar
+
+
+### **7. Visão de Implementação**
+
+#### **7.1 Visão Geral**
+A visão de implementação mostra como o sistema proposto será implementado. Uma das suas principais características é a visao geral do Diagrama de Classes final do projeto.
+ +#### **7.2 Diagrama de Classes** +O Diagrama de Classes é uma representação da estrutura e relações das classes que servem de modelo para os objetos. Consiste em um conjunto de objetos com as mesmas características. Dessa forma, consegue-se identificar os objetos e agrupá-los, de forma a encontrar suas respectivas classes.
+ +A sua rastreabilidade pode ser acompanhada [neste link](https://unbarqdsw.github.io/2020.1_G13_iGado/#/docs/Modeling/ClassDiagram) + +
+ + +#### **7.3 Diagrama de Entidade Relacionamento** +
O Diagrama de Entidade-Relacionamento (DER) é um tipo de fluxograma que ilustra como “entidades”, como pessoas, objetos ou conceitos, se relacionam entre si dentro de um sistema. Diagramas de Entidade Relacionamento são mais utilizados para projetar ou depurar bancos de dados relacionais nas áreas de engenharia de software. Também conhecidos como DERs, ou modelos ER, usam um conjunto definido de símbolos, tais como retângulos, diamantes, ovais e linhas de conexão para representar a interconectividade de entidades, relacionamentos e seus atributos. Eles espelham estruturas gramaticais, onde entidades são substantivos e relacionamentos são verbos.
+ +A sua rastreabilidade pode ser acompanhada [aqui](https://unbarqdsw.github.io/2020.1_G13_iGado/#/docs/Modeling/DatabaseModeling). + + + + +### **8. Tamanho e Desempenho** + +#### **8.1 Visão Geral** + +
Descreve os principais objetivos de desempenho do software assim como as principais características de dimensionamento do software que impactam na arquitetura do aplicativo.
+ +#### **8.2 Requisitos Mínimos** + +* Sistemas operacionais: Android e iOS +* É necessário possuir internet móvel ou Wi-Fi para utilizar o Software. +* O ambiente de desenvolvimento deve funcionar tanto em Windows, Linux e MacOS; +* iOS 12.0 ou superior; +* Android 10.0 ou superior; + + +### **9. Qualidade** + +Descrição de como a arquitetura do software contribui para todos os recursos (exceto a funcionalidade) do sistema: extensibilidade, confiabilidade, portabilidade e assim por diante. + +#### **9.1 NFR** + +A fim de rastrear requisitos não funcionais, o NFR mostram impactos que um hardgoal causa em um softgoal, deixando explícito a rastreabilidade e propósito de uma determiada feature, deixando claro os recursos do sistema de qualidade, como usabilidade, eficiência e etc.
+ +
+
+ Clique aqui para ampliar
diff --git a/docs/Project/BacklogPrioritization.md b/docs/Project/BacklogPrioritization.md
new file mode 100644
index 0000000..ffc385c
--- /dev/null
+++ b/docs/Project/BacklogPrioritization.md
@@ -0,0 +1,22 @@
+# Priorização Backlog do Produto
+
+| Data | Versão | Descrição | Autor(es) |
+| :--------: | :----: | :-------------------------------------: | :-------------------------------------------: |
+| 19/09/2020 | 1.0 | Criação do documento de Priorização do Backlog do Produto | [Caio Vinícius](https://github.com/caiovfernandes), [Guilherme Mendes](https://github.com/guilherme-mendes), [Iuri Severo](https://github.com/iurisevero), [João Guedes](https://github.com/sudjoao) e [Lucas Fellipe](https://github.com/lucasfcm9) |
+
+
+## MoSCoW
+
+MoSCoW é uma técnica que consiste na priorização dos requisitos. Para cada requisito do Backlog do produto, deve-se atribuir uma das seguintes palavras MUST, SHOULD, COULD e WOULD.
+ +* MUST: São itens essenciais para o projeto. +* SHOULD: São itens críticos para o projeto. +* COULD: São itens desejáveis para o projeto. +* WOULD: São itens que podem ser incluídos no projeto. + +## Backlog Priorizado + +
+ Clique aqui para ampliar
++Autor(es): Caio Vinícius, Guilherme Mendes, Iuri Severo, João Guedes e Lucas Fellipe \ No newline at end of file diff --git a/docs/Project/CommunicationManagementPlan.md b/docs/Project/CommunicationManagementPlan.md new file mode 100644 index 0000000..9c4b109 --- /dev/null +++ b/docs/Project/CommunicationManagementPlan.md @@ -0,0 +1,19 @@ +# Plano de Gerenciamento de Comunicação + +| Data | Versão | Descrição | Autor | +| :--------: | :----: | :-------------------------------------: | :-------------------------------------------: | +| 08/09/2020 | 1.0 | Criação da primeira versão do documento | [Lucas Fellipe](https://github.com/lucasfcm9) | + +## 1. Objetivo + +
O objetivo desse documento é padronizar as formas de comunicação interna entre os integrantes da equipe, bem como as ferramentas utilizadas para comunicação e gerência da equipe. Também visa formalizar os meios de comunicação entre os membros do projeto e os Stakeholders.
+ +## 2. Ferramentas + +| Ícone | Ferramenta | Descrição | +| :----------------------------------------------------------- | :--------------------- | :----------------------------------------------------------- | +|
| Telegram | A ferramenta será utilizada para o compartilhamento de arquivos, links, marcar reuniões, alertas e discussões imediatas com a equipe. Além disso, utilizamos o bot @IFTTT. |
+| 
| Microsoft Teams | A ferramenta será utilizada para fazer brainstorming, sprint planning, sprint retrospective, sprint review, dailies e reuniões mais extensas com todo o grupo para tirar dúvidas ou passar informações do projeto. Além disso, será responsável por armazenar arquivos referentes ao projeto e reuniões entre dois integrantes do grupo para utilizar o pair programming. |
+| 
| ZenHub | A ferramenta será utilizada para aplicar o Kanban e monitorar o andamento das issues. |
+| 
| GitHub | A plataforma será utilizada para centralização da documentação na Wiki. Ferramenta de versionamento, onde tem-se todo o código do produto. Além disso, é por ela que comenta-se as issues. |
+
diff --git a/docs/Project/CostManagementPlan.md b/docs/Project/CostManagementPlan.md
new file mode 100644
index 0000000..d1ae01e
--- /dev/null
+++ b/docs/Project/CostManagementPlan.md
@@ -0,0 +1,52 @@
+# Plano de Gerenciamento de Custos
+
+| Data | Versão | Descrição | Autor |
+| :--------: | :----: | :-------------------------------------: | :----------------------------------------------------------: |
+| 08/09/2020 | 1.0 | Criação da primeira versão do documento | [Caio Vinícius](https://github.com/caiovfernandes) e [Lucas Fellipe](https://github.com/lucasfcm9) |
+| 03/10/2020 | 2.0 | Atualização do Plano de Custos | [Guilherme Mendes](https://github.com/guilherme-mendes) e [Lucas Fellipe](https://github.com/lucasfcm9) |
+
+O total dos custos de um projeto é a somatória de todos os recursos necessários para executar as atividades previstas no projeto expressos em unidade monetária. O principal objetivo do gerenciamento dos custos é cumprir o orçamento do projeto.
+ +## Custo Pessoal + +| Função | Quantidade | Salário | Valor/Hora | Valor Mensal Total | Valor Total no Projeto | +| :---------------------------- | ---------- | ----------- | ------------------ | ---------------------- | ---------------------- | +| Equipe de Gerência de Projeto | 5 | R$ 7.351,00 | R$ 61,25 | R$ 36.755,00 | R$ 147.020,00 | +| Total | | | | | R$ 147.020,00 | + + + +## Custo de Infraestrutura + +| Produto/Equipamento | Quantidade | Valor Unitário | Valor Mensal Total | Valor Total no Projeto | +| :------------------ | ---------- | ------------------ | ---------------------- | ------------------- | +| Notebook | 5 | R$ 2.939,00 | - | R$ 14.695,00 | +| Internet | 5 | R$ 129,90 | R$ 649,50 | R$ 2.598,00 | +| Energia | 3000 kWh | R$ 0,518 Kwh | R$ 388,50 | R$ 1.554,00 | +| Total | | | | R$ 18.847,00 | + + + +## Ferramentas + +| Ferramenta | Quantidade | Valor Unitário | Valor Mensal Total | Valor Total no Projeto | +| :--------- | ---------- | -------------- | ------------------ | ---------------------- | +| Canvas PRO | 1 | R$ 26,90 | R$ 26,90 | R$ 107,60 | +| Microsoft Teams | 5 | R$ 28,40 | R$ 142,00 | R$ 568,00 | +| Total | | | | R$ 675,60 | + + + +## Total + +| Total Custo Pessoal | Custo de Infraestrutura | Ferramentas | Total | Total + 20% de Riscos + 20% de Lucro | +| ------------------- | ------------------ | ----------- | ------------ | ------------------------------------ | +| R$ 147.020,00 | R$ 18.847,00 | R$ 675,60 | R$ 166.542,60 | R$ 233.159,64 | + +## Referências + +- SERRANO, Milene; Tópico 2 - DSW Base - Dúvidas & Respostas: Série 02. Acesso em: 11 set. 2020. +- MONTES, Eduardo; Gerenciamento dos custos: O que é, objetivo e processos. Disponível em:As entrevistas foram realizadas para ter uma ideia mais ampla e geral de possíveis necessidades de um usuário. As entrevistas foram fundamentais para uma análise eficaz e priorização de funcionalidades a serem desenvolvidas.
+ + +### Stakeholder 1 - Marcelo - Proprietário de Fazenda + + +
+
+
+
+
+
+
+
+* [Link de acesso aos áudios.](https://drive.google.com/drive/folders/18mvH7m5mghKcsPgdAPMfRzIrtS3Ekkuy?usp=sharing)
+
+
+### Stakeholder 2 - Cássio - Proprietário de Fazenda
+
+
+* [Link de acesso aos áudios.](https://drive.google.com/drive/folders/1vgu663EvHvOmYsbYWH2wRfHNLxlyLQRu?usp=sharing)
+
+
+### Stakeholder 3 - Eduardo - Engenheiro Agrônomo
+
+
+* [Link de acesso à reunião.](https://drive.google.com/drive/folders/1SArQv6TOXg5rXBqwOMENQO6eFVe1SJOj?usp=sharing)
+
+## Referências
+
+SERRANO, Maurício; SERRANO, Milene. Material apresentado para a disciplina de Requisitos de Software no curso de Engenharia de Software da UnB, FGA.
\ No newline at end of file
diff --git a/docs/Project/ProductBacklog.md b/docs/Project/ProductBacklog.md
new file mode 100644
index 0000000..38073b0
--- /dev/null
+++ b/docs/Project/ProductBacklog.md
@@ -0,0 +1,17 @@
+# Backlog do Produto
+
+| Data | Versão | Descrição | Autor |
+| :--------: | :----: | :-------------------------------------: | :-------------------------------------------: |
+| 08/09/2020 | 1.0 | Criação do documento de Backlog do Produto | [Caio Vinícius](https://github.com/caiovfernandes), [Guilherme Mendes](https://github.com/guilherme-mendes), [Iuri Severo](https://github.com/iurisevero), [João Guedes](https://github.com/sudjoao) e [Lucas Fellipe](https://github.com/lucasfcm9) |
+
+
+
+
+O Product Backlog é uma lista contendo todas as funcionalidades desejadas para um produto. O conteúdo desta lista é definido pelo Product Owner, porém, a lista foi definida por todos os integrantes do grupo. O Product Backlog não precisa estar completo no início de um projeto. Pode-se começar com tudo aquilo que é mais óbvio em um primeiro momento. Com o tempo, o Product Backlog cresce e muda à medida que se aprende mais sobre o produto e seus usuários.
+ +## Backlog + + +[Clique aqui para ampliar](https://user-images.githubusercontent.com/40740008/92952141-da3b8800-f435-11ea-85e2-3951132e75cf.png) ++**Autor(es):** [Caio Vinícius](https://github.com/caiovfernandes), [Guilherme Mendes](https://github.com/guilherme-mendes), [Iuri Severo](https://github.com/iurisevero), [João Guedes](https://github.com/sudjoao) e [Lucas Fellipe](https://github.com/lucasfcm9) + +## Referências +ARAÚJO, Caio; PEREIRA, Guilherme; ALVES, Iuri; SOUZA, Gabriel; GUEDES, João; MOREIRA, Lucas; Wire - Backlog do Produto. Disponível em:
O plano de gerenciamento de riscos fornece informações sobre papéis e responsabilidades relativas aos riscos, indica como as atividades do gerenciamento dos riscos são incluídas no orçamento e no cronograma. Além disso, descreve as categorias de risco que podem ser expressas como uma EAR (Estrutura Analítica dos Riscos).
+ +## 2. Objetivo + +O plano de gerenciamento de riscos tem como objetivo descrever quais são os riscos do projeto, como eles serão monitorados e controlados ao longo das sprints, visando entender seus impactos, procurando formas de mitigar esses possíveis riscos.
+ +A EAR facilita a identicação dos riscos em projetos. Tem por função mostrar as principais categorias de riscos para um projeto, auxiliando como guia para análise do contexto, da documentação e para o questionamento das partes interessadas, buscando ganho de tempo na identificação dos riscos. Os riscos podem ser divididos nas seguintes categorias:
+ +## 3. Estrutura Analítica dos Riscos + +
+
+* Riscos Técnicos:
+
+ | **Tipo** | Descrição |
+ | :----------- | :----------------------------------------------------------- |
+ | Requisitos | Riscos pela falta de mapeamento e elicitação de requisitos. |
+ | Tecnologias | Riscos gerados pela escolha da tecnologia errada. |
+ | Complexidade | Riscos gerados pela falta de conhecimento sobre as tecnologias escolhidas. |
+ | Qualidade | Riscos consequentes da qualidade do produto final. |
+
+
+
+* Riscos de Gerenciamento:
+
+ | **Tipo** | Descrição |
+ | :----------- | :----------------------------------------------------------- |
+ | Estimativa | Riscos que afetam o tempo de realização do projeto. |
+ | Controle | Riscos que afetam o controle de atividades. |
+ | Planejamento | Riscos relacionados ao planejamento de elaboração do projeto. |
+ | Comunicação | Riscos relacionados aos meios de comunicação como, por exemplo, a falta de comunicação da equipe. |
+
+
+
+* Riscos Organizacionais:
+
+ | **Tipo** | **Descrição** |
+ | :----------- | :----------------------------------------------------------- |
+ | Recursos | Riscos que são consequentes da falta de material físico e/ou tecnológico. |
+ | Priorização | Riscos decorrentes pela má escolha de histórias de usuários nas Sprints. |
+ | Dependências | Riscos que podem ser gerados por dependências que afetam a evolução do projeto. |
+
+
+
+* Riscos externos:
+
+ | Tipo | **Descrição** |
+ | :--------------------------- | :----------------------------------------------------------- |
+ | Cliente (StakeHolder) | Riscos gerados pelo cliente em relação ao produto, como mudanças repentinas no escopo devido a um pedido do cliente. |
+ | Greve na UnB | Riscos que podem ser gerados pela paralisação das atividades remotas da UnB (Universidade de Brasília). |
+
+ ## 4. Análise Quantitativa de Riscos
+
+ A análise quantitativa de riscos consiste na priorização e categorização dos riscos de acordo com 2 métricas:
+ * **Probabilidade:** chances de um risco ocorrer;
+ * **Impacto:** quanto o risco impacta no projeto;
+
+### Tabela 4.1 - Probabilidade
+
+| **Probabilidade** | Certeza | **Peso** |
+| :---------------: | :-------: | :------: |
+| Muito baixa | 0 - 20% | 1 |
+| Baixa | 20 - 40% | 2 |
+| Média | 40 - 60% | 3 |
+| Alta | 60 - 80% | 4 |
+| Muito Alta | 80 - 100% | 5 |
+
+### Tabela 4.2 - Impacto
+
+| **Impacto** | **Descrição** | Peso |
+| :---------: | :-------------------------------------- | :--: |
+| Muito baixo | Pouco Expressivo | 1 |
+| Baixo | Pouco Impacto | 2 |
+| Médio | Impacto Médio | 3 |
+| Alto | Grande Impacto | 4 |
+| Muito Alto | Impacto impede a continuação do projeto | 5 |
+
+O grau de risco é definido pela multiplicação da probabilidade pelo impacto. Conforme a tabela abaixo:
+
+| Impacto/Probabilidade | Muito Baixa | Baixa | Média | Alta | Muito Alta |
+| :-------------------: | :---------: | :---: | :---: | :--: | :--------: |
+| Muito Baixa | 1 | 2 | 3 | 4 | 5 |
+| Baixa | 2 | 4 | 6 | 8 | 10 |
+| Média | 3 | 6 | 9 | 12 | 15 |
+| Alta | 4 | 8 | 12 | 16 | 20 |
+| Muito Alta | 5 | 10 | 15 | 20 | 25 |
+
+Sendo que:
+
+Risco >= 15: Elevado,
+
+5 < Risco < 15: Médio e
+
+Risco <= 5: Baixo.
+
+
+
+## 5. Identificação dos Riscos
+
+| ID | Se | Por conta | O impacto será | Categoria EAR |
+| :--: | :----------------------------------------------------------- | :----------------------------------------------------------- | :----------------------------------------------------------- | :----------------------- |
+| 1 | o projeto não atender aos requisitos propostos | do levantamento de requisitos falho e falta de validação constante | atraso na entrega do produto final e redefinição dos requisitos | Requisitos |
+| 2 | a tecnologia usada apresentar problemas | do seu proprietário | atraso na entrega do produto final e troca de tecnologia equivalente | Tecnologias |
+| 3 | a equipe de desenvolvimento não se adaptar a tecnologia escolhida | da falta de conhecimento ou da indisponibilidade da equipe | que o produto não será entregue | Complexidade |
+| 4 | houverem dificuldades em realizar os testes | da falta de conhecimento | atraso na entrega das histórias de usuários | Complexidade |
+| 5 | houver mudanças arquiteturais | da falha na realização do escopo | mais retrabalho, como alteração nas histórias de usuários planejadas, mudanças de infra e mudanças a nível de código | Complexidade |
+| 6 | houver mudança de escopo | da falha na realização do escopo e na elicitação dos requisitos | refatoração dos requisitos e da documentação | Planejamento |
+| 7 | o produto final estiver em baixa qualidade | da equipe de desenvolvimento | refatoração de todo o produto | Qualidade |
+| 8 | as atividades não forem concretizadas no prazo definido | da falta de integração dos integrantes da equipe | atraso na baseline do projeto | Estimativas/Dependências |
+| 9 | houver histórias de usuário mal definidas | da falha de elicitação de requisitos | atraso na entrega do produto final e necessidade de refatoração das histórias | Estimativa |
+| 10 | houver sprint mal planejada | de histórias mal planejadas | atraso na entrega do produto final, dificuldade de compreensão das histórias e necessidade de refatoração | Estimativa/Priorização |
+| 11 | houver falta de comunicação da equipe | da indisponibilidade da equipe | dificuldade no gerenciamento e falta de alinhamento da equipe | Comunicação |
+| 12 | membros da equipe abandonarem o projeto | de desmotivação e indisponibilidade | sobrecarga entre os membros da equipe restantes | Recursos |
+| 13 | a qualidade do *software* não atender as expectativas do cliente | má implementação e erros na parte de elicitação de requisitos | descontentamento do cliente e possibilidade de cancelamento do projeto | Cliente/Qualidade |
+| 14 | houver perdas ou defeitos em equipamentos | mal uso e roubos | atraso na entrega do projeto | Recursos |
+| 15 | houver o cancelamento do projeto | da falta de interesse do cliente | interrupção e/ou cancelamento do projeto | Cliente |
+| 16 | houver greve na UnB | de orientações de assembleias do corpo docente ou estudantil | interrupção do projeto | Greve na UnB |
+| 17 | a equipe não conseguir automatizar o deploy e a integração contínua | da falta de conhecimento ou indisponibilidade | atraso na entrega do produto final em ambiente de produção | Complexidade |
+| 18 | houver imaturidade na gerência do projeto | de negligências e abandono de integrantes da equipe | diminuição da qualidade do projeto e atraso das histórias | Estimativa/Dependências |
+
+
+
+## 6. Interpretação
+
+| ID | Impacto | Probabilidade | Avaliação | Contigência | Mitigação |
+| :--: | :--------: | :-----------: | :-------: | :----------------------------------------------------------- | :----------------------------------------------------------- |
+| 1 | Muito Alto | Muito Alta | 25 | Revalidar todo os requisitos com o *Product Owner* e com o cliente | Realizar constantes reuniões com os integrantes da equipe, com o cliente e pesquisas necessárias para obtenção de conhecimento e compreensão sobre o escopo do projeto |
+| 2 | Muito Alto | Baixa | 10 | Trocar para uma nova tecnologia equivalente | Escolher uma tecnologia com suporte |
+| 3 | Alto | Alta | 16 | Indicar treinamentos para a equipe de desenvolvimento sobre a tecnologia escolhida | Estabelecer treinamentos constantes sobre a tecnologia escolhida |
+| 4 | Muito Alto | Alta | 20 | Indicar treinamentos para a equipe de desenvolvimento sobre testes | Estabelecer treinamentos constantes sobre testes |
+| 5 | Muito Alto | Média | 15 | Realizar a mudança de Arquitetura do projeto buscando outras tecnologias capazes de solucionar os problemas gerados | Buscar conhecimento com professores, alunos e pessoas fora do ambiente universitária, novas pesquisas e pensamentos críticos a respeito da arquitetura. |
+| 6 | Muito Alto | Baixa | 10 | Redefinir o mais rápido possível as mudanças de escopo | Manter a comunicação constante com o cliente |
+| 7 | Muito Alto | Muito Alta | 25 | Realizar a refatoração de código, testes e validação com o cliente | Realizar treinamentos de todas as tecnologias utilizadas, além de garantir a realização de testes, boas práticas de programação e validações constantes com o cliente |
+| 8 | Muito Alto | Muito Alta | 25 | Realizar a entrega das histórias na próxima Sprint como dívida técnica | Planejar as atividades de forma mais coerente e dividi-las nas *sprints* com base nos pesos e dificuldade definida no Planning Poker |
+| 9 | Alto | Muito Alta | 20 | Realizar uma refatoração das histórias para que entrem em conformidade com os requisitos pré-definidos | Realizar constantes reuniões entre os integrantes da equipe e o cliente e, além disso, realizar pesquisas necessárias para obtenção de conhecimento e compreensão sobre o escopo do projeto |
+| 10 | Alto | Alta | 16 | Realizar o replanejamento da Sprint utilizando a priorização do Backlog do Produto | Montar o Backlog da Sprint utilizando a priorização |
+| 11 | Muito Alto | Alta | 20 | Promover as mudanças necessárias, desde a realização de Daily meetings mais objetivas a mudanças de ferramentas para comunicação | Criando o plano de comunicação em que a equipe concorde totalmente |
+| 12 | Alto | Muito Alta | 20 | Realocar as tarefas pré-definidas entre os membros restantes | Conversar com a equipe a fim de reafirmar a importância do projeto para que a equipe o priorize |
+| 13 | Muito Alto | Muito Alta | 25 | Realizar a refatoração do código e dos testes e, além disso, validações com o cliente | Realizar treinamento de todas as tecnologias utilizadas, garantir a realização de testes, boas práticas de programação e validações com o cliente |
+| 14 | Alto | Média | 12 | Realocar as tarefas entre os membros da equipe que possuem equipamentos sem defeitos | Incentivar a manutenção recorrente de equipamentos |
+| 15 | Muito Alto | Muito baixa | 5 | Oferecer a melhor possibilidade de produto para o cliente | Manter comunicação constante com o cliente |
+| 16 | Muito Alto | Média | 15 | Aceitar o risco pois não pode-se fazer nada | - |
+| 17 | Alto | Alta | 16 | Procurar ajuda de professores, alunos e pessoas fora do ambiente universitário e aumentar o tempo de estudo | Realização de pesquisas constantes e consultoria com outros alunos, professores e pessoas fora do ambiente universitário |
+| 18 | Alto | Média | 12 | Conversar com os membros imaturos e mostrar que o projeto deve ser levado a sério | Manter o pensamento crítico e estratégico a respeito das métricas coletadas e realizando todos os rituais das metologias definidas |
+
+
+
+## Referências
+
+* FILHO, Ateldy; GOMES, Vitor; SOUZA, João; DANTAS, Bruno; Ada - Plano de Gerenciamento de Riscos. Disponível em: https://fga-eps-mds.github.io/2019.1-ADA/#/docs/project/risk_management_plan>. Acesso em: 08 set. 2020.
+* Aula13-1 - Gerenciamento dos Riscos: Processo: Planejar o gerenciamento dos riscos. Disponível em: Flask é um microframework de python baseado em Werkzeug, Jinja 2 e good intentions, que tem como objetivo ser uma base para o desenvolvimento de diversas aplicações. Para isso, ele possui um core simples, porém extensível, que permite os desenvolvedores realizarem seus objetivos por conta própria ou pelo uso dos diversos pacotes e bibliotecas existentes para o framework.
+ +### Unittest + +A estrutura de testes unitários unittest foi originalmente inspirada por JUnit e tem um comportamento semelhante aos principais frameworks de testes unitários em outras linguagens. Ele suporta automação de teste, compartilhamento de configuração e código de desligamento para testes, agregação de testes em coleções e independência dos testes da estrutura de relatório.
+ +### Flutter + + Flutter é um conjunto de ferramentas que facilitam o desenvolvimento de interfaces de tamanhos variados e para todos tipos de aparelho. O framework trabalha principalmente a partir de Widgets que, por meio de um relacionamento de composição, permitem ao desenvolvedor utilizar diversos elementos de UI pré definidos. Além disso, o framework também permite ao usuário criar Widgets próprios e páginas por meio da herança de objetos abstratos como o StatefulWidget.
+Código retirado de:
+**abc**: Este módulo fornece a infraestrutura para definir classes básicas abstratas (ABCs) em Python;
+**os**: Este módulo fornece uma maneira portátil de usar a funcionalidades dependentes do sistema operacional. + +### Bibliotecas utilizadas no Frontend + +**flutter/material.dart**: Biblioteca que permite os widgets do Flutter implementarem _[Material Desing](https://material.io/design)_;
+**flutter/widgets.dart**: Estrutura de widgets do Flutter;
+**rflutter_alert/rflutter_alert.dart**: Biblioteca para criação de alertas e popups customizáveis;
+**flutter_test/flutter_test.dart**: Biblioteca de testes para flutter, criada a partir do pacote _[test](https://pub.dev/packages/test)_; + +## Plugins + +### Plugins utilizados no Backend + +**Flask-RESTful**: Flask-RESTful é uma extensão para Flask que adiciona suporte para a criação rápida de APIs REST. Ela é uma leve abstração que trabalha com as bibliotecas/ORM existentes;
+**Flask-SQLAlchemy**: Flask-SQLAlchemy é uma extensão do Flask que adiciona suporte para SQLAlchemy ao aplicativo desenvolvido. Ela visa simplificar o uso do SQLAlchemy com o Flask, fornecendo padrões úteis e auxiliares extras que tornam mais fácil a realização de tarefas comuns;
+**Flask-Testing**: A extensão Flask-Testing fornece utilitários de testes unitários para Flask;
+**Flask-JWT-Extended**: Flask-JWT-Extended adiciona suporte para o uso de [JSON Web Tokens (JWT)](https://jwt.io/) ao Flask para proteção de visualizações e também muitos recursos úteis (e opcionais) integrados para facilitar o trabalho com JSON Web Tokens;
+**flask-bcrypt**: Flask-Bcrypt é uma extensão do Flask que fornece utilitários de hash bcrypt para a aplicação desenvolvida;
+**psycopg2-binary**: Psycopg é o adaptador de banco de dados PostgreSQL mais popular para a linguagem de programação Python. Suas principais características são a implementação completa da especificação Python DB API 2.0 e a segurança de thread. + +## Serviços + +### Gunicorn + +
Gunicorn 'Green Unicorn' é um servidor Python WSGI HTTP para UNIX. É um modelo de trabalhador pré-fork. O servidor Gunicorn é amplamente compatível com vários frameworks da web, simplesmente implementado, com recursos de servidor leves e bastante rápido.
+ +## Outros + +### Widgets Personalizados + +Uma das funcionalidades disponibilizadas pelo Flutter é a de criar Widgets personalizados melhorar a reutilização de código. Essa prática também é adotada em outros frameworks voltados para desenvolvimento UI como os components do React Native.
+ +No projeto iGado os Widgets personalizados podem ser encontrado na pasta [2020.1_G13_iGado_Frontend/lib/components](https://github.com/UnBArqDsw/2020.1_G13_iGado_Frontend/tree/master/lib/components). Os Widgets criados pelo grupo foram: + +* [dropdown_icon_text.dart](https://github.com/UnBArqDsw/2020.1_G13_iGado_Frontend/blob/master/lib/components/dropdown_icon_text.dart) +* [icon_text_form_field.dart](https://github.com/UnBArqDsw/2020.1_G13_iGado_Frontend/blob/master/lib/components/icon_text_form_field.dart) +* [radio_button_transform.dart](https://github.com/UnBArqDsw/2020.1_G13_iGado_Frontend/blob/master/lib/components/radio_button_transform.dart) +* [simple_card.dart](https://github.com/UnBArqDsw/2020.1_G13_iGado_Frontend/blob/master/lib/components/simple_card.dart) +* [title_text_form_field.dart](https://github.com/UnBArqDsw/2020.1_G13_iGado_Frontend/blob/master/lib/components/title_text_form_field.dart) +* [visibility_form_field.dart](https://github.com/UnBArqDsw/2020.1_G13_iGado_Frontend/blob/master/lib/components/visibility_form_field.dart) + +## Referências + +* Flutter architectural overview. Disponível em:Após a discussão dos requisitos foi iniciada uma discussão para definir as tecnologias e o banco de dados. Assim como as técnicas de elicitação, as tecnologias foram escolhidas de acordo com as opiniões dos membros de o que seria melhor para o aprendizado de cada um e para o desenvolvimento do projeto.
+ +Para o front foi definido a utilização de Flutter, visto que é uma tecnologia ascendente, com boa documentação e alta curva de aprendizado, além de facilitar na estilização das telas.
+ +Para o back foi definido a utilização de Python com Django ou com Flask, iremos pesquisar mais para ver qual framework se encaixa melhor no nosso projeto.
+ +Será utilizado Docker para organização do ambiente e utilizaremos um banco de dados relacional, que será definido mais para frente, de acordo com o que for melhor para o projeto.
diff --git a/docs/SprintsAndMeetings/2020-08-24-Sprint0Opening.md b/docs/SprintsAndMeetings/2020-08-24-Sprint0Opening.md new file mode 100644 index 0000000..6b9dab1 --- /dev/null +++ b/docs/SprintsAndMeetings/2020-08-24-Sprint0Opening.md @@ -0,0 +1,53 @@ +# Abertura da Sprint 0 + +| Data | Versão | Descrição | Autor(es) | +| :--------: | :----: | :-----------------------: | :---------------------------: | +| 11/09/2020 | 1.0 | Transcrição do documento 20200824 do teams | [Iuri Severo](https://github.com/iurisevero) | + +**Data**: 24 de agosto de 2020 + +**Redigida por**: Iuri Severo + +**Participantes**: +* Caio Fernandes +* Guilherme Mendes +* Iuri Severo +* João Pedro +* Lucas Fellipe + +## Notas pré reunião + +Essa reunião foi marcada para definir as políticas de repositório, data de início e fim de sprint e para criar as issues iniciais do projeto. As políticas adotadas vão seguir os padrões adotados no projeto Wire, da matéria de requisitos, que é um padrão o qual o grupo já está habituado a seguir.
+ +Segunda-feira foi o dia definido para início da sprint, tendo finalização no Sábado, quando acontecerá a reunião de sprint review, retrospective e planning, com o Domingo sendo um dia para descanso da equipe. Também foi definido que começaremos a fazer dailys a partir da semana que vem.
+ +## Planning + +### Duração + +| Duração | Início | Fim | +| ------- | ---------- | ---------- | +| 6 dias | 24/08/2020 | 29/08/2020 | + +### Sprint Backlog + +As issues vão ser referentes as técnicas de elicitação de requisitos contidas no documento [Técnicas de Elicitação de Requisitos e Tecnologias](/docs/SprintsAndMeetings/2020-08-21-RequirementsElicitationTechniquesAndTechnologies.md): + +| Descrição da Tarefa | Responsável(eis) | Pontuação | Débito Técnico | +| ------------------- | ---------------- | --------- | -------------- | +| Entrevistar Cássio e Marcelo | Lucas, Caio, Guilherme e Iuri | 0 | 0 | +| Entrevistar Thiago | João Pedro e Guilherme | 0 | 0 | +| Entrevistar Tio do Caio | Caio e Lucas | 0 | 0 | +| Questionário | João Pedro e Iuri | 0 | 0 | +| Documento de Visão | Lucas, Caio, Guilherme, Iuri e João | 0 | 0 | +| Demonstração Relâmpago | Lucas, Caio, Guilherme, Iuri e João | 0 | 0 | +| 5W2H | Caio e Lucas | 0 | 0 | +| Rich Picture | Lucas, Caio, Guilherme, Iuri e João | 0 | 0 | +| Brainstorming | Lucas, Caio, Guilherme, Iuri e João | 0 | 0 | +| Ishikawa | Iuri | 0 | 0 | + +> Se houver débito técnico ele deverá ser incluso na tabela de Sprint Backlog e a coluna de Débito Técnico deverá ser alterada para "1" (true) + +## Notas pós reunião + +Após as aulas do dia 24/08 foi percebido que seria melhor alterar as técnicas utilizadas e reduzir a quantidade de artefatos, focando nos que serão mais úteis para o desenvolvimento da matéria. \ No newline at end of file diff --git a/docs/SprintsAndMeetings/2020-08-29-Sprint0Closure.md b/docs/SprintsAndMeetings/2020-08-29-Sprint0Closure.md new file mode 100644 index 0000000..1183df2 --- /dev/null +++ b/docs/SprintsAndMeetings/2020-08-29-Sprint0Closure.md @@ -0,0 +1,50 @@ +# Fechamento da Sprint 0 +| Data | Versão | Descrição | Autor(es) | +| :--------: | :----: | :-----------------------: | :---------------------------: | +| 11/09/2020 | 1.0 | Transcrição do documento 20200829 do teams | [Iuri Severo](https://github.com/iurisevero) | + +**Data**: 29 de agosto de 2020 + +**Redigida por**: Iuri Severo + +**Participantes**: +* Caio Fernandes +* Guilherme Mendes +* Iuri Severo +* João Pedro +* Lucas Fellipe + +## Review + +* Caio: Também assistiu as vídeo aulas e fez o script de commit. Hoje fez o Rich picture e também evolui o script, basicamente; +* Guilherme: Essa semana assistiu as vídeo aulas que a Milene disponibilizou, ainda não terminou, faltam umas 4 ou 5 aulas. Também desenvolveu o rich picture, com base nas reuniões com os stackholders e com umas ideias que foram discutidas no grupo; +* Iuri: Fez o forms com o João Pedro, assistiu as aulas até o OpenUP, fez o rich picture baseado no que foi discutido pelo grupo, nas aulas e no conteúdo extra. Falou também sobre metodologias no rich picture. +* João Pedro: Essa semana ele assitiu as vídeos aulas, até a de metodologia de Open Up. Achou ela interessante, mas quer ver as outras antes de falar algo mais certo. Fez um rich Picture baseado no forms que o Iuri e ele fizeram. Quer ter mais ensumo para ver o que as pessoas fazem na fazenda; +* Lucas: Também assistiu as vídeo aulas, faltam 3. Fez a rich picture baseado nas entrevistas, nos questionários e nas conversas que o grupo teve. Criou a página do github pages no repositório; + +## Retrospective + +* Caio + * Positivos: Comunicação está muito boa, todo mundo expressa ideias e opiniões sobre o que é gerado + * Negativos: Estou bem atolado de coisa para fazer, essa semana surgiu uma demanda maior de coisa no trabalho e não tô conseguindo conciliar as tarefas + * Melhorias: Melhor organização de ver as aulas e definir horário de trabalho para cada coisa +* Guilherme + * Positivo: Concordo com o que foi falado, em relação a comunicação do grupo, e o engajamento, todo mundo participando e comentando. Todos concordaram com o tema, o que é muito bom + * Negativos: Organização, conseguir concluir as issues, ver as aulas e trabalhar. + * Melhorias: Organização, para evitar os pontos negativos +* Iuri + * Positivos: Comunicação do grupo, conseguimos desenvolver bem a ideia; + * Negativos: Organização dos horários e Issues; + * Melhorias: Conciliar aula, trabalho e desenvolvimento. +* João Pedro: + * Positivos: Eu acho que foi o forms, que já teve respostas, então conseguimos pegar uma base de dados boa. Não tive conflitos de horário com meu pareamento que era o Iuri e a comunicação do grupo é muito boa. + * Negativos: Muito tempo de aula, isso impede um pouco o trabalho + * Melhorias: Organizar melhor os horários para ver as aulas e conseguir trabalhar mais +* Lucas + * Positivos: Comunicação muito boa, todo mundo se sente livre pra dar ideia, falar e se expressar. + * Negativo: Organização, tudo muito novo pra gente, tudo corrido, muita coisa pra assistir. + * Melhorias: Tem que fazer uma tabela para questão de horário entre a gente. + +## Notas pós reunião + +Após a reunião foi iniciado o Design Sprint proposto em aula, com algumas alterações. Durante o Design Sprint foi feito um brainstorming e o rich picture geral do aplicativo. \ No newline at end of file diff --git a/docs/SprintsAndMeetings/2020-08-29-Sprint1Opening.md b/docs/SprintsAndMeetings/2020-08-29-Sprint1Opening.md new file mode 100644 index 0000000..0b4db33 --- /dev/null +++ b/docs/SprintsAndMeetings/2020-08-29-Sprint1Opening.md @@ -0,0 +1,45 @@ +# Abertura da Sprint 1 + +| Data | Versão | Descrição | Autor(es) | +| :--------: | :----: | :-----------------------: | :---------------------------: | +| 11/09/2020 | 1.0 | Transcrição do documento 20200829 do teams | [Iuri Severo](https://github.com/iurisevero) | +| 26/10/2020 | 1.1 | Adição do vídeo de apresentação dos padrões para o grupo | [João Pedro Guedes](https://github.com/sudjoao)| + +Gravação da Sprint Review, Retrospective e Planning + +**Data**: 29 de agosto de 2020 + +**Redigida por**: Iuri Severo + +**Participantes**: +* Caio Fernandes +* Guilherme Mendes +* Iuri Severo +* João Pedro +* Lucas Fellipe + +## Planning + +### Duração + +| Duração | Início | Fim | +| ------- | ---------- | ---------- | +| 6 dias | 31/08/2020 | 05/09/2020 | + +### Sprint Backlog + +| Descrição da Tarefa | Responsável(eis) | Pontuação | Débito Técnico | +| ------------------- | ---------------- | --------- | -------------- | +| 5W2H | Caio e Lucas | 0 | 1 | +| Ishikawa | Iuri | 0 | 1 | +| Mapa mental | João Pedro e Guilherme | 0 | 0 | +| Documento de Visão | Lucas, Caio, Guilherme, Iuri e João | 0 | 1 | +| Storyboard | Lucas, Caio, Guilherme, Iuri e João | 0 | 0 | +| Protótipo | Lucas, Caio, Guilherme, Iuri e João | 0 | 0 | +| Definir metodologia | Lucas, Caio, Guilherme, Iuri e João | 0 | 0 | + +> Se houver débito técnico ele deverá ser incluso na tabela de Sprint Backlog e a coluna de Débito Técnico deverá ser alterada para "1" (true) + +## Notas pós reunião + +Após a reunião foi marcada uma reunião para a equipe finalizar o design sprint, discutir as metodologias estudadas e definir a metodologia que será utilizada no decorrer do semestre. A reunião ficou marcada para quarta-feira, dia 02 de setembro. \ No newline at end of file diff --git a/docs/SprintsAndMeetings/2020-09-02-DesignSprintAndMethodology.md b/docs/SprintsAndMeetings/2020-09-02-DesignSprintAndMethodology.md new file mode 100644 index 0000000..0cd3aeb --- /dev/null +++ b/docs/SprintsAndMeetings/2020-09-02-DesignSprintAndMethodology.md @@ -0,0 +1,63 @@ +# Design Sprint e Metodologia + +| Data | Versão | Descrição | Autor(es) | +| :--------: | :----: | :-----------------------: | :---------------------------: | +| 11/09/2020 | 1.0 | Transcrição do documento 20200902 do teams | [Iuri Severo](https://github.com/iurisevero) | + +**Data**: 02 de setembro de 2020 + +**Redigida por**: Iuri Severo + +**Participantes**: +* Caio Fernandes +* Guilherme Mendes +* Iuri Severo +* João Pedro +* Lucas Fellipe + +**Pauta da Reunião**: +* Finalizar o Design sprint +* Definir a metodologia + +## Finalizar o Design Sprint + +Durante o Design Sprint foi elaborado: +* Storyboard +* Protótipo de Média Fidelidade + * O protótipo foi iniciado e foi decidido que seria finalizado durante a semana para que pudéssemos discutir as metodologias + +## Definir Metodologia + +Foi iniciado a discussão a respeito de quais artefatos serão elaborados e quais ritos serão adotados; + +* Scrum: + * Velocity + * Burndown + * Planning poker + * Daily + * Sprint Backlog + * Sprint Review + * Sprint Retrospective + * Sprint Planning + * Backlog do produto + * Sprint com duração de 1 semana +* XP: + * Pair Programming; + * Baby steps; + * Equipe integral; + * Código coletivo; +* OpenUp: + * Documento de Visão + * Glossário e Léxicos + * Protótipos + * Modelo de Dados + * Material de Suporte + * Disciplinas e Fases, mas com a possibilidade de retornar uma fase, caso seja necessário +* Outros: + * Kanban + * Testes + * Não serão adotados papéis, cada um trabalhará nas issues que preferir, o que permitirá uma maior diversidade de áreas de atuação de cada membro + +## Notas pós reunião + +> Adicione aqui algum comentário que afetará a sprint após essa reunião, se não houver nenhum comentário a ser feito, apague essa parte. \ No newline at end of file diff --git a/docs/SprintsAndMeetings/2020-09-05-Sprint1Closure.md b/docs/SprintsAndMeetings/2020-09-05-Sprint1Closure.md new file mode 100644 index 0000000..53154af --- /dev/null +++ b/docs/SprintsAndMeetings/2020-09-05-Sprint1Closure.md @@ -0,0 +1,61 @@ +# Fechamento da Sprint 1 + +| Data | Versão | Descrição | Autor(es) | +| :--------: | :----: | :-----------------------: | :---------------------------: | +| 11/09/2020 | 1.0 | Transcrição do documento 20200905 do teams | [Iuri Severo](https://github.com/iurisevero) | + +**Data**: 05 de setembro de 2020 + +**Redigida por**: Iuri Severo + +**Participantes**: +* Caio Fernandes +* Guilherme Mendes +* Iuri Severo +* João Pedro +* Lucas Fellipe + +## Review + +* Caio: Participou da reunião com o Eduardo, ele deu algumas dicas para equipe. Participou da reunião de design sprint, escreveu sobre o script de commit e adicionou o gif na wiki. Fez a estimativa de custos com o Lucas e começou a fazer o documento de visão. O documento ficou salvo no Teams. +* Guilherme: Essa semana ele participou da reunião com o Eduardo, da reunião de design sprint, pareou com o João Pedro para fazer o mapa mental. Conseguiram concluir e editou poucas coisas no protótipo. Pretende continuar o documento de visão, ainda hoje vai tentar mexer nele. +* Iuri: Participou da reunião com o Eduardo, da reunião de design sprint, alterou algumas páginas no protótipo e fez o diagrama de Ishikawa. +* João: Essa semana ele se reuniu com o Guilherme e fizeram o mapa mental, como o Guilherme comentou. Participou da reunião de design sprint, onde foi feito o story telling e o protótipo foi iniciado. Finalizou a base do protótipo e aplicou a identidade visual na wiki. +* Lucas: Fez o 5W2H e subiu pra wiki, junto com o Caio. Participou da Design Sprint para fazer o storyboard e mexeu também no documento de visão. Inseriu alguns dados nele, pretende mexer mais nele ainda hoje. Também participou da renião com o Eduardo. + +## Retrospective + +* Caio + * Positivos: O engajamento da equipe, todo mundo participa de tudo que a gente fala e interage. Isso é muito bom, a equipe unida; + * Negativos: Pra mim, eu queria ter feito mais coisa. Tive marcado de parear com o Lucas e não consegui porque estava muito cansado; + * Melhorias: Começar as dailys. Acho questão de organização, a equipe ainda não se encaixou. +* Guilherme + * Positivos: Todo mundo da equipe tá procurando saber e tentando contribuir ao máximo. O contato do caio com o Eduardo foi muito bacana, o Lucas sempre tirando dúvidas com o pai da Sofia, Iuri com os documentos e Johnson com protótipo. Todo mundo alinhado e trabalhando; + * Negativos: Deveríamos ter começado as dailys. Todo mundo atolado com trabalho e faculdade; + * Melhorias: A Daily e organização +* Iuri + * Positivo: Engajamento da equipe; + * Negativo: Acho que não fiz tudo que podia ter feito essa semana, mas consegui finalizar o Ishikawa pelo menos, que era a issue que eu estava responsável; + * Melhorar: Daily, vai ajudar na organização e fazer as coisas correrem melhor; +* João + * Positivo: Concordo com quase tudo que todo mundo falou. Os artefatos foram feitos com qualidade, todos estão na wiki e com embasamento teórico. Pareamento com o Gui foi muito bom, conseguimos parear mesmo sem combinar antes, os dois estavam dispostos; + * Negativo: Desenho é uma matéria pesada, principalmente EAD. Gasto muitas horas para ver as aulas, mais do que o horário e ainda tem que fazer os artefatos, gasta muito tempo; + * Melhorar: Daily. +* Lucas + * Positivos: Concordo com todos, a equipe tá engajada, estamos num projeto bom. Concordo com o Johnson, em relação a qualidade dos artefatos. Todos estão trabalhando muito bem; + * Negativos: Semestre pesado, muita coisa para fazer, muitas videoaulas. Temos que assistir aulas depois do horário, mas acho que isso é normal, tá todo mundo assim; + * Melhorar: Daily vai melhorar a comunicação e vai ajudar na organização; + +## Notas pós reunião + +Entre a Sprint Review e a Sprint Retrospective aconteceu a seguinte discussão: + +**Caio**: Acho que não seria legal se comparar com os grupos do semestre passado e anteriores, porque temos menos gente. Vai ser muito complicado o semestre porque o escopo da matéria não mudou, mas a quantidade de membros do grupo sim e por isso teremos que priorizar bem o que vamos fazer. + +**Lucas**: Concordou com o que foi falado + +Johnson acrescentou comentado sobre o tempo que ele gastou no protótipo e se realmente valeu, se não era melhor focar no documento de visão. + +**Lucas**: Temos que priorizar o que vai ser feito, porque se tentarmos fazer tudo não vai dar certo. + +Todos concordaram com os pontos levantados \ No newline at end of file diff --git a/docs/SprintsAndMeetings/2020-09-05-Sprint2Opening.md b/docs/SprintsAndMeetings/2020-09-05-Sprint2Opening.md new file mode 100644 index 0000000..f4ece39 --- /dev/null +++ b/docs/SprintsAndMeetings/2020-09-05-Sprint2Opening.md @@ -0,0 +1,46 @@ +# Abertura da Sprint 2 + +| Data | Versão | Descrição | Autor(es) | +| :--------: | :----: | :-----------------------: | :---------------------------: | +| 11/09/2020 | 1.0 | Transcrição do documento 20200905 do teams | [Iuri Severo](https://github.com/iurisevero) | + +**Data**: 05 de setembro de 2020 + +**Redigida por**: Iuri Severo + +**Participantes**: +* Caio Fernandes +* Guilherme Mendes +* Iuri Severo +* João Pedro +* Lucas Fellipe + +## Planning + +### Duração + +| Duração | Início | Fim | +| ------- | ---------- | ---------- | +| 6 dias | 07/09/2020 | 12/09/2020 | + +### Sprint Backlog + +| Descrição da Tarefa | Responsável(eis) | Pontuação | Débito Técnico | +| ------------------- | ---------------- | --------- | -------------- | +| Documento de Visão | Lucas, Caio, Guilherme, Iuri e João | 8 | 1 | +| Backlog do Produto | Caio, Guilherme e Lucas | 13 | 0 | +| Documentar e explicar metodologia | João Pedro e Iuri | 5 | 0 | +| Diagrama BPMN da metodologia | Lucas, Caio, Guilherme, Iuri e João | 13 | 0 | + +O documento de Visão ficou dividido da seguinte forma: +* Tópico 3. Descrição dos envolvidos e dos usuários - Lucas +* Tópico 4. Visão geral do produto – João Pedro e Iuri +* Tópico 5. Recursos do produto – Guilherme +* Tópico 6. Restrições - Lucas +* Tópico 7. Requisitos do Sistemas – Caio + +> Se houver débito técnico ele deverá ser incluso na tabela de Sprint Backlog e a coluna de Débito Técnico deverá ser alterada para "1" (true) + +## Notas pós reunião + +Após a reunião foi marcada uma reunião para a equipe elaborar o diagrama BPMN. A reunião ficou marcada para quarta-feira, dia 09 de setembro. \ No newline at end of file diff --git a/docs/SprintsAndMeetings/2020-09-12-Sprint2Closure.md b/docs/SprintsAndMeetings/2020-09-12-Sprint2Closure.md new file mode 100644 index 0000000..be293ca --- /dev/null +++ b/docs/SprintsAndMeetings/2020-09-12-Sprint2Closure.md @@ -0,0 +1,65 @@ +# Fechamento da Sprint 2 + +| Data | Versão | Descrição | Autor(es) | +| :--------: | :----: | :-----------------------: | :---------------------------: | +| 12/09/2020 | 1.0 | Fechamento da Sprint 2 | [Iuri Severo](https://github.com/iurisevero) | + +**Data**: 12 de setembro de 2020 + +**Redigida por**: Iuri Severo + +**Participantes**: +* Caio Fernandes +* Guilherme Mendes +* Iuri Severo +* João Pedro +* Lucas Fellipe + +## Notas pré reunião + +Antes da reunião foi levantado os pontos que o Iuri percebeu durante a transcrição das reuniões, que foram os artefatos escolhidos para elicitação, mas que foram esquecidos. Todos do grupo estão cientes que isso aconteceu por conta da prioridade maior de outros artefatos desenvolvidos pela equipe. + +## Review + +* Caio: Nessa sprint participou da elaboração do BPMN, ajudou na elaboração dos léxicos com o Guilherme e Lucas, ajudou na elaboração do backlog e ajudou na elaboração do documento de visão; +* Guilherme: Nessa sprint participou da elaboração do BPMN, dos léxicos com o Lucas e o Caio, ajudou no backlog, no documento de visão e na documentação das entrevistas; +* Iuri: Nessa sprint participou do BPMN, do detalhamento das metodologias, do documento de visão, transcreveu reuniões que estavam no teams para wiki, criou modelos de documentação de reuniões e gravou os audios pro BPMN; +* João: Essa semana começou fazendo o detalhamento da metodologia com o Iuri, depois o BPMN com todo mundo, depois disso subiu o BPMN para wiki. Ajudou no backlog, trabalhou no documento de visão e ontem preparou as coisas para entrega e modificou a organização da wiki; +* Lucas: Nessa sprint fez o plano de gerenciamento de riscos, o plano de comunicação, participou da elaboração do BPMN junto com a equipe, fez a parte dele do documento de visão, participou da elaboração do backlog do produto, ontem arrumou algumas coisas para entrega e subiu o plano de custos para wiki. Ajudou na elaboração dos léxicos. + +### Gráfico de Burn-Down + +
+
+### Gráfico de Velocity
+
+
+
+## Retrospective
+
+* Caio
+ * Positivos: Como sempre, a equipe é muito boa, todos trabalham bastante, fazem as reuniões e paream. É um ponto muito positivo;
+ * Negativos: Vou levantar dois pontos: o primeiro ponto é que eu fiquei de documentar o documento de custos e acabei esquecendo disso; e o segundo ponto é que eu não estava presente ontem, acabei esquecendo e peço desculpas por isso. To devendo uma pizza pra vocês;
+ * Melhorias: Não tenho melhorias para citar.
+* Guilherme
+ * Positivos: Concordo com o Caio em relação a comunicação e engajamento do grupo, todo mundo bem integrado, participando e comentando todos documentos e artefatos. Organização do grupo melhorou bastante;
+ * Negativos: Acho que, como é normal, teve algumas falhas nas pontuações. Acho que teve um problema na criação das issues, no planejamento do que seria feito na sprint. Tivemos que criar e fechar issues durante a sprint;
+ * Melhorias: Planejar melhor as sprint e o que será feito.
+* Iuri
+ * Positivo: A gente trabalha muito bem junto e a gente conseguiu fechar todos os documentos, mesmo tendo documentos que a gente não sabia que ia fazer;
+ * Negativo: Não saber quais documentos que a gente tinha que fazer não foi algo bom de acontecer;
+ * Melhorar: Planejar sprint, saber melhor quais as tarefas que temos.
+* João
+ * Positivo: Como todo mundo falou, a proatividade de todos membros do grupo. Pareamento foi muito bom. Sinto que aprendi coisas novas essa semana, foi legal. Mesmo sendo cansativo, foi muito bom;
+ * Negativo: Mandei mensagem para Milene perguntando quais documentos tinhamos que entregar e descobri que tinham vários documentos que não fizemos;
+ * Melhorar: Essa questão de prestar mais atenção nas entregas e deixar realmente definido o que temos que fazer. Olhar as entregas na hora do planejamento e evitar impedimentos. Ler melhor o moodle para saber o que temos que fazer.
+* Lucas
+ * Positivos: Acredito que todo mundo trabalha muito bem junto, tá todo mundo engajado. Acho que nossos documentos são feitos com muita qualidade. Os pareamentos são muito bons, é muito bom trocar esse conhecimento entre a gente;
+ * Negativos: Essa questão de a gente decidir melhor quais artefatos vão ser feitos, definir bem. Eu sei que tá todo mundo ocupado, muita coisa para fazer, mas acredito que quando tivermos mais tempo livre, pouco antes do fim da sprint tentar adiantar algumas coisas. Independente disso, sempre entregamos as issues. Planejamento das sprints;
+ * Melhorar: Planejar as sprints melhor, definindo melhor quais artefatos serão feitos.
+
+## Notas pós reunião
+
+O Caio disse que vai pagar pizza para o grupo.
+* Pedir feedback para outros monitores.
+* Colocar mais coisas nos léxicos.
diff --git a/docs/SprintsAndMeetings/2020-09-12-Sprint3Opening.md b/docs/SprintsAndMeetings/2020-09-12-Sprint3Opening.md
new file mode 100644
index 0000000..501c7ce
--- /dev/null
+++ b/docs/SprintsAndMeetings/2020-09-12-Sprint3Opening.md
@@ -0,0 +1,45 @@
+# Abertura da Sprint 3
+
+| Data | Versão | Descrição | Autor(es) |
+| :--------: | :----: | :-----------------------: | :---------------------------: |
+| 12/09/2020 | 1.0 | Abertura da Sprint 3 | [Iuri Severo](https://github.com/iurisevero) |
+
+**Data**: 12 de setembro de 2020
+
+**Redigida por**: Iuri Severo
+
+**Participantes**:
+* Caio Fernandes
+* Guilherme Mendes
+* Iuri Severo
+* João Pedro
+* Lucas Fellipe
+
+## Planning
+
+### Duração
+
+| Duração | Início | Fim |
+| ------- | ---------- | ---------- |
+| 7 dias | 13/09/2020 | 19/09/2020 |
+
+### Sprint Backlog
+
+| Descrição da Tarefa | Responsável(eis) | Pontuação | Débito Técnico |
+| ------------------- | ---------------- | --------- | -------------- |
+| Avaliação por pares | Caio, Guilherme, Iuri, João e Lucas | 5 | 0 |
+| Preparar o ambiente de código para o back | Guilherme e Iuri | 8 | 0 |
+| Preparar o ambiente de código para o front | João Pedro | 8 | 0 |
+| Priorizar o backlog | Caio, Guilherme, Iuri, João e Lucas | 8 | 0 |
+| Diagrama Entidade e Relacionamento | Caio e Lucas | 21 | 0 |
+
+> Se houver débito técnico ele deverá ser incluso na tabela de Sprint Backlog e a coluna de Débito Técnico deverá ser alterada para "1" (true)
+
+## Notas pós reunião
+
+Segunda-feira o grupo se reunirá para fazer a avaliação em pares.
+O grupo se reunirá para fazer a priorização do backlog (dia a definir).
+E para a próxima sprint ficarão as seguintes issues:
+* Refatorar os Léxicos - 13
+* Adicionar questões de configuração no backlog - 3
+* Matriz de relação dos requisitos - 8
\ No newline at end of file
diff --git a/docs/SprintsAndMeetings/2020-09-19-Sprint3Closure.md b/docs/SprintsAndMeetings/2020-09-19-Sprint3Closure.md
new file mode 100644
index 0000000..630986a
--- /dev/null
+++ b/docs/SprintsAndMeetings/2020-09-19-Sprint3Closure.md
@@ -0,0 +1,59 @@
+# Fechamento da Sprint 3
+
+| Data | Versão | Descrição | Autor(es) |
+| :--------: | :----: | :-----------------------: | :---------------------------: |
+| 19/09/2020 | 1.0 | Fechamento da Sprint 3 | [Iuri Severo](https://github.com/iurisevero) |
+
+**Data**: 19 de setembro de 2020
+
+**Redigida por**: Iuri Severo
+
+**Participantes**:
+* Caio Fernandes
+* Guilherme Mendes
+* Iuri Severo
+* João Pedro
+* Lucas Fellipe
+
+## Review
+
+* Caio: Nessa sprint fez a avaliação por pares segunda, quarta e sexta pareou com o Lucas para fazer o DER. Quarta de manhã participou da priorização do Backlog.
+* Guilherme: Assim como o Caio e o resto do grupo, participou da avaliação por pares na segunda, na quarta participou da priorização do Backlog e pareou com o Iuri 3 dias para desenvolver o ambiente do backend.
+* Iuri: Assim como o Caio e o resto do grupo, participou da avaliação por pares na segunda, na quarta participou da priorização do Backlog e pareou com o Guilherme 3 dias para desenvolver o ambiente do backend. Pesquisou um pouco de Eve com Mongo.
+* João Pedro: Essa sprint trabalhou na configuração inicial do repositório de frontend, com README. Participou da priorização do backlog e da avaliação por pares.
+* Lucas: Essa semana participou da avaliação por pares, quarte participou da priorização do backlog e pareou com o Caio para fazer o DER, quarta de tarde, sexta de noite e hoje de manhã terminaram o documento.
+
+### Gráfico de Burn-Down
+
+
+
+### Gráfico de Velocity
+
+
+
+## Retrospective
+
+* Caio
+ * Positivos: O grupo continua trabalhando bem, todo mundo trabalhando junto. Pareamento com o Lucas foi bom, apesar dos dois estarem com muito conflito de horário, a comunicação foi boa para melhorar o artefato desenvolvido.
+ * Negativos: -
+ * Melhorias: -
+* Guilherme
+ * Positivos: Concordo com o Caio, o grupo ainda está bem focado. O pareamento com o Iuri, a gente conseguiu encontrar tempo durante a semana, se organizar bem e concluir a issue. As sprints estão fechando sem dívida técnica.
+ * Negativos: Não teve
+ * Melhorias: Melhorar a questão da revisão dos PRs para melhorar o burndown. Estamos concluindo as issues, mas ninguém está validando e fechando o PR.
+* Iuri
+ * Positivos: Concordo com o que foi dito sobre o grupo, todos continuam trabalhando bem. O pareamento com o Gui deu muito certo, apesar do meu problema no cadastro da AWS.
+ * Negativos: AWS não ter deixado eu fazer meu cadastro atrasou o deploy.
+ * Melhorias: Revisar PR, ficar mais atento nisso. Criar as issues antes de realizar a tarefa
+* João Pedro
+ * Positivos: A questão do trabalho em grupo, como todo mundo falou. Achei legal que mesmo marcando reunião 8h da manhã todo mundo participa
+ * Negativos: Senti que essa semana eu podia ter me organizado melhor.
+ * Melhorias: Organização
+* Lucas
+ * Positivos: O grupo ainda está muito engajado, todo mundo entregando as issues antes da sprint acabar. O pareamento com o Caio foi muito bom, apesar dos conflitos de horários. Foi uma semana puxada para todo mundo, mas conseguimos fazer as issues. Comunicação do time tá muito ok, todo mundo sempre está disponível para ajudar e tirar dúvidas.
+ * Negativos: Correria com a faculdade e com o estágio, todo mundo tem algum projeto em paralelo e essa parte de validação dos PR que o Guilherme comentou, que a gente acaba esquecendo.
+ * Melhorias: Melhorar a questão de revisão dos PRs. Tirar um tempo pra fazer isso e organização no geral.
+
+## Notas pós reunião
+
+As issues estão feitas, mas os PRs não foram revisados.
diff --git a/docs/SprintsAndMeetings/2020-09-19-Sprint4Opening.md b/docs/SprintsAndMeetings/2020-09-19-Sprint4Opening.md
new file mode 100644
index 0000000..07f512c
--- /dev/null
+++ b/docs/SprintsAndMeetings/2020-09-19-Sprint4Opening.md
@@ -0,0 +1,43 @@
+# Abertura da Sprint 4
+
+| Data | Versão | Descrição | Autor(es) |
+| :--------: | :----: | :-----------------------: | :---------------------------: |
+| 19/09/2020 | 1.0 | Abertura da Sprint 4 | [Iuri Severo](https://github.com/iurisevero) |
+| 26/10/2020 | 1.1 | Adição do vídeo de apresentação dos padrões para o grupo | [João Pedro Guedes](https://github.com/sudjoao)|
+
+Gravação da Sprint Review, Retrospective e Planning
+
+**Data**: 19 de setembro de 2020
+
+**Redigida por**: Iuri Severo
+
+**Participantes**:
+* Caio Fernandes
+* Guilherme Mendes
+* Iuri Severo
+* João Pedro
+* Lucas Fellipe
+
+## Planning
+
+### Duração
+
+| Duração | Início | Fim |
+| ------- | ---------- | ---------- |
+| 7 dias | 20/09/2020 | 26/09/2020 |
+
+### Sprint Backlog
+
+| Descrição da Tarefa | Responsável(eis) | Pontuação | Débito Técnico |
+| ------------------- | ---------------- | --------- | -------------- |
+| Diagrama de Classe | João Pedro e Lucas | 21 | 0 |
+| Fazer um Diagrama Dinâmico | Iuri e Caio | 21 | 0 |
+| Diagrama de Pacotes | Guilherme (e João Pedro) | 8 | 0 |
+| Matriz de relação dos requisitos | Guilherme | 5 | 0 |
+
+> Se houver débito técnico ele deverá ser incluso na tabela de Sprint Backlog e a coluna de Débito Técnico deverá ser alterada para "1" (true)
+
+## Notas pós reunião
+E para a próxima sprint ficarão as seguintes issues:
+* Adicionar questões de configuração no backlog - 3
+* Refatorar os Léxicos - 13
\ No newline at end of file
diff --git a/docs/SprintsAndMeetings/2020-09-26-Sprint4Closure.md b/docs/SprintsAndMeetings/2020-09-26-Sprint4Closure.md
new file mode 100644
index 0000000..df1bdf7
--- /dev/null
+++ b/docs/SprintsAndMeetings/2020-09-26-Sprint4Closure.md
@@ -0,0 +1,56 @@
+# Fechamento da Sprint 4
+
+| Data | Versão | Descrição | Autor(es) |
+| :--------: | :----: | :-----------------------: | :---------------------------: |
+| 26/09/2020 | 0.9 | Fechamento da Sprint 4 | [Guilherme Mendes](https://github.com/guilherme-mendes) |
+| 26/09/2020 | 1.0 | Adição dos Gráficos de Burn-Down e Velocity da Sprint 4 | [Iuri Severo](https://github.com/iurisevero) |
+
+**Data**: 26 de setembro de 2020
+
+**Redigida por**: Guilherme Mendes
+
+**Participantes**:
+* Caio Fernandes
+* Guilherme Mendes
+* Iuri Severo
+* João Pedro
+* Lucas Fellipe
+
+## Review
+
+* Caio: Nessa sprint assistiu as aulas de UML estático e dinâmico, pareou com o Iuri quarta, quinta e sexta para a realização do diagrama de sequência. (diagrama dinâmico)
+* Guilherme: Nessa sprint elaborou o diagrama de pacotes na quarta-feira e a matriz de relações.
+* Iuri: Nessa sprint assistiu as aulas de modelagem, pareou com o Caio quarta, quinta e sexta para realizar o diagrama de sequência. Alêm disso, se reuniram para finalizar a documentação da sprint passada.
+* João: Nessa sprint, eu e o Lucas pareamos para realizar o diagrama de classes. Ontem conseguiram finalizar a última versão e subiram para o GitHub pages. Assistiu as aulas dos diagramas estáticos.
+* Lucas: Nessa sprint, eu e o João pareamos para realizar o diagrama de classes, 3 vezes durante a semana. o João finalizou o diagrama ontem e eu subi para a wiki com o PR já aprovado. Além disso, assistiu as primeiras aulas de modelagem.
+
+### Gráfico de Burn-Down
+
+
+
+### Gráfico de Velocity
+
+
+
+## Retrospective
+
+* Caio
+ * Positivos: Essa semana foi muito boa, consegui trabalhar constantemente para a matéria, assisti as aulas e fiz o pareamento com o Iuri.
+ * Negativos: Avaliação da professora, grupo com menos integrantes, alta carga de trabalho.
+ * Melhorias: Não tem melhorias.
+* Guilherme
+ * Positivos: Semana bem produtiva, conseguimos finalizar muitos documentos da parte de modelagem e o bom engajamento do grupo.
+ * Negativos: Não tem pontos negativos.
+ * Melhorias: Melhorias dos artefatos citados pela professora Milene.
+* Iuri
+ * Positivo: As entregas, conseguimos entregar tudo que propusemos, semana bem produtiva para todos, ótima organização do time.
+ * Negativo: Esquecimento da documentação da sprint passada e fazer novos diagramas de modelagem que não fizemos.
+ * Melhorar: Nenhuma melhoria.
+* João
+ * Positivo: Pareamento, comunicação e organização. Todos trabalhando bem durante a semana, como foram ditos na dailies.
+ * Negativo: Desânimo ao descobrir que terão mais artefatos a serem feitos, trazendo uma grande carga na equipe pelo tamanho do nosso escopo.
+ * Melhorar: Melhoria dos artefatos de acordo com o feedback da professora a respeito da primeira entrega.
+* Lucas
+ * Positivos: Pareamento, organização do grupo, comunicação constante do grupo, todo mundo trabalhando bem, se dedicou a disciplina.
+ * Negativos: Desânimo em ter que descobrir e ser obrigado a fazer todos os artefatos, pelo tamanho do escopo da matéria.
+ * Melhorar: Continuar melhorando organização e comunicação, além da melhoria dos artefatos citados pela professora Milene.
diff --git a/docs/SprintsAndMeetings/2020-09-26-Sprint5Opening.md b/docs/SprintsAndMeetings/2020-09-26-Sprint5Opening.md
new file mode 100644
index 0000000..cfed971
--- /dev/null
+++ b/docs/SprintsAndMeetings/2020-09-26-Sprint5Opening.md
@@ -0,0 +1,43 @@
+# Abertura da Sprint 5
+
+| Data | Versão | Descrição | Autor(es) |
+| :--------: | :----: | :-----------------------: | :---------------------------: |
+| 26/09/2020 | 1.0 | Abertura da Sprint 5 | [Guilherme Mendes](https://github.com/guilherme-mendes) |
+
+**Data**: 26 de setembro de 2020
+
+**Redigida por**: Guilherme Mendes
+
+**Participantes**:
+* Caio Fernandes
+* Guilherme Mendes
+* Iuri Severo
+* João Pedro
+* Lucas Fellipe
+
+## Planning
+
+### Duração
+
+| Duração | Início | Fim |
+| ------- | ---------- | ---------- |
+| 7 dias | 26/09/2020 | 03/10/2020 |
+
+### Sprint Backlog
+
+| Descrição da Tarefa | Responsável(eis) | Pontuação | Débito Técnico |
+| ------------------- | ---------------- | --------- | -------------- |
+| Digrama de componentes | Iuri Severo | 8 | 0 |
+| Diagrama de estados | Guilherme e Lucas Fellipe | 13 | 0 |
+| Diagrama de atividades | João Pedro | 8 | 0 |
+| Diagrama de comunicação | Caio Vinícius | 8 | 0 |
+| Avaliação por pares | Todos | 3 | 0 |
+| Refatoração Plano de Custos | Guilherme Mendes e Lucas Fellipe | 5 | 0 |
+| Refatoração Plano de Léxicos | Iuri Severo | 3 | 0 |
+| Refatoração Plano de Design Sprint e Protótipo de Alta fidelidade | João Pedro e Caio Vinícius | 3 | 0 |
+
+> Se houver débito técnico ele deverá ser incluso na tabela de Sprint Backlog e a coluna de Débito Técnico deverá ser alterada para "1" (true)
+
+## Notas pós reunião
+
+O grupo se reunirá para fazer a avaliação por pares.
\ No newline at end of file
diff --git a/docs/SprintsAndMeetings/2020-10-03-Sprint5Closure.md b/docs/SprintsAndMeetings/2020-10-03-Sprint5Closure.md
new file mode 100644
index 0000000..a20dc46
--- /dev/null
+++ b/docs/SprintsAndMeetings/2020-10-03-Sprint5Closure.md
@@ -0,0 +1,59 @@
+# Fechamento da Sprint 5
+
+| Data | Versão | Descrição | Autor(es) |
+| :--------: | :----: | :-----------------------: | :---------------------------: |
+| 03/10/2020 | 0.8 | Fechamento da Sprint 5 | [Lucas Fellipe](https://github.com/lucasfcm9) |
+| 10/10/2020 | 0.9 | Adição dos gráficos de burndown e velocity | [Lucas Fellipe](https://github.com/lucasfcm9) |
+| 10/10/2020 | 1.0 | Revisão do documento | [Iuri Severo](https://github.com/iurisevero) |
+
+**Data**: 03 de outubro de 2020
+
+**Redigida por**: Lucas Fellipe
+
+**Participantes**:
+* Caio Fernandes
+* Guilherme Mendes
+* Iuri Severo
+* João Pedro
+* Lucas Fellipe
+
+## Review
+
+* Caio: Fez a refatoração de dois documentos do Desing Sprint, o primeiro foi o documento da Desing Sprint e o segundo foi o do Brainstorming, também participou da avaliação por pares. Elaborou o diagrama de comunicaçãao.
+* Guilherme: Na segunda-feira pareou com o Lucas para realizar o diagrama de estados, participou da avaliação por pares e hoje (sábado) finalizou a refatoração do plano de custos junto com o Lucas.
+* Iuri: No domingo elaborou o diagrama de componentes, na segunda refatorou os léxicos e participou da avaliação por pares.
+* João: Domingo fez o diagrama de atividades, terça-feira fez a refatoração da documentação do protótipo de alta fidelidade, quinta-feira fez a refatoração do documento de mapa mental e sexta partipou da avaliação por pares.
+* Lucas: Na segunda-feira pareou com o Guilherme para a realização do diagrama de estados, participou da avaliação por pares e (sábado) finalizou a refatoração do plano de custos junto com o Guilherme.
+
+### Gráfico de Burn-Down
+
+
+
+
+### Gráfico de Velocity
+
+
+
+
+## Retrospective
+
+* Caio
+ * Positivos: União da equipe.
+ * Negativos: Teve muita demanda do trabalho, atrasou muito para realizar a issue do Design Sprint.
+ * Melhorias: Não tem melhorias.
+* Guilherme
+ * Positivos: Conseguimos entregar todos os diagramas na data certa.
+ * Negativos: Teve muitos impedimentos nessa semana, muitos trabalhos de outras disciplinas, só que não chegou a afetar a disciplina de desenho.
+ * Melhorias: Lembrar de usar o KanBan.
+* Iuri
+ * Positivo: O burn-down ficou mais bonito, conseguimos entregar os diagramas na segunda, já que era o prazo.
+ * Negativo: A sprint foi mais tranquila e, devido a isso, a próxima sprint vai pesar, ou seja, vai ser mais difícil.
+ * Melhorar: Lembrar de usar o KanBan e as estimativas referentes as issues.
+* João
+ * Positivo: A entrega dos diagramas com qualidade e o burn-down ficou bonito.
+ * Negativo: Demorou para terminar a outra issue (Design Sprint).
+ * Melhorar: Organização, como sempre.
+* Lucas
+ * Positivos: A entrega dos diagramas e o burn-down que ficou bonito.
+ * Negativos: Muitos impedimentos durante a semana, muitos trabalhos, uma carga muito alto sobre os integrantes do grupo.
+ * Melhorar: Organização e comunicação.
diff --git a/docs/SprintsAndMeetings/2020-10-03-Sprint6Opening.md b/docs/SprintsAndMeetings/2020-10-03-Sprint6Opening.md
new file mode 100644
index 0000000..cd46940
--- /dev/null
+++ b/docs/SprintsAndMeetings/2020-10-03-Sprint6Opening.md
@@ -0,0 +1,44 @@
+# Abertura da Sprint 6
+
+| Data | Versão | Descrição | Autor(es) |
+| :--------: | :----: | :-----------------------: | :---------------------------: |
+| 03/10/2020 | 0.9 | Abertura da Sprint 6 | [Lucas Fellipe](https://github.com/lucasfcm9) |
+| 10/10/2020 | 1.0 | Revisão do documento | [Iuri Severo](https://github.com/iurisevero) |
+
+**Data**: 03 de outubro de 2020
+
+**Redigida por**: Lucas Fellipe
+
+**Participantes**:
+* Caio Fernandes
+* Guilherme Mendes
+* Iuri Severo
+* João Pedro
+* Lucas Fellipe
+
+## Planning
+
+### Duração
+
+| Duração | Início | Fim |
+| ------- | ---------- | ---------- |
+| 7 dias | 04/10/2020 | 10/10/2020 |
+
+### Sprint Backlog
+
+| Descrição da Tarefa | Responsável(eis) | Pontuação | Débito Técnico |
+| ------------------- | ---------------- | --------- | -------------- |
+| Dojo de Flutter | João Pedro e Iuri Severo | 8 | 0 |
+| Estudo dirigido sobre GRASPs Criador | Caio Vinícius | 5 | 0 |
+| Estudo dirigido sobre GoFs Criacionais | Guilherme Mendes | 5 | 0 |
+| Estudo dirigido sobre GoFs Estruturais | Lucas Fellipe | 5 | 0 |
+| Estudo dirigido sobre GoFs Comportamentais | João Pedro | 5 | 0 |
+| Estudo dirigido sobre GRASPs Especialista | Caio Vinícius | 5 | 0 |
+| Estudo dirigido sobre padrões de projetos emergentes | Iuri Severo | 8 | 0 |
+
+> Se houver débito técnico ele deverá ser incluso na tabela de Sprint Backlog e a coluna de Débito Técnico deverá ser alterada para "1" (true)
+
+## Notas pós reunião
+
+Durante a Daily que ocorreu na segunda-feira, depois de assistirmos as vídeo-aulas sobre GRASPs, o grupo decidiu deixar o estudo dirigido relacionado as GRASPs para o Caio Vinícius e o estudo dirigido referente
+aos padrões de projetos emergentes para o Iuri Severo.
\ No newline at end of file
diff --git a/docs/SprintsAndMeetings/2020-10-10-Sprint6Closure.md b/docs/SprintsAndMeetings/2020-10-10-Sprint6Closure.md
new file mode 100644
index 0000000..dc0ec81
--- /dev/null
+++ b/docs/SprintsAndMeetings/2020-10-10-Sprint6Closure.md
@@ -0,0 +1,57 @@
+
+# Fechamento da Sprint 6
+
+| Data | Versão | Descrição | Autor(es) |
+| :--------: | :----: | :-----------------------: | :---------------------------: |
+| 10/10/2020 | 0.9 | Fechamento da Sprint 6 | [Caio Fernandes](https://github.com/caiovfernandes) |
+| 14/10/2020 | 1.0 | Revisão do documento | [Iuri Severo](https://github.com/iurisevero) |
+
+**Data**: 10 de Outubro de 2020
+
+**Redigida por**: Caio Fernandes
+
+**Participantes**:
+* Caio Fernandes
+* Guilherme Mendes
+* Iuri Severo
+* João Pedro
+* Lucas Fellipe
+
+## Review
+
+* Caio: Assistiu as aulas de GRASP, redigiu o estudo dirigido e participou do DOJO de Flutter.
+* Guilherme: Assistiu as aulas de GOF's criacionais, redigiu o estudo dirigido e participou do DOJO de Flutter.
+* Iuri: Assistiu as aulas de GRASP, pesquisou sobre os padrões de projetos emergente e planejou o DOJO de FLUTTER com o João Pedro.
+* João: Assistiu as aulas sobre GRASP's, GOF's criacionais, GOF's comportamentais, também planejou e participou do DOJO de Flutter.
+* Lucas: Assitiu aulas sobre GOF's estruturais, redigiu estudo dirigido e participou do DOJO de Flutter.
+
+### Gráfico de Burn-Down
+
+
+
+### Gráfico de Velocity
+
+
+
+## Retrospective
+
+* Caio
+ * Positivos: Time muito integrado, todos os membros trabalhando e DOJO de Flutter
+ * Negativos: Não codamos nesta sprint
+ * Melhorias:
+* Guilherme
+ * Positivos: Iniciativa do DOJO de Flutter, muito bom e explicativo. Empenho dos membros para assistir as aulas e elaborar os estudos dirigidos.
+ * Negativos: Time não começou a implementar códigos.
+ * Melhorias: Refatoração dos artefatos, mesmo com o feedback não planejamos ainda.
+* Iuri
+ * Positivo: Estudos dos membros e Dojo de Flutter.
+ * Negativo: Fizemos pouco ponto nesta sprint e o gráfico de burndown ficou ruim. Receber o feedback depois da sprint já planejada também foi um ponto negativo. Confusão com padrões de projetos emergentes, dificuldade em entender o que seriam esses padrões.
+ * Melhorar: Criar issue, pontuar, adicionar a label e atualizar o KanBan. Grupo está esquecendo disso.
+* João
+ * Positivo: Planejamento da semana foi muito bom. Conteúdo deste módulo também e Dojo de Flutter. Feedback da professora, foi bom.
+ * Negativo: Organização, também estava desanimado no começo da semana.
+ * Melhorar: Melhorar organização e planejamento das tarefas.
+* Lucas
+ * Positivos: Semana foi muito boa, os estudos dirigidos ficaram muito bons. Dojo de flutter também foi muito bom e todo o time fez as entregas corretamente.
+ * Negativos: Não codamos neste sprint.
+ * Melhorar: Organização e comunicação.
diff --git a/docs/SprintsAndMeetings/2020-10-10-Sprint7Opening.md b/docs/SprintsAndMeetings/2020-10-10-Sprint7Opening.md
new file mode 100644
index 0000000..fb4bcb0
--- /dev/null
+++ b/docs/SprintsAndMeetings/2020-10-10-Sprint7Opening.md
@@ -0,0 +1,52 @@
+# Abertura da Sprint 7
+
+| Data | Versão | Descrição | Autor(es) |
+| :--------: | :----: | :-----------------------: | :---------------------------: |
+| 10/10/2020 | 0.9 | Abertura da Sprint 7 | [Caio Fernandes](https://github.com/caiovfernandes) |
+| 14/10/2020 | 1.0 | Revisão do documento | [Iuri Severo](https://github.com/iurisevero) |
+| 26/10/2020 | 1.1 | Adição do vídeo de apresentação dos padrões para o grupo | [João Pedro Guedes](https://github.com/sudjoao)|
+
+Gravação da Sprint Review, Retrospective e Planning
+
+**Data**: 10 de setembro de 2020
+
+**Redigida por**: Caio Fernandes
+
+**Participantes**:
+* Caio Fernandes
+* Guilherme Mendes
+* Iuri Severo
+* João Pedro
+* Lucas Fellipe
+
+## Planning
+
+### Duração
+
+| Duração | Início | Fim |
+| ------- | ---------- | ---------- |
+| 7 dias | 10/10/2020 | 17/10/2020 |
+
+### Sprint Backlog
+
+| Descrição da Tarefa | Responsável(eis) | Pontuação | Débito Técnico |
+| ------------------- | ---------------- | --------- | -------------- |
+| Definir padrões dos GRASP's | Caio Fernandes | 5 | 0 |
+| Definir padrões dos GoF's Criacionais | Guilherme Mendes | 5 | 0 |
+| Definir padrões dos GoF's Estruturais | Lucas Fellipe | 5 | 0 |
+| Definir padrões dos GoF's Comportamentais | João Pedro | 5 | 0 |
+| Apresentar padrões emergentes | Iuri Severo | 3 | 0 |
+| Databse: DDL do Banco de Dados | Todos | 13 | 0 |
+| Databse: DML do Banco de Dados | Todos | 5 | 0 |
+| US41 - Cadastro de usuário | João Pedro | 8 | 0 |
+| US42 - Visualizar perfil | Iuri Severo e Guilherme Mendes | 13 | 0 |
+| US45 - Login Autenticação | Caio Fernandes, Lucas Fellipe e João Pedro| 21 | 0 |
+
+
+
+> Se houver débito técnico ele deverá ser incluso na tabela de Sprint Backlog e a coluna de Débito Técnico deverá ser alterada para "1" (true)
+
+## Notas pós reunião
+Próxima sprint seria interessante realizar:
+* Refatoração do DER.
+* Refatoração dos documentos
\ No newline at end of file
diff --git a/docs/SprintsAndMeetings/2020-10-17-Sprint7Closure.md b/docs/SprintsAndMeetings/2020-10-17-Sprint7Closure.md
new file mode 100644
index 0000000..6e7d934
--- /dev/null
+++ b/docs/SprintsAndMeetings/2020-10-17-Sprint7Closure.md
@@ -0,0 +1,62 @@
+# Fechamento da Sprint 7
+
+| Data | Versão | Descrição | Autor(es) |
+| :--------: | :----: | :-----------------------: | :---------------------------: |
+| 17/10/2020 | 0.9 | Fechamento da Sprint 7 | [João Pedro](https://github.com/sudjoao) |
+| 21/10/2020 | 1.0 | Revisão do documento | [Iuri Severo](https://github.com/iurisevero)|
+
+**Data**: 17 de outubro de 2020
+
+**Redigida por**: João Pedro Guedes
+
+**Participantes**:
+* Caio Fernandes
+* Guilherme Mendes
+* Iuri Severo
+* João Pedro
+* Lucas Fellipe
+
+## Review
+
+* Caio: Nessa semana fez a apresentação dos graps segunda-feira, durante a semana participou das reuniões de apresentação dos membros dos grupos, implementou a issue de login e autenticação e um pouco da de registro. Vai terminar a issue hoje com o Lucas
+* Guilherme: Fez apresentação sobre gofs criacionas, assistiu as demais apresentações, pareou com o Iuri para fazer a issue de visualização de dados do usuário e pretende terminar hoje a parte do frontend.
+* Iuri: Assim como todo mundo, apresentou sobre emergentes e assistiu outras apresentações. Pareou com o Gui para tentar fazer a issue de visualização e apanharam um bocado do banco.
+* João Pedro: Fez apresentação sobre GoFs comportamentais e assistiu as outras apresentações. Fez a página de cadastro do usuário, e as respectivas rotas relacionadas, criou o services no frontend para integrar com o back.
+* Lucas: Fez apresentação de GOFs estruturais, participou das apresentações, implementou a issue de criação e autenticação com o Caio e o Johnson. Vai terminar a issue hoje com o Caio.
+
+### Gráfico de Burn-Down
+
+
+
+### Gráfico de Velocity
+
+
+
+
+## Retrospective
+
+* Caio
+ * Positivos: Todos trabalharam muito, fizemos bastante coisas, conseguimos seguir o planejamento.
+ * Negativos: O planejamento da Sprint passada não foi tão bom assim, aconteceu retrabalho.
+ * Melhorias: Melhorar planejamento.
+* Guilherme
+ * Positivos: Todos trabalharam muito bem, todos fizeram suas partes do estudo dirigido, começamos a codificar também.
+ * Negativos: Planejamento.
+ * Melhorias: Planejamento das sprints.
+* Iuri
+ * Positivos: Quantidade de trabalho feito, conseguimos adiantar muita coisa, reuniões com todo mundo junto.
+ * Negativos: Problemas com banco/relacionamento, atrapalhou muito a sprint.
+ * Melhorias: Dependencia entre issues.
+* João Pedro
+ * Positivos: Alinhamento do grupo, todos trabalhando junto e dando o máximo de si, comprometimento, quantidade de trabalho.
+ * Negativos: Muita coisa pra fazer por falta de planejamento efetivo.
+ * Melhorias: Planejamento das sprints.
+* Lucas
+ * Positivos: O que todo mundo falou, todos engajados e comprometidos, todos fazendo as coisas. O estudo dirigido foi um ponto muito positivo, pois cada um explicando o que aprendeu ajudou muito. Começar a fazer o código também deu uma animada.
+ * Negativos: Problema com o banco/relacionamento, o planejamento.
+ * Melhorias: Melhorar o planejamento, evitar dependência entre as issues.
+
+## Notas pós reunião
+
+* Criar issue do DNL;
+* Subir ainda hoje os documentos falando onde e quais padrões iremos aplicar.
\ No newline at end of file
diff --git a/docs/SprintsAndMeetings/2020-10-17-Sprint8Opening.md b/docs/SprintsAndMeetings/2020-10-17-Sprint8Opening.md
new file mode 100644
index 0000000..491d5ea
--- /dev/null
+++ b/docs/SprintsAndMeetings/2020-10-17-Sprint8Opening.md
@@ -0,0 +1,45 @@
+# Abertura da Sprint 8
+
+| Data | Versão | Descrição | Autor(es) |
+| :--------: | :----: | :-----------------------: | :---------------------------: |
+| 17/10/2020 | 0.9 | Abertura da Sprint 8 | [João Pedro Guedes](https://github.com/sudjoao) |
+| 21/10/2020 | 1.0 | Revisão do documento | [Iuri Severo](https://github.com/iurisevero) |
+| 26/10/2020 | 1.1 | Adição do vídeo de apresentação dos padrões para o grupo | [João Pedro Guedes](https://github.com/sudjoao)|
+
+Gravação da Sprint Review, Retrospective e Planning
+
+**Data**: 17 de outubro de 2020
+
+**Redigida por**: João Pedro Guedes
+
+**Participantes**:
+* Caio Fernandes
+* Guilherme Mendes
+* Iuri Severo
+* João Pedro
+* Lucas Fellipe
+
+## Planning
+
+### Duração
+
+| Duração | Início | Fim |
+| ------- | ---------- | ---------- |
+| 7 dias | 18/10/2020 | 24/10/2020 |
+
+### Sprint Backlog
+
+| Descrição da Tarefa | Responsável(eis) | Pontuação | Débito Técnico |
+| ------------------- | ---------------- | --------- | -------------- |
+| US41 - Cadastro de usuário | João Pedro | 8 | 1 |
+| US45 - Login Autenticação | Caio Fernandes, Lucas Fellipe e João Pedro| 21 | 1 |
+| US46 - Eu, como desenvolvedor desejo aplicar padrões de projetos no Relatório |Iuri, João Pedro e Lucas |21 | 0 |
+| US48 - Eu, como desenvolvedor desejo aplicar padrões de projetos no Bovino |Caio e Guilherme |13 | 0 |
+|Refatoração de Diagrama de Classes| Caio | 5 | 0 |
+|Refatoração de Diagrama de Pacotes| João Pedro | 5| 0 |
+|Refatoração de Diagrama de Componentes| Lucas | 5| 0 |
+|Refatoração de Diagrama de Estados| Iuri | 5| 0 |
+|Refatoração de Diagrama de Colaboração|Guilherme |2|0 |
+|Refatoração de Diagrama de Atividades| Guilherme |2| 0 |
+|Refatoração de Diagrama de Sequencia| João Pedro |2| 0 |
+> Se houver débito técnico ele deverá ser incluso na tabela de Sprint Backlog e a coluna de Débito Técnico deverá ser alterada para "1" (true)
diff --git a/docs/SprintsAndMeetings/2020-10-26-Sprint8Closure.md b/docs/SprintsAndMeetings/2020-10-26-Sprint8Closure.md
new file mode 100644
index 0000000..e980b56
--- /dev/null
+++ b/docs/SprintsAndMeetings/2020-10-26-Sprint8Closure.md
@@ -0,0 +1,58 @@
+# Fechamento da Sprint 8
+
+| Data | Versão | Descrição | Autor(es) |
+| :--------: | :----: | :-----------------------: | :---------------------------: |
+| 26/10/2020 | 0.8 | Fechamento da Sprint 8 | [Iuri Severo](https://github.com/iurisevero) |
+| 02/11/2020 | 0.9 | Adição dos gráficos | [Iuri Severo](https://github.com/iurisevero) |
+| 03/11/2020 | 1.0 | Revisão do Documento | [Lucas Fellipe](https://github.com/lucasfcm9) |
+
+**Data**: 26 de outubro de 2020
+
+**Redigida por**: Iuri Severo
+
+**Participantes**:
+* Caio Fernandes
+* Guilherme Mendes
+* Iuri Severo
+* João Pedro
+* Lucas Fellipe
+
+## Review
+
+* Caio: Nessa sprint refatorou o diagrama de classe e também implementou os padrões de projeto na parte de bovinos, no backend;
+* Guilherme: Essa semana refatorou o diagrama de colaboração e de atividades e ficou junto com o Caio na história de criação dos bovinos e aplicação dos padrões de projeto;
+* Iuri: Refatorou o diagrama de Estados e aplicou os padrões de projeto nos relatórios com o Lucas e o João Pedro;
+* João Pedro: Nessa sprint aplicou os padrões de projeto nos relatórios com o Lucas e com o Iuri, além disso começou a refatorar o diagrama de pacotes e subiu os vídeos para o youtube e adicionou na wiki;
+* Lucas: Nessa sprint aplicou os padrões de projeto nos relatórios com o João e com o Iuri, refatorou o diagrama de componentes, teve um pouco de dificuldades, mas conseguiu fazer;
+
+### Gráfico de Burn-Down
+
+
+
+### Gráfico de Velocity
+
+
+
+
+## Retrospective
+
+* Caio
+ * Positivos: Como sempre, todo mundo trabalhando muito bem e num ritmo constante. Estamos evoluindo bem no projeto. Tivemos problema com sqlalchemy no inicio e agora não estamos mais com tanta dificuldade
+ * Negativos: Essa semana teve muita coisa da faculdade
+ * Melhorias: Nenhuma
+* Guilherme
+ * Positivos: Todos estão trabalhando muito para entregar as issues, se esforçando bastante; Achei que teríamos dificuldade na aplicação dos padrões, mas até que nos saímos bem
+ * Negativos: Não teve, essa semana foi muito boa;
+ * Melhorias: Planejamento no inicio da sprint, que aconteceu de termos que acrescentar issues ao longo da sprint
+* Iuri
+ * Positivos: Conseguimos aplicar os padrões durante o pareamento, foi difícil, mas deu certo. Todos trabalharam bem na sprint.
+ * Negativos: Acho que nenhum
+ * Melhorias: Criação das issues, milestones, sprint e movimentação das tasks no board do zenhub.
+* João Pedro
+ * Positivos: Foi muito legal o empenho do grupo, todos correndo atrás para aplicar os padrões de projeto e o conhecimento que adquirimos para conseguir aplicá-los. Pareamento ajudou muito na hora de entender o conteúdo;
+ * Negativos: A escolha da tecnologia foi um ponto negativo, apesar de ser uma tecnologia que sabíamos, tivemos problemas por conta do flask. Se fosse java, por exemplo, teríamos menos dificuldade;
+ * Melhorias: Organização, faltou um pouco da entrega contínua, mas também eram issues difíceis
+* Lucas
+ * Positivos: Todos estão trabalhando bastante para entregar as issues; Comunicação foi muito boa, os pareamentos também, todo mundo empenhado para se ajudar; Conseguimos aplicar os padrões de projeto, apesar de serem complicados
+ * Negativos: Vou concordar com o João Pedro em relação a tecnologia, com o SQLAlchemy, que complicou a aplicação dos padrões, mas deu bom no final
+ * Melhorias: Comunicação e organização sempre é passivo de melhoria
diff --git a/docs/SprintsAndMeetings/2020-10-26-Sprint9Opening.md b/docs/SprintsAndMeetings/2020-10-26-Sprint9Opening.md
new file mode 100644
index 0000000..51eae24
--- /dev/null
+++ b/docs/SprintsAndMeetings/2020-10-26-Sprint9Opening.md
@@ -0,0 +1,43 @@
+# Abertura da Sprint 9
+
+| Data | Versão | Descrição | Autor(es) |
+| :--------: | :----: | :-----------------------: | :---------------------------: |
+| 26/10/2020 | 0.8 | Abertura da Sprint 9 | [Iuri Severo](https://github.com/iurisevero) |
+| 02/11/2020 | 0.9 | Correção do título do documento e duração | [Iuri Severo](https://github.com/iurisevero) |
+| 03/11/2020 | 1.0 | Revisão do Documento | [Lucas Fellipe](https://github.com/lucasfcm9) |
+
+**Data**: 26 de outubro de 2020
+
+**Redigida por**: Iuri Severo
+
+**Participantes**:
+* Caio Fernandes
+* Guilherme Mendes
+* Iuri Severo
+* João Pedro
+* Lucas Fellipe
+
+## Planning
+
+### Duração
+
+| Duração | Início | Fim |
+| ------- | ---------- | ---------- |
+| 7 dias | 27/10/2020 | 02/10/2020 |
+
+### Sprint Backlog
+
+| Descrição da Tarefa | Responsável(eis) | Pontuação | Débito Técnico |
+| ------------------- | ---------------- | --------- | -------------- |
+| Refatoração de Diagrama de Pacotes | João Pedro | 5| 1 |
+| Refatoração de Diagrama de Sequencia | João Pedro |2| 1 |
+| Avaliação por pares | Todos | 5 | 0 |
+| Documento de Arquitetura | Todos | 13 | 0 |
+| Tela geral de bovino | Caio e João Pedro | 13 | 0 |
+| Tela individual de bovino | Guilherme e Lucas | 8 | 0 |
+| Tela de criação de bovino | Guilherme e Lucas | 8 | 0 |
+| Barra de navegação | Iuri e João Pedro | 8 | 0 |
+| CI do git com Lint | Caio e Iuri | 5 | 0 |
+| Alterar o banco para o Heroku com SQL | Iuri | 3 | 0 |
+
+> Se houver débito técnico ele deverá ser incluso na tabela de Sprint Backlog e a coluna de Débito Técnico deverá ser alterada para "1" (true)
diff --git a/docs/SprintsAndMeetings/2020-11-02-Sprint10Opening.md b/docs/SprintsAndMeetings/2020-11-02-Sprint10Opening.md
new file mode 100644
index 0000000..a8be129
--- /dev/null
+++ b/docs/SprintsAndMeetings/2020-11-02-Sprint10Opening.md
@@ -0,0 +1,48 @@
+# Abertura da Sprint 10
+
+| Data | Versão | Descrição | Autor(es) |
+| :--------: | :----: | :-----------------------: | :---------------------------: |
+| 02/11/2020 | 0.9 | Abertura da Sprint 10 | [Lucas Fellipe](https://github.com/lucasfcm9) |
+| 04/11/2020 | 1.0 | Revisão do Documento | [Caio Fernandes](https://github.com/caiovfernandes) |
+| 04/11/2020 | 1.1 | Arrumando tabela de sprint backlog| [João Guedes](https://github.com/sudjoao)|
+
+
+Gravação da Sprint Review, Retrospective e Planning
+
+**Data**: 02 de Novembro de 2020
+
+**Redigida por**: Lucas Fellipe
+
+**Participantes**:
+* Caio Fernandes
+* Guilherme Mendes
+* Iuri Severo
+* João Pedro
+* Lucas Fellipe
+
+## Planning
+
+### Duração
+
+| Duração | Início | Fim |
+| ------- | ---------- | ---------- |
+| 7 dias | 02/11/2020 | 09/11/2020 |
+
+### Sprint Backlog
+
+| Descrição da Tarefa | Responsável(eis) | Pontuação | Débito Técnico |
+| ------------------- | ---------------- | --------- | -------------- |
+| Documento de Arquitetura | Todos | 21 | 1 |
+| US26 - Eu, como usuário, desejo cadastrar o peso do bovino, para ter o controle de ganho de massa do bovino | João Pedro | 8 | 0 |
+| US28 - Eu, como usuário, desejo obter a média de peso por lote bovino, para que eu tenha controle da qualidade de cada lote. | Caio e Guilherme | 8 | 0 |
+| US20 - Eu, como usuário, desejo selecionar o tipo de acasalamento realizado, para uma melhor organização dos meus manejos | Lucas e Iuri | 13 | 0 |
+| Linkagem das telas dos bovinos | João Pedro | 3 | 0 |
+
+
+
+
+
+> Se houver débito técnico ele deverá ser incluso na tabela de Sprint Backlog e a coluna de Débito Técnico deverá ser alterada para "1" (true)
+
+## Notas pós reunião
+* O grupo vai se reunir quarta-feira 8:00 horas da manhã para definir as tarefas do documento de arquitetura.
diff --git a/docs/SprintsAndMeetings/2020-11-02-Sprint9Closure.md b/docs/SprintsAndMeetings/2020-11-02-Sprint9Closure.md
new file mode 100644
index 0000000..75c5802
--- /dev/null
+++ b/docs/SprintsAndMeetings/2020-11-02-Sprint9Closure.md
@@ -0,0 +1,60 @@
+# Fechamento da Sprint 9
+
+| Data | Versão | Descrição | Autor(es) |
+| :--------: | :----: | :-----------------------: | :---------------------------: |
+| 02/11/2020 | 0.9 | Fechamento da Sprint 9 | [Lucas Fellipe](https://github.com/lucasfcm9) |
+| 04/11/2020 | 1.0 | Revisão do Documento | [Caio Fernandes](https://github.com/caiovfernandes) |
+
+**Data**: 02 de Novembro de 2020
+
+**Redigida por**: Lucas Fellipe
+
+**Participantes**:
+* Caio Fernandes
+* Guilherme Mendes
+* Iuri Severo
+* João Pedro
+* Lucas Fellipe
+
+## Review
+
+* Caio: Nessa semana fez a issue do CI e também a issue do front (tela geral de bovinos). Além disso, participou da avaliação por pares.
+* Guilherme: Nessa semana participou da avaliação por pares e juntamente com o Lucas trabalhou nas duas issues de criação e visualização dos bovinos.
+* Iuri: Nessa sprint pareou com o João para fazer a issue da NavBar e com o Caio para fazer o CI do backend. Também participou da avaliação por pares.
+* João Pedro: Essa semana participou da avaliação por pares, trabalhou na bottom navigation com o Iuri e ajudou o Lucas e o Guilherme com o Front-end. Além disso, fez a tela geral dos bovinos com o Caio. Refatorou o diagrama de pacotes e de sequência.
+* Lucas: Essa semana partipou da avaliação por pares, trabalhou na duas issues de criação e visualização dos bovinos juntamente com o Guilherme Mendes.
+
+### Gráfico de Burn-Down
+
+
+
+
+### Gráfico de Velocity
+
+
+
+## Retrospective
+
+* Caio
+ * Positivos: Como sempre a equipe trabalhando muito bem, todo mundo trabalhando bastante, nível equilibrado. O João estudou Flutter antes e está ajudando bastante no Front-end.
+ * Negativos: Não conseguiu parear muito com o João. Sempre tinha conflito de horário. Ele fez boa parte da issue sozinho.
+ * Melhorias: Nenhum.
+* Guilherme
+ * Positivos: Concorda com o Caio. Todos trabalhando bastante, bem equivalente e bem engajados no projeto. O pareamento com o Lucas foi um ponto positivo, conseguimos nos organizar bem para realizar as issues. O João também foi um outro ponto positivo pois nos ajudou bastante no Front-end.
+ * Negativos: Não ter estudado tanto Flutter.
+ * Melhorias: Estudar mais o Flutter para aplicar no Front-end.
+* Iuri
+ * Positivos: O pareamento foi um ponto positivo, conseguimos fechar as issues até quinta-feira.
+ * Negativos: Pendências que ficaram nas duas issues que estava.
+ * Melhorias: Repositório, prestar mais atenção nos detalhes, como milestones, pull requests, criação de issues, etc.
+* João Pedro
+ * Positivos: O grupo como um todo, todo mundo tá trabalhando. Quase não teve nada pendente. Estamos vendo nosso projeto pegar forma e isso é muito bom. Todo mundo está se ajudando.
+ * Negativos: Minha organização, acabou pegando muita coisa na sprint. A organização do grupo. O grupo não percebeu que tinha uma issue para fazer.
+ * Melhorias: Repositório, prestar mais atenção nos detalhes, como milestones, pull requests, criação de issues, etc.
+* Lucas
+ * Positivos: Todo mundo trabalhando muito bem. Todos estão bem engajados. O pareamento com o Guilherme foi muito positivo, conseguimos nos organizar bem para a realização das issues. Além disso, o João está nos ajudando bastante com o Front-end, visto que ele estudou bastante Flutter.
+ * Negativos: Organização do repositório e organização do grupo. A semana foi um pouco complicada e por isso tivemos esses erros.
+ * Melhorias: Comunicação e organização, como sempre.
+
+## Notas pós reunião
+* O grupo não realizou a issue de criação do documento de arquitetura pois ninguém lembrou.
diff --git a/docs/SprintsAndMeetings/2020-11-09-Sprint10Closure.md b/docs/SprintsAndMeetings/2020-11-09-Sprint10Closure.md
new file mode 100644
index 0000000..c16725a
--- /dev/null
+++ b/docs/SprintsAndMeetings/2020-11-09-Sprint10Closure.md
@@ -0,0 +1,57 @@
+| Data | Versão | Descrição | Autor(es) |
+| :--------: | :----: | :-----------------------: | :---------------------------: |
+| 09/11/2020 | 1.0 | Criação do modelo de Fechamento de Sprint | [Caio Fernandes](https://github.com/caiovfernandes) |
+| 17/11/2020 | 1.1 | Revisão do modelo de Fechamento de Sprint |[Guilherme Mendes](https://github.com/guilherme-mendes) |
+
+# Fechamento da sprint 10
+
+**Data**: 09 de novembro de 2020
+
+**Redigida por**: Caio Fernandes
+
+**Participantes**:
+* Caio Fernandes
+* Guilherme Mendes
+* Iuri Severo
+* João Pedro Guedes
+* Lucas Fellipe
+
+
+## Review
+
+* Caio Fernandes: Participou da elaboração do documento de arquitetura e pareou com o Guilherme para realizar a média de peso de bovinos por lote.
+* Guilherme Mendes: Participou da elaboração do documento de arquitetura e pareou com o Caio para realizar a média de peso de bovinos por lote.
+* Iuri Severo: Participou da elaboração do documento de arquitetura, ficou reponsável juntamente com o João pelos casos de usos e também pareou com o Lucas para realização da funcionalidade de manejo de reprodução. Tanto no backend quanto no frontend.
+* João Pedro Guedes: Participou da elaboração do documento de arquitetura, pareando com o Iuri para realização dos casos de uso e também fez a funcionalidae de manejo de pesagem tanto no frontend quanto backend.
+* Lucas Fellipe: Participou da elaboração do documento de arquitetura, elaborando Visão lógica, tamanho e desempenho. Pareou com o Iuri para fazer o manejo de reprodução tanto no back quanto no front.
+
+
+### Gráfico de Burn-Down
+
+
+
+
+### Gráfico de Velocity
+
+
+
+* Caio Fernandes: Descrição dos pontos positivos, negativos e melhorias para a sprint seguinte
+ * Positivos: Emepenho dos membros e aplicação está utilizável.
+ * Negativos:
+ * Melhorias: Fechar issues ao longo da semana
+* Guilherme Mendes: Descrição dos pontos positivos, negativos e melhorias para a sprint seguinte
+ * Positivos: Empenhos do grupo. Todos estão trabalhando muito bem para realizar as entregas. Grupo está progredindo no desenvolvimento da aplicação. Organização do grupo
+ * Negativos: Semana muito cheio, a entrega das issues ficou para última hora, isso acarretou em um burndown ruim
+ * Melhorias:
+* Iuri Severo: Descrição dos pontos positivos, negativos e melhorias para a sprint seguinte
+ * Positivos: Organização da sprint oocorreu bem. Aplicação tomando forma, já dá para utilizá-la. Todos trabalharam bem na sprint.
+ * Negativos:
+ * Melhorias: Fechar issues mais cedo
+* João Pedro Guedes: Descrição dos pontos positivos, negativos e melhorias para a sprint seguinte
+ * Positivos: Organização da sprint. Tudo foi entregue, não houve dívida técnica.
+ * Negativos: Grupo deveria prestar mais atenção a aplicar mais padrões, visto que a matéria é arquitetura e desenho de software.
+ * Melhorias:
+* Lucas Fellipe: Descrição dos pontos positivos, negativos e melhorias para a sprint seguinte
+ * Positivos: Organização da sprint foi muito boa (issues, zenhub, etc..). Aplicação está tomando forma, interação com a aplicação está muito boa.
+ * Negativos: Semana muito cheia.
+ * Melhorias: Comunicação e organização
diff --git a/docs/SprintsAndMeetings/2020-11-09-Sprint11Opening.md b/docs/SprintsAndMeetings/2020-11-09-Sprint11Opening.md
new file mode 100644
index 0000000..c506e7f
--- /dev/null
+++ b/docs/SprintsAndMeetings/2020-11-09-Sprint11Opening.md
@@ -0,0 +1,51 @@
+| Data | Versão | Descrição | Autor(es) |
+| :--------: | :----: | :-----------------------: | :---------------------------: |
+| 09/11/2020 | 1.0 | Criação do modelo de Abertura de Sprint | [Caio Fernandes](https://github.com/caiovfernandes) |
+| 17/11/2020 | 1.1 | Revisão do modelo de Abertura de Sprint |[Guilherme Mendes](https://github.com/guilherme-mendes) |
+
+
+# Abertura da Sprint 11
+
+**Data**: 09 de novembro de 2020
+
+**Redigida por**: Caio Fernandes
+
+**Participantes**:
+* Caio Fernandes
+* Guilherme Mendes
+* Iuri Severo
+* João Pedro Guedes
+* Lucas Fellipe
+
+
+## Planning
+
+### Duração
+
+| Duração | Início | Fim |
+| ------- | ---------- | ---------- |
+| 6 dias | 09/11/2020 | 15/11/2020 |
+
+### Sprint Backlog
+
+| Descrição da Tarefa | Responsável(eis) | Pontuação | Débito Técnico |
+| ------------------- | ---------------- | --------- | -------------- |
+| Task | Assignees | Milestone | 0 |
+| US38 - Relatorio GERAL | Caio, Lucas e Guilherme | 13 | 0 |
+| US36 - Relatorio GMD | Caio, Lucas e Guilherme | 8 | 0 |
+| Refatoração Back | John, Iuri | 8 | 0 |
+| Refatoração Front | John, Iuri | 13 | 0 |
+| US03 - Editar Gado de Corte | Caio, Lucas e Guilherme | 5 | 0 |
+| US07 - Editar Gado de Leite | Caio, Lucas e Guilherme | 5 | 0 |
+| US04 - Excluir Gado de Corte | Caio, Lucas e Guilherme | 2 | 0 |
+| US08 - Excluir Gado de Leite | Caio, Lucas e Guilherme | 2 | 0 |
+
+
+## Notas pós reunião
+Backlog:
+
+| Descrição da Tarefa | Responsável(eis) | Pontuação | Débito Técnico |
+| ------------------- | ---------------- | --------- | -------------- |
+| Deploy do backend | ? | 8 | 0 |
+| Alterar o banco para o Heroku com SQL | ? | 5 | 0 |
+| US21 - Eu, como usuário, desejo diferenciar o gado de leite de acordo com o diagnóstico de gestação, para diferenciar quais estão em período de prenhez e quais estão vazias | ? | 13 | 0 |
\ No newline at end of file
diff --git a/docs/SprintsAndMeetings/2020-11-16-Sprint11Closure.md b/docs/SprintsAndMeetings/2020-11-16-Sprint11Closure.md
new file mode 100644
index 0000000..bd1c8c5
--- /dev/null
+++ b/docs/SprintsAndMeetings/2020-11-16-Sprint11Closure.md
@@ -0,0 +1,64 @@
+# Fechamento da Sprint 11
+
+| Data | Versão | Descrição | Autor(es) |
+| :--------: | :----: | :-----------------------: | :---------------------------: |
+| 16/11/2020 | 1.0 | Criação do modelo de Fechamento de Sprint | [João Pedro Guedes](https://github.com/sudjoao) |
+| 20/11/2020 | 1.1 | Revisão do modelo de Fechamento de Sprint | [Guilherme Mendes](https://github.com/guilherme-mendes) |
+
+Os documentos de Fechamento de sprint deverão seguir o seguinte padrão:
+
+
+**Data**: 16 de novembro de 2020
+
+**Redigida por**: João Pedro Guedes
+
+**Participantes**:
+* Caio Fernandes
+* Guilherme Mendes
+* Iuri Severo
+* João Pedro
+* Lucas Fellipe
+
+## Review
+
+* Caio: Semana passada documentou a sprint review e planning, essa semana pareou com o Guilherme e Lucas para fazer a issue de edição e exclusão de bovino, tentaram terminar a parte de gerar relatório porém só conseguiram fazer o back.
+* Guilherme: No ínicio da Sprint terminou o documento de arquitetura, pareou com Lucasa e Caio paraa fazer a issue de edição e exclusão de bovino, iniciaram a parte de gerar relatório, vai tentar fazer ainda hoje o botão de gerar relatório no front.
+* Iuri: Refatorou o back e front com João Pedro, e além disso fizeram algumas alterações de como ficou a organização de manejos.
+* João Pedro: Refatorou o back e front com Iuri Severo, e além disso fez algumas alterações da organização dos manejos.
+* Lucas: Pareou com Guilherme e Caio para fazer a issue de edição e exclusão de bovino, porém fizeram só o back e além disso terminou sua parte do documento de arquitetura.
+
+### Gráfico de Burn-Down
+
+
+
+
+### Gráfico de Velocity
+
+
+
+## Retrospective
+
+* Caio
+ * Positivos: Grupo trabalha bem e todos se ajudam, gosta de trabalhar com o grupo.
+ * Negativos: Demorou um pouco pra pegar a issue.
+ * Melhorias: Planejamento e organização pessoal.
+* Guilherme
+ * Positivos: Todo mundo trabalhando muito bem, bem focados, planejamento do grupo foi bom, crê que conseguiremos finalizar até sexta. Pareamentos muito bons.
+ * Negativos: Deixar as coisas muito pra última hora, porém final do semestre aperta bastante o tempo.
+ * Melhorias: Organização.
+* Iuri
+ * Positivos: Pareamento muito bom, conseguiu trabalhar bem as issues e terminar sexta-feira, deixou código mais limpo e adiantou uma tela que estava para ser planejada.
+ * Negativos: Esqueceu de dar push antes de abrir o Pull Request. Após terminar sua issue largou o projeto de lado e não acompanhou muito o andamento das outras coisas.
+ * Melhorias: Ficar na matéria a Sprint inteira.
+* João Pedro
+ * Positivos: Pareamento muito bom, conseguiu trabalhar bem as issues e terminar sexta-feira, deixou código mais limpo e adiantou uma tela que estava para ser planejada.
+ * Negativos: -
+ * Melhorias: Organização.
+* Lucas
+ * Positivos: Grupo trabalhando muito bem, pareamento foi muito bom, todos esforçados e fazendo as coisas.
+ * Negativos: Organização semanal, deixou muito em cima para fazer as coisas.
+ * Melhorias: Organização.
+
+## Notas pós reunião
+
+> Parte front do relatório ficará de dívida caso o Guilherme não consiga fazer hoje.
\ No newline at end of file
diff --git a/docs/SprintsAndMeetings/2020-11-16-Sprint12Opening.md b/docs/SprintsAndMeetings/2020-11-16-Sprint12Opening.md
new file mode 100644
index 0000000..f7e4879
--- /dev/null
+++ b/docs/SprintsAndMeetings/2020-11-16-Sprint12Opening.md
@@ -0,0 +1,47 @@
+
+# Abertura da Sprint 12
+
+| Data | Versão | Descrição | Autor(es) |
+| :--------: | :----: | :-----------------------: | :---------------------------: |
+| 16/11/2020 | 1.0 | Criação do modelo de Abertura de Sprint | [João Pedro Guedes](https://github.com/sudjoao) |
+| 20/11/2020 | 1.1 | Revisão do modelo de Abertura de Sprint | [Guilherme Mendes](https://github.com/guilherme-mendes) |
+
+Os documentos de abertura de sprint deverão seguir o seguinte padrão:
+
+
+**Data**: 16 de novembro de 2020
+
+**Redigida por**: João Pedro Guedes
+
+**Participantes**:
+* Caio Fernandes
+* Guilherme Mendes
+* Iuri Severo
+* João Pedro
+* Lucas Fellipe
+
+
+## Planning
+
+### Duração
+
+| Duração | Início | Fim |
+| ------- | ---------- | ---------- |
+| 4 dias | 17/11/2020 | 20/11/2020 |
+
+### Sprint Backlog
+
+| Descrição da Tarefa | Responsável(eis) | Pontuação | Débito Técnico |
+| ------------------- | ---------------- | --------- | -------------- |
+| Relatório Geral | João Pedro e Lucas Fellipe | 13 | 1 |
+| Relatório GMD | João Pedro e Lucas Fellipe | 8 | 1 |
+| Documentação de Reutilização de Software | Iuri | 8 | 0 |
+| Gravação do vídeo | Todos | 8 | 0 |
+| Sistema JWT Autenticação | Caio e Guilherme | 8 | 0 |
+| US43 e US44 | Caio e Guilherme | 5 | 0 |
+
+
+## Notas pós reunião
+
+> Reunir quarta-feira 08:00 para fazer o planejamento e roteiro do vídeo;
+> Reunir sexta-feira 08:00 para fazer a gravação.
\ No newline at end of file
diff --git a/docs/SprintsAndMeetings/MeetingModel.md b/docs/SprintsAndMeetings/MeetingModel.md
new file mode 100644
index 0000000..e2edae7
--- /dev/null
+++ b/docs/SprintsAndMeetings/MeetingModel.md
@@ -0,0 +1,37 @@
+# Modelo de Reunião
+
+| Data | Versão | Descrição | Autor(es) |
+| :--------: | :----: | :-----------------------: | :---------------------------: |
+| 11/09/2020 | 1.0 | Criação do modelo de Reunião | [Iuri Severo](https://github.com/iurisevero) |
+
+Os documentos de Reuniões deverão seguir o seguinte padrão:
+
+# Assunto da Reunião
+
+**Data**: ```dia``` de ```mês``` de ```ano```
+
+**Redigida por**: ```NomeDoRedator```
+
+**Participantes**:
+* ```NomeDoParticipante```
+* ```NomeDoParticipante2```
+
+**Pauta da Reunião**:
+* ```Tema```
+* ```Tema2```
+
+## Notas pré reunião
+
+> Adicione aqui algum comentário relevante para a reunião, se não houver nenhum comentário a ser feito, apague essa parte.
+
+## Tema
+
+> O redator deverá escrever o que ocorreu na reunião conforme achar melhor, seja com tópicos ou parágrafos
+
+## Tema 2
+
+> O redator deverá escrever o que ocorreu na reunião conforme achar melhor, seja com tópicos ou parágrafos
+
+## Notas pós reunião
+
+> Adicione aqui algum comentário que afetará a sprint após essa reunião, se não houver nenhum comentário a ser feito, apague essa parte.
\ No newline at end of file
diff --git a/docs/SprintsAndMeetings/SprintClosureModel.md b/docs/SprintsAndMeetings/SprintClosureModel.md
new file mode 100644
index 0000000..cd65e1a
--- /dev/null
+++ b/docs/SprintsAndMeetings/SprintClosureModel.md
@@ -0,0 +1,41 @@
+# Modelo de Fechamento de Sprint
+
+| Data | Versão | Descrição | Autor(es) |
+| :--------: | :----: | :-----------------------: | :---------------------------: |
+| 11/09/2020 | 1.0 | Criação do modelo de Fechamento de Sprint | [Iuri Severo](https://github.com/iurisevero) |
+
+Os documentos de Fechamento de sprint deverão seguir o seguinte padrão:
+
+# Fechamento da Sprint Segundo o livro Design Patterns: Elements of Reusable Object-Oriented Software, os padrões comportamentais estão preocupados com algoritmos e a atribuição de responsabilidades entre objetos. Os padrões comportamentais descrevem não apenas os padrões de objetos ou classes, mas também os padrões de comunicação entre eles. Estes padrões caracterizam o fluxo de controle complexo que é difícil de seguir em tempo de execução. Eles mudam seu foco do fluxo de controle para permitir que você se concentre apenas em objetos do caminho que estão interconectados.
+Existem vários padrões que são abordados na parte comportamental, cada um preocupado com uma coisa e que tem um objetivo específico, como será específicado logo abaixo.
+
+### Chain of Responsibility
+Tem como objetivo evitar a dependência entre um objeto receptor e um objeto solicitante. Mantém guardado um ponteiro com o seu sucessor.
+
+
+
+### Iterator
+Fornece uma maneira de acessar elementos de uma agregação de objetos sequencialmente.
+
+
+
+### Mediator
+Responsável por diminuir a ligação entre vários objetos, faz isso a partir da criação de um mediador que ficará responsável por fazer todas essa comunicação.
+
+
+
+### Memento
+Armazena um estado interno de um objeto em um determinado momento para que depois seja possível você voltar para aquele estado anterior do objeto.
+
+
+
+### Observer
+Definição de um mecanismo eficiente, normalmente utilizando uma dependência de *um para muitos*, para reagir às alterações realizadas em determinados objetos.
+
+
+
+### State
+Permite um objeto alterar seu comportamento quando um estado interno é alterado.
+
+
+
+### Strategy
+Define uma família de algoritmos que têm um mesmo objetivo, mas dependendo do contexto inserido será selecionado o algortimo que faz mais sentido para resolver aquele problema.
+
+
+
+### Template Method
+Define uma ordem lógica, ou esqueleto, de ações que devem ser realizadas no sistema, a ordem sempre continuará a mesma mas os ações realizadas podem ser realizadas de maneira diferente dependendo da sub-classe que a está executando.
+
+
+
+### Visitor
+Representa uma operação a ser executada em elementos de um objeto. O padrão visitor permite a definição de uma nova operação sem fazer alterações nos elementos das classes onde ele opera.
+
+
+
+
+
+## Referências
+* GAMMA, Erich; HELM, Richard; JOHNSON, Ralph; VLISSIDES, John. Design Patterns: Elements of Reusable Object-Oriented Software Addison-Wesley Professional (1994). Acesso em: 10 out. 2020.
+* CARR, Richard. Gang of Four Design Patterns. Disponível em: http://www.blackwasp.co.uk/gofpatterns.aspx. Acesso em: 10 out. 2020.
+* DEVMEDIA. Design Patterns: Padrões "GoF". Disponível em: https://www.devmedia.com.br/design-patterns-padroes-gof/16781. Acesso em: 10 out. 2020.
+* SERRANO, Milene. Arquitetura e Desenho de Software AULA - GoFs Comportamentais. Acesso em: 10 out. 2020.
+
+
diff --git a/docs/Studies/CreationalGoF.md b/docs/Studies/CreationalGoF.md
new file mode 100644
index 0000000..433eaf4
--- /dev/null
+++ b/docs/Studies/CreationalGoF.md
@@ -0,0 +1,239 @@
+# GoF's Criacionais
+
+| Data | Versão | Descrição | Autor(es) |
+| :--------: | :----: | :-------------------------------------: | :-------------------------------------------: |
+| 10/10/2020 | 1.0 | Criação do estudo de GoFs Criacionais | [Guilherme Mendes](https://github.com/guilherme-mendes) |
+| 10/10/2020 | 1.1 | Revisão do documento | [Lucas Fellipe](https://github.com/lucasfcm9) |
+| 26/10/2020 | 1.2 | Adição do vídeo de apresentação dos padrões para o grupo | [João Pedro Guedes](https://github.com/sudjoao)|
+| 26/10/2020 | 1.3 | Refatoração do estudo de GoFs Criacionais | [Guilherme Mendes](https://github.com/guilherme-mendes) |
+| 26/10/2020 | 1.4 | Revisão do documento | [João Pedro Guedes](https://github.com/sudjoao)|
+
+
+## Introdução
+
+Os GoF's são padrões de design que visam prover soluções para problemas recorrentes no desenvolvimento e manutenção de software orientado a objetos. Buscando sempre boas práticas de programação.
+Os Padrões de Design Criacionais (Creational Patterns) fornecem vários mecanismos de criação de objetos, que aumentam a flexibilidade e reutilização de código já existente.
+ +Vídeo de Apresentação dos Padrões para o grupo + +- Problemáticas: + - Definir qual classe concreta deve ser utilizada para criar o objeto (instâncias de um objeto); + - Definir como os objetos devem ser criados e como eles se relacionam com outros objetos do sistema. + +- Principais GoF's Criacionais: + - Factory Method + - Abstract Method + - Builder + - Prototype + - Singleton + +### Factory Method + +O Factory Method é um padrão criacional de projeto que fornece uma interface para criar objetos em uma superclasse e permitir delegar a instanciação às subclasses.
+ +
+
+- Vantagens:
+
+ - Reutilização;
+ - Manutenibilidade;
+ - Coesão;
+ - Dentre outros aspectos relevantes para a programação de sistemas OO.
+
+- Exemplo de uso:
+
+```python
+import os
+from flask import Flask
+from flask_sqlalchemy import SQLAlchemy
+
+# instantiate the db
+db = SQLAlchemy()
+
+def create_app(script_info=None):
+
+ # instantiate the app
+ app = Flask(__name__)
+
+ # set config
+ app_settings = os.getenv('APP_SETTINGS')
+ app.config.from_object(app_settings)
+
+ # set up extensions
+ db.init_app(app)
+
+ # register blueprints
+ from project.api.example import example_blueprint
+ app.register_blueprint(example_blueprint)
+
+ # shell context for flask cli
+ @app.shell_context_processor
+ def ctx():
+ return {'app': app, 'db': db}
+
+ return app
+```
+
+### Abstract Factory
+
+Permitir a criação de famílias de objetos relacionados ou dependentes por meio de uma única interface e sem que a classe concreta seja especificada.
+ +
+
+- Vantagens:
+
+ - Os produtos obtidos de uma fábrica são compatíveis entre si.
+ - Evita um vínculo forte entre produtos concretos e o código cliente.
+ - Extrair o código de criação do produto para um lugar, fazendo o código ser de fácil manutenção.
+ - Introduzir novas variantes de produtos sem quebrar o código cliente existente.
+
+- Exemplo de uso:
+
+```jsx
+interface GUIFactory is
+ method createButton():Button
+ method createCheckbox():Checkbox
+
+class WinFactory implements GUIFactory is
+ method createButton():Button is
+ return new WinButton()
+ method createCheckbox():Checkbox is
+ return new WinCheckbox()
+```
+
+### Builder
+
+
+
+Separar o processo de construção de um objeto de sua apresentação e permitir a sua criação passo a passo. Diferentes tipos de objetos podem ser criados com implementações distintas de cada passo.
+ +- Vantagens: + + - Construção de objetos passo a passo, adiar as etapas de construção ou rodar etapas recursivamente. + - Reutilização do código de construção quando construindo várias representações de produtos. + - Isolamento do código de construção complexo da lógica de negócio do produto. + +- Exemplo de uso: + + ```jsx + class Builder(ABC): + + @abstractproperty + def product(self) -> None: + pass + + @abstractmethod + def produce_part_a(self) -> None: + pass + + @abstractmethod + def produce_part_b(self) -> None: + pass + + @abstractmethod + def produce_part_c(self) -> None: + pass + + class Director: + + def __init__(self) -> None: + self._builder = None + + @property + def builder(self) -> Builder: + return self._builder + + @builder.setter + def builder(self, builder: Builder) -> None: + self._builder = builder + + def build_minimal_viable_product(self) -> None: + self.builder.produce_part_a() + + def build_full_featured_product(self) -> None: + self.builder.produce_part_a() + self.builder.produce_part_b() + self.builder.produce_part_c() + + if __name__ == "__main__": + ``` + +### Prototype + +Criação de novos objetos a partir da cópia de objetos existentes.
+ +
+
+- Vantagens:
+
+ - Clonar objetos sem acoplá-los a suas classes concretas.
+ - Se livrar de códigos de inicialização repetidos em troca de clonar protótipos pré-construídos.
+ - Produzir objetos complexos mais convenientemente.
+ - Alternativa para herança quando lidar com configurações pré determinadas para objetos complexos.
+
+- Exemplo de uso:
+
+```jsx
+abstract class Shape is
+ field X: int
+ field Y: int
+ field color: string
+
+ constructor Shape() is
+
+ constructor Shape(source: Shape) is
+ this()
+ this.X = source.X
+ this.Y = source.Y
+ this.color = source.color
+
+ abstract method clone():Shape
+```
+
+### Singleton
+
+Criação de uma única instância de uma classe e fornecer um modo de recuperá-la.
+ +
+
+- Vantagens:
+
+ - Uma classe só terá uma única instância.
+ - Um ponto de acesso global para aquela instância.
+ - O objeto singleton é inicializado somente quando for pedido pela primeira vez.
+
+- Exemplo de uso:
+
+```python
+from typing import Optional
+
+class SingletonMeta(type):
+ _instance: Optional[Singleton] = None
+
+ def __call__(self) -> Singleton:
+ if self._instance is None:
+ self._instance = super().__call__()
+ return self._instance
+class Singleton(meteclass->SingletonMeta):
+ def some_business_logic(self):
+ #code
+```
+
+### Multiton
+
+Criação limitada de instancias para que haja um controle maior do que esta sendo consumido.
+ +
+
+
+### Object Pool
+
+Possibilita o reaproveitamentos de objetos.
+ +
+
+### Referências
+
+- LARMAN, Craig. Utilizando UML e Padrões: Uma Introdução a Análise e ao Projeto.
+- Refactoring Guru. Design Patterns. [S. l.], 2020. Disponível em: [https://refactoring.guru/design-patterns](https://refactoring.guru/design-patterns). Acesso em: 09 out. 2020.
+- SERRANO, Milene. Arquitetura e Desenho de Software AULA - GoFs Comportamentais. Acesso em: 10 out. 2020.
\ No newline at end of file
diff --git a/docs/Studies/DojoFlutter.md b/docs/Studies/DojoFlutter.md
new file mode 100644
index 0000000..76c1740
--- /dev/null
+++ b/docs/Studies/DojoFlutter.md
@@ -0,0 +1,102 @@
+# Dojo de Flutter
+| Data | Versão | Descrição | Autor(es) |
+| :--------: | :----: | :-------------------------------------: | :-------------------------------------------: |
+| 06/10/2020 | 0.1 | Criação dos Diagramas iniciais da estrutura do front | [Iuri Severo](https://github.com/iurisevero) e [João Guedes](https://github.com/sudjoao) |
+| 08/10/2020 | 0.2 | Cronograma do Dojo | [Iuri Severo](https://github.com/iurisevero) e [João Guedes](https://github.com/sudjoao) |
+| 08/10/2020 | 0.3 | Detalhamento do Dojo | [Iuri Severo](https://github.com/iurisevero) e [João Guedes](https://github.com/sudjoao) |
+| 08/10/2020 | 0.4 | Adição dos tópicos Stateless e Stateful Widgets e Arquivo de Constantes | [Iuri Severo](https://github.com/iurisevero) e [João Guedes](https://github.com/sudjoao) |
+| 08/10/2020 | 0.5 | Adição das árvores de login e registro | [Iuri Severo](https://github.com/iurisevero) e [João Guedes](https://github.com/sudjoao) |
+| 20/10/2020 | 0.6 | Adição do texto de aplicação do dojo | [Iuri Severo](https://github.com/iurisevero) |
+| 21/10/2020 | 0.7 | Adição dos vídeos relacionados a aplicação do dojo | [João Pedro Guedes](https://github.com/sudjoao) |
+
+## Cronograma de Conteúdos
+
+* O que é Flutter?
+* A estrutura de Flutter;
+* O que são widgtes?
+ * Scaffold;
+ * Container;
+ * Row;
+ * Column;
+ * Image.
+* Pubspec.yaml pra que serve?
+ * Utilizar para pegar os ícones;
+ * Importar alguma imagem na prática;
+* Statefull e Stateless;
+ * Componentização;
+ * Orientação a objetos;
+* Fazendo outras telas;
+* Navegação entre telas;
+ * Navigator;
+ * Routes;
+* Arquivo de constantes.
+
+## Conteúdos
+### O que é Flutter?
+["Flutter is Google’s UI toolkit for building beautiful, natively compiled applications for mobile, web, and desktop from a single codebase."](https://flutter.dev/)
+
+Flutter é um conjunto de ferramentas que facilitam o desenvolvimento de interfaces de tamanhos variados e para todos tipos de aparelho. De modo simplificado, o Flutter "pede" para o aparelho uma tela em branco e adiciona _widgets_ pré-montados nela, o que faz funcionar para Android e IOs, independente do tamanho da tela.
+
+### A estrutura do Flutter
+Tudo dentro de um aplicativo em Flutter é considerado um _widget_, é durante a criação das telas o programador constrói blocos de _widgets_, adicionando-os um acima do outro, como lego. No fim, o desenvolvedor constrói uma árvore de _widgets_, como a do exemplo abaixo:
+
+
+
+### O que são _widgets_?
+["Widgets describe what their view should look like given their current configuration and state. When a widget’s state changes, the widget rebuilds its description, which the framework diffs against the previous description in order to determine the minimal changes needed in the underlying render tree to transition from one state to the next."](https://flutter.dev/docs/development/ui/widgets-intro)
+
+Basicamente, Widgets são estruturas que se constroem a partir de um estado descrito pela aplicação. Quando esse estado muda, a estrutura se reconstroe para ficar de acordo com o estado atual. Alguns _widgets_ básicos são:
+* Scaffold;
+* Container;
+* Row;
+* Column;
+* Image.
+
+### Pubspec.yaml pra que serve?
+É um arquivo que guarda o metadata dos pacotes utilizados pela aplicação, assim como suas dependências. Nele é possível realizar diversas alterações, como o nome do aplicativo, seu ícone e a adição de Assets.
+
+### Stateful e Stateless
+Em flutter podemos separar os widgets em widgets que podem mudar de estado(Stateful) e widgets que não mudam de estado(Stateless).
+
+Um widget stateless é um widget estático, que vai sempre continuar do mesmo jeito independente da interação que o usuário faz, um exemplo disso pode ser um texto que aparece na tela.
+
+
+Dizer que um widget é stateful significa que ele tem a capacidade de mudar de estado a partir de alguma interação externa, como um clique em um botão etc, ou seja a principal característica de um widget stateful é ele ser dinâmico.
+
+As mudanças de estado ocorridas em um stateful widget são causadas a partir da utilização da função setState() que pode ser utilizada , por exemplo, para uma aplicação de uma calculadora, onde a pessoa vai clicando nos números e operações e os mesmos vão aparecendo na tela de forma que quase instantânea.
+
+Mais informações sobre em: 
++
+
+### Navegação entre telas
+A navegação entre telas do Flutter é feita a partir de um _widget_ que gerencia _widgets_ "filhos" em um comportamento de pilha. Esse _widget_ é o **Navigator**, enquanto seus "filhos" são as **Rotas**.
+
+Mais informações sobre o sistema de navegação do Flutter estão disponível em Padrões de projetos são pricípios e soluções adotadas para resolver problemas comuns encontrados durante o desenvolvimento de um projeto de software. Esse padrões são documentados e visam seguir uma estrutura e um comportamento regular para solucionar um problema específico a partir de sua aplicação.
+ No entanto, fatores como: (i) falta de conhecimento da implementação do padrão por parte do desenvolvedor; (ii) sucessivas mudanças em outras classes e refletidas nessa parte do código; (iii) falta de refatoração no código; ou, (iv) característica do problema e não necessita implementar o padrão (Job, 2014, p. 27), podem resultar em situações onde se tem um padrão comportamental não estruturado, aspecto comum de padrões emergentes.
+
+Vídeo de Apresentação dos Padrões para o grupo
+
+## Singleton
+
+
O Singleton é um padrão adotado para classes que só podem possuir uma instância no projeto. Por exemplo, a classe que vai guardar os dados do jogador em um jogo. A ideia base é tornar o construtor do objeto privado, para que ninguém além da própria classe possa criar uma instância dele (Loviscach, 2012). Em vez disso, a classe fornece um método estático do qual é possível obter a instância já existente.
+ +_Figura 1.1: Padrão Singleton_ +
+_Fonte: Job, 2014, p.2_ + +_Código Fonte 1.1: O padrão Singleton em estado emergente na classe Licences_ +``` +// Os imports , atributo s e demais métodos foram omitido s +public class Licences { + public static final String GPL = "GNU LICENSE"; + public static final String LGPL = "GNU LESSER PUBLIC LICENSE"; + /** Um atributo privado e estático. */ + private static Licences singleton ; + /** Returna uma referencia desta classe. */ + public static Licences getlnstance() { + if (singleton == null ) { + singleton = new Licences() ; + } + return singleton ; + } + public String getGPL() { + return GPL; + } + public String getLGPL() { + return LGPL; + } +} +``` +_Fonte: Job, 2014, p.28~29_ + +
No código acima é possível ver os padrões estruturais do Singleton, exceto pelo construtor da classe Licence que não é especificado. Isso a faz ser classificada como um padrão emergente, visto que não segue a risca os padrões de projeto.
O padrão Composite é adotado quando é necessário tratar um conjunto de objetos como uma singularidade. Um exemplo dessa ação pode ser encontrado em diversos softwares de edição de imagem e desenho, na função de agrupamento: diversos objetos distintos passam a ser tratados como um só, o grupo, o qual é possível movimentar, redimensionar, duplicar, etc..
+A solução adotada para isso é uma hierarquia de classes baseada em dois objetos, um Composite Object e uma Leaf Object, onde o Composite Object é uma combinação de elementos individuais e outros Composites Objects, e a Leaf Object é o objeto individual. O resultado disso é uma estrutura de árvore, onde as folhas são os objetos.
+ +_Figura 1.2: Exemplo do padrão Composite_ +
+_Fonte: Gamma, Helm, Johnson, Vlissides, 1994, p. A-30_ + +_Código Fonte 1.2: Pseucodigo do padrão Composite em estado emergente_ +``` +class Figura { + Figura[] atributo; // Deve ser um conjunto de elementos do tipo Figura + void desenhar() { + for (atributo.lenght()) { + atributo.desenhar(); // Para cada elemento do conjunto + } + } +} +``` +_Fonte: Job, 2014, p.34_ + +
É possível perceber que a classe Figura tem o comportamento do padrão Composite, no entanto não segue a estruturação proposta pelo padrão.
O padrão State permite que um objeto mude seu comportamento conforme um estado interno. Por exemplo, uma classe C possui um atributo a que pode ser alterado a qualquer momento da execução dessa classe; Essa alteração é validada conforme o estado atual da classe e, após isso, atualizado, alterando o estado da classe.
+
No exemplo de Código 1.3, pode-se perceber que o comportamento do State é seguido, porém dentro de uma única função que trata todos estados possíveis.
+_Fonte: Gamma, Helm, Johnson, Vlissides, 1994, p. A-11_ + +_Código Fonte 1.3: Pseucodigo do padrão State em estado emergente_ +``` +class C{ + A state ; + void m() { + IF (state == "StateA" ){ //executa algo e muda o estado + state ="StateB"; + }ELSE IF (state == "StateB" ){ //executa algo e muda o estado + state ="StateC"; + }ELSE IF (state == "StateC "){ //executa algo e muda o estado + state ="StateA"; + } + ) +} +``` +_Fonte: Job, 2014, p.33_ + +## Factory Method +
O padrão Factory Method define uma interface para criação de objetos. A partir dela é possível instaciar objetos de outras subclasses definidas.
+ +_Figura 1.4: Exemplo do padrão Factory Method_ +
+_Fonte: Gamma, Helm, Johnson, Vlissides, 1994, p. A-4_ + +
O Código Fonte 1.4 demonstra um padrão emergente derivado do Factory Method. Nele, a classe Design Patterns são ferramentas incrivelmente importantes para desenvolvedores de software. Acima de resolver problemas comuns, eles fornecem às pessoas um vernáculo padrão para se comunicarem e oferecem abstrações conceituais valiosas em um amplo conjunto de circunstâncias.
+
+Vídeo de Apresentação dos Padrões para o grupo
+
+ GRASP significa General Responsability Assignment Software Patterns. Esses padrões, como o nome sugere, visam principalmente responder à pergunta: "Quem faz o quê?" GRASP é um conjunto de 9 padrões de software de atribuição de responsabilidade geral. São eles: O Criador assume a responsabilidade de criar outros objetos. Esse padrão é provavelmente o mais fácil de entender conceitualmente. Existem vários motivos pelos quais uma classe pode assumir a responsabilidade de criar outra.
+
+ O Criador pode ter informações sobre como criar o referido objeto, ou pode ser a classe que usa o objeto mais de perto. Essas decisões serão amplamente estabelecidas no design inicial do sistema, e outros documentos, como diagramas UML, guiarão e informarão o padrão do Criador.
+O GRASP Criador permite que muitas outras práticas recomendadas se encaixem, como injeção de dependência e baixo acoplamento. O Padrão do Criador pode ser usado para reforçar o design lógico de um sistema.
+
+ Em geral, uma classe `B` deve ser responsável por criar instâncias de classe `A` se uma, ou preferencialmente mais, das seguintes afirmações se aplicam:
+
+- Instâncias de `B` contêm ou agregam instâncias de `A`;
+- Instâncias de `B` gravam instâncias de `A`;
+- Instâncias de `B` utilizam de perto instâncias de `A`;
+- Instâncias de `B` têm as informações de iniciação das instâncias de `A` e passam isso na criação. A medida que os sistemas crescem, podemos descobrir que estamos colocando muita lógica em nossos controladores. Isso resulta no que chamamos de “controladores inchados”. Controladores inchados implicam em um acoplamento forte em nosso sistema, o que é ruim. Siginifica que suas classes estão coesas. Isso é garantido por atribuir de forma coerente a distribuição das classes utilizando padrões de projeto.
+
+ Coesão está ligada ao princípio da responsabilidade única, que foi introduzido por Robert C. Martin no inicio dos anos 2000 e diz que uma classe deve ter apenas uma única responsabilidade e realizá-la de maneira satisfatória, ou seja, uma classe não deve assumir responsabilidades que não são suas O acoplamento significa o quanto uma classe depende da outra para funcionar. E quanto maior for esta dependência entre ambas, dizemos que estas classes estão fortemente acopladas.
+
+ O forte acoplamento também nos traz muitos problemas, problemas semelhantes aos que um cenário pouco coeso nos traz. O Controlador é responsável por lidar com as solicitações dos atores. Ele é o intermediário entre o clique do usuário em “Enviar” e o back-end que faz isso acontecer.
+
+ O Controlador sabe como interpretar as ações das interfaces de usuário e como conectar essas ações aos comportamentos em seu sistema. Este padrão permite que as interfaces de usuário sejam separadas de forma limpa dos “objetos de negócios” e tenham ambas as alterações independentementes umas das outras. Nisso está implícito que um sistema também pode suportar muitas interfaces de usuário diferentes ao mesmo tempo.
+
+ Podemos imaginar um controlador como o volante de um carro, ele conecta as intenções de um motorista às ações do veículo. Mudar o motor do carro não precisa mudar a forma como o carro é usado em alto nível. E da mesma forma, a substituição de um volante não requer que nenhum componente interno seja modificado.
+A Controller também é um padrão importante em frameworks modernos de desenvolvimento web, formando um pilar do padrão arquitetônico Model-View-Controller. Um conceito já conhecido e aplicado em Orientação por Objetos.
+
+ No GRASP, utiliza-se o polimorfismo ao notar que mais de uma de nossas classes tem métodos que se comportam de maneira muito parecida.
+
+ Então, cria-se um classe abstrata para ser utilizada como base. Este GRASP ocorre quando você aplica no seu projeto um serviço próprio, com um módulo novo.
+Geralmente ocorre quando se tem Polimorfismo
+
+ A Variação Protegida (VP) é um princípio básico na motivação da maioria dos mecanismos e padrões na programação e no projeto para fornecer flexibilidade e proteção contra variações. Os GoFs Estruturais explicam como montar objetos e classes em estruturas maiores, porém mantendo essas estruturas flexíveis e eficientes. Eles mexem na estrutura dos modelos presentes e em como esses modelos estão interagindo. São padrões que atuam de forma significante nas correlações entre as classes e nas relações de depedência. O Adapter permite que um objeto seja substituído por outro e, apesar de realizarem a mesma tarefa, possuem interfaces diferentes. Ele serve como um adaptador, ou seja, é um objeto especial que converte a interface principal de um objeto para que outro objeto possa entendê-lo. Você pode utilizar o Adapter quando você quer usar uma classe existente, porém a sua interface não é compatível com o restante do código. O Adapter ajuda que objetos com diferentes interfaces colaborem entre si, por exemplo: O Composite é um padrão de projeto estrutural que tem como objetivo agrupar objetos que fazem parte de uma relação parte-todo de forma a tratá-los sem distinção. Uma interface, ou até mesmo uma classe abstrata, é implementada por diversas outras classes. Ele permite com que você componha objetos em estruturas de árvores e então trabalhe com essas estruturas como se elas fossem objetos individuais. Você pode utilizar o padrão Composite quando você tem que implementar uma estruturas de objetos tipo árvore. O Decorator é um padrão de projeto estrutural que permite adicionar responsabilidades a um objeto de maneira dinâmica, criando algo similar a uma extensão do objeto. Ele permite, a partir de uma base, anexar novos comportamentos aos objetos. O Bridge é um padrão de projeto que permite que você divida uma classa grande ou um conjunto de classes intimamente ligadas em duas hierarquias separadas que podem ser desenvolvidas separadamente, sem uma depender da outra. De forma simplificada, esse padrão permite a divisão de uma classe em implementações menores. O Facade é um padrão de projeto estrutural que fornece uma interface simplificada para uma biblioteca, um framework ou qualquer conjunto complexo de classes. O Proxy é um padrão de projeto estrutural que permite que você forneça um substituto para outro objeto. Um proxy controla o acesso ao objeto original, permitindo que você faça algo antes ou depois do pedido chegar ao objeto original. O método do FlyWeight surgiu para solucionar o problema de gerenciamento de memória em programas que consomem bastante RAM. Basicamente, ele é uma otimização. A classe FlyWeight fica responsável por guardar as instâncias dos objetos que antes eram repetidas. Dessa forma, o consumo de memória reduz drasticamente e a classe FlyWeight compartilha, via métodos, para as demais partes do sistema.StackTraceElementFactory não possui uma subclasse definida para instanciar o objeto do tipo StackTraceElement, o que foge das restrições estruturais do padrão seguido.
+
+_Código Fonte 1.4: O padrão Factory Method em estado emergente na classe ```StackTraceElementFactory```_
+```
+// Os imports , atributo s e demais métodos foram omitido s
+public class StackTraceElementFactory {
+ public StackTraceElement nativeMethodElement(String declaringClass,
+ String methodName) {
+ return create(declaringClass, methodName, "Native", -2);
+ }
+ public StackTraceElement unknownSourceElement(String declaringClass,
+ String methodName) {
+ return create(declaringClass, methodName, "Source", -1);
+ }
+ private StackTraceElement create(String declaringClass, String methodName,
+ String fileName, int lineNumber) {
+ StackTraceElement result = new Throwable().getStackTrace()[0];
+ setField(result, "declaringClass", declaringClass);
+ setField(result, "methodName", methodName);
+ setField(result, "fileName", fileName);
+ setField(result, "lineNumber", new Integer(lineNumber));
+ return result;
+ }
+}
+```
+_Fonte: Job, 2014, p.29~30_
+
+## Referências
+* JOB, Ricardo de Sousa. Uma abordagem para detecção de padrões emergentes. Disponível em:
+O GRASP Especialista resolve isso encapsulando informações sobre uma tarefa em uma classe distinta. Isso pode parecer um pouco abstrato, mas vamos trabalhar com um exemplo simples:
+A autenticação do usuário é um problema comum. Podemos ter um usuário que está logando para ter seu nome de usuário e senha validados no sistema. Com apenas um controlador, isso pode ter a seguinte aparência:
+ Login do usuário → Controlador → Banco de dados
+Esta transação requer muito trabalho por parte do Controlador. A autenticação pode envolver hashing, pesquisas de banco de dados e talvez outras tarefas específicas do aplicativo. Portanto, apresentamos um especialista: Módulo de autenticação.
+
+ Este módulo sabe exatamente como autenticar um usuário, e o Controlador precisa apenas delegar a solicitação de autenticação a este módulo para saber que a autenticação será tratada corretamente.
+Solicitação de login → Controlador → Módulo de autenticação → Banco de dados
+Dessa forma, o padrão GRASP Especialista é muito parecido com um especialista no mundo real. Quando desejamos construir uma casa, podemos contar com a ajuda de um arquiteto. É possível para uma pessoa projetar sua própria casa (e muitas pessoas fazem), mas na maioria das vezes preferiríamos terceirizar essa tarefa. As pessoas já têm o suficiente para administrar ao construir uma casa, e um arquiteto certamente está mais bem equipado para projetar casas.
+Ex:
+
+- Classes para cuidar da segurança
+- Módulo de persistência no banco (DAO)
+- Módulo de Autenticação de usuários
+- Entre outras..
+O encapsulamento de dados, das interfaces, e o polimorfismo são mecanismos básicos para se obter a VP. As técnicas de linguagens baseada em regras, interpretadores de regra, projetos reflexivos e de metadados, máquinas virtuais, etc, são mecanismos mais avançados para se obter a VP.
+Os Padrões Estruturais se preocupam com as interações entre os objetos. Dessa forma, os Padrões Estruturais têm como objetivo diminuir essa dependência entre os objetos. Serão apresentados os seguintes Padrões Estruturais: Adapter, Composite, FlyWeight, Decorator, Proxy, Bridge e o Facade. 
+
+### Exemplo
+
+
+
+Este é um exemplo do padrão Adapter, onde adaptamos a Entrada PS2 para a Entrada USB.
+
+## Composite
+
+A estrutura do Composite é formada por uma Interface, por leafs e pela classe Composite.
+
+
+
+
+## Decorator
+
+
+Pode-se ver que há um Decorator Base, que servirá como um ponte entre o Client e os Decorators que realmente irão alterar o comportamento do objeto concreto.
+
+### Exemplo
+
+
+## Bridge
+
+
+### Exemplo
+
+
+
+
+## Facade
+
+
+### Exemplo
+
+
+
+
+## Proxy
+
+
+### Exemplo
+
+
+
+
+## Flyweight
+
+
+