+| 
|:--:|
| **Scrum Master**|
diff --git a/docs/sprints/Planejamento-Sprint-1.md b/docs/sprints/Planejamento-Sprint-1.md
index b3d2daa9..397f8752 100644
--- a/docs/sprints/Planejamento-Sprint-1.md
+++ b/docs/sprints/Planejamento-Sprint-1.md
@@ -8,7 +8,7 @@
## 2. Papéis
-| | 
|
+| | 
|
|:--:|:--:|
| **Scrum Master** | **Product Owner** |
diff --git a/docs/sprints/Planejamento-Sprint-2.md b/docs/sprints/Planejamento-Sprint-2.md
index 0389ace9..5bb9075e 100644
--- a/docs/sprints/Planejamento-Sprint-2.md
+++ b/docs/sprints/Planejamento-Sprint-2.md
@@ -8,11 +8,11 @@
## 2. Papéis
-| | |
+| | |
|:--:|:--:|
| **Scrum Master** | **Product Owner** |
-| 
| 
| 
|
+| 
| 
| 
|
|:--:|:--:|:--:|
| **DevOps** | **Arquitetura** | **Joker** |
diff --git a/docs/sprints/Planejamento-Sprint-3.md b/docs/sprints/Planejamento-Sprint-3.md
index 8aa5e91c..2bba00b8 100644
--- a/docs/sprints/Planejamento-Sprint-3.md
+++ b/docs/sprints/Planejamento-Sprint-3.md
@@ -9,11 +9,11 @@
## 2. Papéis
-| | |
+| | |
|:--:|:--:|
| **Scrum Master** | **Product Owner** |
-| | | |
+| | | |
|:--:|:--:|:--:|
| **DevOps** | **Arquitetura** | **Joker** |
diff --git a/docs/sprints/Planejamento-Sprint-4.md b/docs/sprints/Planejamento-Sprint-4.md
index 0e97ffcd..60e8f8c6 100644
--- a/docs/sprints/Planejamento-Sprint-4.md
+++ b/docs/sprints/Planejamento-Sprint-4.md
@@ -8,11 +8,11 @@
## 2. Papéis
-| | |
+| | |
|:--:|:--:|
| **Scrum Master** | **Product Owner** |
-| | | |
+| | | |
|:--:|:--:|:--:|
| **DevOps** | **Arquitetura** | **Joker** |
diff --git a/docs/sprints/Planejamento-Sprint-5.md b/docs/sprints/Planejamento-Sprint-5.md
index ef00b155..0d5f1520 100644
--- a/docs/sprints/Planejamento-Sprint-5.md
+++ b/docs/sprints/Planejamento-Sprint-5.md
@@ -8,11 +8,11 @@
## 2. Papéis
-| | |
+| | |
|:--:|:--:|
| **Scrum Master** | **Product Owner** |
-| | | |
+| | | |
|:--:|:--:|:--:|
| **DevOps** | **Arquitetura** | **Joker** |
diff --git a/docs/sprints/Resultado-Sprint-1.md b/docs/sprints/Resultado-Sprint-1.md
index 3f3e0c5a..d73f82b8 100644
--- a/docs/sprints/Resultado-Sprint-1.md
+++ b/docs/sprints/Resultado-Sprint-1.md
@@ -1,6 +1,6 @@
## 1. Relato da _Sprint_
-Para a Sprint 1 fomos orientados a definir os papéis que o grupo de EPS iria desempenhar durante a execução do projeto de MDS, como EPS fica responsável pela gerencia os papéis foram distribuídos da seguinte forma. Scrum Master - Romeu Carvalho, Product Owner - Lucas Malta, DevOps Victor Moura, Arquitetura Vitor Falcão e Joker Arthur Diniz. Durante esta Sprint recebemos o código fonte do projeto e podemos analisá-lo melhor, foi realizada também uma reunião com o cliente para que fosse definido um escopo para o projeto, escopo que se encontra no Product Backlog e posteriormente se encontrará também em uma matriz de rastreabilidade para que possa haver um melhor controle sobre os requisitos e suas dependências. Foi realizado também os primeiros eventos do Scrum Retrospectiva, Review, e o Planejamento sendo este não ocorreu pois o time box foi excedido durante os outros eventos causando exaustão. No mesmo dia dos eventos foi realizado também a pontuação das Histórias de Usuário, esta que também se encontra no Product Backlog . +
Para a Sprint 1 fomos orientados a definir os papéis que o grupo de EPS iria desempenhar durante a execução do projeto de MDS, como EPS fica responsável pela gerencia os papéis foram distribuídos da seguinte forma. Scrum Master - Romeu Carvalho, Product Owner - Lucas Malta, DevOps Victor Moura, Arquitetura Vitor Falcão e Joker Arthur Diniz. Durante esta Sprint recebemos o código fonte do projeto e podemos analisá-lo melhor, foi realizada também uma reunião com o cliente para que fosse definido um escopo para o projeto, escopo que se encontra no Product Backlog e posteriormente se encontrará também em uma matriz de rastreabilidade para que possa haver um melhor controle sobre os requisitos e suas dependências. Foi realizado também os primeiros eventos do Scrum Retrospectiva, Review, e o Planejamento sendo este não ocorreu pois o time box foi excedido durante os outros eventos causando exaustão. No mesmo dia dos eventos foi realizado também a pontuação das Histórias de Usuário, esta que também se encontra no Product Backlog .
#### Papéis @@ -17,7 +17,7 @@ ------------ ## 2. Fechamento da _Sprint_ -As tarefas propostas foram realizadas com sucesso, não houveram contratempos durante essa sprint. +
As tarefas propostas foram realizadas com sucesso, não houveram contratempos durante essa sprint.
### 2.1 Backlog da Sprint @@ -70,4 +70,4 @@ ## 8. Visão do _Scrum Master_ -Sendo essa de fato a primeira sprint de MDS e EPS após os devidos treinamentos, foi decidido aderirmos aos eventos da metodologia do Scrum então foi criada uma planilha de monitoramento de presença dos eventos, mais especificamente da Daily, foram criados também modelos de atas de reunião e de dojos, conseguimos ter acesso ao código fonte do projeto o que será de suma importância para a próxima sprint. +
Sendo essa de fato a primeira sprint de MDS e EPS após os devidos treinamentos, foi decidido aderirmos aos eventos da metodologia do Scrum então foi criada uma planilha de monitoramento de presença dos eventos, mais especificamente da Daily, foram criados também modelos de atas de reunião e de dojos, conseguimos ter acesso ao código fonte do projeto o que será de suma importância para a próxima sprint.
diff --git a/docs/sprints/Resultado-Sprint-4.md b/docs/sprints/Resultado-Sprint-4.md index 3970bc92..5352c76b 100644 --- a/docs/sprints/Resultado-Sprint-4.md +++ b/docs/sprints/Resultado-Sprint-4.md @@ -1,6 +1,6 @@ ## 1. Relato da _Sprint_ -A Sprint 04 teve como objetivo o alinhamento de MDS com o Roadmap que foi traçado por EPS, a feature de conectar um sensor, Kinect, ao nosso sistema e a implementação do banco de dados do projeto. +
A Sprint 04 teve como objetivo o alinhamento de MDS com o Roadmap que foi traçado por EPS, a feature de conectar um sensor, Kinect, ao nosso sistema e a implementação do banco de dados do projeto.
--- @@ -65,4 +65,4 @@ ## 8. Visão do _Scrum Master_ -A Sprint 04 na visão do SM, apesar de ter uma queima de pontos elevadas pode ser considerada um fracasso. Os motivos são: A história que possuía a maior relevância no desenvolvimento da Sprint e também a mais atrasada era a US17 - Conectar um sensor ao sistema, após uma reunião, tardia, com o cliente foi descoberto que esta não era, não foi em nenhum momento prioridade do nosso projeto, erro gravíssimo por parte de EPS que pensou durante todas as Sprints justamente o contrário, outra história de grande importancia que era a implementação do banco de dados não foi concluída, e durante um feedback com a professora Carla Rocha, foi necessário acrescentar um refactoring ao protótipo de alta fidelidade que já estava concluído, Em relação a metodologia ocorreu um erro grave de mudança de objetivo da Sprint onde deveríamos ter sidos conscientes em só realizar o refactoring após terminarmos a implementação do banco de dados. Por conta de uma má gerência do SM atrelado a problemas pessoais que ocorreram o grupo de MDS ficou prejudicado e então a Sprint toda ficou prejudicada, por parte do restante do grupo de EPS os Roadmaps das respectivas áreas foram terminados, e o motivo de estarem presentes neste backlog é apenas para mostrar o que foi realizado durante a Sprint por parte do grupo de EPS, os pontos referentes a essas tarefas foram queimados na milestone da Release 01. Está falta de uma gerência adequada durante a Sprint com certeza irá afetar a Sprint 05 que será a próxima a ser desenvolvida onde MDS, provavelmente, terá um maior trabalho para acompanhar o Roadmap proposto. Mesmo não sendo funcionalidade principal o término da US17 será contemplado e utilizado nas Sprints seguintes onde poderemos realizar as outras Histórias de usuário utilizando dados reais e não apenas dados Mocados. +
A Sprint 04 na visão do SM, apesar de ter uma queima de pontos elevadas pode ser considerada um fracasso. Os motivos são: A história que possuía a maior relevância no desenvolvimento da Sprint e também a mais atrasada era a US17 - Conectar um sensor ao sistema, após uma reunião, tardia, com o cliente foi descoberto que esta não era, não foi em nenhum momento prioridade do nosso projeto, erro gravíssimo por parte de EPS que pensou durante todas as Sprints justamente o contrário, outra história de grande importancia que era a implementação do banco de dados não foi concluída, e durante um feedback com a professora Carla Rocha, foi necessário acrescentar um refactoring ao protótipo de alta fidelidade que já estava concluído, Em relação a metodologia ocorreu um erro grave de mudança de objetivo da Sprint onde deveríamos ter sidos conscientes em só realizar o refactoring após terminarmos a implementação do banco de dados. Por conta de uma má gerência do SM atrelado a problemas pessoais que ocorreram o grupo de MDS ficou prejudicado e então a Sprint toda ficou prejudicada, por parte do restante do grupo de EPS os Roadmaps das respectivas áreas foram terminados, e o motivo de estarem presentes neste backlog é apenas para mostrar o que foi realizado durante a Sprint por parte do grupo de EPS, os pontos referentes a essas tarefas foram queimados na milestone da Release 01. Está falta de uma gerência adequada durante a Sprint com certeza irá afetar a Sprint 05 que será a próxima a ser desenvolvida onde MDS, provavelmente, terá um maior trabalho para acompanhar o Roadmap proposto. Mesmo não sendo funcionalidade principal o término da US17 será contemplado e utilizado nas Sprints seguintes onde poderemos realizar as outras Histórias de usuário utilizando dados reais e não apenas dados Mocados.
diff --git a/docs/sprints/Resultado-Sprint-5.md b/docs/sprints/Resultado-Sprint-5.md index e69de29b..e100ba28 100644 --- a/docs/sprints/Resultado-Sprint-5.md +++ b/docs/sprints/Resultado-Sprint-5.md @@ -0,0 +1,66 @@ +## 1. Relato da _Sprint_ + +A Sprint 04 teve como objetivo o alinhamento de MDS com o Roadmap que foi traçado por EPS, a feature de gerar gráfico do movimento e rotulá-lo, e implementação do banco de dados.
+ +--- + +## 2. Fechamento da _Sprint_ +
A Sprint 05 foi fechada no dia, e com grandes conquistas realizadas durante a mesma, sendo que na Sprint obtivemos durante as reuniões de Daily 100% de presença durante 3 dias o alinhamento com o Roadmap ficou como pendência mas nada que o time já não tenha se mostrado capaz de realizar.
+ +### 2.1 Backlog da Sprint + +| ID | Issue | Status | Pontos | +|:--:| ------- | :----: | :----: | +| 01 | [US01 - Cadastrar Movimento](https://github.com/fga-gpp-mds/2018.1-Reabilitacao-Motora/issues/96) | Em Aberto | 21 | +| 05 | [US05 - Rotular Movimento](https://github.com/fga-gpp-mds/2018.1-Reabilitacao-Motora/issues/88) | Fechada | 21 | +| 05 | [US07 - Cadastrar Paciente](https://github.com/fga-gpp-mds/2018.1-reabilitacao-motora/issues/95) | Em Aberto | 5 | +| 13 | [US13 - Gerar Gráficos de Movimentos](https://github.com/fga-gpp-mds/2018.1-Reabilitacao-Motora/issues/46)| Fechada | 34 | +| TK | [Implementação do Banco de dados](https://github.com/fga-gpp-mds/2018.1-Reabilitacao-Motora/issues/66) | Fechada | 05 | +| TK | [Atualizar branch master com a devel](https://github.com/fga-gpp-mds/2018.1-reabilitacao-motora/issues/98) | Fechada | 01 | +| TK | [Atualizar branch gh-pages](https://github.com/fga-gpp-mds/2018.1-reabilitacao-motora/issues/106)| Fechada | 01 | + +> O id "TS" é para *tasks* que são consideradas importantes o suficiente para serem pontuadas. + +### 2.3 Pontuação Final + +* **Pontuação Total:** 80 +* **Pontos Concluídos:** 62 +* **Pontos Não Agregados:** 26 + +------------ + +## 3. _Burndown Chart_ + + + +> O _Burndown_ se encontra disponível neste [Link](https://github.com/fga-gpp-mds/2018.1-Reabilitacao-Motora/issues#reports?report=burndown&milestoneId=3179764) + +------------ + +## 5. velocity + +> **O _velocity_ desta equipe** : 43 Pontos. + +------------ + + +## 6. Retrospectiva da _Sprint_ + + + + >[Link](https://raw.githubusercontent.com/RomeuCarvalhoAntunes/2018.1-Reabilitacao-Motora/master/docs/imagens/Retrospectiva/Retrospectiva_Sprint05.png) + +------------ + +## 7. Quadro de Conhecimento + + + +## 8. Quadro de Presença Daily + + + + +## 8. Visão do _Scrum Master_ +A Sprint 05 ao contrário da 04 foi considerada um sucesso absoluto, mesmo existindo pendências nada que o time não possa lidar para melhorar, nesta Sprint fechamos US importantíssimas como a de gerar gráfico e de rotulação, as 2 haviam sido programadas para Sprint 04 mas no meio do caminho foram encontrados problemas o que levaram inclusive a repontuação das US o velocity resultado desta Sprint praticamente foi dobrado, e comparado com o nosso EVM que teria como um velocity ideal a média de 28 pontos podemos assegurar que o projeto esta bem encaminhado para ser realizado no prazo e no mais tardar da Sprint 07 o alinhamento com o Roadmap estará ideal, visto que na Sprint 06 esta será interrompida pela R1. Apesar dos problemas pessoais enfrentados durante a Sprint pode se considerar totalmente satisfatória com os respectivos objetivos atingidos e uma queima de pontos elevada. +
diff --git a/docs/wiki/Atas-Reuniao.md b/docs/wiki/Atas-Reuniao.md new file mode 100644 index 00000000..324c4e8a --- /dev/null +++ b/docs/wiki/Atas-Reuniao.md @@ -0,0 +1,55 @@ +| Data | Versão | Descrição | Autor(es) | +| :---: | :---: | --- | :---: | +| 17/04/2018 | 1.0 | Criação do documento| Arthur Diniz | + + +# Ata de Reunião + + +## Sumário + +[1. O que é](#1-o-que-é) + +[2. Modelo](#2-modelo) + +[3. Atas](#3-atas) + +[4. Referência Bibliográfica](#4-referência-bibliográfica) + + +## 1. O que é + +A ata é um registro escrito sobre todos os acontecimentos e assuntos debatidos durante uma reunião ou outro tipo de assembleia. A ata é um relato resumido do que foi discutido e normalmente é redigido pela equipe de gerência do projeto
+ +Fazer uma ata de reunião é uma das funções básicas, e requer atenção porque nenhum detalhe pode passar despercebido.
+ +Na ata específica para o projeto de Reabilitação Motora foram usados campos para descrever seu escopo como dia, local, duração da reunião, presidência da reunião e o tipo de reunião que foi executada. Além disso quem esteve responsável pelo preenchimento da ata deve dar uma breve descrição do que foi discutido e a conclusão dos fatos durante a reunião.
+ +## 2. Modelo + + + + +## 3. Atas + + + + + + + + + + + + + + + + + + + +## 4. Referência Bibliográfica + +* Disponível em [https://manualdasecretaria.com.br/ata-de-reuniao-como-fazer/](https://manualdasecretaria.com.br/ata-de-reuniao-como-fazer/) Acesso em 17/04/2018 diff --git a/docs/wiki/AtasDojo.md b/docs/wiki/AtasDojo.md new file mode 100644 index 00000000..4bfcce9d --- /dev/null +++ b/docs/wiki/AtasDojo.md @@ -0,0 +1,41 @@ +| Data | Versão | Descrição | Autor(es) | +| :---: | :---: | --- | :---: | +| 17/04/2018 | 1.0 | Criação do documento| Arthur Diniz | +| 17/04/2018 | 1.1 | Correção data da ata de git| Arthur Diniz | + +# Ata de Dojo + + +## Sumário + +[1. O que é](#1-o-que-é) + +[2. Modelo](#2-modelo) + +[3. Atas](#3-atas) + +[4. Referência Bibliográfica](#4-referência-bibliográfica) + + +## 1. O que é + +A ata é um registro escrito sobre todos os acontecimentos e assuntos debatidos durante uma reunião ou outro tipo de assembleia. A ata é um relato resumido do que foi discutido e normalmente é redigido pela equipe de gerência do projeto
+ +Fazer uma ata de reunião é uma das funções básicas, e requer atenção porque nenhum detalhe pode passar despercebido.
+ +Na ata específica para o projeto de Reabilitação Motora foram usados campos para descrever seu escopo como dia, local, duração da reunião, presidência da reunião e o tipo de reunião que foi executada. Além disso quem esteve responsável pelo preenchimento da ata deve dar uma breve descrição do que foi discutido e a conclusão dos fatos durante a reunião.
+ +## 2. Modelo + + + +## 3. Atas + + + + + + +## 4. Referência Bibliográfica + +* Disponível em [https://manualdasecretaria.com.br/ata-de-reuniao-como-fazer/](https://manualdasecretaria.com.br/ata-de-reuniao-como-fazer/) Acesso em 17/04/2018 diff --git a/docs/wiki/Commits.md b/docs/wiki/Commits.md index 9849384d..9ff8dc26 100644 --- a/docs/wiki/Commits.md +++ b/docs/wiki/Commits.md @@ -11,10 +11,10 @@ Data|Versão|Descrição|Autor * Os commits devem utilizar o seguinte modelo: ``` -[TAG] Breve descrição +Descrição sucinta das alterações feitas ``` * Exemplo prático: ``` -[BUG] Corrige captura de movimento +Adicionando função cadastro de paciente. ``` diff --git a/docs/wiki/Documento-de-Arquitetura.md b/docs/wiki/Documento-de-Arquitetura.md new file mode 100644 index 00000000..968c20ef --- /dev/null +++ b/docs/wiki/Documento-de-Arquitetura.md @@ -0,0 +1,318 @@ +# Histórico de Versões + +Data|Versão|Descrição|Autor +-|-|-|- +09/04|1.0.0|Início do Documento | João Lucas +10/04|1.1.0|Adição do subitem 1.5 e do item 3| Davi Alves +10/04|1.2.0|Adição do tópico 2| Djorkaeff Alexandre Vilela Pereira +10/04|1.2.1|Revisão e correção dos itens 1.1, 1.2, 2, 3.1 e 3.2| Guilherme de Lyra +10/04|1.3.0|Adição do subitem 1.3| Guilherme de Lyra +10/04|1.3.1|Revisão do subitem 1.3| Guilherme de Lyra +10/04|1.4.0|Adição do item 7| Guilherme de Lyra +10/04|1.5.0|Adição do subitem 4.2 e itens 8 e 9| Davi Alves +10/04|1.6.0|Adição do item 5| Guilherme Siqueira +11/04|1.6.1|Revisão dos subitens 1.3, 4.2, 5.1.1, 8 e 9| Guilherme de Lyra +11/04|1.7.0|Adição dos subitens 4.1 e 4.3| Guilherme de Lyra +11/04|1.8.0|Revisão e Complementação do item 2| João Lucas +11/02|1.8.1|Revisão dos itens 2, 7 e subitem 4.1| Davi Alves +11/04|1.9.0|Adição do subitem 6.1| João Lucas +11/04|1.9.1|Revisão do subitem 3.2| Davi Alves +12/04|1.9.2|Atualização o Diagrama de Casos de Uso | Guilherme de Lyra +12/04|1.9.3|Revisão e Pequenas Alterações| João Lucas +12/04|1.10.0|Modificação do subitem 6.1| João Lucas +12/04|1.10.1|Revisão do Documento| João Lucas +14/04|1.11.0|Adição de Diagrama Geral| João Lucas e Vitor Falcão +15/04|1.11.1|Revisão do Documento| João Lucas +15/04|1.12.0|Adição do item 5| João Lucas, Victor Moura e Vitor Falcão +15/04|1.12.1|Revisão do item 5| João Lucas, Victor Moura e Vitor Falcão +17/04|1.12.2|Correção item 5| João Lucas +18/04|1.12.3|Correção do MER| João Lucas +# Sumário +---------------- + 1. [Introdução](#1) + * 1.1 [Finalidade](#1_1) + * 1.2 [Escopo](#1_2) + * 1.3 [Definições, Acrônimos e Abreviações](#1_3) + * 1.4 [Referências](#1_4) + * 1.5 [Visão Geral](#1_5) + 2. [Representação da Arquitetura](#2) + 3. [Metas e Restrições de Arquitetura](#3) + 4. [Visão dos Casos de Uso](#4) + * 4.1 [Diagrama de Casos de Uso](#4_1) + * 4.2 [Atores de Casos de Uso](#4_2) + * 4.3 [Descrições de Casos de Uso](#4_3) + 5. [Visão Lógica](#5) + * 5.1 [Pacotes de Design Significativos do Ponto de Vista da Arquitetura](#5_1) + * 5.1.1 [Classe](#5_1_1) + * 5.1.2 [Pacotes](#5_1_2) + 6. [Visão de Dados](#6) + * 6.1 [MER](#6_1) + * 6.1.1 [Entidades](#6_1_1) + * 6.1.2 [Relacionamentos](#6_1_2) + * 6.2 [DER](#6_2) + * 6.3 [Diagrama Lógico](#6_3) + 7. [Tamanho e Desempenho](#7) + 8. [Qualidade](#8) + +Documento de Arquitetura de Software +------------------------------------ + +## 1. Introdução + +### 1.1 Finalidade +Este documento possui como finalidade uma visão geral abrangente à implementação arquitetural do projeto Reabilitação Motora - FisioTech. +Desenvolvido pelos alunos das disciplinas de Engenharia de Produto de Software e Métodos de Desenvolvimento de Software com o intuito de ajudar no tratamento de pessoas que sofrem de paralisia do membro superior.
+ +### 1.2 Escopo +Este artefato documenta a arquitetura a ser implementada no software e abrangendo assuntos relacionados as metas e restrições da arquitetura, visão de casos de uso, visão lógica, implementação, dados, tamanho e desempenho.
+ +### 1.3 Definições, Acrônimos e Abreviações +Abreviação|Significado +:-:|:-: +|**ECS**| Entity Component System (em tradução livre: "sistema entidade componente") +|**MDS**| Métodos de Desenvolvimento de Software +|**EPS**| Engenharia de Produto de Software +|**kB**| Kilobyte +|**MMO**| Massive Multiplayer Online Game - Jogo Online em Massa de Multijogadores +|**MER**| Modelo Entidade-Relacionamento +|**DER**| Diagrama Entidade-Relacionamento +|**OUI**| Object Ubity Interface +|**GO**| GameObject +|**Adapter**| Adaptador + +### 1.4 Referências +Este documento faz referência ao seguinte link e documento. + +
LINS DE ALBUQUERQUE, Leonardo. Plataforma para captura e estimação de movimentos em membro superior utilizando Sistemas Dinâmicos Lineares Chaveados. 150 f. Tese (Monografia) - Departamento de Engenharia Elétrica, Universidade de Brasília, 2017
+ +* **Unity** +* -- https://unity3d.com/pt/ + +### 1.5 Visão Geral +Este documento descreve e detalha as características de arquitetura do software a ser desenvolvido, identificando e especificando os possíveis problemas assim como também, aprofundar e classificar os escopos do projeto. Inicialmente será apresentada a arquitetura da solução e logo em seguida serão descritas as metas estabelecidas e as restrições da arquitetura proposta. Depois serão definidas diversas visões sobre fundamentos da arquitetura. Enfim serão apresentados todos os recursos que são referentes ao tamanho, desempenho e também a qualidade do software.
+ +## 2. Representação da Arquitetura +A arquitetura utilizada no projeto é a arquitetura denominada "Entity Component System" (ECS, "entidade-componente-sistema"), a escolha dessa arquitetura foi feita por vários motivos, dentre eles a sua facilidade de aplicação dentro do Unity 3D e também por ser a arquitetura mais utilizada em jogos eletrônicos e sistemas com interface gráfica 3D nos tempos atuais. Essa arquitetura tem como princípio a "composição ao invés de herança", o que permite uma flexibilidade maior na criação de novas entidades. Com a ECS, criamos um sistema de hierarquia entre as entidades e seus componentes, podendo assim reutilizar os componentes e dar o mesmo comportamento específico para diversas entidades que tem fins totalmente diferentes. Cada entidade consiste de um ou mais componentes que adicionam comportamento ou funcionalidade para a mesma, portanto o comportamento de uma entidade qualquer pode ser alterado durante o tempo de execução simplesmente adicionando ou removendo um componente da mesma. Isso elimina os problemas de ambiguidade que eram gerados nas hierarquias feitas por heranças profundas e vastas, que se tornam difíceis de entender, manter e estender.
+ + +**Figura 1**- Diagrama de classes +[Clique aqui para visualizar a imagem](https://raw.githubusercontent.com/fga-gpp-mds/2018.1-Reabilitacao-Motora/doc_arq/docs/imagens/Arquitetura/ECS.png) + +Adam Martin, um desenvolvedor de jogos MMO, criou a terminologia mais utilizada de jogos. Em jogos, a arquitetura trabalha com "sistemas" que seriam como funções que interagem com outras entidades que tenham componentes físicos e visíveis. Entidade é o objeto que consiste apenas de uma identificação única, Componentes são os dados brutos do aspecto do objeto e como interage com o mundo e Sistema são threads que executam ações das entidades que possuem mesmos componentes. +
+ +## 3. Metas e Restrições de Arquitetura +### 3.1 Metas +O sistema deve ter uma plataforma de captura, monitoramento e avaliação de movimentos; de forma que venha a facilitar, para o fisioterapeuta, a visualização do progresso do paciente.
+ +### 3.2 Restrições + +O sistema a ser desenvolvido terá como base de sua arquitetura e interface gráfica a utilização da game engine Unity 3D. Um asset do Unity, específico para o sensor, deve estar devidamente contido nos Assets para a captura e sincronismo do movimento humano no sistema.
+A implementação do projeto será a linguagem de programação C# (C-Sharp).Ele Deverá ser utilizado no ambiente Windows 10.
Os profissionais responsáveis pela reabilitação estarão hábeis a cadastrarem-se no sistema e, também, a cadastrar pacientes. Após isso, numa sessão, poderão captar os movimentos do paciente, visualizar gráficos e dados concretos acerca do movimento realizado, e, também, salvar essas informações para acessá-las novamente quando necessário for; viabilizando, portanto, uma análise muito mais precisa e objetiva sobre a condição e evolução do paciente.
+ +### 4.3 Descrições de Casos de Uso + +| **Caso de uso** | **Descrição** | +:-:|:-: +| **UC01 - Manter movimento** | Criar, alterar ou deletar um movimento. | +| **UC02 - Manter paciente** | Criar, alterar ou deletar um paciente. | +| **UC03 - Manter rótulo** | Criar, alterar ou deletar um rótulo de um movimento. | +| **UC04 - Manter fisioterapeuta** | Criar, alterar ou deletar um fisioterapeuta. | + + +## 5. Visão Lógica + +Em visão lógica, o Diagrama Geral da Arquitetura demonstra como será o funcionamento do projeto. Inicialmente, através de um sensor, o usuário executará um movimento para que seja capturado e através de um adapter, que deve atender as exigências de acoplamento, envia ao programa em Unity 3D. O KINECT, diferente dos outros sensores, já possui integração feita de forma nativa no software, portanto não exige o uso do adapter.
+O Módulo de Processamento (pode ser considerado um plugin que realiza processamentos externos) é uma unidade de processamento, podendo ser escrita em qualquer linguagem de programação, que receberá dados do movimento e poderá utilizá-los para realizar cálculos não abordados pelo sistema. A sua comunicação com o software também é feita por meio de um adapter.
+ + +**Figura 3**- Diagrama Geral da Arquitetura +[Clique aqui para visualizar a imagem](https://raw.githubusercontent.com/fga-gpp-mds/2018.1-Reabilitacao-Motora/doc_arq/docs/imagens/Arquitetura/diagrama.png) + + +**Figura 4**- Diagrama Geral da Arquitetura com o KINECT como sensor +[Clique aqui para visualizar a imagem](https://raw.githubusercontent.com/fga-gpp-mds/2018.1-Reabilitacao-Motora/doc_arq/docs/imagens/Arquitetura/kinect.png) + +### 5.1 Pacotes de design Significativos do Ponto de Vista da Arquitetura + +#### 5.1.1 GameObjects e Componentes +Devido à arquitetura de componentes inerente ao Unity, tudo que há no projeto é um GameObject. O GameObject é uma combinação de componentes. Ou seja: ele é a base para a adição de componentes ao objeto da scene, determinando o comportamento do mesmo nela. Basicamente tudo no Unity é um componente. Desde scripts a câmeras. Quando um componente ou um script é adicionado a um GameObject, esse componente adicionado pode ser acessado através da função GetComponent da classe GameObject. Uma vez que o GameObject é destruído, todos os componentes abaixo da sua hierarquia são destruídos.
+ +
Dentro de todo GameObject há componentes, sendo exemplos deles Transform (representa a posição, rotação e escala do objeto na scene), RigidBody (dá propriedade físicas ao GameObject), Renderers (componentes que permitem exibição dos GameObjects em cena), etc.
+ + +**Figura 5**- Representação de relação GameObject e Componentes +[Clique aqui para visualizar a imagem](https://raw.githubusercontent.com/fga-gpp-mds/2018.1-Reabilitacao-Motora/doc_arq/docs/imagens/Arquitetura/unity.png) + +Para melhor visualização da relação entre os componentes no Unity, segue um diagrama: + + +## 6. Visão de Dados + +### 6.1 MER + +#### 6.1.1 Entidades + +**PESSOA** + +Atributo|Propriedade|Tipo|Descrição +-|-|-|- +**idPessoa** | Chave Primária Obrigatório | INTEGER | Identificação da Pessoa +**nomePessoa** | Obrigatório | VARCHAR(30) | Nome da Pessoa +**sexo** | Obrigatório | CHAR(1) | Sexo da Pessoa +**dataNascimento** | Obrigatório | DATE | Data de Nascimento da Pessoa +**telefone1** | Obrigatório | VARCHAR(18) | Número do Telefone Obrigatório da Pessoa +**telefone2** | Opcional | VARCHAR(18) | Número do Telefone Opcional da Pessoa + +**FISIOTERAPEUTA** + +Atributo|Propriedade|Tipo|Descrição +-|-|-|- +**idFisioterapeuta** | Chave Primária Obrigatório | INTEGER | Identificação de um Fisioterapeuta +**idPessoa** | Chave Estrangeira Obrigatório | INTEGER | Identificação da Pessoa +**regiao** | Opcional | VARCHAR(2) | Região de tratamento do Fisioterapeuta +**crefito** | Opcional | VARCHAR(10) | Identificação do CREFITO do Fisioterapeuta +**login** | Obrigatório | VARCHAR(255) | Login do Fisioterapeuta +**senha** | Obrigatório | VARCHAR(255) | Senha do Fisioterapeuta + + +**PACIENTE** + +Atributo|Propriedade|Tipo|Descrição +-|-|-|- +**idPaciente** | Chave Primária Obrigatório | INTEGER | Identificação de um Paciente +**idPessoa** | Chave Estrangeira Obrigatório | INTEGER | Identificação da Pessoa +**observacoes** | Opcional | VARCHAR(300) | Observações do Paciente + + +**MÚSCULO** + +Atributo|Propriedade|Tipo|Descrição +-|-|-|- +**idMusculo** | Chave Primária Obrigatório | INTEGER | Identificação de um Músculo +**nomeMusculo** | Obrigatório | VARCHAR(20) | Nome do Músculo + + +**SESSÃO** + +Atributo|Propriedade|Tipo|Descrição +-|-|-|- +**idSessao** | Chave Primária Obrigatório | INTEGER | Identificação da Sessão +**idFisioterapeuta** | Chave Estrangeira Obrigatório | INTEGER | Identificação de um Fisioterapeuta +**idPaciente** | Chave Estrangeira Obrigatório | INTEGER | Identificação de um Paciente +**dataSessao** | Obrigatório | DATE | Data da realização da Sessão de Exercícios +**observacaoSessao** | Opcional | VARCHAR(300) | Observação da Sessão + +**MOVIMENTO** + +Atributo|Propriedade|Tipo|Descrição +-|-|-|- +**idMovimento** | Chave Primária Obrigatório | INTEGER | Identificação do Movimento +**idFisioterapeuta** | Chave Estrangeira Obrigatório | INTEGER | Identificação de um Fisioterapeuta +**nomeMovimento** | Obrigatório | VARCHAR(50) | Nome do Movimento +**descricaoMovimento** | Opcional | VARCHAR(150) | Descrição do Movimento +**pontosMovimento** | Obrigatório | VARCHAR(150) | Pontos do Movimento + +**EXERCÍCIO** + +Atributo|Propriedade|Tipo|Descrição +-|-|-|- +**idExercicio** | Chave Primária Obrigatório | INTEGER | Identificação do Exercício +**idPaciente** | Chave Estrangeira Obrigatório | INTEGER | Identificação de um Paciente +**idMovimento** | Chave Estrangeira Obrigatório | INTEGER | Identificação do Movimento +**idSessao** | Chave Estrangeira Obrigatório | INTEGER | Identificação da Sessão +**descricaoExercicio** | Opcional | VARCHAR(150) | Descrição do Exercício +**pontosExercicio** | Obrigatório | VARCHAR(150) | Pontos do Exercícios + +**PONTOS RÓTULO FISIOTERAPEUTA** + +Atributo|Propriedade|Tipo|Descrição +-|-|-|- +**idRotuloFisioterapeuta** | Chave Primária Obrigatório | INTEGER | Identificação dos Pontos de Rótulo do Fisioterapeuta +**idMovimento** | Chave Estrangeira Obrigatório | INTEGER | Identificação do Movimento +**estagioMovimentoFisio** | Obrigatório | VARCHAR(30) | Estagio do Movimento do Fisioterapeuta solicita +**tempoInicial** | Obrigatório | REAL | Tempo Inicial do Movimento +**tempoFinal** | Obrigatório | REAL | Tempo Final do Movimento + +**PONTOS RÓTULO PACIENTE** + +Atributo|Propriedade|Tipo|Descrição +-|-|-|- +**idRotuloPaciente** | Chave Primária Obrigatório | INTEGER | Identificação dos Pontos de Rótulo do Paciente +**idExercicio** | Chave Estrangeira Obrigatório | INTEGER | Identificação do Exercício +**estagioMovimentoPaciente** | Obrigatório | VARCHAR(30) | Estagio do Movimento que o Paciente executa +**tempoInicial** | Obrigatório | REAL | Tempo Inicial do Movimento +**tempoFinal** | Obrigatório | REAL | Tempo Final do Movimento + +#### 6.1.2 Relacionamentos + +**PESSOA** especializa totalmente em **FISIOTERAPEUTA** ou **PACIENTE**, pois ambas as entidades compartilham vários atributos em comum. + +**MOVIMENTO** -- estimula – **MÚSCULO** +Um movimento estimula, obrigatoriamente, um ou mais músculos; e, um músculo, é estimulado por vários tipos de movimentos. +(Cardinalidade n:m) + +**MOVIMENTO** -- baseia -- **EXERCÍCIO** +O exercício, realizado pelo paciente, é baseado num movimento ideal. +(Cardinalidade 1:n) + +**FISIOTERAPEUTA** -- cadastra -- **MOVIMENTO** +Um fisioterapeuta cadastra um ou vários movimentos. +(Cardinalidade 1:n) + +**PACIENTE** -- realiza – **EXERCÍCIO** +Um paciente realiza um ou vários movimentos. +(Cardinalidade 1:n) + +**SESSÃO** -- possui -- **EXERCÍCIO** +Numa sessão, múltiplos exercícios são realizados. +(Cardinalidade 1:n) + +**PACIENTE** -- participa -- **SESSÃO** +Um paciente participa de uma ou várias sessões. +(Cardinalidade 1:n) + +**FISIOTERAPEUTA** -- conduz -- **SESSÃO** +Um fisioterapeuta conduz uma ou varias sessões. +(Cardinalidade 1:n + +**MOVIMENTO** -- gera – **PONTOS RÓTULO FISIOTERAPEUTA** +Um movimento gera n pontos nos eixos x e y. +(Cardinalidade 1:n) + +**EXERCÍCIO** -- gera – **PONTOS RÓTULO PACIENTE** +Um exercício gera n pontos nos eixos x e y. +(Cardinalidade 1:n) + + +### 6.2 DER + +**Figura 6**- Diagrama Entidade-Relacionamento +[Clique aqui para visualizar a imagem](https://raw.githubusercontent.com/fga-gpp-mds/2018.1-Reabilitacao-Motora/doc_arq/docs/imagens/Arquitetura/der.png) +### 6.3 Diagrama Lógico + +**Figura 7**- Diagrama ME-R Lógico +[Clique aqui para visualizar a imagem](https://raw.githubusercontent.com/fga-gpp-mds/2018.1-Reabilitacao-Motora/doc_arq/docs/imagens/Arquitetura/logico.png) + + +## 7. Tamanho e Desempenho + +
Estimamos que um movimento de duração de 15 segundos gera, em média, aproximadamente 750 pontos (o que, salvo num arquivo, dá aproximadamente 6kB); tendo em vista que em uma sessão poucos movimentos serão realizados de forma monitorada (já que o sensor tem a finalidade de mapear e estimar a situação do paciente, e que, após isso, o fisioterapeuta conduzirá os movimentos necessários), pode-se inferir que o sistema não processará uma grande quantidade de dados — principalmente por se tratar de um sistema local/_offline_. Seu desempenho será determinado, principalmente, pelo computador utilizado pelo operador.
+ +## 8. Qualidade + +O sistema irá utilizar padrões de interface gráfica desktop desenvolvido na linguagem C# em paralelo com o software Unity 3D. Também deverá ser compatível com os principais sistemas operacionais. Além disso, os desenvolvedores deverão adotar boas práticas para que o sistema como um todo venha ser desenvolvido com qualidade satisfatória.
diff --git "a/docs/wiki/Documento-de-Vis\303\243o.md" "b/docs/wiki/Documento-de-Vis\303\243o.md" index 5ab3ee2a..d42beda2 100644 --- "a/docs/wiki/Documento-de-Vis\303\243o.md" +++ "b/docs/wiki/Documento-de-Vis\303\243o.md" @@ -12,9 +12,13 @@ Data|Versão|Descrição|Autor 15/03|1.7.0|Adição dos subitens 3.4.1 e 3.4.2|João Lucas 15/03|1.8.0|Atualização do subitem 1.1 e Adição do subitem 2.1|Davi Alves 16/03|1.9.0|Adição do subitem 3.5 e 3.6|Davi Alves -16/03|1.9.1|Revisão e Correção dos itens|João Lucas +16/03|1.9.1|Revisão e Correção dos itens| João Lucas 18/03|1.9.2|Revisão e Correção dos itens 2, 3, 3.3.1, 3.4.1 e 3.4.2|Guilherme de Lyra 21/03|2.0.0|Adição do tópico 5 e 6|Djorkaeff Alexandre +17/04|2.1.0|Adição do tópico 3.3.3|João Lucas +17/04|2.1.1|Revisão e Correção| João Lucas +17/04|2.1.2|Estruturando o item 5| Djorkaeff Alexandre +17/04|2.1.2|Correção de alguns tópicos| João Lucas # Sumário @@ -32,7 +36,12 @@ Data|Versão|Descrição|Autor - 3.1 [Resumo dos Usuários](#3_1) - 3.2 [Ambiente do Usuário](#3_2) - 3.3 [Perfis dos Envolvidos](#3_3) + - 3.3.1 [Equipe de Desenvolvimento](#3_3_1) + - 3.3.2 [Equipe de Gestão de Projeto](#3_3_2) + - 3.3.3 [Cliente](#3_3_3) - 3.4 [Perfis dos Usuários](#3_4) + - 3.4.1 [Paciente](#3_4_1) + - 3.4.2 [Fisioterapeuta](#3_4_2) - 3.5 [Principais Necessidades dos Usuários ou dos Envolvidos](#3_5) - 3.6 [Alternativas e Concorrência](#3_6) 4. [Visão Geral do Produto](#4) @@ -49,11 +58,11 @@ ___ ##### 1.1 Propósito -Este documento tem por objetivo estabelecer um posicionamento geral e estruturado sobre a aplicação, as características e o desenvolvimento do sistema. Objetiva também expor as funcionalidades, definindo requisitos de alto nível em termos de necessidade para usuários finais.
+Este documento tem por objetivo estabelecer um posicionamento geral e estruturado sobre a aplicação, as características e o desenvolvimento do sistema. Objetiva também expor as funcionalidades, definindo requisitos de alto nível em termos de necessidade para usuários finais.
##### 1.2 Escopo -Este projeto tem como finalidade auxiliar na recuperação de movimento dos membros superiores de vítimas de AVC, esse auxílio será feito de forma a sistematizar a amostragem de resultados de movimentos e facilitar a visualização desses para o fisioterapeuta responsável.
+Este projeto tem como finalidade auxiliar na recuperação, de pacientes que sofreram algum tipo de restrição dos movimentos dos membros superiores, com foco na espasticidade, esse auxílio será feito de forma a sistematizar a amostragem de resultados de movimentos e facilitar a visualização desses para o fisioterapeuta responsável.
##### 1.3 Definições, acrônimos e abreviações @@ -72,27 +81,24 @@ CHAVES, Felipe; SILVA, Guilherme; HORINOUCHI, Lucas; DOS SANTOS, Lucas; NÓBREGA Disponível em: https://github.com/fga-gpp-mds/2017.2-Receituario-Medico/wiki. Acesso em 07 mar. 2018; ##### 1.5 Visão geral -Este documento é dividido em 7 tópicos descrevendo os detalhes das características do software proposto. +
Este documento é dividido em 7 tópicos descrevendo os detalhes das características do software proposto. Sendo dividido em:
- -* **Introdução:** no qual é introduzido os detalhes gerais sobre a visão do projeto; -* **Posicionamento:** descrevendo o problema e a oportunidade de negócio; -* **Descrições dos Envolvidos e dos Usuários:** esta seção descreve o perfil das partes interessadas no projeto; -* **Visão Geral do Produto:**Esta seção fornece uma visualização de alto nível das capacidades do produto, interfaces para outros aplicativos e configurações dos sistemas;
-* **Recursos do Produto:** breve descrição dos recursos do produto; -* **Restrições:** as restrições de *design*, restrições externas, como requisitos operacionais ou regulamentares; - -___ +* **Introdução:** No qual é introduzido os detalhes gerais sobre a visão do projeto; +* **Posicionamento:** Descrevendo o problema e a oportunidade de negócio; +* **Descrições dos Envolvidos e dos Usuários:** Esta seção descreve o perfil das partes interessadas no projeto; +* **Visão Geral do Produto:** Esta seção fornece uma visualização de alto nível das capacidades do produto, interfaces para outros aplicativos e configurações dos sistemas; +* **Recursos do Produto:** Breve descrição dos recursos do produto; +* **Restrições:** As restrições de *design*, restrições externas, como requisitos operacionais ou regulamentares; ### 2. Posicionamento ##### 2.1 Oportunidade de Negócio -O corpo humano é dividido em três partes fundamentais: cabeça, tronco e membros. Sendo os membros classificados em superiores e inferiores. O movimento desses membros é algo essencial para que uma pessoa possa executar tarefas no dia a dia, e ter uma vida apropriada.
-Porém, existem cada vez mais pessoas sendo afetadas por algo popularmente conhecido como derrame cerebral, um problema neurológico decorrente de uma obstrução ou rompimento dos vasos sanguíneos cerebrais. As sequelas futuras do AVC (acidente vascular cerebral) consistem comumente na parte motora, afetando com paralisia total ou parcial a um dos lados do corpo.
-Sendo assim fisioterapeutas são necessários para auxiliar na recuperação desses movimentos, realizando um acompanhamento para verificar o ganho de amplitude de movimentos, ajudar com alongamentos e mobilizações passivas em todos os planos de movimentos. Cabe ao fisioterapeuta a tarefa de analisar o progresso de seu paciente visualmente ou utilizando tecnologias que provem métodos de aquisição de dados do paciente, o que não é um trabalho fácil e nem possui uma certa agilidade.
-Diante dos fatos apresentados, é proposto no projeto o desenvolvimento de uma plataforma de captura e estimação de movimentos capaz de auxiliar na otimização do processo fisioterapêutico.
O corpo humano é dividido em três partes fundamentais: cabeça, tronco e membros. Sendo os membros classificados em superiores e inferiores. O movimento desses membros é algo essencial para que uma pessoa possa executar tarefas no dia a dia, e ter uma vida apropriada.
+
Porém, existem cada vez mais pessoas sendo afetadas por algo popularmente conhecido como derrame cerebral, um problema neurológico decorrente de uma obstrução ou rompimento dos vasos sanguíneos cerebrais. As sequelas futuras do AVC (acidente vascular cerebral) consistem comumente na parte motora, afetando com paralisia total ou parcial a um dos lados do corpo.
+Sendo assim fisioterapeutas são necessários para auxiliar na recuperação desses movimentos, realizando um acompanhamento para verificar o ganho de amplitude de movimentos, ajudar com alongamentos e mobilizações passivas em todos os planos de movimentos. Cabe ao fisioterapeuta a tarefa de analisar o progresso de seu paciente visualmente ou utilizando tecnologias que provem métodos de aquisição de dados do paciente, o que não é um trabalho fácil e nem possui uma certa agilidade.
+
Diante dos fatos apresentados, é proposto no projeto o desenvolvimento de uma plataforma de captura e estimação de movimentos capaz de auxiliar na otimização do processo fisioterapêutico.
##### 2.2 Descrição do problema @@ -108,12 +114,10 @@ Diante dos fatos apresentados, é proposto no projeto o desenvolvimento de uma p |:---|:---| |**Que** |necessitam de analises mais precisas para um melhor tratamento| |**O Reabilitação Motora**|é uma aplicação para otimizar a fisioterapia| -|**Que**|faz a leitura por sensores dos movimentos do paciente e efetua uma analise automática dos mesmos
| +|**Que**|faz a leitura por sensores dos movimentos do paciente e efetua uma análise automática dos mesmos
| |**Diferente de**|avaliações subjetivas e qualitativas efetuadas por fisioterapeutas| |**Nosso produto**|é uma solução para chegar a melhores resultados em sessões de fisioterapias, menos suscetível a falhas antrópicas
| -___ - ### 3. Descrições da parte interessada e dos Usuários @@ -129,51 +133,55 @@ Nome|Descrição|Responsabilidade Nome|Descrição -|- -| Paciente |Pacientes com a doença que buscam tratamento com fisioterapeutas
| +| Paciente |Pessoas com movimentos restringidos dos membros superiores que buscam tratamento com fisioterapeutas
| | Fisioterapeuta |Profissionais da área de Fisioterapia que auxiliam pessoas com problemas de coordenação e mobilidade.
| ##### 3.2 Ambiente do Usuário -A aplicação será utilizada em computadores ligados a monitores e sensores que atendam os requisitos mínimos de sistema estabelecidos.
+A aplicação será utilizada em computadores ligados a monitores e sensores que atendam aos requisitos mínimos de sistema estabelecidos.
##### 3.3 Perfis dos Envolvidos ###### 3.3.1 Equipe de Desenvolvimento -Representante|Djorkaeff Alexandre, Guilherme de Lyra, Guilherme Siqueira, João Lucas. +Representante|Davi Alves, Djorkaeff Alexandre, Guilherme de Lyra, Guilherme Siqueira e João Lucas. -|- -**Descrição**|Desenvolvedores. -**Tipo**|
Estudantes da Universidade de Brasília da disciplina de Métodos de Desenvolvimento de Software.
-**Responsabilidade**|Desenvolvimento, Testes, Documentação e Implementação do *software*.
-**Critérios de Sucesso**|Finalizar o desenvolvimento e realizar a entrega do *software* em tempo estipulado.
-**Envolvimento**|Alto. -**Problemas/Comentários**|A equipe é inexperiente na linguagem de programação utilizada no desenvolvimento, no padrão arquitetural e nas metodologias de desenvolvimento.
- +**Descrição** |Desenvolvedores. +**Tipo** |Estudantes da Universidade de Brasília da disciplina de Métodos de Desenvolvimento de Software.
+**Responsabilidade** |Desenvolvimento, Testes, Documentação e Implementação do *software*.
+**Critérios de Sucesso** |Finalizar o desenvolvimento e realizar a entrega do *software* em tempo estipulado.
+**Envolvimento** |Alto. +**Problemas/Comentários** |A equipe é inexperiente na linguagem de programação utilizada no desenvolvimento, no padrão arquitetural e nas metodologias de desenvolvimento.
###### 3.3.2 Equipe de Gestão de Projeto -Representante|Lucas Malta, Vitor Falcão, Arthur Diniz, Victor Moura, Romeu Carvalho.
+Representante|Arthur Diniz, Lucas Malta, Romeu Carvalho, Victor Moura e Vitor Falcão.
-|- -**Descrição**|Gerenciamento de projeto. -**Tipo**|Estudantes da disciplina de Engenharia de Produto de Software da Universidade de Brasília.
-**Responsabilidade**|Gerir o desenvolvimento do produto identificando problemas e apontando caminhos e soluções.
-**Critérios de Sucesso**|Manter a equipe focada no projeto, gerência dos riscos associados ao projeto e finalizar o desenvolvimento do projeto.
-**Envolvimento**|Alto. -**Problemas/Comentários**|Não familiarizados com o ambiente de desenvolvimento de aplicações com uso de sensores de movimento.
- - - -###### 3.3.3 Cliente +**Descrição** |Gerenciamento de projeto. +**Tipo** |Estudantes da disciplina de Engenharia de Produto de Software da Universidade de Brasília.
+**Responsabilidade** |Gerir o desenvolvimento do produto identificando problemas e apontando caminhos e soluções.
+**Critérios de Sucesso** |Manter a equipe focada no projeto, gerência dos riscos associados ao projeto e finalizar o desenvolvimento do projeto.
+**Envolvimento** |Alto. +**Problemas/Comentários** |Não familiarizados com o ambiente de desenvolvimento de aplicações com uso de sensores de movimento.
+###### 3.3.3 Clientes +Representante|Carla Silva Rocha Aguiar / Prof. Roberto Baptista +-|- +**Descrição** |Professores da Universidade de Brasília Campus Gama.
+**Tipo** |Clientes idealizadores do projeto e com grande interesse no seu desenvolvimento. +**Responsabilidade** |
Avaliar e validar o *software*.
+**Critérios de Sucesso** |O *software* deve apresentar todos os requisitos e metodologias das disciplinas de MDS e EPS.
+**Envolvimento** |Alto. +**Problemas/Comentários** |-
##### 3.4 Perfis dos Usuários ###### 3.4.1 Paciente Representante|Pacientes :-:|:-: -|**Descrição**|Pacientes com sequelas do AVC. +|**Descrição**|Pacientes com restrição na movimentação dos membros superiores. |**Tipo**|Pacientes que sofrem de paralisia no membro superior (causada pela espasticidade). |**Responsabilidade**| - |**Critérios de Sucesso**|Restaurar a movimentação do braço afetado. @@ -184,7 +192,7 @@ Representante|Pacientes Representante|Fisioterapeutas :-:|:-: -|**Descrição**|Pessoas da área de recuperação de movimentos através de exercícios. +|**Descrição**|Profissionais da saúde da área de recuperação de movimentos através de exercícios. |**Tipo**|Formação em Fisioterapia. |**Responsabilidade**|Ajudar e monitorar pacientes com a necessidade de tratamento na área de locomoção do braço. |**Critérios de Sucesso**|Pacientes recuperarem a totalmente movimentação do braço. @@ -201,45 +209,33 @@ Necessidade|Prioridade|Interesse|Solução Atual|Solução Proposta ##### 3.6 Alternativas e Concorrência -Atualmente existem algumas alternativas tecnologicas disponíveis no mercado utilizadas por profissionais de fisioterapia, varias delas estão focadas em prover sensoreamento e métodos de aquisição de dados dos pacientantes. Porém a tarefa de analisar esses dados é feita muitas das vezes de forma manual, gerando um certo atraso para resultados, afetando a eficiência e precisão.
-___ +Atualmente existem algumas alternativas tecnológicas disponíveis no mercado utilizadas por profissionais de fisioterapia, varias delas estão focadas em prover sensoriamento e métodos de aquisição de dados dos pacientes. Porém a tarefa de analisar esses dados é feita muitas das vezes de forma manual, gerando um certo atraso para resultados, afetando a eficiência e precisão.
### 4. Visão Geral do Produto -A aplicação analisará de forma automática, com auxílio de sensores, o movimento do braço (desde o ombro até a mão) dos pacientes de sessões de fisioterapia, apresentando um modelo esqueleto completo do mesmo e dando para o usuário, em tempo real, os resultados da estimação dos movimentos realizados. Esses resultados são menos propensos a erros antrópicos, pois são analisados pelo software e resultados quantitativos e numéricos são entregues ao fisioterapeuta.
### 5. Recursos do Produto -
+
O sistema oferece as seguintes funcionalidades aos usuários:
-Gerenciar e manter usuários (pacientes): os profissionais de fisioterapia poderão cadastrar novos pacientes no sistema, atualizar os dados de um paciente e também remover um paciente.
-
-Facilitar, para o fisioterapeuta, a visualização do progresso do paciente na movimentação dos membros superiores em questão e o controle dos seus pacientes.
-
-Otimizar o tempo gasto pelo usuário profissional de fisioterapia ao analisar os movimentos feitos por um paciente de fisioterapia.
-
-Disponibilizar ao fisioterapeuta as informações referentes a cada paciente cadastrado.
+*
Gerenciar e manter usuários (pacientes): os profissionais de fisioterapia poderão cadastrar novos pacientes no sistema, atualizar os dados de um paciente e também remover um paciente.
+*Facilitar, para o fisioterapeuta, a visualização do progresso do paciente na movimentação dos membros superiores em questão e o controle dos seus pacientes.
+*Otimizar o tempo gasto pelo usuário profissional de fisioterapia ao analisar os movimentos feitos por um paciente de fisioterapia.
+*Disponibilizar ao fisioterapeuta as informações referentes a cada paciente cadastrado.
+*Possibilitar ao fisioterapeuta a criação de um padrão de movimento para que o paciente possa repetir esse movimento durante as sessões de fisioterapia, com o intuito de melhorar seus movimentos.
+*Possibilitar ao fisioterapeuta rotular os movimentos para sub-dividílos em fases.
+*Possibilitar ao fisioterapeuta atualizar, visualizar, remover e criar novos movimentos padrões.
-Possibilitar ao fisioterapeuta a criação de um padrão de movimento para que o paciente possa repetir esse movimento durante as sessões de fisioterapia, com o intuito de melhorar seus movimentos. -
-Possibilitar ao fisioterapeuta rotular os movimentos para sub-dividílos em fases. -
-Possibilitar ao fisioterapeuta atualizar, visualizar, remover e criar novos movimentos padrões. -
- -___ ### 6. Restrições ##### 6.1 Restrições de Design -
O design será elegante e simples, pensado ao pormenor, onde apenas o essencial tem lugar à vista.
+O design será elegante e simples, pensado ao pormenor, onde apenas o essencial tem lugar à vista.
##### 6.2 Restrições de Implementação -O sistema será desenvolvido utilizando a linguagem c# e o Unity que é motor de jogo 3D proprietário e uma IDE criado pela Unity Technologies.
+O sistema será desenvolvido utilizando a linguagem C# e o Unity que é motor de jogo 3D proprietário e uma IDE criado pela Unity Technologies.
##### 6.3 Restrições de Segurança -O programa não tem grandes restrições de segurança mas deve-se manter a base de dados segura para que os dados não sejam corrompidos pois teremos no mesmo informações pessoais e números de documentos dos pacientes, essas informações só deverão estar disponíveis para o fisioterapeuta administrador do sistema que é o único que terá acesso a usar e manter o mesmo.
+O programa não tem grandes restrições de segurança mas deve-se manter a base de dados segura para que os dados não sejam corrompidos pois teremos no mesmo informações pessoais e números de documentos dos pacientes, essas informações só deverão estar disponíveis para o fisioterapeuta administrador do sistema que é o único que terá acesso a usar e manter o mesmo.
##### 6.4 Restrições de Uso -Para o uso do sistema é necessário que o usuário tenha um dispositivo do tipo Computador e um dispositivo que possa reconhecer os dados de angulação do paciente (Primeiramente utiliza-se de Kinect, que é um sensor de movimento 3d). Caso o usuário não possua o sensor o sistema deverá apresentar erro ao clicar nas opções nas quais o sensor é necessário.
-___ +Para o uso do sistema é necessário que o usuário tenha um dispositivo do tipo Computador e um dispositivo que possa reconhecer os dados de angulação do paciente (Primeiramente utiliza-se de Kinect, que é um sensor de movimento 3d). Caso o usuário não possua o sensor o sistema deverá apresentar erro ao clicar nas opções nas quais o sensor é necessário.
diff --git a/docs/wiki/EVM.md b/docs/wiki/EVM.md new file mode 100644 index 00000000..93ab9bc9 --- /dev/null +++ b/docs/wiki/EVM.md @@ -0,0 +1,109 @@ +# EVM + +## Custo do Projeto + + + + + +--- + +## EVM Release 01 + + +| Sprint (n) | Sprints Planejadas (PS) | Duração da Sprint (L), em dias | Pontos Planejados - Release (PRP) | Pontos Adicionados no PRP | Pontos Planejados - Sprint (PSP) | Pontos Adicionados - Sprint (PA) | Pontos Removidos - Sprint (PR) | Pontos Realizados - Sprint (PC) | Porcentagem Planejada Concluída (PPC) | Esforço Feito na Sprint | Porcentagem Real Concluída (APC) | Porcentagem Esperada - Visão Cliente | Porcentagem Concluída - Visão Cliente | Valor Planejado - Release (BAC) | Valor Planejado (PV) | Custo Real (AC) | Valor Agregado (EV) | Variação de Custo (CV) | Variação de Prazo (SV) | Índice de Desempenho de Custo (CPI) | Índice de Desempenho de Prazo (SPI) | +|---------------|-------------------------------|-----------------------------------------|------------------------------------------------|---------------------------------|----------------------------------------|----------------------------------------|--------------------------------------|-----------------------------------------|------------------------------------------------|-------------------------------|----------------------------------------|-----------------------------------------------|--------------------------------------------------|---------------------------------------------|-------------------------|-------------------------|-------------------------------|---------------------------------|---------------------------------|---------------------------------------------------|--------------------------------------------------| +| 0 | 7 | 7 | 200 | 0 | 13 | 0 | 0 | 13 | 100,00% | 100,00% | 6,50% | 6,14% | 6,50% | R$ 42.215,16 | R$ 6.030,73 | R$ 2.743,99 | R$ 2.743,99 | R$ 0,00 | -R$ 3.286,74 | 1 | 0,4550005389 | +| 1 | 7 | 7 | 200 | 0 | 18 | 0 | 0 | 18 | 100,00% | 100,00% | 15,50% | 12,29% | 15,50% | R$ 42.215,16 | R$ 6.030,73 | R$ 3.799,36 | R$ 3.799,36 | R$ 0,00 | -R$ 2.231,37 | 1 | 0,6300007462 | +| 2 | 7 | 7 | 200 | 0 | 33 | 0 | 0 | 4 | 12,12% | 12,12% | 17,50% | 18,43% | 17,50% | R$ 42.215,16 | R$ 6.030,73 | R$ 6.965,50 | R$ 844,30 | -R$ 6.121,20 | -R$ 5.186,43 | 0,1212121212 | 0,1400001658 | +| 3 | 7 | 7 | 200 | 0 | 32 | 0 | 0 | 19 | 59,38% | 59,38% | 27,00% | 24,57% | 27,00% | R$ 42.215,16 | R$ 6.030,73 | R$ 6.754,43 | R$ 4.010,44 | -R$ 2.743,99 | -R$ 2.020,29 | 0,59375 | 0,6650007876 | +| 4 | 7 | 7 | 200 | 0 | 52 | 0 | 0 | 30 | 57,69% | 57,69% | 42,00% | 30,71% | 42,00% | R$ 42.215,16 | R$ 6.030,73 | R$ 10.975,94 | R$ 6.332,27 | -R$ 4.643,67 | R$ 301,54 | 0,5769230769 | 1,050001244 | +| 5 | 7 | 7 | 200 | 0 | 26 | 0 | 0 | 64 | 246,15% | 100,00% | 74,00% | 36,86% | 74,00% | R$ 42.215,16 | R$ 6.030,73 | R$ 5.487,97 | R$ 13.508,85 | R$ 8.020,88 | R$ 7.478,12 | 2,461538462 | 2,240002653 | +| 6 | 7 | 7 | 200 | 0 | 26 | 0 | 0 | 0 | 0,00% | 0,00% | 74,00% | 43,00% | 74,00% | R$ 42.215,16 | R$ 6.030,73 | R$ 5.487,97 | R$ 0,00 | -R$ 5.487,97 | -R$ 6.030,73 | 0 | 0 | + +--- + +## Gráficos + +### PV x EV x AC + + + +> Valor Planejado (PV) + - Constante pois todas as _Sprints_, possuem o mesmo valor, teoricamente. + +> Custo Real (AC) + - Quantidade de pontos planejados vezes o valor em reais do ponto = (Valor do Projeto /Pontos totais do projeto) + +> Valor Agregado (EV) + - Quantidade de pontos queimados na _sprint_ vezes o valor do ponto. + +### CV x SV + + + +> Variação de Custo (CV) + +> Variação de Prazo (SV) + +### CPI x SPI + + + +> Índice de Desempenho de Custo (CPI) +- CPI = 1 → Projeto está atendendo as expectativas (dentro do orçamento) +- CPI > 1 → Projeto está superando as expectativas (economizando) +- CPI < 1 → Projeto está abaixo das expectativas (estouro no orçamento) + +> Índice de Desempenho de Prazo (SPI) +- SPI = 1 → Projeto está atendendo as expectativas (dentro do prazo) +- SPI > 1 → Projeto está superando as expectativas (adiantado) +- SPI < 1 → Projeto está abaixo das expectativas (atrasado) + + +--- + +## EVM Detalhado por Sprint + + +### Sprint 00 + + + +--- + +### Sprint 01 + + + +--- + +### Sprint 02 + + + +--- + +### Sprint 03 + + + +--- + +### Sprint 04 + + + +--- + +### Sprint 05 + + + +--- + +### Sprint 06 + + + +--- diff --git a/docs/wiki/Prototipo.md b/docs/wiki/Prototipo.md index fd6537da..e04e7704 100644 --- a/docs/wiki/Prototipo.md +++ b/docs/wiki/Prototipo.md @@ -2,4 +2,4 @@Feito por Guilherme Siqueira e Djorkaeff Alexandre.
-O protótipo foi feito na plataforma [Quant-UX](https://www.quant-ux.com/). Para acessá-lo, clique [aqui](https://www.quant-ux.com/test.html?h=a2aa10ax8F5aqFYNrSZUCLeyaj9yuSwzXKZdY4vCDdmoDho3h2LLzjwPM6pu). Deve-se interagir com o protótipo como se fosse a aplicação final. Botões são interativos. +O protótipo foi feito na plataforma [Quant-UX](https://www.quant-ux.com/). Para acessá-lo, clique [aqui](https://www.quant-ux.com/test.html?h=a2aa10aUbwoaitNtofUizk9iydeBepQG9UZKiRivlnz1DdIWrXJGBP5mM2ze). Deve-se interagir com o protótipo como se fosse a aplicação final. Botões são interativos. diff --git a/docs/wiki/Termo-Abertura-Projeto.md b/docs/wiki/Termo-Abertura-Projeto.md index ce77a6d6..4610929d 100644 --- a/docs/wiki/Termo-Abertura-Projeto.md +++ b/docs/wiki/Termo-Abertura-Projeto.md @@ -5,7 +5,8 @@ | 15/03/2018 | 0.1 | Criação do documento e elaboração dos tópicos 11, 13, 14 e 15 | Arthur Diniz | | 20/03/2018 | 0.2 | Inserção dos tópicos 1 e 2 | Vitor Falcão | | 02/04/2018 | 0.3 | Inserção dos tópicos 3 e 7. Modificações no tópico 4 | Victor Moura | -| 02/04/2018 | 0.4 | Elaboração dos tópicos 8 e 9 | Arthur Diniz +| 02/04/2018 | 0.4 | Elaboração dos tópicos 8 e 9 | Arthur Diniz | +| 17/04/2018 | 0.5 | Concluindo e revisando o documento | Romeu Antunes | ---- @@ -142,9 +143,15 @@ Release 02 | 20/04/18 a 25/06/18 | Entrega total do sistema ## 10. Resumo do Custo estimado ### 10.1. Recursos Humanos +Os recursos humanos que estão sendo usados no desenvolvimento do projeto são, 5 pessoas para gerenciamento sendo os papéis definidos pelo Framework Scrum e sendo os papéis Scrum Master, Product Owner, DevOps, Arquitetura e joker. A parte de desenvolvimento do projeto está com o grupo de MDS que é constituído de 5 integrantes. Cada membro dos diferentes grupos deve disponibilizar o período de 10 horas semanais para se dedicar ao desenvolvimento do projeto. Utilizando esses dados estimamos quanto um aluno custa por mês para a Universidade de Brasília (UnB), para utilizarmos no calculo de valor do projeto e estimar o valor das nossas horas de trabalho.
+ ### 10.2. Equipamentos e Serviços +O custo de equipamentos utilizados pelos membros do grupo está no valor de R$ 33.618,00 este valor foi retirado com base nos valores de mercado dos notebooks pessoais dos membros. Na parte de serviços foi utilizada uma média de consumo elétrico dos notebooks pessoais dos membros para estimar um valor para uma conta de luz onde seria o local de trabalho do grupo, acrescemos também um valor de uma franquia de internet que julgamos suficientes para suportar os 10 membros trabalhando juntos ao mesmo tempo.
+ ### 10.3. Custo Total + +> O Custo total do projeto esta no valor de R$ 98.174,78. ## 11. Lista das partes interessadas ### 11.1 Desenvolvedor da Sistema e do Software de Reabilitação @@ -186,6 +193,7 @@ Release 02 | 20/04/18 a 25/06/18 | Entrega total do sistema ## 12. Requisitos para aprovação do Projeto +Para considerar o projeto aprovado ele deverá estar de acordo com as especificações dos nossos Stakeholders externos que são: Prof. Carla Silva Rocha Aguiar e Prof. Roberto. O projeto deverá captar o movimento do paciente e gerar o gráfico de linha a respeito do mesmo movimento, o fisioterapeuta deverá poder marcar no gráfico pontos para que haja a rotulação de movimento o projeto deve se comunicar com outras plataformas por meio de uma interface TCP para que o cliente não fique dependendo de um sensor especifico.
## 13. Gerente do Projeto diff --git a/docs/wiki/riscos_do_projeto.md b/docs/wiki/riscos_do_projeto.md new file mode 100644 index 00000000..12ed79df --- /dev/null +++ b/docs/wiki/riscos_do_projeto.md @@ -0,0 +1,72 @@ +# Riscos do Projeto + +| Data | Versão | Alteração | Autor | +|:----------:|:------:|:-----------------------------------------------------------------:|:-------------------------------------------:| +| 10/04/2018 | 0.1 | Criação do documento | Victor Moura | +| 10/04/2018 | 0.2 | Adicionando referência de quantificação | Victor Moura | + +## Levantamento de Riscos Negativos + +| Label | Título | Descrição | Probabilidade | Nível do Impacto | +| ----- | ------ | --------- | ------------- | ---------------- | +| R01 | Integração com o sensor do Cliente | Software feito pela equipe não estar integrado com o sensor do cliente | - | - | +| R02 | Utilizar Kinect para captar movimentos | Software feito pela equipe não suportar integração do Kinect para captar os movimentos | - | - | +| R03 | Falta de código a ser feito por conta da plataforma utilizada | Excesso de uso da interface do Unity e falta de scripts pode reduzir o engajamento do time | - | - | +| R04 | Integração Contínua do Unity | Integração contínua do Unity não funcionar | - | - | +| R05 | Greve na Universidade | UnB entrar em greve, impedindo o andamento do projeto | - | - | +| R06 | Tecnologia desconhecida | Falta de conhecimento da tecnologia pode dificultar o desenvolvimento do projeto | - | - | +| R07 | Falta de contato com o Cliente | Falta de contato com o cliente torna obscuro o processo de gerência de requisitos | - | - | +| R08 | Baixa maturidade de MDS em relação à metodologia e às ferramentas de apoio | Falta de conhecimento nas ferramentas que apoiam o projeto pode reduzir a produtividade do time | - | - | +| R09 | Uso de tecnologia privada | Por não ser uma plataforma de código aberto, o Unity possui muitas limitações em sua versão gratuita | - | - | +| R10 | Atraso nas entregas | Entregas não condizentes com o planejamento realizado | - | - | +| R11 | Baixa produtividade da equipe | Equipe não apresentar desempenho esperado durante a sprint | - | - | +| R12 | Falta de documentação | Falta de documentação atualizada com a implementação pode dificultar o acompanhamento do projeto | - | - | +| R13 | Complexidade da arquitetura | Arquiteturas complexas podem, por conta da curva de aprendizado, reduzir a produtividade do time | - | - | +| R14 | Falta de disponibilidade dos membros | Membros não presentes nos rituais da metodologia acabam ficando desatualizados em relação ao andamento do projeto | - | - | + +## Levantamento de Riscos Positivos + +| Label | Título | Descrição | Probabilidade | Nível do Impacto | +| ----- | ------ | --------- | ------------- | ---------------- | +| R15 | Boa integração do time | Times bem integrados possuem um melhor ambiente de trabalho, propiciando o aumento da produtividade e o engajamento dos membros | - | - | +| R16 | Engajamento dos membros em relação ao projeto | Membros mais engajados estimulam a criatividade e a resiliência durante o processo de desenvolvimento | - | - | +| R17 | Alta produtividade da equipe | Alta produtividade da equipe reduz a probabilidade de se ocorrerem atrasos | - | - | +| R18 | Estabilidade técnica dos pipelines de produção | Com os pipelines estáveis, tem-se mais tempo para ser dedicado às outras atividades pertinentes ao projeto | - | - | +| R19 | Arquitetura estar bem definida | Com uma arquitetura bem definida, menos mudanças impactantes ocorrem e, portanto, ocorre menos retrabalho | - | - | +| R20 | Satisfação do cliente | O sucesso do projeto possui como um dos principais indicadores a satisfação do cliente | - | - | + +## Probabilidade x Impacto + +### Tabela de probabilidades + +| Probabilidade | Intervalo | Nível | +| ------------- | --------- | ----- | +| Muito baixa | Menos de 20% | 1 | +| Baixa | 21% a 40% | 2 | +| Moderada | 41% a 60% | 3 | +| Alta | 61% a 80% | 4 | +| Muito alta | Mais de 80% | 5 | + +### Tabela de impactos + +| Probabilidade | Intervalo | Nível | +| ------------- | --------- | ----- | +| Muito baixo | Impacto não significativo | 1 | +| Baixo | Impacto de baixa influência | 2 | +| Moderado | Impacto notável com poucas consequências | 3 | +| Alto | Impacto que compromete o andamento do projeto | 4 | +| Muito alto | Impacto que inviabiliza o andamento do projeto | 5 | + +### Matriz de quantificação dos riscos + +| Probabilidade/Impacto | Muito baixo | Baixo | Moderado | Alto | Muito alto | +| --------------------- | ----------- | ----- | -------- | ---- | ---------- | +| Muito baixa | 1 | 2 | 3 | 4 | 5 | +| Baixa | 2 | 4 | 6 | 8 | 10 | +| Moderada | 3 | 6 | 9 | 12 | 15 | +| Alta | 4 | 8 | 12 | 16 | 20 | +| Muito alta | 5 | 10 | 15 | 20 | 25 | + +## Gerência de Riscos + +Além das tabelas presentes neste documento, temos as [planilhas no Google Drive](https://docs.google.com/spreadsheets/d/1EIi_RUSnb4NRGk6ByyrqA3ADAQUBa38AiujRxv7egA0/edit?usp=sharing) que possuem o registro por sprint e os gráficos de burndown.