Desenvolvimento de Plataforma para Gestão Integrada de … · 2017-08-28 · Arquitetura do...

Faculdade de Engenharia da Universidade do Porto

Desenvolvimento de Integrada de Calçado para Pé D

Pedro Emanuel de Castro Meneses

Mestrado Integrado em Engenharia Electrotécnica e de Com

Orientador: Co-orientador:


Desenvolvimento de Plataforma para Gestão Integrada de Calçado para Pé Diabético

Pedro Emanuel de Castro Meneses

Dissertação realizada no âmbito do Mestrado Integrado em Engenharia Electrotécnica e de Com

Major Automação

Orientador: Américo Lopes de Azevedo (Professor Doutororientador: Paulo Ferreira dos Santos (Doutor)

Junho de 2012


Plataforma para Gestão iabético

Mestrado Integrado em Engenharia Electrotécnica e de Computadores

Américo Lopes de Azevedo (Professor Doutor) Paulo Ferreira dos Santos (Doutor)

ii

© Pedro Meneses, 2012

iii

Resumo

Cada vez mais os avanços tecnológicos têm sido um potencial aliado na evolução dos

métodos de diagnóstico e tratamento no sistema de saúde. A tecnologia só tem utilidade se

for de encontro às necessidades dos seus clientes e resolver problemas que os humanos não

têm capacidade de resolver autonomamente. Esta dissertação centra-se na construção de

uma plataforma WEB com capacidade para combater os problemas de comunicação e

diagnóstico no processo de prescrição de calçado para pé diabético.

O trabalho apresentado neste documento foi desenvolvido no contexto de um projeto

europeu – projeto CORENET (Customer-ORiented and Eco-friendly NETworks for healthy

fashionable goods) que visa essencialmente, desenvolver métodos, ferramentas e tecnologias

para produção de pequenas séries de produtos ou serviços e divide-se em quatro grandes

fases:

• Análise de requisitos funcionais e não funcionais;

• Definição das funcionalidades a implementar;

• Desenvolvimento e implementação da plataforma;

• Testes e validação.

Esta plataforma pretende interligar os vários intervenientes na encomenda de calçado

para pé diabético de forma a reduzir tempos, despesas, erros e aumentar a satisfação dos

clientes deste tipo de calçado.

Esta plataforma deverá ser capaz de oferecer as diferentes funcionalidades necessárias a

cada tipo de utilizador sem que isso implique maior complexidade na forma como operam e

interagem. Facilitar a comunicação durante todo o processo é outro dos grandes objetivos

que se pretendem alcançar com este projeto.

Por se tratar de um trabalho integrado num projeto europeu tornou-se necessária a

produção de documentação que permitisse enquadrar o trabalho que estava a ser

desenvolvido com o projeto. Esta documentação será anexada ao relatório e mencionada

sempre que se justificar.

No fim deste projeto pretende-se que esta plataforma sirva de ponto de partida para

apoiar os médicos e técnicos na prescrição de calçado para pacientes que sofrem de pé

diabético.

v

Abstract

Increasingly, technological advances have been a potential ally in the development of

diagnostic methods and treatment in the health system. The technology is only useful if it to

meets the needs of their customers and solve problems that humans are unable to resolve

independently. This dissertation focuses on building a web platform with the capacity to

tackle the problems of communication in the process of diagnosis and prescription footwear

for diabetic foot.

The work presented herein was developed in the context of a European project - project

CoreNet (Customer-Oriented and Eco-friendly healthy Networks for fashionable goods) which

aims primarily to develop methods, tools and technologies for production of small series of

products or services and it is divide into four phases:

• Analysis of functional and nonfunctional requirements;

• Definition of features to implement;

• Development and implementation of the platform;

• Testing and validation.

This platform aims to link the various stakeholders in order to reduce time, costs, errors

and increase customer satisfaction in this type of footwear.

This platform should be able to offer different functionalities required by each type of

user can do this without more complexity in how they operate and interact. Facilitate a

communication throughout the process is another major goal that it is necessary achieve with

this project.

Because it is an integrated work in a European project has become necessary to produce

documentation that would allow frame the work that was being developed with the project.

This documentation shall be attached to the report and referred to where appropriate.

At the end of this project is intended that this platform will serve as a starting point to

support doctors and technicians in the prescription of footwear for patients suffering from

diabetic foot.

vii

Agradecimentos

Esta secção do relatório reservei aos verdadeiros profissionais que me apoiaram e

orientaram todo este trabalho. De entre os inúmeros profissionais que trabalharam comigo

neste projeto, identifico três que merecem um agradecimento individual:

• Ao professor Américo Azevedo pela orientação do trabalho. Sempre se revelou

muito mais que um orientador. Preocupou-se com muito mais do que uma simples

orientação de um trabalho e nestes seis meses fez-me crescer a nível profissional

possibilitando-me experiências profissionais que não teria a sorte de as ter se não

fosse pelo seu profissionalismo;

• Ao professor João Bastos pela incansável disponibilidade. Apesar de não ter

qualquer tipo de obrigação neste trabalho, foi uma das peças fundamentais na

concretização deste projeto. Foi com a sua ajuda que me integrei no projeto

CoReNet e com quem aprendi muito acerca daquilo que tinha que fazer nas

reuniões em que participei;

• Ao Eng. Paulo Santos pela co-orientação do trabalho e pelas experiências que me

proporcionou. Demonstrou uma constante preocupação com o trabalho que estava

a desenvolver e foi-me oferecendo um conjunto de caminhos que poderia

percorrer. Sem nunca me dizer como fazer, integrou-me numa equipa de trabalho

e proporcionou-me um verdadeiro ambiente empresarial para desenvolver o meu

trabalho.

A estes três profissionais, o meu obrigado pelo profissionalismo que demonstraram e a

incansável ajuda que me dispensaram. Sem dúvida que me fizeram crescer como profissional

possibilitando-me a integração no mundo do trabalho e seguindo de perto as minhas ações.

Pedro Meneses

ix

Índice

Resumo ............................................................................................ iii

Abstract ............................................................................................. v

Agradecimentos .................................................................................. vii

Índice ............................................................................................... ix

Lista de figuras ................................................................................... xi

Lista de tabelas ................................................................................. xiii

Abreviaturas e Símbolos ....................................................................... xiv

Capítulo 1 .......................................................................................... 1

Introdução ......................................................................................................... 1 1.1 - Enquadramento ........................................................................................ 1 1.2 - Projeto CoReNet ....................................................................................... 2 1.3 - Motivação e Objetivos ................................................................................ 3 1.4 - Resultados Esperados ................................................................................. 4 1.5 - Estrutura do Documento .............................................................................. 5

Capítulo 2 .......................................................................................... 7

Caracterização do Problema ................................................................................... 7 2.1 - Relevância Industrial .................................................................................. 7 2.2 - Relevância do Pé diabético .......................................................................... 8 2.3 - Método de Diagnóstico do Pé Diabético ......................................................... 10 2.4 - Objetivos da Plataforma Tecnológica ............................................................ 10

Capítulo 3 ......................................................................................... 13

Especificação da infraestrutura de Informação .......................................................... 13 3.1 - Modelo AS-IS .......................................................................................... 13 3.2 - Requisitos do Processo de Prescrição ............................................................ 15 3.3 - Arquitetura do Sistema ............................................................................. 17 3.4 - Análise e Conceção .................................................................................. 19 3.5 - Casos de Uso da Plataforma ....................................................................... 22

Capítulo 4 ......................................................................................... 27

Desenvolvimento e Implementação da Solução .......................................................... 27 4.1 - Revisão Tecnológica ................................................................................. 27

x

4.2 - Arquitetura da Base de Dados ..................................................................... 29 4.3 - Dispositivo Eletrónico para avaliação da pressão plantar .................................... 30 4.4 - Interface com o Utilizador ......................................................................... 33 4.4.1 - Módulo “Processo” ............................................................................. 34 4.4.2 - Módulo “Upload” ................................................................................ 35 4.4.3 - Módulo “Catálogo” ............................................................................. 37 4.4.4 - Módulo “Características” ...................................................................... 37 4.4.5 - Módulo “Diálogo” ............................................................................... 38 4.4.6 - Módulo “Comunicação” ........................................................................ 40 4.4.7 - Módulo “Administração” ....................................................................... 42 4.5 - Modelo TO-BE ......................................................................................... 42

Capítulo 5 ......................................................................................... 45

Conclusões e Trabalho Futuro ............................................................................... 45 5.1 - Validação da solução ................................................................................ 45 5.2 - Conclusões ............................................................................................ 46 5.3 - Trabalho Futuro ...................................................................................... 47

Anexo A ............................................................................................ 49

Gestão do Projeto ............................................................................................. 49 A.1 - Diagrama de Gantt .................................................................................. 50 A.2 - Tarefas do diagrama de Gantt..................................................................... 51

Anexo B ............................................................................................ 53

Requisitos do Sistema de Informação ...................................................................... 53 B.1 - Entrevista ao Podologista – Hospital de Santo António (25/10/2011) ...................... 53 B.2 - Protótipo em PowerPoint .......................................................................... 55 B.3 - Lista de Requisitos ................................................................................... 58

Anexo C ............................................................................................ 61

Arquitetura do Sistema de Informação .................................................................... 61 C.1 - Modelo Entidade – Associação ..................................................................... 61 C.2 - Modelo Relacional ................................................................................... 62

Anexo D ............................................................................................ 65

Validação da Solução .......................................................................................... 65 D.1 - Apresentação da ICE Conference ................................................................. 65

Referências ....................................................................................... 71

xi

Lista de figuras

Figura 1.1 – Abordagem do CORENET para pequenas séries de roupas e sapatos na área da saúde [Seventh Framework Programme, 2010] .................................................... 3

Figura 2.1 – Arquitetura da Plataforma ................................................................. 11

Figura 3.1 – Fluxograma representativo do processo de prescrição de calçado para pé diabético ................................................................................................ 14

Figura 3.2 – Arquitetura funcional da plataforma de apoio à prescrição de calçado para pé diabético ............................................................................................ 18

Figura 3.3 – Interface Podologista – Sistema ........................................................... 19

Figura 3.4 – Interface Técnico – Sistema ................................................................ 20

Figura 3.5 – Interface Administrador – Sistema ........................................................ 21

Figura 3.6 – Esquematização das funções desempenhadas pelo bloco de processamento ..... 22

Figura 3.7 – Diagrama de casos de uso para a plataforma ........................................... 23

Figura 3.8 – Diagrama do caso de uso “Submeter Processo” ........................................ 24

Figura 3.9 – Diagrama do caso de uso “Carregar Ficheiros” ......................................... 24

Figura 3.10 – Implementação – Caso de Uso ............................................................ 25

Figura 4.1 – Arquitetura da base de dados sobre a forma Entidade-Associação ................. 30

Figura 4.2 – Constituição do sistema WalkinSense .................................................... 31

Figura 4.3 – Instalação do dispositivo e características [Tomorrow, 2012] ....................... 32

Figura 4.4 – Interface que permite analisar a evolução da pressão plantar do pé do paciente................................................................................................. 33

Figura 4.5 – Módulo “Processo” da infraestrutura de informação .................................. 35

Figura 4.6 – Módulo “Upload” da infraestrutura de informação .................................... 35

Figura 4.7 – Sistema de pastas da infraestrutura de informação ................................... 36

Figura 4.8 – Módulo “Catálogo” da infraestrutura de informação .................................. 37

xii

Figura 4.9 – Módulo “Características” da infraestrutura de informação .......................... 38

Figura 4.10 – Módulo “Diálogo” da infraestrutura de informação .................................. 39

Figura 4.11 – Caixa de diálogo para submissão do processo para o fabricante .................. 39

Figura 4.12 – Ficheiro XML enviado para o fabricante com a lista dos processos submetidos ............................................................................................. 40

Figura 4.13 – Ficheiro XML enviado para o fabricante com os dados do processo ............... 41

Figura 4.14 – Módulo “Administração” da infraestrutura de informação ......................... 42

Figura A.1 – Diagrama de Gantt com as macro tarefas ............................................... 50

Figura B.1 – Interface do Podologista onde poderá fazer login ..................................... 56

Figura B.2 – Interface do Podologista onde terá acesso à área de diagnóstico do paciente ... 56

Figura B.3 – Interface do Podologista onde terá acesso à área de diagnóstico do paciente ... 57

xiii

Lista de tabelas

Tabela 1 - Incidência e custo, úlceras e amputações para problemas relacionados com diabetes nos USA [Saleh, 2005] ....................................................................... 9

Tabela A.1 – Tabela com todas as tarefas retiradas do diagrama de Gantt ...................... 51

Tabela B.1 - Lista de requisitos do sistema ............................................................. 58

xiv

Abreviaturas e Símbolos

AJAX Asynchronous JavaScript and XML

BD Base de Dados

CORENET Customer-ORiented and Eco-friendly NETworks for healthy fashionable goods

CSS Cascading style sheets

CSV Comma Separated Values

FEUP Faculdade de Engenharia da Universidade do Porto

HTML HyperText Markup Language

IEEE Institute of Electrical and Electronics Engineers

INESC Instituto de Engenharia de Sistemas e Computadores

ISO International Organization for Standardization

NICE National Institute for Health and Clinical Excellence

PDF Portable Document Format

PHP Hypertext Preprocessor

SQL Structured Query Language

S.I. Sistema de Informação

UE União Europeia

UKTI United Kingdom Trade and Investment

USB Universal Serial Bus

WEB World Wide Web

XML Extensible Markup Language

Capítulo 1

Introdução

Este documento descreve o trabalho desenvolvido no contexto da unidade curricular

“Dissertação” do Mestrado Integrado em Engenharia Eletrotécnica e de Computadores na

Faculdade de Engenharia da Universidade do Porto.

Neste capítulo faz-se o enquadramento do trabalho explicando o contexto em que se

desenvolveu, são apresentados os objetivos do trabalho assim como a motivação que levou ao

seu desenvolvimento e apresenta-se a estrutura deste relatório justificando as opções

tomadas.

1.1 - Enquadramento

Este projeto foi desenvolvido em ambiente empresarial1 no âmbito de um projeto

europeu2 envolvendo diversas instituições de I&D e empresas industriais de diversos países.

O objetivo deste projeto é responder às necessidades e expectativas de um conjunto de

consumidores específicos, tais como obesos, diabéticos e pessoas que necessitem de cuidados

especiais na elaboração da sua roupa e calçado. Atualmente, os consumidores com este tipo

de necessidades especiais são confrontados com uma gama de escolhas muito reduzida

fazendo com que tenham de usar coisas que não gostam em detrimento do seu estado de

saúde. Para possibilitar uma maior escolha aos consumidores e ao mesmo tempo flexibilizar o

processo de encomenda e produção de roupa e calçado com características especiais, é

imperial o uso das novas tecnologias e formas de comunicação que agora estão ao dispor da

sociedade.

Este trabalho centra-se essencialmente na produção de calçado para pé diabético e na

construção de uma plataforma tecnológica que interligue os três intervenientes neste

processo: o paciente, o médico e o técnico da indústria onde será desenvolvido o calçado.

1 Tomorrow Options S.A

2 CoReNet – Customer-Oriented and Eco-Friendly Networks for Healthy Fashionable Goods

2 Introdução

É importante realçar que a evolução do estado de saúde de um paciente com pé diabético

depende fortemente da rapidez e da eficácia com que é tratado. Tendo em conta alguns

dados da Federação Internacional de Diabetes [IDF, 2005], este é um problema grave de

saúde pública onde se tem gasto avultadas quantias de dinheiro em amputações e consultas

que podiam ser evitadas. Para isso, é necessária uma ferramenta com capacidade para uma

rápida e correta troca de informação entre podologistas e técnicos de saúde.

Uma vez que se trata de um projeto com uma abrangência europeia levanta-se um

problema adicional: o processo de encomenda deste tipo de calçado é feito de maneira

diferente entre os vários países (Portugal e Inglaterra, por exemplo). A solução a encontrar

deverá satisfazer ambos os processos.

1.2 - Projeto CoReNet

Como já foi referido anteriormente, os principais objetivos do corenet passam por

atender um conjunto de necessidades de um grupo de cidadãos muito específico, cumprindo

os graus de exigência na qualidade, preço acessível e compatibilidade ambiental.

Particularmente, o corenet irá incidir sobre os obesos, diabéticos e pessoas com

deficiência através de:

• Sapatos personalizados e confortáveis (com redução das costuras, materiais

biológicos, flexíveis e componentes leves, por exemplo);

• Roupas personalizadas e confortáveis (tamanhos especiais, funcionalidades

especiais e bio têxteis para problemas de pele, por exemplo);

Pretende-se que o corenet:

• Obtenha e faça a gestão dos dados do consumidor para conhecer as suas

necessidades;

• Envolva o consumidor na fase de design e configuração do produto;

• Faça a gestão dos fornecedores de forma a planear e distribuir o tempo;

• Desenvolva máquinas de fabrico inovadoras, em particular para impressão digital

e gravação a laser;

• Entregue o produto ao consumidor final;

• Monitorize a qualidade e sustentabilidade dos produtos.

Muitas pequenas séries de mercado estão a emergir principalmente devido às mudanças

na sociedade e às expectativas e necessidades dos consumidores. O projeto corenet vai tratar

especificamente do setor da saúde. É cada vez mais importante satisfazer as necessidades

desse tipo de consumidores, não só a níveis estéticos, mas também em termos de bem-estar,

saúde e funcionalidades especiais dos produtos.

Os objetivos do corenet passam por fechar esta lacuna do mercado atual criando uma

solução sustentável baseada no custo e no design, desenvolvendo produtos personalizados

capazes de satisfazerem os seus clientes, tendo em conta a sua saúde e o seu desejo nos

produtos da moda.

1.3 - Motivação e Objetivos 3

Figura 1.1 – Abordagem do CORENET para pequenas séries de roupas e sapatos na área da

saúde [Seventh Framework Programme, 2010]

1.3 - Motivação e Objetivos

Com a evolução da competição a nível industrial que se tem verificado nos últimos anos,

as empresas têm tido a necessidade de se adaptarem aos novos paradigmas do mercado

global para poderem resistir a uma economia de escala em crescente evolução.

Cada vez mais as grandes empresas apostam na produção em grande escala, fazendo com

que as pequenas empresas desapareçam ou tenham que se adaptar a uma realidade diferente

optando por uma nova estratégia de negócio.

A produção de pequenas séries de produtos complexos e muito personalizados para cada

cliente torna-se uma área de negócio cada vez mais importante, principalmente para as

pequenas e médias empresas (PMEs) que não têm capacidade de produção em massa

[Azevedo et al., 2011].

Este tipo de estratégia revela-se particularmente relevante na produção de bens para a

saúde, onde cada produto tem que ser totalmente adaptado a cada cliente.

Inerente a esta necessidade de adaptação por parte de algumas pequenas empresas,

existe também a necessidade de uma plataforma que permita sincronizar as diferentes fases

do processo de prescrição de calçado para pé diabético. Fazendo uma pequena pesquisa

nesta área, facilmente se conclui que a produção de calçado para pacientes de pé diabético é

bastante diferente da produção de calçado tradicional.

Isto ocorre porque cada sapato tem de ser completamente adaptado ao paciente e em

conformidade com um conjunto de requisitos prescritos pelo podologista. Esta circunstância

4 Introdução

levanta um conjunto de constrangimentos na forma como o fabricante de calçado tem que

lidar com a procura do cliente, como recebe a informação do podologista e como avalia essa

informação. Vários estudos têm revelado alguns problemas críticos na forma como flui o

processo e na forma como o estado do paciente é avaliado.

Neste sentido, é de grande importância desenvolver uma plataforma que facilite a

comunicação e troca de informação entre o podologista e a indústria que faz a produção de

calçado especializado.

Os principais objetivos definidos no contexto do projeto de dissertação foram:

• Identificação e caracterização do problema – procurou-se analisar, descrever e

caracterizar o fluxo de informação que existe no processo tal e qual como é

executado atualmente;

• Desenvolvimento e construção da arquitetura do sistema - conceber uma

solução para o problema recorrendo às tecnologias que melhor se adaptem à

situação em análise;

• Elaboração de um protótipo - Desenvolver uma plataforma web de acordo com a

arquitetura especificada e que cumpra os requisitos do cliente.

Este conjunto de três grandes objetivos, conjuntamente com as restrições temporais

associadas ao projeto permitiram representar as atividades a desenvolver ao longo do período

de duração do projeto utilizando um diagrama de Gantt (Anexo A.1). Esse diagrama

acompanhou todo o projeto e foi atualizado sempre que necessário.

No anexo A.1 encontra-se o diagrama de Gantt com as metas temporais associadas às

macro tarefas do projeto. As tarefas podem ser consultadas no anexo A.2 onde está

representada uma tabela com todos os objetivos juntamento com as suas metas temporais.

Naturalmente, os objetivos descritos anteriormente, foram detalhados e divididos em

pequenos objetivos com metas temporais bem definidas de forma a estruturar o trabalho e

cumprir todos os objetivos em tempo útil.

1.4 - Resultados Esperados

Uma vez que se trata de um trabalho realizado em ambiente empresarial, espera-se

desenvolver uma solução que seja útil para a empresa e que seja responsável por alertar para

a gravidade do problema do processo de prescrição de calçado para pé diabético.

Como se trata de um sistema de engenharia, espera-se completar todas as fases do processo

no desenvolvimento de uma solução. Mais importante que a solução final será abranger todas

as fases do seu desenvolvimento para facilitar e permitir uma futura discussão para

melhoramentos a implementar na solução tecnológica.

Espera-se desenvolver um protótipo com capacidade para interligar todos os

intervenientes do processo e facilitar a comunicação entre eles. Deverá ser um protótipo

totalmente funcional e pronto a ser instalado num servidor para avaliar o seu funcionamento

e o seu desempenho no cumprimento das suas funcionalidades junto dos seus utilizadores.

Erro! A origem da referência não foi encontrada.Erro! A origem da referência não foi

encontrada. 5

1.5 - Estrutura do Documento

O planeamento do trabalho é uma das fases mais importantes num sistema de engenharia.

Neste projeto adotou-se uma abordagem típica na engenharia de sistemas recorrendo aos

referenciais normativos, como por exemplo, a IEEE std 1220-2005.

O relatório foi estruturado da mesma forma que se desenvolveu o trabalho e seguindo os

referenciais normativos referidos anteriormente. Facilmente se identificam quatro grandes

fases do projeto e essas fases dão origem a quatro dos cinco capítulos deste relatório:

• Caracterização do problema – Todos os projetos em engenharia são

desenvolvidos com o intuito de satisfazer uma necessidade de um cliente. É

essencial perceber bem essa necessidade para que o resultado final vá de

encontro à satisfação do cliente. Por isso, uma primeira etapa é perceber e

descrever essa necessidade para que posteriormente se compreendam quais os

atores envolvidos e as diferentes etapas pelas quais o processo deve passar;

• Proposta de solução – Depois de identificar a necessidade do cliente é necessário

compreender o problema, especificar os requisitos para a solução e desenvolver

uma arquitetura que cumpra os objetivos do projeto;

• Desenvolvimento da solução – Esta fase corresponde à parte técnica do trabalho.

Mesmo antes de passar à programação e desenvolvimento da solução é necessário

fazer uma pesquisa sobre as tecnologias disponíveis e escolher as mais adequadas

ao projeto. Escolher e construir a base de dados necessária ao projeto e construir

a plataforma com base nas especificações dos diferentes intervenientes no

processo;

• Integração e validação – Como já se referiu anteriormente, esta plataforma foi

desenvolvida no contexto de um projeto com vários parceiros. Como é natural,

deverá ser capaz de se integrar com outras plataformas e trocarem dados entre

si. Os testes de validação são também uma importante fase do projeto. Não é

suficiente a plataforma trabalhar corretamente, é preciso que vá de encontro às

necessidades do cliente e esteja de acordo com aquilo que especificou.

No primeiro capítulo é feito um enquadramento do projeto e são definidos um conjunto

de objetivos que se esperam alcançar no fim do projeto.

O segundo capítulo deste documento consiste essencialmente na identificação do

problema de forma a entender as necessidades do cliente. Inclui alguns conteúdos associados

à primeira fase do projeto.

O terceiro capítulo resume-se à especificação da infraestrutura de informação. De uma

forma geral pode ser associada ao conjunto da primeira e segunda fase do projeto. Neste

capítulo é feito o levantamento de requisitos e é definida uma arquitetura para a plataforma.

No quarto capítulo descreve-se a forma como a solução foi desenvolvida. Incide

principalmente na quarta fase do projeto descrita anteriormente.

Por fim, no último capítulo, para além de algumas conclusões e perspetivas de trabalho

futuro relativas ao projeto é descrita a forma como foi feita a validação da solução.

Naturalmente, este capítulo integra a última fase do projeto.

6 Introdução

Capítulo 2

Caracterização do Problema

Antes de se desenvolver um projeto de engenharia é importante contextualizar o

problema de forma a entender as necessidades dos clientes. A melhor forma de perceber a

necessidade de um cliente é fazer com que o engenheiro sinta a mesma necessidade. Nesse

sentido, neste capítulo faz-se uma introdução ao problema de forma a contextualizar os

aspetos mais importantes e identificar os principais problemas que o cliente quer ver

resolvidos.

2.1 - Relevância Industrial

A indústria têxtil, não está adequada a lidar com pequenos grupos de consumidores com

características especiais, por isso, deve ser adequada para ter capacidade de responder a

estas necessidades. Uma vez que se trata de um pequeno grupo de consumidores, não faz

sentido usar o mesmo tipo de negócio que se usa atualmente na indústria têxtil, onde são

desenvolvidos produtos a velocidades espantosas e são colocados no mercado em quantidades

gigantescas (produção para stock) esperando que o consumidor compre aquilo que foi

produzido. Para este novo tipo de mercado, a produção tem que ser feita em função da

procura e com produtos totalmente orientados ao cliente, uma vez que cada produto tem

características muito próprias. Reconstruir um novo modelo de produção que seja capaz de

suportar este conjunto de características envolve muita tecnologia e integração de várias

empresas o que significa maior planeamento e coordenação entre os vários atores envolvidos.

Atualmente, no setor têxtil, os fabricantes estão totalmente integrados numa rede de

produção que começa na indústria química com produção de fibras e termina com os produtos

acabados. No setor do calçado, a abordagem é muito semelhante onde as indústrias que

montam os componentes (sapatos e acessórios) estão interligados com fornecedores de

matéria-prima e componentes semiacabados. Os fornecedores de tecnologia estão a ganhar

mais importância na indústria do calçado porque ao lado dos produtores de máquinas e

aplicações de informação e comunicação, novos serviços devem ser prestados às indústrias de

produção.

8 Caracterização do Problema

Desta forma, facilmente se conclui que a estrutura da rede neste tipo de indústrias não se

restringe às indústrias de produção. Estão incluídos também, os fornecedores, as indústrias

prestadoras de serviços (centros de design, logística e os inspetores de qualidade, por

exemplo). Assim sendo, a melhoria da produtividade, flexibilidade e qualidade numa empresa

vai ter influência na competitividade de toda a rede.

Cada organização deve funcionar como um único componente inteligente de um sistema

complexo onde cada unidade colabora em direção às metas e objetivos comuns, começando

com a identificação das características dos produtos que vão de encontro às necessidades dos

consumidores, permitindo que o cliente esteja envolvido no processo de produção tornando-o

mais eficiente e eficaz.

À medida que o setor da indústria têxtil e calçado é globalizado, torna-se evidente a

competitividade entre os diferentes países fazendo com que locais com mão-de-obra mais

barata se tornem nos que representam maior volume de vendas. Isto obrigou a UE a

reestruturar a sua estratégia adicionando mais valor aos seus produtos de forma a atingirem

novos nichos de mercado.

O desempenho global desta indústria tem sido fortemente afetado pela globalização e

pelos países cujas condições de trabalho são menos regularizadas, mas há um grupo de

consumidores que está disposto a comprar não apenas produtos baratos mas que ofereçam

alto desempenho e conforto: Pacientes com problemas de saúde e que precisam de roupas e

calçados especiais. Cada vez mais as empresas precisam de desenvolver estratégias de

inovação baseadas em criatividade, qualidade e diferenciação dos seus produtos. Por isso,

pequenas séries de produtos altamente especializados para um grupo de consumidores com

características muito especiais, representa uma boa oportunidade de negócio. [Magaletti et

al., 2010]

2.2 - Relevância do Pé diabético

O pé diabético é uma doença causada pelos níveis elevados de glicose no sangue

(diabetes). Esses níveis elevados de glicose dificultam a circulação sanguínea resultando num

menor fornecimento de sangue aos pés. Como consequência deste défice de sangue nos pés,

os tecidos nervosos sofrem danos reduzindo a capacidade de sentir dor e a cicatrização das

feridas. Os pacientes de pé diabético não sentem qualquer tipo de dor ou qualquer tipo de

úlcera que se possa estar a formar no pé. Nos casos mais graves, estas lesões podem levar a

amputações [IDF, 2005].

Infelizmente, estes casos não são tão raros como inicialmente se pode pensar e trata-se

de um problema grave de saúde pública. De acordo com a Federação internacional de

Diabetes [IDF, 2005]:

• Em todo o mundo, cerca de 70% das amputações de pernas acontecem a pessoas

com diabetes;

• Algures no mundo, uma perna perde-se a cada trinta segundos devido a diabetes;

• Estima-se que cerca de 85% das amputações que acontecem devido a diabetes

podiam ser evitadas;

• Cerca de 85% das amputações de membros inferiores relacionadas com diabetes

são precedidas de úlceras;

2.2 -Relevância do Pé diabético 9

• A maior parte das úlceras nos pés podem ser prevenidas apenas com cuidados de

saúde adequados;

• Nos países desenvolvidos, uma em cada seis pessoas com diabetes terá uma

úlcera durante a sua vida.

• Nos países desenvolvidos, estima-se que cerca 15% dos recursos de saúde sejam

necessários para tratar os problemas de pé diabético. Este valor ascende aos 40%

quando se trata dos países em desenvolvimento.

Se a estes factos se acrescentar dados relativos a incidências e custos para problemas

relacionados com diabetes nos USA (tabela 1), rapidamente se conclui que afinal o problema

de pé diabético trata-se de um problema de saúde pública e que pode ser combatido

precocemente reduzindo custos e vidas humanas.

Tabela 1 - Incidência e custo, úlceras e amputações para problemas relacionados com diabetes nos USA

[Saleh, 2005]

Incidências e Custos

Número de pacientes diabéticos 12 milhões (5%)

Número de pacientes diabéticos com problemas nos pés

relacionados com a doença 3 milhões

Número de novos casos de diabetes 600 mil/ano

Custo hospitalar do diabético para infeções do pé

diabético $200 milhões/ano

Tempo médio de permanência no hospital 22 semanas

Custo por hospitalização $6.600

Custo por amputação $800-$12.000

Admissão devido a problemas nos pés 20% de todas as admissões de diabéticos

Úlceras e Amputações

Pacientes com média de 3 anos de vida após amputação

de membros inferiores 50%

Redução de amputações devido a cuidados médicos e

educação do paciente 50%

Redução de amputações devido à melhoria do cuidado

com o pé 50%

Amputações de pacientes internados com úlceras

infetadas 80%


2.3 - Método de Diagnóstico do Pé Diabético

Pela secção anterior, facilmente se conclui que as úlceras nos pés deste tipo de pacientes

representam um elevado custo de tratamento e um efeito que pode levar à amputação, nos

casos mais graves. Neste sentido, a prevenção das úlceras representa a forma mais

económica e eficaz no combate a esta doença. Quando são detetadas anomalias, o

tratamento do pé diabético geralmente envolve o uso de calçado apropriado, palmilhas de

proteção, cirurgia e terapia física [Pedeboy et al., 2012].

Atualmente, a maioria das avaliações clínicas dos pacientes com pé diabético baseiam-se

apenas na observação visual e experiência do podologista. Desta forma os problemas só são

detetados quando já são visíveis, como por exemplo a alteração da cor da pele, a formação

de um calo ou até mesmo a existência de uma úlcera, o que muitas vezes é tarde demais. De

acordo com um estudo realizado por Guldemond [Guldemond et al., 2006], a identificação da

elevada pressão plantar através da avaliação clínica é difícil, insuficiente e pode ser

potencialmente prejudicial. Gouldemond vai ainda mais longe ao afirmar que o processo de

triagem clínica usado atualmente tem que ser repensado de forma a incluir uma avaliação

quantitativa da pressão plantar para uma identificação com maior precisão dos locais com

elevada pressão plantar.

A solução para um paciente que sofre de uma má distribuição da pressão plantar passa

pela prescrição de calçado personalizado de forma a redistribuir a pressão pelo pé. No

entanto, a prescrição de um calçado com características inadequadas ao paciente pode

revelar-se um potencial aliado para a formação de novas úlceras. Normalmente, após uma

prescrição, a evolução do pé do paciente é avaliada pelo podologista através de um conjunto

de consultas periódicas. Mas, mais uma vez, esta avaliação baseia-se apenas na observação

visual do pé, o que pode levar a um aumento dos riscos, custos e tempo gasto pelos

podologistas.

2.4 - Objetivos da Plataforma Tecnológica

Para um tratamento mais eficaz dos pacientes de pé diabético é necessário atingir níveis

mais elevados de colaboração entre os prestadores de serviços de saúde e os fabricantes de

calçado através de um novo conjunto de ferramentas, produtos e serviços, principalmente na

área das tecnologias da informação.

Uma melhor interação e comunicação entre estes dois universos (indústria de calçado e

serviços de saúde) traria vantagens para todos os intervenientes:

• Do ponto de vista da indústria do calçado, haveria um maior número de vendas.

Abordando uma estratégia diferente, algumas empresas podem apostar na criação

de valor no produto que vendem e apostar no aspeto exterior dos sapatos, uma

vez que, atualmente, pouco ou nada é investido na área do design. Ao

proporcionar produtos medicamente funcionais com características modernas vão

proporcionar conforto e bem-estar aos seus clientes;

• Do ponto de vista do paciente, veria o seu problema resolvido mais rapidamente,

sem ter que recorrer à amputação e teria um maior número de opções na altura

de escolher o aspeto exterior do seu sapato (atualmente os catálogos oferecem

2.4 -Objetivos da Plataforma Tecnológica 11

um reduzido número de opções) permitindo usar o que gosta mesmo tendo

problemas nos pés;

• Do ponto de vista do podologista ou o técnico de saúde, aumentaria a sua

eficiência reduzindo o tempo de consulta com os pacientes e obteria um menor

número de amputações nos seus pacientes.

A plataforma deve ser capaz de facilitar a interação entre os intervenientes do

processo, permitindo uma rápida conclusão do processo e respetiva instalação do sapato no

paciente. Simultaneamente, facilitando a comunicação entre o podologista e o fabricante

será possível reduzir erros e custos na prescrição do sapato (figura 2.1).

Figura 2.1 – Arquitetura da Plataforma

Um dos parceiros do projeto3 desenvolveu um dispositivo eletrónico4 com capacidade

para adquirir dados qualitativos e quantitativos relativamente à distribuição da pressão

plantar. Este dispositivo representa um componente vital na plataforma que se descreve

neste documento. Através deste dispositivo será possível visualizar informação quantitativa

do estado do paciente e trocar essa informação entre podologistas ou técnicos usando esta

plataforma. Desta forma, será possível avaliar quantitativamente o estado do paciente antes

e depois da instalação dos sapatos e analisar se estão a provocar o resultado esperado ou se

precisam de adaptações. Assim, reduzem-se os riscos de ocorrerem novas úlceras devido a

uma má análise do estado do paciente e simplificam-se as comunicações entre o fabricante e

o podologista ou técnico de saúde.

3 Tomorrow Options S.A

4 WalkinSense

Capítulo 3

Especificação da infraestrutura de Informação

De acordo com os referenciais normativos IEEE std 1220-2005, este capítulo representa a

segunda fase do sistema de engenharia. É uma das fases mais importantes de todo o processo

porque a solução a desenvolver dependerá fortemente da interpretação que é dada aquilo

que o cliente enuncia.

Nesta fase é essencial compreender o processo tal e qual como é executado atualmente e

interpretar aquilo que os vários intervenientes desejam como solução.

A forma como este projeto se desenvolve encaixa perfeitamente num modelo de

desenvolvimento interativo e incremental. Consiste num desenvolvimento incremental com

sete fases: planeamento, requisitos, análise e design, implementação, desenvolvimento,

teste e avaliação. Todas as sete fases são repetidas sequencialmente ao longo do

desenvolvimento do projeto [IEEE std 1220-2005]. Desta forma, é feita uma constante

avaliação e validação do projeto, aproximando a solução daquela que será entregue ao

cliente. Assim, torna possível envolver o cliente ao longo de todo o desenvolvimento do

projeto.

3.1 - Modelo AS-IS

Atualmente, o processo de prescrição de calçado para pé diabético é centralizado na

interação entre o paciente e o podologista (ou outra entidade de saúde semelhante), com

algumas variações entre países e os seus respetivos sistemas de saúde. De uma forma

sumarizada, o processo pode ser descrito pelas seguintes fases:

1. O podologista observa o paciente e decide se precisa de sapatos especiais;

2. Normalmente, o podologista prescreve uma palmilha personalizada para ser inserida

no sapato do paciente. Geralmente esta palmilha é fabricada pelo próprio

podologista ou então por um técnico especializado;

3. O podologista indica um conjunto de fabricantes deste tipo de calçado ao paciente e

ele próprio desloca-se ao fabricante;

14 Especificação da infraestrutura de Informação

4. No fabricante, um técnico especializado faz um conjunto de medições para

determinar os valores de um conjunto de características que se podem alterar num

sapato;

5. É disponibilizado ao paciente um catálogo em papel com sapatos adequados ao seu

estado de saúde, deixando o paciente apenas preocupar-se com o aspeto estético.

6. É dada ordem de produção dos respetivos sapatos;

7. O sapato e a palmilha são enviados para o podologista que testa no seu paciente e vê

se são necessários alguns ajustes. Caso sejam necessárias algumas alterações, os

sapatos são enviados novamente para o fabricante, a não ser que as alterações

sejam passíveis de ser efetuadas pelo próprio podologista;

8. Após a instalação do sapato e da palmilha no pé do paciente, são feitas algumas

consultas periódicas para avaliar a evolução do estado clinico do paciente e fazer

pequenas correções caso sejam necessárias.

Na figura 3.1 pode ver-se o fluxograma que representa o processo de prescrição de

calçado para pé diabético com os respetivos atores associados a cada atividade.

Figura 3.1 – Fluxograma representativo do processo de prescrição de calçado para pé diabético

3.2 -Requisitos do Processo de Prescrição 15

3.2 - Requisitos do Processo de Prescrição

O levantamento de requisitos é a fase mais importante da especificação do S.I.

Existe uma necessidade por parte do consumidor e é essa necessidade que leva a uma

ideia de negócio e potencialmente à construção de um sistema de informação. Esta deve ser

a ideia essencial que deve acompanhar toda a evolução e construção do software: o S.I. é

desenvolvido com o intuito de satisfazer uma necessidade e essa necessidade deve ser

compreendida corretamente para que o sistema de informação cumpra o seu objetivo.

Mais uma vez, o recurso às normas militares revela-se um excelente ponto de partida para

se fazer um correto levantamento dos requisitos, mais concretamente a norma IEEE Std 830-

1998. Esta norma é uma revisão da IEEE Std 830-1993 que recomenda um conjunto de boas

práticas para um correta especificação de requisitos para o desenvolvimento de software de

qualidade capaz de satisfazer a necessidade do cliente.

Segundo esta mesma norma existem cinco questões essenciais que um correto

levantamento de requisitos deve abranger [IEEE std 830-1993]:

a) Funcionalidade: o que é suposto o software fazer?

b) Interfaces externas: Como é que o software interage com as pessoas, com outro

software ou com hardware?

c) Desempenho: Qual a velocidade, disponibilidade, tempo de resposta, etc?

d) Atributos: Existem aspetos importante a ter em conta relacionados com a

manutenção, segurança, conectividade, etc?

e) Restrições de design impostas na implementação: Existem restrições a nível da

linguagem usada no desenvolvimento, políticas de integridade de bases de dados,

ambientes operacionais, etc?

Como facilmente se conclui pelos tópicos anteriores, o levantamento de requisitos

envolve muitos mais intervenientes do que simplesmente o cliente. Muitas vezes, a pessoa

que requer o sistema de informação não é quem o vai utilizar, logo, tem uma determinada

visão sobre aquilo que quer. Outra visão completamente diferente terá quem o vai utilizar

todos os dias para fazer o trabalho, e ainda outra visão diferente terá o gestor que quer

analisar o desempenho do processo ao longo do tempo.

Para diferentes intervenientes devem adotar-se diferentes abordagens no levantamento

de requisitos.

No caso deste projeto em concreto, alguns requisitos resultam da própria natureza do

projeto e por envolver diferentes países e consequentemente diferentes abordagens na

prescrição de sapatos para pé diabético. Outros requisitos são impostos pela própria empresa

onde o software se desenvolve, uma vez que existe a necessidade de interagir com hardware

já em comercialização. E finalmente, os utilizadores do sistema, como por exemplo os

técnicos e médicos podologistas, identificam um conjunto de funcionalidades que a solução

deve ter para ir de encontro às suas necessidades.

No que se refere a este último conjunto de atores, o método utilizado consiste num

conjunto de perguntas pré-desenvolvidas (podem ser consultadas no Anexo B.1) com o intuito

de responder às questões acima apresentadas e que vão de encontro às recomendações feitas

pela norma. Para completar essa abordagem, foi elaborado um pequeno protótipo (incluído

no Anexo B.2) em PowerPoint com o objetivo de confrontar os podologistas e técnicos com


uma primeira abordagem ao problema e perceber o que mudariam nesse protótipo para que

seja útil e vá de encontro ao que pretendem.

Esse primeiro protótipo serviu ainda para abordar a empresa sobre as restrições impostas

pelo hardware.

De forma a organizar e facilitar uma posterior avaliação dos requisitos e que também

servirá para avaliar e validar o desempenho da plataforma web, deve ter-se em conta um

conjunto de características relevantes. Um documento de especificação de requisitos para

um sistema de informação deve ser [IEEE std 830-1993]:

a) Correto: Cada requisito deve especificar apenas uma funcionalidade;

b) Não ambíguo: Cada requisito deve ter apenas uma interpretação;

c) Completo: Deve envolver todas as cinco questões acima mencionadas;

d) Consistente: Um requisito não deve entrar em conflito com outro requisito;

e) Ordenado por grau de prioridade: Os requisitos devem ter uma característica

que defina o grau de prioridade no que diz respeito à validação desse requisito:

i. Essencial: Não é aceitável que este requisito não seja satisfeito;

ii. Condicional: São requisitos que melhoram a aplicação mas não são

considerados essenciais;

iii. Opcional: São requisitos que podem não ser verificados. Um conjunto de

funcionalidades extra e que não são absolutamente necessárias mas que

poderiam ser interessantes do ponto de vista funcional.

f) Verificável: Deve ser possível verificar no software se existe alguma

funcionalidade que cumpra o requisito especificado. Cada requisito deve incluir

um processo que sirva para verificar se esse requisito é ou não cumprido;

g) Modificável: Deve ser possível adicionar, eliminar ou modificar qualquer requisito

em qualquer momento, sem que para isso seja necessário reescrever o documento

na íntegra;

Com base em todas estas recomendações retiradas da norma, foi construído um

documento com a identificação dos requisitos e devidamente classificados. No anexo B.3

encontra-se esse documento na íntegra.

Com base nesse documento é possível identificar cinco requisitos que se podem denominar

por requisitos core para o sistema:

1. O sistema deve manter a confidencialidade dos dados dos pacientes: Este foi o

requisito principal imposto pela empresa onde se desenvolveu a solução. É

absolutamente crítico que os dados dos pacientes sejam completamente

desacoplados do processo mas ao mesmo tempo que seja possível mapear os

processos nos pacientes à espera do calçado ortopédico;

2. Para cada processo, a plataforma deve permitir a troca de mensagens entre

utilizadores: Cumprir este requisito representa atingir um dos objetivos principais

da plataforma (facilitar a comunicação entre os intervenientes);

3. O sistema deve integrar uma ferramenta java3D5: Esta ferramenta que se

pretende integrar representa uma forma quantitativa de analisar o estado de saúde

do paciente. Logo, cumprir este requisito representa um importante avanço nos

métodos de diagnóstico da patologia de pé diabético;

5 Esta ferramenta consiste num software aplicativo que é executado no contexto de um web browser. Foi desenvolvida pela Tomorrow Options S.A com o intuito de reproduzir os ficheiros exportados do software do WalkinSense

3.3 -Arquitetura do Sistema 17

4. Para cada processo, a plataforma deve permitir a consulta de catálogos dos

fabricantes registando a referência do produto: Este requisito tem por objetivo

oferecer mais modelos de sapatos aos pacientes através da integração de vários

fabricantes, aumentando a concorrência entre eles;

5. O sistema deve permitir fazer Upload de ficheiros: Este requisito tem por objetivo

oferecer a possibilidade aos utilizadores de trocarem ficheiros entre eles de forma a

complementarem a informação de cada processo. Visa essencialmente reduzir os

erros no produto final através de uma maior e mais fácil troca de informação entre

utilizadores responsáveis pelo processo.

Cumprir estes requisitos significa atingir os objetivos definidos para a plataforma. Mais do

que requisitos com prioridade máxima, estes são os requisitos que definem a identidade da

plataforma e a forma como combatem os problemas que existem atualmente no processo de

prescrição de calçado para pé diabético.

Foram ainda identificadas três questões críticas que devem ser exploradas no

desenvolvimento do sistema de informação [Santos, 2012]

• A maioria dos médicos queixam-se que as plataformas para preencher dados não

são fáceis de usar;

• O tempo que o paciente espera desde a prescrição do calçado até o receber com

as características desejadas é crítico, uma vez que os pacientes de alto risco

desenvolvem úlceras frequentemente;

• O aspeto estético dos sapatos é muito importante para se obter adesão do

paciente.

3.3 - Arquitetura do Sistema

A especificação de um sistema de informação deve apoiar-se numa análise cuidada dos

requisitos e do respetivo mapeamento em funcionalidades que a plataforma deve suportar.

Esta análise funcional caracteriza-se por uma descrição detalhado do sistema e do que deve

ser capaz de fazer para estar de acordo com as especificações dos vários atores envolvidos.

Através da arquitetura funcional é possível descrever a forma como um sistema complexo se

divide em pequenos subsistemas e a forma como se interligam. Na figura 3.2 pode observar-

se a arquitetura funcional para a plataforma de suporte à prescrição de calçado para pé

diabético.


Podologista

Técnico

WalkinSense

Visualização

Armazenamento Processamento Comunicações

Fabricante

Informação

Instruções

Informação

Instruções/Dados

Informação

Instruções/Dados

Dados

Dados Dados

Dados

Comandos

Figura 3.2 – Arquitetura funcional da plataforma de apoio à prescrição de calçado para pé diabético

De um modo geral pode dizer-se que o sistema interliga três grandes atores: O técnico

especializado ligado à indústria do calçado ortopédico, o podologista e mais indiretamente o

paciente.

A interface do sistema de informação é apresentada a utilizadores registados e com

permissões diferentes de acordo com os privilégios de cada tipo de utilizador.

Na figura 3.2 estão representados oito grandes blocos, sendo que cinco deles representam

subsistemas e os outros três representam os diferentes utilizadores do sistema (podologista,

fabricante e técnico).

O bloco das comunicações representa o protocolo que terá que ser desenvolvido para

trocar informação com os fabricantes. Apesar de haver comunicações em todo o sistema e

entre os vários blocos representados na figura 3.2, apenas neste bloco existirá um protocolo

com capacidade para trocar informação com outras aplicações exteriores.

O bloco de armazenamento corresponde a uma base de dados onde será armazenada a

informação relativa a toda a infraestrutura de informação. Esta base de dados será acedida

através de uma linguagem de programação que será escolhida de acordo com as

especificações e de forma a cumprir os requisitos do utilizador.

O bloco de processamento representa um conjunto de páginas desenvolvidas numa

linguagem de programação web com capacidade de transformar a linguagem humana em

linguagem máquina. Todas as ações dos utilizadores passarão por este bloco, onde serão

processadas e interpretadas e só depois de validadas passarão para os restantes blocos. Esta é

uma das formas encontradas para se reduzirem os erros no processo de prescrição de calçado

para pé diabético. Assim, será sempre possível avisar o utilizador que aquilo que pretende

fazer é ou não correto.

O bloco de visualização corresponde à representação visual dos dados guardados no bloco

de armazenamento. Será também desenvolvido numa linguagem de programação apropriada

e tem como única função apresentar e recolher os dados e ações do utilizador.

O bloco do WalkinSense corresponde a um dispositivo eletrónico com capacidade de

adquirir e apresentar informação quantitativa relativa à pressão plantar.

3.4 -Análise e Conceção 19

De uma forma resumida pode considerar-se que a plataforma recolhe vários tipos de

informação de cada tipo de utilizador (ator), processa essa informação, armazena-a numa

base de dados e apresenta-a de forma estruturada aos respetivos utilizadores.

3.4 - Análise e Conceção

Depois do levantamento de requisitos e de uma definição da arquitetura do sistema é

necessário descrever o que o sistema deve ser capaz de fazer em termos de funcionalidades.

Ou seja, mapear os requisitos especificados pelos utilizadores em funcionalidades a ser

implementadas nos diferentes blocos da arquitetura do sistema.

A figura 3.3 representa o mapeamento das funcionalidades identificadas nos requisitos,

relativas aos utilizadores do tipo “Podologista”.

Figura 3.3 – Interface Podologista – Sistema

Depois de se validar no sistema, o podologista terá acesso à lista de processos. Aqui

poderá encontrar o processo desejado selecionando um conjunto de filtros que estarão à sua

disposição de forma a aumentar a eficiência da pesquisa. Em vez de selecionar poderá criar

um novo processo se assim desejar. Ao escolher um processo, e no caso de ser ele o autor,

poderá editar os dados do processo ou elimina-lo. Se não for o autor, apenas poderá consultar

ou adicionar novas informações ao processo. Neste caso, é possível aceder a uma área de

diálogo para trocar informações com outros utilizadores e aceder a uma área de upload de

documentos que permitem complementar os dados do processo.

No caso de o utilizador ser um “Técnico”, a interface disponível encontra-se

representada na figura 3.4.


Figura 3.4 – Interface Técnico – Sistema

A interface que é apresentada a um utilizador do tipo “Técnico” não difere em muito da

interface de um podologista. As duas diferenças mais relevantes são:

• Um técnico não pode criar um processo;

• Um técnico pode submeter um processo para produção;

• No caso de se tratar de um utilizador do tipo “Administrador”, a interface que lhe

é apresentada segue as orientações da figura 3.5.

3.4 -Análise e Conceção 21

Login no S.I

Aceder aos

Processos

Escolher

Processo

Criar Processo

Editar Processo

Eliminar

Processo

Consultar

Processo

Alterar Dados

do Processo

Fazer Upload de

Ficheiros para o

Processo

Aceder a uma área de diálogo

para troca de informação entre

podologistas ou técnicos

Consultar

Catálogos /

Escolher Modelo

Submeter para

Produção

Administração

Ver Utilizador

Eliminar

Utilizador

Adicionar

Utilizador

Editar

Utilizador

Figura 3.5 – Interface Administrador – Sistema

Um administrador tem todas as funcionalidades dos outros utilizadores às quais se

acrescem as funcionalidades administrativas. Nessa área, um administrador poderá editar,

eliminar e adicionar novos utilizadores. É importante referir, que haverá um administrador

que nunca poderá ser eliminado.

Recorrendo mais uma vez à arquitetura do sistema, o bloco de processamento também

pode ser dividido e simplificado em subsistemas mais simples, como se pode ver pela figura

3.6.


Figura 3.6 – Esquematização das funções desempenhadas pelo bloco de processamento

Como já foi referido anteriormente, este bloco apenas processa a informação que recebe

do utilizador e converte em dados compatíveis para armazenamento na base de dados. Este

bloco funciona também na ordem inversa, ou seja, recebe os dados da base de dados e

disponibiliza-os na plataforma web.

3.5 - Casos de Uso da Plataforma

Com o objetivo de mapear os requisitos em funcionalidades e fazer uma melhor

interpretação dos requisitos, recorreu-se a diagramas de casos de uso. Na figura 3.7

encontra-se representado o diagrama de casos de uso para a plataforma de suporte ao

processo de prescrição de calçado para pé diabético. Como é natural e dado o elevado

número de funcionalidades da plataforma, estão apenas representados os casos de uso

essenciais e que representam as funcionalidades “core” da plataforma.

Recebe os dados do sistema

de informação provenientes

das ações dos utilizadores

Processa os dados de forma

a serem compatíveis com a

arquitetura da BD

Armazena os dados na BD

3.5 -Casos de Uso da Plataforma 23

Figura 3.7 – Diagrama de casos de uso para a plataforma

Com este diagrama evidenciam-se as responsabilidades de cada utilizador e as suas

permissões no sistema. Note-se que para qualquer ação é necessário autenticação no sistema,

ou seja, não é possível utilizar a plataforma sem que se possua as credenciais de acesso. São

elas que atribuem as diferentes permissões a cada utilizador.

É importante referir que tal como está representado no diagrama anterior, não é possível

fazer qualquer ação relacionada com um processo sem que antes se tenha escolhido um

processo. Não faria sentido adicionar ou trocar informação entre utilizadores se não estivesse

tudo associado a um determinado processo. Desta forma está assegurado que toda a

informação armazenada na base de dados está associada a um processo em concreto.

No caso de o utilizador ser do tipo “Administrador”, este terá acesso a todas as

funcionalidades ao dispor dos outros utilizadores às quais se acrescentam as funcionalidades

inerentes à gestão de utilizadores.

Os casos de uso “Submeter Processo” e “Carregar Ficheiros” são suficientemente

complexos para se justificar um maior detalhe na sua especificação. Mais uma vez,

recorrendo a diagramas de casos de uso, pode representar-se com maior detalhe estas duas

funcionalidades. Na figura 3.8 encontra-se representado o caso de uso “Submeter Processo”.


Figura 3.8 – Diagrama do caso de uso “Submeter Processo”

Este caso de uso é o responsável por fazer a comunicação entre a plataforma e o

fabricante. É através desta funcionalidade que a informação de cada processo é enviada para

a indústria do calçado ortopédico. O elemento central deste caso de uso é uma página XML

gerada de forma dinâmica e que permite ao fabricante aceder a toda a informação dos

processos submetidos para produção. O fabricante só terá acesso aos processos que estão

prontos para a produção, ou seja, os processos são filtrados para que só sejam apresentados

aqueles que contêm toda a informação necessária para a produção.

Figura 3.9 – Diagrama do caso de uso “Carregar Ficheiros”

A figura 3.9 representa o caso de uso “Carregar Ficheiros”. O utilizador só tem que

escolher o processo e o respetivo ficheiro que quer adicionar ao processo. A infraestrutura de

informação automaticamente faz a verificação da extensão do ficheiro (verifica se o tipo de

ficheiro é permitido) e carrega o ficheiro no respetivo processo. Mais à frente neste relatório,

o processo de “upload” é explicado em maior detalhe, assim como a respetiva gestão dos

ficheiros nos processos.

De uma forma geral, a plataforma pode ser resumida pela figura 3.10

3.5 -Casos de Uso da Plataforma 25

Figura 3.10 – Implementação – Caso de Uso

A figura anterior evidencia mais uma vez, que a plataforma é a principal ferramenta que

irá fechar o processo de prescrição de calçado para pé diabético. Será a responsável por criar

um elo de ligação entre os fabricantes e os técnicos ou podologistas que prescrevem o

calçado e facilitar a troca de informação entre eles.

Capítulo 4

Desenvolvimento e Implementação da Solução

Ao longo deste capítulo pretende-se descrever a forma como foi desenvolvida e

implementada a plataforma de apoio ao processo de prescrição de calçado para pé diabético.

Nesta fase do projeto pretende-se implementar por ordem de prioridade todas as

funcionalidades determinadas pelos requisitos. Não menos importante do que implementar

essas funcionalidades é escolher as tecnologias apropriadas para as implementar.

4.1 - Revisão Tecnológica

São inúmeras as linguagens de programação ao dispor do programador. O maior desafio é

saber quais utilizar. Para este projeto, optou-se por uma solução hibrida que envolve um

conjunto de linguagens diferentes de forma a tornar mais versátil a integração com outras

aplicações provenientes de outras empresas envolvidas no projeto.

As linguagens de programação escolhidas para o desenvolvimento da plataforma são:

• HTML: HyperText Markup Language é uma linguagem baseada em marcas

através das quais é formatado o conteúdo das páginas. Basicamente, o HTML

dispõe os comandos formatação usuais que se encontram nos processadores

de texto [Harris, 2011];

• CSS: Cascading style sheets é uma folha de estilo que define um conjunto de

regras que determinam como é que o browser6 apresenta os documentos

HTML. Desta forma é possível separar o conteúdo do documento do estilo da

apresentação. De entre as vantagens destacam-se:

6 Programa com capacidade para interagir com páginas virtuais que estejam hospedadas num servidor WEB.

28 Desenvolvimento e Implementação da Solução

a. As folhas de estilo podem ser definidas em ficheiros externo

os ficheiros HTML, o que permite utilizar as mesmas

definições de estilo em múltiplas páginas;

b. Desta forma, é possível mudar completamente o estilo de

uma aplicação atuando sobre um único ficheiro [Harris,

2011].

• PHP: Hypertext Preprocessor é uma linguagem interpretada livre e é utilizada

para gerar conteúdo dinâmico na WEB.

Numa primeira fase da WEB, não era possível efetuar qualquer tipo de processamento,

como por exemplo aceder a bases de dados, através de HTML, existindo apenas ficheiros

estáticos armazenados em servidores. Usando PHP é permitido recolher dados introduzidos

pelo utilizador, processar esses dado e gerar respostas que, por sua vez são enviadas aos

utilizadores [Harris, 2011].

• JavaScript: é uma linguagem de script dinâmica e baseada em objetos. A

grande vantagem em utilizar esta linguagem para integrar com HTML reside

no facto do código JavaScript correr localmente no navegador do utilizador e

não num servidor, fazendo com que o browser responda mais rapidamente a

ações do utilizador [Cecco, 2011];

• jQuery: é uma biblioteca JavaScript cross-browser7 desenvolvida para

simplificar os scripts8 que interagem com o HTML. Neste projeto, esta

biblioteca é usada principalmente para melhorar o aspeto gráfico da

aplicação através de animações e manipulação de eventos [Cecco, 2011];

• Smarty: é um sistema de templates WEB, escrito em PHP e que visa separar a

apresentação da parte que gera o conteúdo dinâmico. Assim, deixa de ser

necessário programar em HTML, sendo apenas necessário passar a informação

para o smarty que automaticamente gera as páginas em HTML [Cecco, 2011];

• AJAX: Asynchronous Javascript and XML é o uso metodológico de tecnologias

JavaScript e XML, providas por browsers, para tornar as páginas WEB mais

interativas com o utilizador, utilizando-se solicitações assíncronas de

informação. Isto permite ligar ao servidor para aceder a uma pequena parte

da informação sem ser preciso recarregar toda a página novamente [Harris,

2011].

No que diz respeito ao armazenamento dos dados, estão disponíveis para este projeto

dois tipos de bases de dados:

• MySQL: É um sistema de gestão de base de dados que utiliza a linguagem

SQL como interface. Atualmente é um dos mais populares com mais de 10

milhões de instalações no mundo, podendo destacar-se a Alcatel - Lucent,

Facebbok e a SonicWall. As funcionalidades que mais a caracteriza são

[MySQL, 2012];

a) Portabilidade (suporta praticamente qualquer plataforma

atual);

7 Habilidade de suportar múltiplos navegadores

8 Programa executado no interior de outros programas

4.1 - Revisão Tecnológica 29

b) Compatibilidade com diversas linguagens de programação,

entre as quais, PHP;

c) Suporta controlo transacional;

d) Suporta Triggers.

• PostgreSQL: É um sistema de gestão de base de dados que utiliza a

linguagem SQL como interface. As características mais importantes são:

a) Consultas complexas;

b) Integridade transacional;

c) Controlo de concorrência multi-versão;

d) Indexação por texto;

e) Suporte ao modelo híbrido objeto-relacional.

Dada a natureza do projeto e os conhecimentos previamente adquiridos relacionados com

bases de dados, PostgreSQL será a escolha para suportar a aplicação a desenvolver para o

projeto.

Nesse sentido, será necessário a utilização de uma aplicação WEB, escrita em PHP, capaz

de gerir uma base de dados do tipo PostgreSQL: PHPPgAdmin. Esta aplicação evidencia as

seguintes características:

• Gere múltiplos servidores;

• Suporta várias versões de PostgreSQL;

• Permite uma fácil manipulação dos dados;

• Exporta as tabelas de dados em diferentes formatos, entre eles, SQL

• Importa scripts SQL;

• Suporta cerca de vinte e sete linguagens de programação.

4.2 - Arquitetura da Base de Dados

A base de dados representa um dos componentes de maior importância no sistema de

informação. Deve ser corretamente projetado para se combaterem futuros pontos de falha.

Para se projetar a arquitetura de uma base de dados existem um conjunto de metodologias e

modelos que permitem visualizar graficamente o comportamento e o armazenamento dos

dados.

Neste projeto modelou-se a base de dados na forma Entidade-Associação, quer na forma

textual quer na forma gráfica e modelou-se também sobre a forma de modelo relacional que

representa um modelo textual muito fiel áquilo que é o código para a criação da base de

dados. A escolha destes modelos recai sobre a necessidade de visualizar graficamente aquilo

que é a base de dados e perceber a localização dos dados de todos os processos.

Naturalmente, e porque se trata de um processo de engenharia, a arquitetura da base de

dados que se representa na figura 4.1, não foi desenhada na primeira tentativa. Tratou-se de

um processo iterativo e de um longo processo de aperfeiçoamento ao longo do projeto.


Figura 4.1 – Arquitetura da base de dados sobre a forma Entidade-Associação

Como se pode observar pela figura, trata-se de uma arquitetura de alguma complexidade

mas que em local algum existe a identidade do paciente. Apenas é registado o processo no

sistema. Esse processo tem como identificação um nome ou um conjunto de números

escolhidos pelo podologista. A associação entre esse código do processo e o paciente fica ao

encargo do paciente. No entanto, e para o caso dessa identificação se perder, o processo fica

registado no sistema com o nome do seu autor e data completa da sua criação. Assim, será

fácil identificar e associar o processo ao paciente através da hora da sua consulta e da data

registada no sistema. A entidade “Process” é sem dúvida a entidade central de todo o

sistema e que vai de encontro áquilo que era o esperado, gerir pelo processo e não por um

conjunto de atividades.

Todas as entidades do sistema de informação estão associadas ao processo. Desta forma,

todas as ações que são executadas através da plataforma terão sempre que ser associadas a

um determinado processo.

Os outros dois modelos, modelo entidade-associação na forma textual e o modelo

relacional podem ser consultados no anexo C.4 e C.5 respetivamente.

4.3 - Dispositivo Eletrónico para avaliação da pressão plantar

A infraestrutura de informação que suporta a prescrição de calçado para pé diabético é

baseada num dispositivo de diagnóstico médico denominado WalkinSense produzido pela

4.3 - Dispositivo Eletrónico para avaliação da pressão plantar 31

empresa Portuguesa de base tecnológica Tomorrow Options SA [Tomorow, 2012] e integrado

com os restantes módulos e serviços do CoReNet.

O WalkinSense é o primeiro sistema concebido para monitorizar a atividade física,

combinada com a avaliação da pressão plantar e análise dos parâmetros da marcha. O

WalkinSense destina-se a ser utilizado por podologistas ou técnicos de saúde para adquirir

dados quantitativos e qualitativos que permitam a avaliação de parâmetros relacionados com

a atividade dos membros inferiores. Através de protocolos de comunicação Bluetooth (sem

fio) ou USB (cabo), todas as informações podem ser transferidas para um computador

possibilitando a análise dos dados através da aplicação do WalkinSense [Santos, 2012].

Este dispositivo foi desenvolvido com o objetivo de facilitar uma avaliação da pressão

plantar juntamente com a atividade dos membros inferiores de forma a detetar o efeito do

calçado no pé dos pacientes durante uma caminhada ou uma corrida. Como já foi referido

anteriormente na secção 2.3 deste relatório, é essencial desenvolver uma forma simples e

rápida de avaliar quantitativamente a evolução do estado de saúde do paciente. Este

dispositivo eletrónico visa essencialmente combater essa lacuna do atual processo.

Para o projeto, este dispositivo representa uma importante ferramenta com capacidade

de reduzir os erros que são cometidos atualmente na interação entre os diferentes

intervenientes no processo de prescrição de calçado para pé diabético, uma vez que fornece

um rápido feedback de efeito dinâmico de acordo com as condições particulares de cada

paciente [Pedeboy et al., 2012].

O sistema é composto por dois elementos: Software e o dispositivo que adquire os dados e

posteriormente os envia para o software através de um protocolo de comunicações

apropriado (figura 4.2).

Figura 4.2 – Constituição do sistema WalkinSense

32

O hardware do WalkinSense consiste num dispositivo e

bateria de lítio e conectado a uma rede de oito

paciente através de uma cinta de velcro à volta do tornozelo, o que associado ao seu

reduzido peso (68 gramas) torna a sua utilização

(figura 4.3).

Os oito sensores são distribuídos de acordo com o desejado pelo utilizador e podem ser

colocados numa palmilha ou diretamente sobre a meia. A distribuição da pressão é

determinada através do pico da pressão plantar e de integrais de tempo nesses pontos.

As variáveis de atividade monitorados incluem velocidade de caminhada, cadência (passos

/ minuto), distância, amplitude e comprimento do passo. Todos estes fatores influenciam a

pressão plantar e os padrões de carga, portanto, medindo

esses fatores e minimizar a pressão nos locais

Figura 4.3 – Instalação do dispositivo e características [

O software permite fazer uma gestão dos pacientes com um histórico de consultas e dos

respetivos resultados dos testes. Este

resultados dos testes através de uma representação gráfica e dinâmica d

pelo dispositivo.

Os resultados dos testes podem ser analisados individualmente ou utilizados para uma

posterior comparação com outro resultado (por exemplo, depois de uma intervenção médica

ou uso de calçado adequado).É ainda permitid

quer comparar, permitindo uma eficiente comparação entre a evolução da pressão em áreas

muito específicas.

É possível exportar os dados do WalkinSense de três formas diferentes:

1. Pode ser criado um ficheiro gr

notas, promovendo uma abordagem multidisciplinar para tratamento,

como mencionado pelas

2. Pode ser criado um arquivo PDF, com dados estáticos mas que permitem

uma fácil partilha d

diferentes enti


do WalkinSense consiste num dispositivo eletrónico alimentado por uma

ítio e conectado a uma rede de oito sensores discretos. O dispositivo é seguro ao


reduzido peso (68 gramas) torna a sua utilização viável durante a prática de exercício físico

sensores são distribuídos de acordo com o desejado pelo utilizador e podem ser


da pressão plantar e de integrais de tempo nesses pontos.

de atividade monitorados incluem velocidade de caminhada, cadência (passos


e os padrões de carga, portanto, medindo-os os médicos podem ter em conta

esses fatores e minimizar a pressão nos locais críticos.

Instalação do dispositivo e características [Tomorrow, 2012

permite fazer uma gestão dos pacientes com um histórico de consultas e dos

respetivos resultados dos testes. Este software permite uma fácil e rápida interpretação dos

resultados dos testes através de uma representação gráfica e dinâmica dos dados recolhidos



ou uso de calçado adequado).É ainda permitido ao utilizador escolher quais os sensores que


É possível exportar os dados do WalkinSense de três formas diferentes:

Pode ser criado um ficheiro gráfico onde é permitido inserir comentários e


como mencionado pelas diretrizes do NICE (figura 4.4);

Pode ser criado um arquivo PDF, com dados estáticos mas que permitem

uma fácil partilha de dados entre diferentes sistemas de saúde ou

diferentes entidades;

• Fácil de operar e

instalar/desinstalar (pesa 70

gramas)

• Bateria recarregável com duração

média de 5-7 dias

• Cabo com oito sensores discretos

de pressão (2cm2 de área ativa)

• Reúne, processa, armazena e

transmite informação (USB ou

Bluetooth)


letrónico alimentado por uma

sensores discretos. O dispositivo é seguro ao


viável durante a prática de exercício físico

sensores são distribuídos de acordo com o desejado pelo utilizador e podem ser


da pressão plantar e de integrais de tempo nesses pontos.

de atividade monitorados incluem velocidade de caminhada, cadência (passos


os os médicos podem ter em conta

2012]

permite fazer uma gestão dos pacientes com um histórico de consultas e dos

permite uma fácil e rápida interpretação dos

os dados recolhidos



o ao utilizador escolher quais os sensores que


áfico onde é permitido inserir comentários e


Pode ser criado um arquivo PDF, com dados estáticos mas que permitem

e dados entre diferentes sistemas de saúde ou

Fácil de operar e

instalar/desinstalar (pesa 70

Bateria recarregável com duração

sensores discretos

de área ativa)

Reúne, processa, armazena e

transmite informação (USB ou

4.3 - Dispositivo Eletrónico para avaliação da pressão plantar 33

3. Existe ainda a possibilidade de exportar os dados num arquivo CSV para

uma posterior análise dos dados usando software estatístico como por

exemplo o Microsoft Excel.

Figura 4.4 – Interface que permite analisar a evolução da pressão plantar do pé do paciente

Através destes diferentes tipos de relatórios pode trocar-se informação com diferentes

entidades. Esta característica é essencial para integrar com a plataforma WEB, facilitando a

comunicação e troca de informação com os diferentes intervenientes no processo.

4.4 - Interface com o Utilizador

A implementação da solução9 foi desenvolvida por módulos e segundo uma metodologia

iterativa de forma a ir validando a solução à medida que se desenvolvia a plataforma. Os

módulos correspondem diretamente às seis fases do processo mais um módulo de gestão de

utilizadores. Os sete módulos são:

Processo: Módulo onde será criado o processo e serão listados todos os processos

disponíveis. Este módulo inclui ainda um conjunto de filtros que permitem uma rápida

consulta dos processos que interessam ao utilizador.

Upload: Módulo que permitirá o utilizador fazer upload quer de ficheiros do WalkinSense

quer de outros ficheiros autorizados e que visem acrescentar informação ao processo.

Catálogo: Zona onde será possível consultar catálogos e escolher produtos para serem

adaptados ao paciente em questão.

9 http://paginas.fe.up.pt/~ilab/corenet/


Características: Local onde serão apresentadas as diferentes características que podem

ser alteradas num sapato de forma a reduzirem a pressão em locais específicos. Nesta zona, o

técnico que faz as medições, poderá inserir os valores que determinar para cada paciente.

Diálogo: Zona onde será permitido trocar informação entre os diferentes intervenientes

envolvidos no processo. Um podologista poderá pedir uma segunda opinião a outro

podologista, ou então, um técnico poderá pedir mais informação ao podologista

relativamente a um processo em concreto.

Administração: Área reservada a administradores onde será permitido fazer uma gestão

dos utilizadores do sistema. Será possível editar, eliminar ou adicionar novos utilizadores.

Comunicação: Este módulo é o responsável pela troca de informação com o exterior da

aplicação. Neste caso, é o responsável pela formatação dos dados do processo e envio para os

fabricantes onde será dada a ordem de produção.

De forma a facilitar a navegação ao longo da página e de se tornar intuitiva a sua

utilização, a plataforma apenas tem quatro páginas diferentes sendo que uma delas é a

página inicial que não tem qualquer funcionalidade para além de uma breve introdução e

enquadramento da plataforma e uma outra que corresponde à área de administração que só

está disponível para os administradores. Isto significa que os restantes utilizadores apenas

navegarão por duas páginas diferentes. Numa dessas páginas o utilizador poderá adicionar ou

escolher novos processos e na outra página serão apresentados todos os outros módulos de

forma organizada e com navegação oculta ao utilizador.

4.4.1 - Módulo “Processo”

Neste módulo, o utilizador tem duas funcionalidades à sua disposição: pode criar um novo

processo ou escolher um processo já existente. Um utilizador apenas terá acesso a estas

funcionalidades depois de se validar no sistema.

Se optar por criar um novo processo, basta inserir um nome para esse processo. Esse

nome é restringido por um tamanho máximo de caracteres e não são permitidos dois

processos com o mesmo nome. Depois de criado, esse processo fica registado na base de

dados juntamente com um identificador único, data de criação e o seu autor. Posteriormente

foi ainda adicionada uma outra característica do processo que é o seu “estado”. O estado de

um processo permite identificar rapidamente se já está em produção, se ainda está em

avaliação ou se já está fechado.

Se o utilizador preferir abrir um processo já existente poderá procurar esse processo

usando vários filtros que estão à sua disposição e que se podem ver na figura 4.5.

É importante referir que apenas o autor de um processo pode editar o seu nome (única

característica introduzida pelo utilizador) e essa alteração em nada afeta os dados já

anexados ao processo.

4.4 - Interface com o Utilizador 35

Figura 4.5 – Módulo “Processo” da infraestrutura de informação

4.4.2 - Módulo “Upload”

Neste módulo, o utilizador pode fazer upload de ficheiros para anexar ao processo que

está em análise.

Para aceder a esta página o utilizador terá que escolher ou criar um processo. Desta

forma, todos os ficheiros que estão na base de dados estão anexados a um processo

específico. Qualquer utilizador poderá anexar ficheiros ao processo, mas apenas o autor do

processo ou o responsável pelo upload do ficheiro o poderá eliminar. A página onde é

permitido anexar os ficheiros aos processos encontra-se representada na figura 4.6.

Figura 4.6 – Módulo “Upload” da infraestrutura de informação


Pela figura anterior pode ver-se facilmente que existem duas áreas diferentes: Uma para

upload de ficheiros do WalkinSense e outra para upload de vários tipos de ficheiros.

A diferença entre estas duas áreas reside no facto dos ficheiros que são carregados na

área dos ficheiros do WalkinSense ficarem disponíveis para visualização através de uma

aplicação desenvolvida em java e com visualização dinâmica dos dados. Esta funcionalidade

permite uma eficiente troca de informação entre utilizadores sem que para isso seja

necessário terem o software do Walkinsense instalado.

Para cada ficheiro existe um conjunto de características que ficam registadas na base de

dados no momento de upload do ficheiro e que podem ser identificadas através da figura 4.6.

De acordo com o especificado pelo cliente, cada ficheiro pode ser retirado do processo

apenas por quem o carregou ou pelo responsável do processo.

A barra azul que aparece como fundo, debaixo de cada ficheiro, informa visualmente o

utilizador se esse ficheiro já foi submetido para o fabricante ou se, pelo contrário, foi

adicionado depois da submissão. A data e o responsável pela última submissão também são

identificados em cada linha. As informações relativas à funcionalidade da submissão de dados

serão descritas numa subsecção seguinte, uma vez que envolve todos os módulos do processo.

É importante referir que os ficheiros não ficam guardados diretamente na base de dados.

Os ficheiros ficam guardados diretamente no disco onde está alojada a plataforma. Desta

forma, o processo de upload é mais fácil, mais rápido e mais standard. Ao carregar o ficheiro,

o nome é guardado na base de dados anexado ao identificador do processo e ao identificador

único do ficheiro. O sistema de pastas e organização dos ficheiros pode ser visto na figura

4.7.

Figura 4.7 – Sistema de pastas da infraestrutura de informação


4.4.3 - Módulo “Catálogo”

Nesta página é possível aceder a um conjunto de artigos disponibilizados pelo fabricante.

Na figura 4.8 pode ver-se um conjunto de sapatos a título de exemplo10. Mais uma vez, só

será possível escolher um artigo se tiver escolhido um processo. Idealmente, o fabricante

disponibilizará um ficheiro organizado com o seu catálogo, e através de uma linguagem de

programação apropriada, esse catálogo será apresentado nesta página.

Figura 4.8 – Módulo “Catálogo” da infraestrutura de informação

4.4.4 - Módulo “Características”

Na figura 4.9 encontra-se representado o módulo das “características”. Nesta área o

utilizador pode inserir todas as medições para um conjunto de catorze características que se

podem adaptar num sapato para pé diabético. Esta página, assim como todas as outras,

contém um sistema de validação de dados e aviso do utilizador se alguma coisa não fizer

sentido. Neste caso, se o utilizador deixar campos por preencher ou preencher com valores

não admissíveis, como caracteres não numéricos por exemplo, é apresentada uma mensagem

ao utilizador e os dados não serão submetidos enquanto não for feita a retificação. A cor

alaranjada que se vê na figura 4.9 aparece como forma de aviso ao utilizador quando se

alteram valores fora de uma gama pré-definida.

10 Esta página não foi muito desenvolvido porque não foi possível contactar com o fabricante de calçado ortopédico que estava alocado ao projeto.


Figura 4.9 – Módulo “Características” da infraestrutura de informação

4.4.5 - Módulo “Diálogo”

Esta área foi acrescentada à plataforma, essencialmente para facilitar a comunicação

entre os vários intervenientes no processo. Essa área está representada na figura 4.10.

Este módulo tem duas áreas distintas: um histórico de mensagens e uma área para troca

de mensagens. A zona de histórico de mensagens contém todas as mensagens que foram

trocadas entre utilizadores relativamente ao processo em questão. A mensagem que se

encontra na área do histórico na figura 4.10 representa um conjunto de informações que o

podologista pode adicionar ao ficheiro através do software do WalkinSense. No momento em

que esse ficheiro é carregado, essas informações são adicionadas como uma mensagem e

destinada a todos os intervenientes do processo. É importante referir, que por uma questão

de organização, cada utilizador apenas vê as mensagens onde o seu nome esteja envolvido,

quer como destinatário quer como remetente. Isto é importante porque mais uma vez,

facilita e simplifica a vida aos intervenientes no processo porque não lhe é mostrada

informação da qual não precisam.


Figura 4.10 – Módulo “Diálogo” da infraestrutura de informação

A área destinada à edição de mensagens contém apenas uma pequena caixa de texto com

uma capacidade limitada de caracteres, uma zona para seleção do destinatário da mensagem

e uma check box. A check box permite escolher se pretende que o utilizador a quem se

destina a mensagem receba uma notificação no seu correio electrónico a informar que tem

uma nova mensagem relativamente a um determinado processo.

Por último, e não menos importante, esta secção dispõe ainda de uma funcionalidade que

permite submeter toda a informação do processo e enviar para o fabricante. A caixa de

diálogo correspondente a essa funcionalidade encontra-se representada na figura 4.11.

Figura 4.11 – Caixa de diálogo para submissão do processo para o fabricante

Esta funcionalidade acrescenta quatro novos dados ao processo:

• Responsável: Utilizador que fica responsável pelo processo a partir do

momento que é submetido e que será consultado pelo fabricante caso seja

necessário;

• Endereço para entrega: Local para entrega do produto;

• Urgência: Tipo de urgência com que é necessária a satisfação da

encomenda. Pode ser classificada em dois graus (Urgente e Normal);

• Forma de pagamento: A comparticipação do estado para este tipo de

produtos varia conforme o sistema nacional de saúde que está envolvido.


Ao submeter o processo, os dados da última submissão são atualizados e o processo passa

para o estado “Produção”.

4.4.6 - Módulo “Comunicação”

Este módulo não requer qualquer tipo de ambiente gráfico. Trata-se de um protocolo de

comunicações desenvolvido para trocar informação com os fabricantes. Baseia-se

essencialmente no REST Protocol11 e é desenvolvido em XML. Este módulo tem duas partes:

uma primeira página mostra os processos que já foram submetidos, e uma outra página que

mostra todos os dados do processo.

A primeira página com a lista dos processos e que é acedida por parte dos fabricantes

está ilustrada na figura 4.12

Figura 4.12 – Ficheiro XML enviado para o fabricante com a lista dos processos submetidos

Com base nesta informação, o fabricante escolhe o processo e faz uma nova chamada à

plataforma através do REST Protocol. Uma parte da informação que o fabricante recebe está

replicada na figura 4.13. Nessa página é enviada toda a informação do processo para o

respetivo fabricante.

11 O REST protocol pode ser comparado com simples chamadas a páginas web através de métodos POST (passagem de variáveis através do endereço de URL)


Figura 4.13 – Ficheiro XML enviado para o fabricante com os dados do processo

A informação disponibilizada na figura 4.13 segue um esquema previamente determinado

para que seja interpretado automaticamente do lado do fabricante. Esse esquema, de forma

resumida, é:

<Process id="xxx" name="xxx" author="xxx" date"xxx">

<File type="xxx" url="xxx"/>

<File type="xxx" url="xxx"/>

<Shoe model="xxx"/>

<FootProperty side="xxx" name="xxx">...valor...</FootProperty>

<FootProperty side="xxx" name="xxx">...valor...</FootProperty>

<ShoeProperty side="xxx" name="xxx">...valor...</ShoeProperty>

<ShoeProperty side="xxx" name="xxx">...valor...</ShoeProperty>

</Process>

Uma primeira linha identifica o processo. Nas linhas do tipo “File type” serão apresentados os

documentos anexados ao processo: identifica-se o tipo de ficheiro, disponibiliza-se o

endereço para download e acrescenta-se mais alguma informação sobre o documento, tal

como a data em que foi anexado ao processo, por exemplo.


De seguida identifica-se a referência do sapato que foi escolhido e enumeram-se as inúmeras

propriedades medidas no pé do paciente. Estas propriedades são identificadas por um nome,

uma localização que é representada por “L” para o pé esquerdo e “R” para o pé direito e

depois o valor dessa propriedade em unidades internacionais.

Desta forma, rapidamente se identifica o processo e as respetivas propriedades do lado do

fabricante correndo um simples programa que interprete este ficheiro XML.

4.4.7 - Módulo “Administração”

Um utilizador apenas terá acesso a este módulo se tiver permissões administrativas. Na

figura 4.14 encontra-se ilustrado este módulo.

Figura 4.14 – Módulo “Administração” da infraestrutura de informação

O administrador pode consultar e editar os seus dados pessoais (esta funcionalidade

também está disponível para os outros utilizadores), pode adicionar, editar e eliminar

utilizadores. Só podem ser adicionados novos administradores ao sistema através deste

módulo.

4.5 - Modelo TO-BE

Nesta secção pretende-se evidenciar as principais diferenças entre a utilização da

plataforma como fio condutor do processo e a forma como o processo flui sem a utilização da

plataforma (já mencionado na secção 3.1).

1. O paciente vai ao podologista;

2. O podologista faz um teste com o WalkinSense e verifica a necessidade de calçado

apropriado;

4.5 - Modelo TO-BE 43

3. O podologista cria o processo na plataforma e carrega o ficheiro;

4. O paciente desloca-se ao fabricante;

5. O fabricante regista na plataforma um conjunto de valores com base na distribuição

da pressão plantar evidenciada pelo teste do WalkinSense e com base num conjunto

de medições;

6. O paciente escolhe o modelo do sapato com base em catálogos digitais;

7. Utilizando a área de diálogo da plataforma, pode haver troca de informação entre o

podologista e o fabricante, de forma a esclarecer dúvidas que possam existir;

8. Podem ser anexados documentos com informação para complementar os dados do

processo;

9. É dada a ordem de produção;

10. Os sapatos são testados e validados com base em novos testes do WalkinSense e

comparando com os ficheiros já carregados anteriormente no processo.

11. Se houver necessidade, os sapatos são reenviados para o fabricante e adicionada

nova informação no processo.

Com a plataforma, evidencia-se uma clara melhoria na facilidade de comunicação entre

os vários intervenientes no processo. O processo torna-se mais ágil e consequentemente mais

eficiente. Os maiores problemas que foram evidenciados na altura do levantamento dos

requisitos prendiam-se com as falhas de comunicação, prevenção de erros, e um processo

pouco ágil. Com esta infraestrutura de informação proporciona-se um fio condutor por onde o

processo flui ao longo das suas etapas de forma organizada e com as suas fases bem

definidas.

Uma outra vantagem é o uso de um método quantitativo que permite avaliar o estado do

paciente e usar essa informação para seguir a evolução do seu estado de saúde.

Esta vantagem é também muito importante, uma vez que, como já foi referido

anteriormente, inúmeros estudos científicos apontam a falta de avaliação quantitativa como

um fator responsável pela falta de eficácia na avaliação do estado de saúde dos pacientes. E

através do uso da plataforma, pode analisar-se a variação da pressão plantar de um paciente

em qualquer lugar, bastando ter uma ligação à internet e java3D12 instalado no computador.

12 Aplicação java com capacidade para correr gráficos com informação em 3D

Capítulo 5

Conclusões e Trabalho Futuro

Este capítulo é dividido em três partes:

• Uma primeira parte onde se descreve a forma como a plataforma foi validada.

• Na segunda parte enumeram-se as principais conclusões finais relativamente a

todo o trabalho desenvolvido

• E numa terceira parte enumeram-se algumas perspetivas de trabalho futuro

associadas à comercialização da solução que se desenvolveu.

5.1 - Validação da solução

Esta fase representa a última etapa do desenvolvimento de qualquer tipo de solução em

sistemas de engenharia. Nenhuma solução é realmente uma solução sem que esteja validada

pelos seus utilizadores. Pode cumprir todos os objetivos e todos os requisitos mas não ser útil

ao utilizador. Muitas vezes, esta fase passa também pela instalação da solução no cliente, só

assim se pode concluir se a solução está totalmente de acordo com aquilo que o cliente

deseja e cumpre o que é previsto. Neste caso, não foi possível proceder à instalação da

solução no cliente, mas foram cumpridos alguns princípios para a validação da solução.

Numa primeira fase, através do documento de requisitos previamente desenvolvido na

fase inicial do projeto, validaram-se os requisitos. Essa validação passou pela verificação

daquilo que era previsto acontecer quando solicitadas um conjunto de ações (coluna

“verificação” do documento B.3). Essa verificação foi completa com sucesso e todos os

requisitos foram validados.

Numa segunda fase, a plataforma foi apresentada aos restantes parceiros do projeto e

integrada com as restantes ferramentas desenvolvidas. Do ponto de vista da integração,

apenas foi necessário passar os dados dos processos para o “Quality Monitor” que é a

ferramenta responsável pelo processamento dos dados e envio para os fabricantes. Essa

integração foi feita usando o REST Protocol já referido anteriormente.

46 Conclusões e Trabalho Futuro

A apresentação da plataforma aos restantes parceiros do projeto foi feita numa

conferência13 onde não resultaram críticas às suas funcionalidades, pelo que se pode

considerar como aprovada. A apresentação pode ser consultada no anexo D.1.

Como terceira e última fase da validação da plataforma, está previsto uma reunião com

um podologista e um técnico da indústria de calçado ortopédico para se proceder à sua

validação por parte dos seus utilizadores. No entanto, até à data de entrega deste relatório,

não foi possível agendar essa reunião. No entanto, é importante referir que nos parceiros do

projeto também estão incluídos fabricantes de calçado ortopédico e que não fizeram

nenhuma crítica na altura da apresentação da plataforma.

5.2 - Conclusões

As conclusões deste projeto incidem principalmente na concretização dos objetivos

definidos previamente para este projeto:

• Identificação e caracterização do problema: Este primeiro objetivo foi

cumprido. Identificaram-se os principais problemas do processo de prescrição de

calçado para pé diabético e construi-se um modelo em “swimlane” com a

representação do processo. Identificaram-se e enumeraram-se os problemas a

resolver com a solução;

• Desenvolvimento e construção da arquitetura do sistema: Depois de

identificado o problema, procuraram-se soluções e definiu-se uma estrutura para

o desenvolvimento de uma plataforma que fosse capaz de resolver os problemas

inicialmente identificados. Essa arquitetura desenvolveu-se com base em

interações constantes entre os diferentes intervenientes no processo. Este

objetivo só pode dizer-se cumprido se o seguinte também for concretizado e

estiver de acordo com o especificado pelo cliente;

• Elaboração de um protótipo: Com base no trabalho desenvolvido no contexto dos

dois objetivos anteriores, desenvolveu-se uma solução e o respetivo protótipo

para teste com os utilizadores. Através da validação dos resultados, pode afirmar-

se que este objetivo foi cumprido. Foi desenvolvido um protótipo em pleno

funcionamento e que satisfaz os requisitos previamente identificados.

De uma forma geral pode concluir-se que os objetivos foram todos cumpridos. Os

problemas da comunicação entre os vários intervenientes no processo são agora simplificados

pela plataforma. Existe um fluxo de informação bem determinado e que gere o processo

como um todo e não por uma sequência de etapas. Também se deu um passo importante na

forma de avaliação do estado clínico dos pacientes que sofrem deste tipo de patologias.

Através do dispositivo que recolhe os dados da pressão plantar do paciente e na forma

simples de carregar o ficheiro para uma plataforma, é agora possível recolher opiniões de

outros podologistas sem ter a necessidade da instalação de qualquer software ou de

perderem tempo em deslocações. E tendo em conta que o tempo de um podologista é de

elevado valor, esta solução revela-se uma ferramenta que pode vir a ser determinante em

alguns casos.

13 ICE Conference, realizada em Munique, Alemanha, nos dias 19 e 20 de Junho

5.3 - Trabalho Futuro 47

5.3 - Trabalho Futuro

Como perspetivas de trabalho futuro podem identificar-se três objetivos principais:

• Integração da plataforma com os fabricantes de calçado ortopédico: este objetivo

visa essencialmente integrar os catálogos dos fabricantes na plataforma e trocar

informação sobre os processos;

• Validação da plataforma junto dos seus utilizadores: Como já foi referido

anteriormente, este objetivo faz parte da fase de validação da plataforma. Por isso,

a curto prazo, deverá ser possível reunir com um podologista e um técnico de forma a

validar a plataforma por parte de quem a vai utilizar e verificar a sua utilidade;

• Instalação e teste no cliente: Como último objetivo, era importante poder instalar a

solução junto do cliente e analisar a sua utilidade para proceder a possíveis

alterações. Como é natural, só depois de algumas utilizações é que se percebem

lacunas ou erros na forma como a plataforma está a processar a informação. Nesse

sentido, analisar a forma como utilizam a plataforma, representa um fator

importante na avaliação da sua utilidade e no desenvolvimento de alterações.

De uma forma geral, como trabalho futuro, podem definir-se um conjunto de etapas que

visem uma contínua melhoria da plataforma até que represente uma mais-valia para os seus

utilizadores.

48 Conclusões e Trabalho Futuro

Anexo A

Gestão do Projeto

50 Gestão do Projeto

A.1 - Diagrama de Gantt

Figura A.1 – Diagrama de Gantt com as macro tarefas

A.2 – Tarefas do diagrama de Gantt 51

A.2 - Tarefas do diagrama de Gantt

Tabela A.1 – Tabela com todas as tarefas retiradas do diagrama de Gantt

ID Tarefa Início Fim Duração

1 Levantamento inicial do processo.

11-10-2011

01-11-2011

16 Dias

2 Integração no projeto. 11-10-2011 18-10-2011 06 Dias

3

Leitura de documentos técnicos relativos ao processo de prescrição de calçado para pé-diabético.

11-10-2011 18-10-2011 06 Dias

4

Elaboração de questões a colocar numa entrevista com um podologista e um técnico do HSA.

18-10-2011 25-11-2011 06 Dias

5 Construção do Modelo AS-IS. 25-10-2011 01-11-2011 16 Dias

6 Análise do Processo.

01-11-2011

22-11-2011

16 Dias

7

Construção do modelo simplificado, em Swimlane, descrevendo as etapas principais do processo.

01-11-2011 04-11-2011 04 Dias

8

Elaboração de um pequeno protótipo do S.I para mostrar ao podologista e técnico do HSA.

04-11-2011 15-11-2011 08 Dias

9

Apresentar o protótipo ao podologista e técnico do HSA e registo das respetivas opiniões e sugestões.

15-11-2011 15-11-2011 01 Dias

10 Construção do Modelo TO-BE. 15-11-2011 22-11-2011 06 Dias

11

Descrição da Solução que se propõe e dos benefícios da sua adoção.

15-11-2011

22-11-2011

06 Dias

12 Identificação e Caracterização dos Requisitos.

22-11-2011

13-12-2011

16 Dias

13 Estudo do funcionamento do WalkinSense. 22-11-2011 29-11-2011 06 Dias

14

Levantamento dos Requisitos Funcionais com base na documentação obtida.

29-11-2011 03-12-2011 05 Dias

15 Levantamento dos Requisitos não Funcionais. 03-12-2011 06-12-2011 03 Dias

16 Caracterização e organização dos Requisitos. 06-12-2011 13-12-2011 06 Dias

17 Identificação das Tecnologias Candidatas.

13-12-2011

03-01-2012

16 Dias

18 Estudo da applet desenvolvida pela TO. 13-12-2011 20-12-2012 06 Dias

19 Descrição das Tecnologias Candidatas. 27-12-2011 03-01-2012 06 Dias

20

Desenvolvimento e construção da Arquitetura do Sistema.

03-01-2012

24-01-2012

16 Dias

21

Construção do Modelo Entidade-Relação para a BD.

03-01-2012 10-01-2012 06 Dias

22 Construção do Modelo Relacional. 10-01-2012 13-01-2012 04 Dias

23 Elaboração dos Casos de Uso. 13-01-2012 24-01-2012 08 Dias

52 Gestão do Projeto

24 Elaboração de um Protótipo.

24-01-2012

23-03-2012

44 Dias

25

Apresentação do Protótipo aos restantes parceiros.

21-02-2012 23-02-2012 03 Dias

26 Aplicar as alterações necessárias. 24-02-2012 20-03-2012 18 Dias

27

Nova apresentação da plataforma aos parceiros do CORENET.

20-03-2012 22-03-2012 03 Dias

28 Integração e Teste.

23-03-2012

29-05-2012

48 Dias

29

Integração do protótipo com o restante projeto (Catálogos da Manas SPA, por exemplo).

23-03-2012 17-04-2012 18 Dias

30 Efetuar as alterações necessárias. 17-04-2012 01-05-2012 11 Dias

31

Testes para verificação de conformidade com o especificado nos requisitos.

01-05-2012 15-05-2012 11 Dias

32

Validação da plataforma com os atores envolvidos na sua utilização.

15-05-2012 22-05-2012 06 Dias

33 Efetuar as alterações necessárias. 22-05-2012 29-05-2012 06 Dias

34 Testes Finais. 29-05-2012 05-06-2012 06 Dias

35 Elaboração da Dissertação (escrita).

11-10-2011

12-06-2012

176 Dias

Anexo B

Requisitos do Sistema de Informação

B.1 - Entrevista ao Podologista – Hospital de Santo António (25/10/2011)

Enquadramento

No âmbito do projeto CORENET pretende-se construir uma plataforma web que ajude o

podologista no processo de consulta e encomenda de um sapato para pé diabético. Ou seja,

informatizar aquilo que acho que agora é feito de forma manual.

Objetivo

� Identificar claramente a sequência de etapas seguidas durante o processo de

consulta do paciente e encomenda do sapato;

� Identificar aquilo que um sistema informático deve ter para ser útil e ao

mesmo tempo fácil de utilizar.

Questões

1. Quando o paciente aqui chega, ele já está registado no sistema ou é o médico que cria esse novo paciente caso ele ainda não exista? R:.O paciente é registado no sistema no ato da marcação da consulta.

2. Quando não existe a necessidade de um sapato especial, o problema pode ser

resolvido por outra forma? Por exemplo, alguma palmilha que corrija de imediato a distribuição do peso em casos menos graves?

2.1 Essa informação fica registada onde?

R:.As palmilhas são feitas na hora (são grátis mas há um limite). E por vezes essa correção é suficiente. Não fica registada em nenhum local. Em casos mais graves é que é necessário a encomenda de calçado especial.

3. Existe calçado pré-definido para pé-diabético? No Reino Unido existem três tipos

de calçado que são escolhidos conforme a gravidade da situação: 3.1 Calçado Geral para pés diabéticos 3.2 Modular (permite adição de características extra) 3.3 Feito por medida (totalmente adaptado ao paciente)

54 Requisitos do Sistema de Informação

R:.Existem três tipos de calçado em que os dois primeiros cobrem cerca de 85% dos casos: Conforto (calçado mais largo); Estandardizado (permite um conjunto de alterações); Feito por medida

4. Como é que o paciente escolhe o aspeto exterior do calçado? Catálogos?

R:.Sim, por catálogo.

5. Que tipo de documento (formulário) é enviado para o fabricante?

R:.O paciente é que vai ao encontro do fabricante. Na consulta é apenas preenchido um histórico do paciente com a evolução da doença.

6. Que informação contém esse formulário?

R:.Volume da forma (três para cada tamanho) Sapatos com tamanho diferente de um pé para o outro? (s/n) Correção (Modular) Hallux Valgus Dedos em garra Volume extra (pode ter várias placas de volume extra) Compensação para o 5ºdedo Palmilha Carbono (sapato rígido) Rocker (balanço) Sola em Elva Altura extra do sapato(mm) Altura extra do ball(mm) Compensação lateral(mm) Compensação medial(mm) Mais volume no peito do pé Nota: A medida do sapato é efetivamente medida e depois é usada uma escala de conversão para os números que existem (padrão). Só em casos excecionais (pé muito deformado) é que se recorre ao sapato feito por medida.

7. Depois de enviado o documento para o fabricante quanto tempo demora a estar pronto, normalmente? R:.Normalmente um mês

8. É possível enviar um pedido e o fabricante rejeitar ou dizer que tem erros?

8.1 Como se processa a correção?

R:.Algumas correções podem ser feitas, outras não, sendo necessário construírem outro sapato. Normalmente, a principal causa do problema é: As dimensões do pé não foram bem retiradas. (principalmente ao nível do volume)

9. O calçado é entregue no hospital? Ou em casa do paciente?

9.1 Em que serviço do hospital?

R:.Depende do grau de confiança pelo paciente. Se já é um paciente recorrente, então é enviado para casa por correio. Caso contrário é entregue no hospital e o paciente vai levanta-lo.

10. Existe comparticipação do estado?

B.2 - Protótipo em PowerPoint 55

R:.Não existe comparticipação por parte do estado. O paciente paga o calçado por inteiro (Muitas vezes pode chegar aos 500 euros).

11. Quando é entregue o calçado o médico faz uma nova consulta ao paciente para

verificar se está conforme o especificado ou se necessita de algum ajuste? 11.1 Esse processo repete-se periodicamente para analisar a evolução do

paciente? Verificar se necessita de um novo par de sapatos… R:.São feitas consultas frequentes e periódicas para acompanhar o estado do paciente.

12. É vantajoso poder enviar para o fabricante, junto com o formulário, a visualização gráfica do estado do paciente dada pelo Walkinsense? R:.Sim, porque a empresa normalmente tem técnicos que analisam o pedido

13. Facilitava o processo se existisse uma plataforma web onde isto fosse tudo feito de forma informática e aplicando filtros à medida que se avança no processo? Por exemplo, o médico define um determinado conjunto de características que o calçado tem que ter, e então a lista de escolha do sapato já vem filtrada mostrando apenas aqueles sapatos de possível adaptação. R:.Sim.

14. O sistema deve ter um registo próprio dos pacientes ou tem que ter alguma

ligação com o sistema nacional de saúde? R:.Pode ter um registo próprio, no caso de Portugal.

15. O médico pode adicionar pacientes ao sistema?

R:.Não. Isso é feito no ato da consulta.

B.2 - Protótipo em PowerPoint

Como já foi referido ao longo deste documento, este protótipo teve como objetivo

recolher as primeiras impressões dos utilizadores quando confrontados com um sistema de

informação. Desta forma, foi possível identificar de imediato um conjunto de alterações

necessárias para que a plataforma fosse verdadeiramente útil. Nas imagens que se seguem,

estão representadas algumas páginas pertencentes a esse protótipo.

A primeira figura (figura B.1), representa a interface a que o podologista teria acesso

antes de se validar no sistema. Como se pode verificar, esta interface continha um menu

lateral onde podiam ser feitas pesquisas e inserções de pacientes ao sistema. Esta foi uma

das primeiras alterações a fazer uma vez que a plataforma tinha que cumprir o princípio da

confidencialidade dos dados dos pacientes.

56

Figura B.1 – Interface do

Na figura B.2 encontra-se representado o menu de diagnóstico. Nesta página, o

podologista poderia ver o teste proveniente do WalkinSense e avaliar a evolução da pressão

plantar.

Figura B.2 – Interface do Podologista onde terá acesso à área de diagnóstico do paciente

Na figura B.3 encontra-se a página com os catálogos digitais e que permitiriam uma

rápida consulta dos modelos existentes. Posteriormente seria escolhido e a

anexada ao processo.


Interface do Podologista onde poderá fazer login

se representado o menu de diagnóstico. Nesta página, o


Interface do Podologista onde terá acesso à área de diagnóstico do paciente

se a página com os catálogos digitais e que permitiriam uma

rápida consulta dos modelos existentes. Posteriormente seria escolhido e a referência seria


se representado o menu de diagnóstico. Nesta página, o



se a página com os catálogos digitais e que permitiriam uma

referência seria

B.2 - Protótipo em PowerPoint

Figura B.3 – Interface do Podologista onde terá acesso à área de diagnóstico do paciente

PowerPoint


57



B.3 - Lista de Requisitos

Tabela B.1 - Lista de requisitos do sistema

Requisitos Descrição Prioridade Verificação

ID Caracterização

ID#1 Funcional O sistema deve ter controlo de acessos 3 Verificação de que não é possível aceder a qualquer tipo de informação da plataforma sem que primeiro tenha feito "login" com as suas credenciais

ID#2 Funcional O sistema deve permitir criar novos processos 3 Criação de um novo processo no sistema e verificar as várias possibilidades de edição e inserção de informação

ID#3 Funcional Deve ser possivel organizar e consultar os processos por autor, data, nome, ID e estado

2 Observação dos vários tipos de pesquisa e filtragem de processos

ID#4 Não Funcional O sistema deve ser versátil para se adaptar a diferentes países e ao respetivo sistema de saúde

3 Observação e comparação dos processos antes e depois da plataforma

ID#5 Funcional O sistema deve ser capaz de trocar informação com os fabricantes

3 Verificação da possibilidade de acesso a informação disponibilizada pelo fabricante (catálogos)

ID#6 Funcional O sistema deve integrar uma ferramenta java3D 3 Verificação do funcionamento da aplicação com animações 3D depois de submeter um ficheiro próprio para esse efeito

ID#7 Funcional Para cada processo a plataforma deve permitir a consulta de catálogos dos fabricantes, registando a referência do produto

3 Verificação da possibilidade de consultar catálogos depois de criar um processo.

ID#8 Funcional Para cada processo, a plataforma deve permitir a troca de mensagens entre utilizadores

2 Verificação da possibilidade de envio de uma mensagem para um utilizador e verificar a receção dessa mensagem do lado do utilizador destinatário

B.3 - Lista de Requisitos 59

ID#9 Funcional

Para cada processo, a plataforma deve permitir a inserção de valores para um conjunto de características necessárias à construção do sapato. Deve ser possível inserir valores diferentes para cada pé e são elas: Extra Volume; Hallux Valgus; Fingers Claw; Pronato; Supinato; Equino; Volume of the form; Compensation Medial; Extra height of the shoe; Extra height of the ball; Lateral Offset; More volume instep; Compensation for the 5th finger; Carbon Insole;

3 Observação da capacidade de inserção de vários valores para as diferentes características

ID#10 Funcional O sistema deve manter a confidencialidade dos dados dos pacientes

3 Verificação da não necessidade de inserção dos dados do paciente para que o processo se desenvolva

ID#11 Funcional O sistema deve permitir fazer upload de ficheiros 3 Observação da existência e possibilidade de leitura de um ficheiro depois de carregado na plataforma para um determinado processo

ID#12 Funcional O sistema deve restringir o tipo de ficheiros permitidos

3 Verificação da impossibilidade de carregar ficheiros com extensão .exe, por exemplo.

ID#13 Funcional

O sistema de ter 3 tipos de utilizadores com permissões diferentes: Admin-> Pode fazer tudo no sistema; Doctor e Assistant-> Podem criar, editar e eliminar processos

3 Criação de três utilizadores de tipos diferentes e verificação das suas permissões

ID#14 Funcional Só o utilizador que criou o processo o pode editar 3 Verificação da impossibilidade de editar um processo do qual não se é autor.

ID#15 Funcional Só o utilizador que criou o processo o pode eliminar 3 Verificação da impossibilidade de eliminar um processo do qual não se é autor.

ID#16 Funcional Qualquer utilizador pode adicionar mais informação ao processo

3 Verificação da possibilidade de adição de informação a um processo da qual não se é autor

ID#17 Funcional Só o utilizador que criou o processo ou que fez upload de um ficheiro tem autorização para eliminar esse

3 Eliminação de um ficheiro depois de o ter carregado num processo qualquer


mesmo ficheiro do respetivo processo

ID#18 Funcional O sistema ao ser submetido para o fabricante deve enviar toda a informação do respetivo processo

3 Verificação da informação recebida pelo fabricante depois de submeter o processo.

ID#19 Funcional Na submissão deve conter a morada de entrega, urgência, forma de pagamento e responsável

2 Verificação da necessidade dos dados relativos à morada de entrega, urgência, forma de pagamento e responsável para poder submeter um processo

ID#20 Funcional O sistema deve alertar o utilizador quando há alteração na informação de um processo já submetido. Nesse caso, permite nova submissão

2 Verificação da existência de uma mensagem de alerta com a data da última submissão

ID#21 Funcional O sistema deve alertar o utilizador quando há alteração nos valores pre-definidos das caracteristicas dos sapatos

1 Verificação da existência de modos de realce para valores diferentes dos pre-definidos

ID#22 Funcional O sistema deve enviar automaticamente um e-mail para o utilizador quando há novas mensagens num processo em que esteja envolvido

1 Confirmação da receção de um-email de notificação do lado do utilizador destinatário da mensagem depois de ser feito o envio através da plataforma

ID#23 Não Funcional O sistema deve ser de fácil interpretação de forma a não requerer qualquer tipo de formação para a sua utilização

3 Entregar a plataforma a um conjunto de utilizadores, observar as suas dúvidas e registar as suas opiniões.

ID#24 Funcional Só o administrador pode adicionar mais administradores

3 Verificação da impossibilidade de adicionar um novo administrador quer através da funcionalidade "sign up" quer através de outro utilizador que não seja administrador

Legenda:

1 Baixa

2 Média

3 Elevada

Anexo C

Arquitetura do Sistema de Informação

C.1 - Modelo Entidade – Associação

Entidades:

Attachment (id_attachment, nome, descricao, size, data, hora, data_submission,

hora_submission)

Catalog (id_catalog, id_shoe, data_submission, hora_submission, data_changed,

hora_changed)

Dialog (id_dialog, dialog, data, hora)

Features (id_features, data_submission, hora_submission, data_changed, hora_changed,

volume_right, volume_left, correction_right, correction_left, hallux_right, hallux_left,

fingers_right, fingers_left, extravolume_right, extravolume_left, compensationfinger_right,

compensationfinger_left, compensationmedial_right, compensationmedial_left, carbon_right,

carbon_left, rocker_right, rocker_left, elva_right, elva_left, extraheightshoe_right,

extraheightshoe_left, extraheightball_right, extraheightball_left, lateral_right, lateral_left,

instep_right, instep_left)

Process (id_process, nome_process, date_creation, hora, data_conclusion, hora_conclusion,

address, urgency, payment)

Status (state)

Tipo (tipo)

Upload (id_upload, id_nome, data, hora, data_submission, hora_submission)

Utilizador (id_utl, nome, username, password, email)

62 Arquitetura do Sistema de Informação

Associações:

fez (Utilizador, Attachment) 1:N p/t

inclui (Process, Attachment) 1:N p/t

contem (Process, Catalog) 1:1 p/t

escreveu (Utilizador, Dialog) 1:N p/t

destina-se (Dialog, Utilizador) N:1 t/p

pertence (Dialog, Process) N:1 t/p

detem (Process, Features) 1:1 p/t

criou (Utilizador, Process) 1:N p/t

gere (Utilizador, Process) 1:N p/t

estáNo (Process, Status) N:1 t/p

carregou (Utilizador, Upload) 1:N p/t

tem (Process, Upload) 1:N p/t

éDo (Utilizador, Tipo) N:1 t/p

C.2 - Modelo Relacional

Attachment | id_attachment || #id_remetente ->Utilizador NN | #id_process ->Process NN |

nome NN | descricao | size NN| data NN | hora NN | data_submission | hora_submission |

Catalog | id_catalog || #id_process ->Process NN | id_shoe | data_submission |

hora_submission | data_changed | hora_changed |

Dialogo | id_dialog || #id_remetente ->Utilizador NN | #id_destinatario ->Utilizador NN |

#id_process ->Process NN | dialogo NN | data NN | hora NN |

Features | id_features || #id_process ->Process NN | volume_right | volume_left |

correction_right | correction_left | hallux_right | hallux_left | fingers_right | fingers_left |

extravolume_right | extravolume_left | compensationfinger_right | compensationfinger_left

| compensationmedial_right | compensationmedial_left | carbon_right | carbon_left |

rocker_right | rocker_left | elva_right | elva_left | extraheightshoe_right |

extraheightshoe_left | extraheightball_right | extraheightball_left | lateral_right |

lateral_left | instep_right | instep_left | data_submission | hora_submission | data_changed

| hora_changed |

C.2 - Modelo Relacional 63

Process | id_process || #id_author ->Utilizador NN | #id_responsable ->Utilizador NN |

#status ->Status NN| nome_process NN, U.K | date_creation NN | hora NN | address | urgency |

payment | date_conclusion | hora_conclusion |

Status | state ||

Tipo | tipo ||

Upload | id_upload || #id_process ->Process NN | #uploader ->Utilizador NN | id_nome

NN | data NN | hora NN | data_submission | hora_submission |

Utilizador | id_utl || #tipo ->Tipo NN | username NN, U.K | nome | password | email

64 Arquitetura do Sistema de Informação

Anexo D

Validação da Solução

D.1 - Apresentação da ICE Conference

Customer-ORiented and Eco-friendly NETworks for healthy and

fashionable goods

260169 CoReNetWeb platform for diabetic foot

The Problem

• There is little communication between the podiatrist andfootwear industry.

• The catalogs offer a limited range of options and the patientdoes not use the shoes because it is not aesthetically pleasing.

• “Exact identification of locations with elevated plantarpressure through clinical evaluation is difficult (…)

source: 2006,Guldemond et al

66 Validação da Solução

Impact

Every 30 seconds a lower limb (or part) is lost to diabetes and 80%of of the 1.5 million annual amputations related with diabetes canbe avoided (diabetic foot ulcers account for around $12bnannually in treatments) Source: International Diabetes Federation

If every American at risk for developing a diabetic foot ulcervisited a podiatrist once before complications set in, the UShealth-care system could save $3.5bn in one year

Source: Journal of the American Podiatric Medical Association, March/April 2011

The typical sports podiatrist refers a patient for the purchase of anew pair of athletic shoes between 10 and 50 times per week (...)prescribing somewhere between 6 and 31 million pairs annually(…) recommending or prescribing footwear can be anintimidating process for the podiatric physician

Source: Podiatry Management, October 2004

Objectives of Prototype

• Allow and facilitate the communication between allstakeholders in the process.

• Incorporate a graphic and quantitative analysis of the plantarpressure of the patient.

• Allow viewing of digital catalogs.

• To reduce the errors that currently exist in the prescribingprocess.

Benefits for Stakeholders

• From the viewpoint of the footwear industry there would bean increase on sales.

• From the viewpoint of the patient, that would mean theresolution of their health problems rapidly without having toresort to amputation with fully configured solutions, bothfunctional as well aesthetics.

• From the viewpoint of the podiatrist, it will provide anincrease of their efficiency.

D.1 - Apresentação da ICE Conference 67

Functional Architecture

The Solution

1. Allows to uploadWalkinSense files.

2. Allows a process management.

3. Incorporates a dialogue area for communication betweenstakeholders in the process.

4. Allows insertion of Features.

5. Allows to upload information for complete the process.

6. Send all information of the process to the respective footwearmanufacturer.

Solution: WalkinSense File


Solution: Features

Solution: Catalogue

Solution: Dialog Area

D.1 - Apresentação da ICE Conference 69

Conclusions

The main objectives behind this approach were:• the simplification of the prescription process• the organization of the information flow related eachprocess behind the diabetic foot patient

• the development of a common platform that linkspodiatrists and healthcare agents, footwear industrytechnicians and manufacturers and ultimately diabetic footpatients.

Upcoming developments include the interconnection of thepresent platform with shoe and insole manufacturers.

Referências

[1] IDF - International Diabetes Federation, “Report_Diabetes - International working group

on the diabetic foot”, 2005

[2] Seventh Framework Programme, “THEME [FoF. NMP.2010-2] - Supply chain approaches for

small series industrial production”, 2010.

[3] Azevedo A., Bastos J., Almeida R., “Collaborative Planning in Customer-Oriented Supplier

Networks – The CoReNet Approach”, 2011.

[4] Mgaletti N., Del Grosso E., Crippa G., Fornasiero R., Baffo I., Brondi C., Brusaferri A.,

Bastos J., Azevedo A., Stellmach D., Weiss M., Winkler M., Franchini V., Chiodi A.,

Fuhrmann A., Satos P., “Deliverable Number D1.1: State of the Art”, 2010.

[5] Saleh S., AL-Tayyar. “The Importance of Plantar Pressure Measurements and Appropriate

Footwear for Diabetic Patients”, 2nd King Saud University Diabetic Foot Program, King

Saud University, 17-22/9/2005, Riyadh, Saudi Arabia.

[6] Pedeboy J.P., Santos P., Meneses P., “Deliverable Number D2.9: Co-Design Environment

of Leather and Footwear Products”, 2012.

[7] Guldemond Nick A., Leffers P., Nieman F.H.M., Sanders A.P., Walenkamp G.H.I.M.,

“Testing the proficiency to distinguish locations with elevated plantar pressure within

and between professional groups of foot therapists”, BMC Musculoskeletal Disorders, pp.

7- 93, Dec. 2006.

[8] IEEE Standard for Application and Management of the Systems Engineering Process, IEEE

Standard 1220, 2005.

[9] IEEE Standard Recommended Practice for Software Requirements Specifications, IEEE

Standard 830, 1998.

[10] Santos P., “The diabetic foot working case”, 2012

[11] Harris A., HTML, XHTML, &CSS All-in-one For Dummies, 2nd ed., Wiley Publishing, Inc.,

Indianapolis, 2011.

[12] Cecco R., Superchardged JavaScript Graphics, 1nd ed., O’Reilly Media, Inc., Sebastopol,

2011.

[13] Oracle Corporation. Disponível em http://www.mysql.com/customers/. Acesso em 20 de

Junho de 2012.

[14] Tomorrow Options S.A. Disponível em http://www.tomorrow-options.com/

pt/downloads. Acesso em 14 de Abril de 2012.

Desenvolvimento de Plataforma para Gestão Integrada de … · 2017-08-28 · Arquitetura do...

Documents

Transcript of Desenvolvimento de Plataforma para Gestão Integrada de … · 2017-08-28 · Arquitetura do...