Relatório de Projeto LifeBox


Relatório do Projeto LifeBox

Equipe: 

Clientes:

Serra, 2017


Sumário

Sumário        2

Gerência de Requisitos        3

Minimundo        3

Regras de Negócio e Cenários        4

Modelagem        13

Casos de Uso        14

Gestão de Projetos        16

Project Model Canvas        16

Backlog de Projeto        17

Acompanhamento do projeto        18

Retrospectiva        24

Gestão de Configuração        27

Metodologia        27

Arquitetura da Integração Contínua e Entrega Contínua        27

Projeto de software        28

Projeto Arquitetural e Arquitetura de Software        28

Plataforma de Implementação e Tecnologias        28

Projeto da Interface com Usuário        29

Projeto da Persistência de Dados        32

Gerência de Qualidade        36

Métricas de qualidade        36

Histórico        36


Gerência de Requisitos

Minimundo 

O LifeBox 2 é um projeto desenvolvido pelos alunos e professores do Ifes-Serra(Clientes), que tem a proposta de melhorar o processo e criar base de conhecimento para estudos relacionados a transporte de órgãos.

O projeto do cliente visa desenvolver uma caixa de transporte de órgãos que atenda as necessidades do Banco de Olhos do Hospital Evangélico e do CNCDO/ES (Central de Notificação, Captação e Distribuição de Órgãos), visando aumentar a qualidade e segurança no processo de transporte de órgãos. O mesmo já está na sua segunda versão e possui uma caixa prototipada no qual hardwares específicos foram adicionados. Nessa fase, o hardware já realiza o monitoramento da temperatura, vibração e localização geográfica (GPS) da caixa durante o transporte de órgãos. Entretanto, os dados obtidos por meio do dispositivo supracitado, estão dispersos e portanto, necessitam de uma aplicação que realize a captura, tratamento,  e especialmente visualização.

Visando a solução do problema em questão, a equipe de desenvolvimento de software, foi incumbida da construção de um sistema web e/ou mobile, para integração, tratamento e  visualização dos dados gerados pelo hardware anexo a caixa de órgãos. O sistema deve prover armazenamento de dados e geração de histórico, acesso às informações de forma intuitiva e prática aos usuários, tanto para acompanhamento em tempo real, quanto para análise futura dos elementos monitorados (temperatura, localização e vibração), bem como, ferramentas para geração de relatórios e acompanhamento de ocorrências com a caixa.

O fluxo do funcionamento ocorrerá da seguinte forma: o gestor dará início a viagem via sistema, a partir deste momento o sistema começará a captar dados da lifebox e então os exibirá relacionando-os à uma viagem no sistema web, onde somente pessoas cadastradas terão acesso. Ao final do trajeto o usuário deverá encerrar a viagem via sistema, neste momento os dados captados serão mantidos em um banco de dados que será usado pelo módulo do sistema responsável por gerar os relatórios, históricos e logs.

Espera-se, ao final do projeto, obter o registro completo das informações obtidas por meio do hardware em desenvolvimento, bem como um aumento na segurança e respectivo incremento na qualidade/saúde do órgão em todo processo de transporte, resultando ainda na possibilidade de análises e estudos futuros que viabilizem o melhoramento contínuo de todo processo.

 

Regras de Negócio e Cenários

RN01. O andamento de todos os transportes em realização deverão estar dispostos num mapa. Exibindo em tempo real, os dados de localização, temperatura e trepidação.

RN02. Os dados de temperatura deverão ser exibidos em forma de gráfico para que se possa acompanhar as leituras realizadas.

RN03. O cadastramento de novos usuários será realizado por usuários com perfil de Administrador, acessando o “Módulo Admin” e em seguida “Usuários” e “Adicionar Usuário”.

No cadastramento do usuário, deve ser informado os seguintes campos:

Campo

Obrigatório?

Observação

Usuário

Sim

Deve ser unico no sistema

Senha

Sim

Considerar regras para a criação e validação da senha

Primeiro Nome

Não

Último Nome

Não

Endereço de email

Sim

Permissões (ativo)

Não

Indica se o usuário está ativo ou  inativo no sistema

Permissões (Membro de Equipe)

Não

Cadastra o usuário em um determinado grupo com determinadas regras de permissões por grupo

Permissões (Status de superusuario)

Não

Indica que este usuário tem todas as permissões sem atribuí-las explicitamente.

Permissões (de usuário)

Não

Permissões específicas, mantenha pressionado o "Ctrl", para selecionar mais de uma opção.

Ultimo Login

Não

Sistemico

Data de Registro

Não

Sistemico

RN04. Cadastramento de Caixas para transporte de Órgãos.

Ao clicar no menu “Cadastros” >> “Caixas”, será exibido a tabela de “Caixas.

O botão “Novo” carrega a tela de “Adicionar Nova Caixa” e o botão “Exportar” cria um arquivo no formato .CSV contendo todos os dados da tabela em questão.

Para alterar um registro, basta clicar no ID do registro correspondente.

Para o cadastramento de dados de uma nova caixa, deverão ser informados os seguintes campos:

Campo

Obrigatório?

Observação

Autorização da Caixa

Sim

Número de identificação que garante que aquela caixa está apta a realizar transporte de órgãos

Cor da Tarja

Sim

Descrição da cor da tarja fixada na caixa

Informações Adicionais

Não

Algum detalhe específico daquela caixa

RN05. Cadastramento de Equipamentos responsáveis pelo monitoramento dos Órgãos.

Ao clicar no menu “Cadastros” >> “Equipamentos”, será exibido a tabela de “Equipamentos”.

O botão “Novo” carrega a tela de “Adicionar Novo Equipamento” e o botão “Exportar” cria um arquivo no formato .CSV contendo todos os dados da tabela em questão.

Para alterar um registro, basta clicar no ID do registro correspondente.

Para o cadastramento de dados de um novo equipamento, deverão ser informados os seguintes campos:

Campo

Obrigatório?

Observação

IMEI do Equipamento

Sim

Numero de identificação de fabrica do hardware

Operadora

Sim

Operadora do serviço de  telefonia

Telefone

Sim

Numero de telefone do SimCard

IMEI SIM Card

Sim

Numero de identificação de fabrica do SimCard

RN06. Cadastramento de Hospitais para iniciar uma viagem de transporte de Órgãos.

Ao clicar no menu “Cadastros” >> “Hospitais”, será exibido a tabela contendo “Hospitais”.

O botão “Novo” carrega a tela de “Adicionar Novo Hospital” e o botão “Exportar” cria um arquivo no formato .CSV contendo todos os dados da tabela em questão.

Para alterar um registro, basta clicar no ID do registro correspondente.

Para o cadastramento de dados dos Hospitais, deverá ser informado os seguintes campos:

Campo

Obrigatório?

Observação

Nome do Hospital

Sim

Nome da Instituição

Telefone

Sim

Telefone do Hospital

Responsável

Sim

Contato responsável

Email

Sim

Email de contato

Cep

Sim

Contém rotina  de consulta sobre o CEP digitado.

Endereço

Sim

Se CEP estiver correto, o preenchimento é automático devendo o usuário completar com o número do imóvel.

Bairro

Sim

Se CEP estiver correto, o preenchimento é automático

Cidade

Sim

Se CEP estiver correto, o preenchimento é automático

UF

Sim

Se CEP estiver correto, o preenchimento é automático

RN07. Cadastramento de Viagens para transporte de Órgãos.

Ao clicar no menu “Cadastros” >> “Viagens”, será exibido a tabela contendo “Viagens”.

O botão “Novo” carrega a tela de “Adicionar Nova Viagem” e o botão “Exportar” cria um arquivo no formato .CSV contendo todos os dados da tabela em questão.

Para alterar um registro, basta clicar no ID do registro correspondente.

Para o cadastramento de dados dos Hospitais, deverá ser informado os seguintes campos:

Campo

Obrigatório?

Observação

Local de Partida

Sim

Hospital onde o transporte se iniciará.

Local de Chegada

Sim

Hospital onde o transporte terminará.

Caixa

Sim

Vinculação de hardware que será utilizado.

Equipamento

Sim

Vinculação da caixa que será utilizada.

Transportado por

Não

Responsável pelo transporte

Contato

Não

Telefone do responsável pelo transporte

Observações

Não

Outras informações pertinentes a viagem

RN08. O sistema deve permitir a visualização individual de dados de uma LifeBox específica.

RN09. O sistema deve gerar relatórios posteriores as viagens

Modelagem

O modelo de comunicação de dados consiste no envio das informações do hardware(Arduino) ao servidor de aplicação, que recebe os dados e persiste no servidor de banco de dados. Dessa forma o sistema exibe o local atual, num mapa interativo, bem como, informações do estado da caixa conforme os dados são recebidos.


Casos de Uso

                                                     

Ação

Inclui

ATORES

Administrador

Gestor

Transportador

Consultar dados da caixa

X

X

Iniciar viagens

Finalizar viagens

X

Cadastrar viagens

X

Consultar todas as caixas

X

Cadastrar caixas

Desabilitar caixas

X

X

Cadastrar usuários

Desabilitar usuários

X

X

Cadastrar equipamentos

Desabilitar equipamentos

X

X

Gerar relatórios

X

Gestão de Projetos

Project Model Canvas

Link: Canvas Online


Backlog de Projeto

TEMA

ESTÓRIA

IMPORTÂNCIA

MOSCOW

ESTIMATIVA

Core

Eu, como responsável pelo transporte do lifebox, gostaria de visualizar os dados da caixa via celular em tempo real para monitorar o transporte e auxiliar na tomada de decisão.

10

C

40

Core

Eu, como gestor, quero visualizar dados da caixa em curso em tempo real para um monitoramento aprimorado.

100

M

20

Core

Eu, como gestor, gostaria de visualizar os trajetos de todas as lifebox em um único mapa para melhor panorama geral

30

M

20

Cadastro/Segurança

Eu, como administrador, gostaria de definir níveis de acesso de outros usuários no sistema

58

M

13

Cadastro

Eu, como gestor, gostaria de iniciar viagens

80

M

8

Cadastro/Segurança

Eu, como administrador, gostaria de cadastrar outros usuários no sistema

60

M

8

Cadastro/Segurança

Eu, como administrador, gostaria de excluir outros usuários do sistema

59

M

8

Cadastro

Eu, como administrador, gostaria de cadastrar caixas no sistema

50

M

8

Cadastro

Eu, como administrador, gostaria de excluir caixas no sistema

49

M

8

Cadastro

Eu, como gestor, gostaria de cadastrar viagens do lifebox

79

M

5

Segurança

Eu, como gestor, gostaria de acessar o sistema via login e senha para melhor segurança e privacidade do sistema

40

M

3

Relatorios

Eu, como gestor, gostaria de visualizar relatórios de viagens já ocorridas para fazer estudos futuros

90

S

2

Relatorios

Eu, como gestor, gostaria de gerar relatórios para impressão com os dados de uma ou mais viagens para melhor controle das informações

70

S

2

Acompanhamento do projeto

Sprint#01 - Scrum Master Márcio

Backlog da Sprint 1:

18 set 2017 - 29 set 2017 - fechado 32 / total 32

Atividades

Pontos

#11 Eu, como gestor, gostaria de acessar o sistema via login e senha para melhor segurança e privacidade do sistema

3

#6 Eu, como administrador, gostaria de cadastrar outros usuarios no sistema

8

#7 Eu, como administrador, gostaria de excluir outros usuarios do sistema

8

#4 Eu, como administrador, gostaria de definir níveis de acesso de outros usuários no sistema

13

Burndown do Projeto:

Burndown do Sprint:

Velocidade: 27 point/sprint

Modificações do Backlog: N/A

Sprint#02 - Scrum Master Wilhas

Backlog da Sprint 2:

02 Out 2017 - 11 Out 2017 - fechado 21.5 / total 21.5

Atividades

Pontos

#10 Eu, como gestor, gostaria de cadastrar viagens do lifebox

5.5

#8 Eu, como administrador, gostaria de cadastrar caixas no sistema

8

#9 Eu, como administrador, gostaria de excluir caixas no sistema

8

Burndown do Projeto:

Burndown do Sprint:

Velocidade: 27 point/sprint

Modificações do Backlog: N/A

Sprint#03 - Scrum Master Rusley

Backlog da Sprint 3:

17 Out 2017 - 27 Out 2017 - fechado 8/ total 8

Atividades

Pontos

#5 Eu, como gestor, gostaria de iniciar viagens

8

Burndown do Projeto:

Burndown do Sprint:

Velocidade: 27 point/sprint

Modificações do Backlog: N/A

Sprint#04 - Scrum Master David

Backlog da Sprint 4:

30 Out 2017 - 10 Nov 2017 - fechado 23/ total 23

Atividades

Pontos

#12 Eu, como gestor, gostaria de visualizar relatórios de viagens já ocorridas para fazer estudos futuros

2

#2 Eu, como gestor, quero visualizar dados da caixa em curso em tempo real para um monitoramento aprimorado.

21

Burndown do Projeto:  

Burndown do Sprint:

 

Velocidade: 23 pontos

Modificações do Backlog: N/A

Sprint#05 - Scrum Master Márcio

Backlog da Sprint 5:

14 Nov 2017 - 24 Nov 2017 - fechado 23/ total 23

Atividades

Pontos

#3 Eu, como gestor, gostaria de visualizar os trajetos de todas as lifebox em um único mapa para melhor panorama geral

21

#13 Eu, como gestor, gostaria de gerar relatórios para impressão com os dados de uma ou mais viagens para melhor controle das informações

2

Burndown do Projeto:

Burndown do Sprint:

Velocidade: 23 point/sprint

Modificações do Backlog:  Sim, existiu a necessidade de criar recurso de monitoramento das caixas independente do vínculo com viagens pré-programadas, além do monitoramento das viagens. Devido a esta nova solicitação cancelamos o módulo mobile, previsto para esta sprint, mas aperfeiçoando o código para uma apresentação responsiva.

Sprint#06 - Scrum Master Wilhas

Backlog da Sprint 6:

27 Nov 2017 - 09 Dez 2017 - fechado 0/ total 0

Atividades

Pontos

#87 Revisar Documentação

3

#86 Ajustar Relatório

5

#102 Ajustar comunicação do arduino com o sistema web

5

#103 Campos Data e hora de inicio e termino de viagem

2

#96 Desenvolvimento dos Testes

5

#107 Erro no datatable

0.5

#108 Esqueceu a sua senha?

0.5

#111 Erro ao importar tabela de viagens

1

Burndown do Projeto:

Burndown do Sprint:

Velocidade:  22 point/sprint

Modificações do Backlog: NA


Retrospectiva

Sprint#1 - Marcio

  1. Definição de escopo;
  2. Mockups.

  1. Criar um Project Model Canvas (PMC);
  2. Trabalhar com definição de requisitos baseados em mockups;

  1. Organizar melhor o cronograma de atividades e a divisão de tarefas.

  1. Pouco conhecimento nas linguagens de programação.

Sprint#2 - Wilhas

  1. Desenvolvimento prático com o Spike

  1. Noção de dificuldade desenvolvimento e planejamento com Planning Poker e o Spike.

  1. Estudar mais os conteúdos técnicos fora da sala de aula.

  1. Alinhamento no conhecimentos da equipe e conhecimento de onde cada um quer chegar.

Sprint#3 - Rusley

  1. Definição de formato das telas (uma tela de Pesquisa e uma de Inclusão/Alteração).

  1. Trabalhar com Formulários no Django .

  1. Melhorar trabalho de colaboração de código no github.

  1. Entendimento no funcionamento do framework Django.

Sprint#4 - David

  1. Refinamos as telas criadas, buscas e modelamos o banco. Melhoramos a interface do sistema.

  1. Trabalhar com filtros do Django, um pouco mais sobre CSS e Github.

  1. Melhorar a tela de relatório, principalmente a geração de PDF.

  1. Um melhor entendimento da ORM do Django. Indefinições por parte da equipe de engenharia (clientes).

Sprint#5 - Márcio

  1. Gerenciamos conflitos por parte dos clientes, envolvemos os padrinhos do projeto.

  1. Novas ferramentas como Import/Export e Auditoria, ambos do Django

  1. Nosso sentimento é que muita coisa pode ser melhorada, esse sentimento cresce à medida que novas ferramentas e tecnologias nos são apresentadas, mas em virtude do pouco tempo disponível, fica difícil colocar em prática todas as melhorias pensadas/analisadas.

  1. O cliente não atende nossas solicitações, deixando o projeto vulnerável e desassistido;

Sprint#6 - Wilhas

  1. Gerenciamento do projeto, layout de relatório.

  1. Gerar relatórios.

  1. Poderia ser feito outras funcionalidades, como um aplicativo para monitoramento offline por parte do transportador. Porém, devido ao tempo do projeto, esses itens foi encaminhado para o Gerente do Projeto.

  1. Tempo hábil para evoluir mais o sistema.

Mais detalhes verificar no Diário de Bordo.


Gestão de Configuração 

Metodologia

Para acompanhamento do projeto as atividades foram organizadas e distribuídas no Taiga.io. Já o armazenamento, controle e versionamento do código-fonte foi gerenciado no GitHub. Como política de versionamento, para cada sprint foi criado uma branch específica de desenvolvimento. Ao final de cada sprint, as alterações realizadas foram publicadas na branch principal(master), sendo o código-fonte dessa branch publicado no servidor de homologação Pythonanywhere, para os respectivos testes e validação do cliente.

Arquitetura da Integração Contínua e Entrega Contínua

No momento, ainda não foram adotadas estratégias de integração contínua e entrega contínua entre o GitHub, que é um repositório de armazenamento e versionamento de código, e Pythonanywhere, que se trata de um servidor de deploy.


Projeto de software

Projeto Arquitetural e Arquitetura de Software  

O projeto está dividido em módulos, possuindo cada um sua responsabilidade no projeto, conforme explicitado abaixo:

Abaixo são detalhadas as responsabilidades de cada módulo:

Plataforma de Implementação e Tecnologias

O projeto foi desenvolvido em Python utilizando o framework Django no Backend. Já para o Frontend foi utilizado o framework Bootstrap. Como banco de dados foi utilizado o MySQL.

Durante o desenvolvimento sentimos a necessidade de uma ferramenta de auditoria, afim de fornecer dados sobre: quem, quando e o que fez no sistema. O Django já possui várias bibliotecas para esta finalidade, adotamos em nosso projeto  o Django-Easy-Audit.

Projeto da Interface com Usuário


Projeto da Persistência de Dados

Todos os Módulos

Link para melhor visualização:  Imagem Ampliada


Módulos criados automaticamente


Módulo Principal

 

O modelo de banco de dados não contemplou todas as melhores práticas de construção e normalização, como por exemplo:

Porém, visto que trata-se de um modelo didático, essas questões não foram ajustadas em prol da resolução do problema geral.

Optou-se em não se criar uma tabela “operadora” visando a praticidade e agilidade do desenvolvimento, porém a compatibilidade do sistema se manteria caso a mesma seja implementada, o que não será feito devido ao curto prazo para entrega do projeto.


Gerência de Qualidade

Métricas de qualidade

Como métrica de qualidade espera-se que o projeto possua 0 (zero) Codesmell’s. Para análise, o projeto faz uso do site SonnarCloud, que, integrado ao Github, realiza uma avaliação do código-fonte sempre que a branch master é atualizada.

Histórico 

Abaixo é exibido o histórico de evolução dos artefatos de software entregues a cada sprint.

Sprint 1

  • Tela de login

Sprint 2

  • Tela de cadastro e pesquisa de Equipamento;
  • Tela de cadastro e pesquisa de Caixa;
  • Tela de cadastro e pesquisa de Hospital;
  • Tela de cadastro e pesquisa de Viagem;

Sprint 3

  • Filtragem nas telas de pesquisa dos cadastros;
  • Adicionada a funcionalidade de mudança de estados na viagem;
  • Adicionada a api de viagens;

Sprint 4

  • Adicionada a opção de exportação e importação de dados;
  • Tela de Monitoramento;

Sprint 5

  • Tela de Sobre e Equipe;
  • Popup de Detalhe do Monitoramento;

Sprint 6

  • Documento de Casos de Uso;
  • Tela de Relatorios;
  • Tela de Auditoria;
  • Aplicativo mobile;
  • Foi removido da entrega do projeto devido às mudanças promovidas pelo cliente e tempo de retorno das dúvidas enviadas;

Sprint 7

  • Documentos de Projeto;
  • Sistema Entregue.


Especialização Técnica - Desenvolvimento Web