1 Instituto Politécnico de Coimbra
Instituto Superior de Engenharia de Coimbra Escola Superior de Tecnologia da Saúde Coimbra
Sistema de Informação para a
realização de testes de Audição
Dicótica e Interacção Binaural
João Ferreira
M estrado em Sistemas e Tecnologias da Informação para a Saúde
2 Inst it ut o Polit écnico de Coim bra
Inst it ut o Superior de Engenharia de Coim bra Escola Superior de Tecnologia da Saúde Coim bra
M estrado em Sistemas e Tecnologias da Informação para a Saúde
Project o/ Est ágio I e Project o/ Est ágio II
Sistema de Informação para a
realização de testes de Audição
Dicótica e Interacção Binaural
João Ferreira
Orientador:
Ant ónio Carvalho ESTESC
Co- Orientador:
Cláudia Reis ESTESC
i
Agradeciment os
Aos orient adores Ant ónio Carvalho e Cláudia Reis agradeço a orient ação prest ada.
A t odos os m eus colegas que m e ajudaram a ult rapassar pequenos problem as durant e o desenvolvim ent o com novas ideias para a im plem ent ação.
ii
Resumo
Nas últ im as duas décadas a evolução das Tecnologias de Inform ação (TI), m udou a form a com o o m undo lida com a inform ação t razendo inúm eras vant agens com pet it ivas, obrigou a uma grande rest rut uração de sist em as e procedim ent os exist ent es.
No caso específico da saúde as TI dissem inaram -se rapidam ent e, e cont inuam em const ant e desenvolvim ent o, por form a a lidarem de form a eficient e com arm azenam ent o, recuperação e gest ão de inform ação clínica, para auxílio dos profissionais clínicos nas suas t om adas de decisão.
Em bora as TI se encont rem dissem inadas na saúde, ainda exist em algum as áreas que não fazem uso dos pot enciais da t ecnologia e que cont inuam a ut ilizar Sist em as de Inform ação (SI) ult rapassados e pouco eficient es.
Est a dissert ação enquadra-se no Grupo de Invest igação em Bioacúst ica e Sist em as (GIBS), que pret ende m odernizar a área da Audiologia em Port ugal que act ualm ent e ut iliza procedim ent os ult rapassados e pouco eficient es.
iii Abstract
In t he last t w o decades t he evolut ion of Inform at ion Technologies (IT) has changed t he w ay t he w orld deals w it h informat ion bringing num erous com pet it ive advant ages, forced a m ajor rest ruct uring of exist ing syst em s and procedures.
In t he specific case of healt h IT have spread rapidly, and rem ain in const ant development in order t o deal efficient ly w it h t he st orage, ret rieval and m anagem ent of clinical informat ion in order t o assist clinicians in t heir decisions.
Alt hough IT are dissem inat ed on healt h, t here are st ill som e areas t hat do not m ake use of t he pot ent ial of t echnology and cont inue t o use Inform at ion Syst em s (IS) out dat ed and inefficient . This w ork is part of t he Grupo de Invest igação em Bioacúst ica e Sist em as (GIBS), w hich aim s t o m odernize t he area of Audiology in Port ugal w hich current ly uses out dat ed and inefficient procedures.
iv
Índice
1. Int rodução ... 1
1.1. Âm bit o do project o ... 1
1.2. Object ivos e m ot ivação ... 1
1.3. Organização da dissert ação... 1
2. Est ado da Art e ... 3
2.1. Sist em as de inform ação ... 3
2.2. Sist em as de inform ação na Saúde ... 4
2.3. Regist os clínicos ... 6
2.4. Processam ent o audit ivo... 7
2.4.1. Test es de avaliação do processam ent o audit ivo ... 7
2.4.2. Test es dicót icos ... 8
2.4.2.1. Test e dicót ico de dígit os ... 8
2.4.2.2. SSW ou t est es de palavras espondaicas alt ernadas ... 9
2.5. Aplicação dos t est es nos dias de hoje ... 9
2.6. Conclusões... 10
3. M et odologia de Desenvolvim ent o do Sist em a de Inform ação ... 11
3.1. Processo de desenvolvim ent o de SI ... 11
3.2. M et odologias de desenvolvim ent o ... 11
3.3. Prot ot ipagem ... 15
4. Análise e desenvolvim ent o ... 17
4.1. Requisit os ... 17
4.2. Tecnologia ut ilizada no desenvolvim ent o da solução ... 19
4.2.1. Java ... 19
4.2.2. IDE’s de desenvolvim ent o ... 20
4.2.3. Post gres SQL ... 20
4.2.4. Cart ão do Cidadão ... 20
4.2.5. Disposit ivo com Android ... 20
4.3. Int erface Gráfica ... 21
4.3.1. Definição da int erface gráfica... 22
4.4. Descrição concept ual da solução im plem ent ada ... 25
4.4.1. Sist em a ... 26
v
4.4.2.1. Gerir Prot ocolos Dicót ico de Dígit os ... 31
4.4.2.2. Gerir Prot ocolos SSW ... 33
4.4.2.3. Gerir Sons Dicót icos de Dígit os / SSW... 34
4.4.3. Perfil de Técnico ... 35
4.4.3.1. Test es ... 36
4.4.4. Perfil de Ut ilizador ... 38
4.5. Est rut ura de dados... 40
4.6. Aspect os relevant es da im plem ent ação ... 42
4.6.1. Cart ão do cidadão Port uguês ... 42
4.6.2. Realização de t est es verbais ... 44
4.6.3. Realização de t est es não-verbais ... 46
4.6.4. Reprodução de sons... 47
4.6.5. Adição de sons ao sist em a ... 48
4.6.6. Gest ão de sons no sist em a ... 49
4.6.7. Adição de prot ocolos ao sist em a ... 50
4.6.8. Form ulário de realização de um t est e ... 52
4.6.9. Criação de relat órios ... 52
4.6.10. Gest ão de relat órios ... 54
4.6.11. Gest ão do int erface gráfico ... 54
5. Avaliações do Sist em a de Inform ação ... 55
5.1. Com pat ibilidade da aplicação ... 55
5.2. Requisit os de Sist em a ... 58
6. Conclusões e Trabalhos Fut uros ... 60
vi
Índice de figuras
Figura 1 - Represent ação esquem át ica da definição de O'Brien ... 4
Figura 2 – Represent ação gráfica do desenvolvim ent o em cascat a ... 12
Figura 3 - Represent ação gráfica do desenvolvim ent o it erat ivo e increm ent al... 14
Figura 4 - Represent ação esquem át ica das m et odologias ágeis ... 15
Figura 5 – Represent ação gráfica da m et odologia de prot ot ipagem ... 16
Figura 6 - Prot ót ipo inicial do esquem a de navegação ... 16
Figura 7 - M et ro UI do novo Window s 8 ... 22
Figura 8 – Definição da int erface gráfica ... 23
Figura 9 - Painel de t arefa ... 24
Figura 10 - Bot ões da aplicação ... 24
Figura 11 - Janela de aviso ... 25
Figura 12 – Diagram a de casos de uso do SI... 27
Figura 13 - Ecrãs de login da aplicação ... 27
Figura 14 - M enu de escolha de perfil ... 28
Figura 15 - Diagram a de casos de uso do perfil de Adm inist rador ... 29
Figura 16 - Regist o de um novo ut ilizador ... 30
Figura 17 - Diagram a de casos de uso da gest ão de prot ocolos dicót icos de dígit os ... 31
Figura 18 - Const rução de um prot ocolo de dígit os ... 32
Figura 19 - Diagram a de casos de uso da gest ão de prot ocolos SSW ... 33
Figura 20 - Diagram a de casos de uso da gest ão de sons ... 34
Figura 21 - Diagram a de casos de uso do perfil de t écnico ... 35
Figura 22 -Diagram a de casos de uso dos t est es ... 36
Figura 23 - Form ulário de início de t est e ... 37
Figura 24 - Diagram a de casos de uso do perfil de Ut ilizador ... 38
Figura 25 - Form ulário de regist o de um novo Pacient e ... 39
Figura 26 - M odelo físico da base de dados ... 41
Figura 27 - Leit or do cart ão do cidadão ... 42
Figura 28 - Janela de pin da aplicação do cart ão do cidadão ... 43
Figura 29 - Leit or do cart ão do cidadão com pin pad ... 43
Figura 30 - Realização de t est es verbais ... 45
vii
Figura 32 - Aplicação para disposit ivo Android ... 47
Figura 33 - Inserção de sons no sist em a ... 49
Figura 34 - Adição de novo pr ot ocolo de dígit os ... 51
Figura 35 - Form ulário de realização de um t est e ... 52
Figura 36 - Relat ório de result ados de t est e dicót ico de dígit os ... 53
Figura 37 - Aplicação em funcionam ent o em Window s XP, Vist a, 7 e 8 ... 55
Figura 38 - Test e em M ac OS 10.5 Leopard com erro ... 56
Figura 39 - Test e em M ac OS 10.8 M ount ain Lion com f alha ... 57
Figura 40 - Test e em Linux 11.10 com falha ... 57
viii
Índice de tabelas
Tabela 1 - Requisit os do SI... 19
Tabela 2 - Leit ura de dados do cart ão do cidadão ... 43
Tabela 3 - Requisit os m ínim os de sist em a Java ... 58
Tabela 4 - Requisit os m ínim os de sist em a Post gres ... 58
Tabela 5 - Requisit os m ínim os de sist em a CC ... 59
Tabela 6 -Requisit os m ínim os de sist em a SI com base de dados local ... 59
ix
Lista de anexos
x
Lista de acrónimos
GIBS – Grupo de Invest igação em Bioacúst ica e Sist em as CC – Cart ão do Cidadão
SI – Sist em a de Inform ação
SIBC - Sist em as de Inform ação Baseados em Com put adores TI – Tecnologias de Inform ação
PA – Processam ent o Audit ivo
PPA – Pert urbação do Processam ent o Audit ivo SSW – St aggered Spondaic Word
PDSI – Processo de Desenvolviment o de um Sist em a de Inform ação ES – Engenharia de Sof t w are
SAM – Sist em a de apoio ao m édico
1
1.
Int rodução
1.1.
Âmbito do projecto
A present e dissert ação enquadra-se no Grupo de Invest igação em Bioacúst ica e Sist em as (GIBS) e descreve o t rabalho realizado durant e as cadeiras de Project o 1 e Project o 2 do M est rado de Sist em as e Tecnologias de Inform ação para a Saúde.
O object ivo do project o é desenvolver um Sist em a de Inform ação para a realização de t est es de Audição Dicót ica e Binaural.
1.2.
Objectivos e motivação
O object ivo principal project o passa por im plem ent ar um sist em a de inform ação que perm it a que sejam realizados t est es dicót icos e de int eracção binaural recorrendo às t ecnologias de inform ação.
Est e é um project o inovador no sent ido que não existe nenhum SI no m ercado Port uguês com as caract eríst icas específicas que perm it am a realização dos t est es.
Act ualm ent e t odos os t est es são realizados recorrendo a leit ores de CD e folhas de papel, em bora seja um sist em a funcional, recorre a procedim ent os ant iquados e que facilm ent e poderão int roduzir erros nos result ados.
O SI foi desenvolvido a nível académ ico, m as sem pre com a m ot ivação de poder vir a ser ut ilizado de form a consist ent e num am bient e real.
1.3.
Organização da dissertação
Est a dissert ação encont ra-se dividida em seis capít ulos.
O segundo capít ulo é com post o por um est ado da art e em SI, sendo descrit a a sua evolução no t em po e os seus principais recursos. Ainda nest e capít ulo é feit a um a descrição dos SI na saúde, do processam ent o audit ivo e dos t ipos de t est es im plem ent ados.
2 No quart o capít ulo é efect uada a análise de requisit os do SI, apresent ada a t ecnologia ut ilizada e são descrit os os pont os m ais relevant es da im plem ent ação, a est rut ura de dados e o SI im plem ent ado na form a concept ual.
No quint o capít ulo é efect uada um a avaliação do SI desenvolvido, quant o às suas caract eríst icas e aos seus requisit os.
3
2.
Est ado da Art e
2.1.
Sistemas de informação
Sist em a de inform ação é a expressão ut ilizada para denom inar as act ividades de aquisição, arm azenam ent o, processam ent o, m anipulação e análise de informação. (Filomena Cast ro Lopes, 2009)
Inform ação por si só cont ém vários significados, o t erm o associado aos SI, pode ser definido com o um conjunt o de dados organizados de form a com preensível e que perm it a um a fácil int erpret ação.
Por out ro lado dados represent am um conjunt o de variáveis independent es que não t em ut ilidade at é serem analisados convenient em ent e. Através da análise e caso os dados sejam relevant es, são ent ão convert idos em informação. Os dados só são efect ivam ent e út eis a partir do m om ent o que é possível obt er um t ipo de inform ação. (West , 1996)
Os SI evoluíram nat uralm ent e ao longo dos anos associados à evolução da t ecnologia, ant es da era dos com put adores os SI eram baseados em grandes arquivos onde eram arm azenadas grandes quant idades de inform ação regist ada em papel.
A funcionalidade dos prim eiros SI era reduzida, serviam apenas para armazenar e consult ar inform ação, sendo a consult a um a t arefa que podia apresent ar algum a dificuldade caso o arquivo não est ivesse convenient em ent e organizado. (The Com put er Societ y (IEEE-CS), 2005) Com o evoluir das t ecnologias de inform ação (TI) e o aparecim ent o dos com put adores iniciou-se o abandono dos SI em form at o de papel e surgiram os sist em as de inform ação bainiciou-seados em com put adores (SIBC)1. (Filom ena Cast ro Lopes, 2009)
Os SI agregados às TI t ornaram -se m ais funcionais e a aquisição, arm azenam ent o, recuperação, m anipulação e t ransm issão de informação passou a ser feit a de form a m ais sim ples e m ais rápida com inúm eras vant agens.
A opt im ização do fluxo da inform ação permit e um a clara redução de cust os operacionais e adm inist rat ivos, aum ent ando-se a produt ividade e a int egridade da inform ação.
As t om adas de decisão e análises ou cruzam ent o de dados t ornam -se m ais fáceis e podem at é ser efect uadas direct am ent e pelo SI. (Varajão, 2010)
O aut or O’Brien definiu os recursos que se relacionam num SI (Figura 1):
1
4
Pessoas – As pessoas que int eragem com um SI, podem ser especialist as t ais com o gest ores de bases de dados, adm inist radores de rede ou sim ples ut ilizadores responsáveis pela int rodução e m anipulação de dados no SI.
Hardw are – Todos os com ponent es físicos necessários para o correct o funcionam ent o do SI, podem ser com put adores, periféricos de ent rada e periféricos de saída, aparelhos de ar condicionados para correct a refrigeração dos servidores, ent re out ros.
Softw are – Todo o soft w are ut ilizado no SI.
Base de dados – Local de arm azenam ent o dos dados, geralm ent e de form a relacional.
Rede – Sist em a que perm it e que a inform ação seja part ilhada ent re vários equipam ent os do SI. (O'Brien, 2003)Figura 1 - Representação esquemática da definição de O'Brien
2.2.
Sistemas de informação na Saúde
Os sist em as de inform ação na Saúde são um inst rum ent o de im port ância crít ica para o apoio à decisão clínica e para um a correct a e eficient e gest ão de dados clínicos.
A int rodução dos SI nos hospit ais port ugueses ocor reu em 1994, por via de soft w are que visava a cont abilização da produt ividade.
Ao longo dos últ im os 18 anos m uit as soluções foram im plem ent adas por form a a agilizar e m elhorar os serviços médicos, cont udo a grande dim ensão da área da Saúde obrigou a que o SI fosse divido em subsist emas.
5 Det ect ados os pont os fracos e t endo em m ent e que os SI poderiam ser aproveit ados de form a m ais eficient e para regist o de dados clínicos nasceram o Sist em a de apoio ao m édico (SAM ) e o Sist em a de apoio à prát ica de Enferm agem (SAPE).
A aplicação SAM t em por object ivo inform at izar o regist o e consult a das act ividades diárias das equipas de m édicos. At ravés do SAM a equipa m édica pode, nom eadam ent e:
• Efect uar prescrições de m edicam ent os;
• Requisit ar exames com plem ent ares de diagnóst ico e t erapêut ica; • Prescrever baixas médicas;
Regist ar/ consult ar inform ação clínica recolhida nas consult as, quer seja de caráct er geral ou especificament e de um dos program as de saúde definidos pela Direcção Geral de Saúde;
Consult ar o hist órico clínico do ut ent e, incluindo as pr escrições, consult as e baixas que lhe est ejam associadas. (Paulo Gom es, 2009)Além da inform ação clínica o SAM dispõe ainda de inform ação adm inist rat iva, nom eadam ent e no que respeit a à gest ão de consult as.
O SAPE visa o t rat am ent o e organização da inform ação processada nos act os de enferm agem . Nest a aplicação o profissional de enferm agem pode:
• Consult ar o plano de t rabalho para a int ervenção previst a num det erm inado cont act o incluída no program a das equipas de enferm agem ;
• Regist ar/ consult ar os sint om as apresent ados pelo ut ent e;
• Regist ar/ consult ar as int ervenções de enferm agem com base no diagnóst ico efect uado;
• Consult ar/ regist ar o plano de t rabalho elaborado pelo sist em a com base na inform ação clínica nele inserido;
• Consult ar as t abelas de param et rização e codificação da act ividade de enferm agem. (Paulo Gom es, 2009)
Os SI na saúde evoluíram para um funcionam ent o em rede, t ornando-se mais flexíveis às m udanças, perm it indo cont rolar inform ação essencial que pode evit ar a duplicação de exam es.
O desenvolvim ent o de SI associados à Saúde é um processo que evolui a par com a t ecnologia, act ualm ent e os sist em as deixaram de est ar cent ralizados e disponíveis apenas em inst it uições de Saúde, at ravés da int ernet o ut ent e pode t er acesso a algum a da sua inform ação clínica. Um exem plo dest a evolução é a e-Agenda que perm it e a m arcação de consult as sem necessidade de o ut ent e se deslocar a um cent r o clínico. (M inist ério da Saúde, 2010)
6
2.3.
Registos clínicos
O regist o clínico de um pacient e é na sua form a t radicional um conjunt o de regist os que são arquivados ao longo do t em po e perm it em m ant er um hist órico dos processos de acom panham ent o e t rat am ent o dos pacient es.
Um regist o clínico cont ém um conjunt o de dados relacionados com o pacient e que est ão divididos em dados clínicos (result ant es de observações, t rat am ent os e diagnóst icos) e dados adm inist rat ivos (relacionados com o processo burocrát ico do pacient e).
Nas inst it uições de saúde a part ilha de regist os do pacient e é feit a em t orno dos dados clínicos, assegurando um processo de com unicação eficaz ent r e diversos prest adores de cuidados. Segundo (Teixeira, 2008) podem os encont rar quat ro t ipologias diferent es de organização da inform ação clínica:
Registo clínico de paciente orientado ao tempo – “(t ime-orient ed pat ient record) – t ipologia de organização dos dados de forma cronológica, ident ificando cada episódio pela respect iva dat a. Os dados result ant es do est udo do pacient e, radiologia ou out ro t ipo de exame, são igualment e regist ados pelos clínicos de acordo com um eixo t emporal.”
Registo clínico de paciente orientado à fonte – “(source-orient ed pat ient record) – das primeiras t ipologias de organização de dados clínicos a aparecer, est ando est es organizados de acordo com a sua font e de origem. Port ant o a proveniência dos dados det ermina a cat alogação dos dados e consequent e registo. A ordem é dit ada pela origem da informação (hist órica clínica; exames físicos, result ados dos meios complement ares de diagnóst ico, et c.).”
Registo clínico de paciente orientado ao protocolo – “(prot ocol-orient ed record) – os dados são organizados de acordo com um prot ocolo. Por exemplo, quando o pacient e est á a ser submet ido a um t rat amento específico (diabet es, asma, et c.) são ut ilizados t emplat es padronizados (ou prot ocolos) no registo dos dados. Esses t emplat es t êm um format o pré-est rut urado e est ipulam que dados específicos t êm que ser obtidos e registados pelos clínicos e que plano de t rat ament o irá ser efect uado ao pacient e.”
Registo de paciente orientado ao problema – “(problem-orient ed record) – nest a t ipologia os dados são organizados por problema. A cada doent e é at ribuído um ou mais problemas, sendo que, para cada problema os dados clínicos são organizados de acordo com a est rut ura SOAP:o
Subject ive observat ions – observações subject ivas (dados) da hist ória clínica do pacient e;o
Object ive observat ions – observações object ivas (dados) ident ificados pelo clínico e result ant es dos exames, observações e t est es;o
Assessment – conclusões em t ermos de diagnóstico;o
Plan - plano médico, t rat ament o ou at it ude para resolver o problema.”7 No SI desenvolvido o regist o clínico do pacient e é orient ado ao prot ocolo, por ser um sist em a que t em com o object ivo a realização de dois t ipos de t est es audiológicos.
2.4.
Processamento auditivo
Por definição processam ent o audit ivo (PA) é um conjunt o de capacidades que o indivíduo possui para int erpret ar o que ouve.
At ravés do PA é possível ident ificar a localização dos sons, efect uar discriminação audit iva, reconhecer padrões audit ivos e aspect os t em porais da audição.
O PA é realizado at ravés de um conjunt o de apt idões necessárias para int erpret ar o que o individuo ouve. (Warren, 2010)
Detecção do som – “Ident ificação da presença/ ausência de som. É uma capacidade do sist ema nervoso periférico.”
Sensação sonora – “ É uma experiência que est á direct ament e relacionada comint ensidades, frequências e qualidade do est ímulo sonoro.”
Localização – “É a capacidade de ident ificar o local de origem do som, sendo indispensável uma audição binaural.”
Reconhecimento – “É um processo que exige uma experiencia ant erior, ou seja, é a identificação correct a de um est ímulo por meio de conheciment o previament e adquirido.”
Descriminação – “Consist e na capacidade de det ect ar diferenças ent re padrões sonoros.”
Atenção – “ É a capacidade de ident ificar a mensagem primária na presença de sonscompet it ivos.”
M emória – “ Capacidade de armazenar as informações acúst icas e poder recuperá-laspost eriorment e, quando necessário.”
Compreensão – “ Capacidade de int erpret ar correct ament e o significado da informaçãoacúst ica.”
A realização de t odas est as et apas só é possível quando um indivíduo não possui qualquer pert urbação do processam ent o audit ivo (PPA).
Um a PPA é por definição um a perda ou um at raso de em algum a das et apas do PA, que inviabiliza um a ou m ais apt idões do PA. (M art ins, 2008)
2.4.1. Testes de avaliação do processamento auditivo
8
Processamento auditivo temporal – “ Avaliam a capacidade de analisar os aspect os t emporais da audição, nomeadament e, resolução t emporal, mascaramento t emporal, int egração t emporal e ordenação t emporal.”
Dicóticos – Reproduzem um est ím ulo principal num ouvido e sim ult aneam ent e reproduzem no out r o ouvido um est im ulo com pet it ivo. (Pfeiffer, 2007) Avaliam a capacidade de separar ou int egrar est ím ulos audit ivos diferent es.
M onoaurais de baixa redundância – “Avaliam a capacidade de reconhecer um est ímulo degradado ou modificado apresent ado em cada ouvido separadament e.”
Interacção Binaural (dicótico) – “ Avaliam a capacidade do sist ema audit ivo cent ral processar a informação recebida em ambos os ouvidos ao mesmo t empo (t est es dicót icos).”2.4.2. Testes dicóticos
O t rabalho realizado e descrit o nest a dissert ação apenas incidiu sobre os t est es dicót icos e os t est es de int eracção binaural, cada elem ent o do GIBS t rabalhou sobre um t est e ou um grupo de t est es específico.
Nos subcapít ulos abaixo será feit o enquadram ent o dos t est es e um a breve descrição do seu funcionam ent o, sem ent rar em det alhes relat ivos às caract eríst icas dos sons reproduzidos e a caract eríst icas audiológicas.
2.4.2.1. Teste dicótico de dígitos
O t est e dicót ico de dígit os com eçou por ser usado por Kim ura para t est ar indivíduos com lesões no lobo t em poral, os t est es ant ecessores apresent avam dois pares de palavras em sim ult âneo nos dois ouvidos, e era pedido ao pacient e para repet ir o m aior núm ero de palavras possível. (Kim ura, 1967)
No t est e dicót ico de dígit os são reproduzidos dois dígit os em cada ouvido em sim ult âneo e é pedido ao indivíduo t est ado que repit a os núm eros ouvidos. (Lem os, 2008)
Os dígit os são com binados dois a dois, de form a a eliminar dígit os iguais. A ordenação dos pares é feit a de form a aleat ória e assim é const ruída um a list a de reprodução de pares de dígit os. (Lem os, 2008)
No t est e original são apresent ados 20 est ím ulos dist int os, ou seja, 80 dígit os no t ot al (40 para cada ouvido). O result ado consist e em cont ar o núm ero de dígit os repet idos correct am ent e para cada ouvido em separado. (Lem os, 2008)
9 Est e t est e dest ina-se a avaliar lesões do t ronco cerebral, cort éx e int er-him isféricas. (Tim ot hy N. Welsh, 2000)
2.4.2.2. SSW ou testes de palavras espondaicas alternadas
O t est e SSW foi um dos prim eiros t est es de avaliação do processam ent o audit ivo cent ral em pregue por Audiologist as, na act ualidade cont inua a ser ut ilizado para avaliar o processam ent o audit ivo cent ral, o t est e é frequent em ent e realizado a crianças com dificuldades na linguagem e na aprendizagem. (PubM ed.gov, 1983)
No t est e SSW, os est ím ulos são form ados por palavras com duas sílabas longas alt ernadas. Cada est ím ulo é com post o por quat ro palavras, as prim eiras duas palavras são apresent adas isoladam ent e designando-se por não com pet it ivos, a t erceira e quart a são apresent adas em sim ult âneo nos dois ouvidos designando-se por com pet it ivo. (M art ins, 2007)
O t est e inicia-se sem pre no ouvido direit o e vai alt ernado ent re ouvido direit o e ouvido esquerdo, dest a form a m et ade dos est ím ulos t em início no ouvido direit o e out ra met ade t em início no ouvido esquerdo. (M art ins, 2007)
O t est e na sua versão port uguesa é com post o por 40 it ens cada um form ado por quat ro palavras, t ot alizando um t ot al de 160 vocábulos. (M art ins, 2007)
A int erpret ação dos result ados dest e t est e é feit a com base nos result ados obt idos na part e com pet it iva e na part e não com pet it iva. (PubM ed.gov, 1983)
O indivíduo deve repet ir o que ouviu obedecendo à ordem de apresent ação das palavras. (M art ins, 2007)
2.5.
Aplicação dos testes nos dias de hoje
Apesar de exist irem diferenças ent re os dois t ipos de t est es, a sua aplicação é feit a da m esm a form a.
Act ualm ent e os t est e são adm inist rados de form a m anual, podendo de um a form a geral dizer-se que são adm inist rados recorrendo a um SI que quadizer-se não aproveit a as vant agens das TI. A adm inist ração dos t est es é feit a recorrendo a um cd que cont ém os prot ocolos2 gravados, associado a est e cd exist em folhas de respost a em papel que são preenchidas pelo Audiologist a m anualm ent e com as respost as do Pacient e. (Lem os, 2008)
2
10 A análise das respost as é efect uada m anualm ent e e apenas no final da administ ração dos t est es.
2.6.
Conclusões
Apesar de a adm inist ração dos t est es já ser feit a recorrendo a um SI, verifica-se que é um SI que não faz uso das m ais recent es t ecnologias de inform ação e que apesent a várias desvant agens:
A criação de um novo prot ocolo é um a t arefa que requer a gravação de um novo cd e a criação de um a nova f olha de respost as.
A exist ência de vários prot ocolos dist int os obriga a que exist am vários cd’s e várias folhas de respost a.
A análise de result ados é um a et apa que pode ser considerada crít ica pois não é possível elim inar o fact or de erro hum ano.Com as TI exist ent es nos dias de hoje é possível const ruir de raiz um SI que opt im ize a adm inist ração de t est es, análise de respost as e const r ução de prot ocolos.
A criação de raiz de um novo SI de inform ação devidam ent e planeado e est rut urado assent e nas novas t ecnologias perm it e, colm at ar as falhas apresent adas sim plificando os seguint es processos:
Gest ão da inform ação clínica;
Criação de prot ocolos de t est e;
Adm inist ração de t est es;11
3.
M et odologia de Desenvolvim ent o
do Sist em a de Inform ação
3.1.
Processo de desenvolvimento de SI
Segundo (Teixeira, 2008) o processo de desenvolvim ent o de um sist em a de inform ação (PDSI) pode ser iniciado de duas form as dist int as:
Com base na t ecnologia;
Com base no problem a;No primeiro caso procura-se um a solução com base numa t ecnologia específica independent em ent e do problem a inicial.
No segundo caso procura-se a m elhor form a de solucionar o problem a inicial independent em ent e da t ecnologia escolhida para at ingir o object ivo.
O PDSI deve ser efect uado com algum as precauções, devem ser ouvidos t odas as pessoas responsáveis pela organização onde vai ser im plement ado o SI, bem com o t odas as pessoas que direct a ou indirect am ent e vão ser afect adas com a int rodução do novo SI e finalm ent e adopt ar m et odologias que proporcionem o correct o levant am ent o de requisit os e que levem à correct a solução do problem a. Por últ im o é necessário fazer o levant am ent o t ecnológico e enquadrá-lo na solução pret endida por form a a cont rolar as despesas associadas às TI.
Um a falha num a das et apas do PDSI pode originar um SI que não soluciona o problem a exist ent e, que em alguns casos pode piorar a sit uação exist ent e, ou causar resist ência por part e dos ut ilizadores, que cont inuaram a ut ilizar os m ét odos exist ent es ant es do SI.
No SI desenvolvido a abordagem ut ilizada foi m ot ivada pelo problem a, significa que o SI pret ende solucionar um problem a já exist ent e, no ent ant o e devido a rest rições económ icas foi necessário t am bém fazer a abordagem com base na t ecnologia. Dest a form a t ent ou-se encont rar o pont o m édio que sat isfaz as duas abordagens sem prejuízo da solução final.
3.2.
M etodologias de desenvolvimento
12 A origem da Engenharia de Soft w are deveu-se ao grande crescim ent o de aplicações inform át icas que se realizou nos últ im os anos. Associado a est e crescim ent o est á o aum ent o de com plexidade das m esm as que fez com que fosse necessário criar m et odologias que perm it issem de form a eficient e cont rolar t odas as fases de um project o.
Segundo (Teixeira, 2008),PDSI não é um a t arefa linear e acarret a alguns riscos t ais com o:
Gast os superiores ao orçam ent o inicial;
Tem po de desenvolvim ent o superior ao t em po est ipulado inicial;
Baixa qualidade e flexibilidade dos SI desenvolvidos;
Excesso ou défice de funcionalidades que não correspondem à solução do problem a; Para cont ornar est es riscos à m edida que a indust ria do soft w are evoluiu foram desenvolvidas m et odologias e t écnicas que visão t ornar o PDSI um a act ividade m ais produt iva e eficient e. M et odologia na ES é um processo com um a série de et apas recom endadas para a const rução de um soft w are.Ao longo dos anos foram surgindo várias m et odologias de desenvolvim ent o de soft w are, a escolha de um a delas deve ser feit a de form a ponderada, por form a a ser com pat ível com o problem a e com os recursos exist ent es.
Os SI com eçaram por ser desenvolvidos de form a sequencial no que se denom inou por m et odologia em Cascat a represent ada esquem at icam ent e na Figura 2, est a no ent ant o com eçou a ser abandonada em favor de m et odologias m ais eficazes, por ser um m odelo de risco e propício a falhas. (Select ing a Developm ent Aproach, 2008)
Figura 2 – Representação gráfica do desenvolvimento em cascata
13 Out ro aspect o negat ivo do desenvolvim ent o em cascat a é o fact o de não exist ir feedback ao longo do desenvolvim ent o, aum ent ando a probabilidade de se alcançar um a solução final que não cum pra ou não sat isfaça na ínt egra os result ados esperados. (Select ing a Development Aproach, 2008)
Com o o SI apenas será t est ado nas últ im as et apas da m et odologia quant o m ais cedo for com et ido um erro m ais t arde será det ect ado e por consequência m ais m orosa será a sua correcção.
Act ualm ent e e aliado à rápida evolução da t ecnologia e ao fact o de as organizações t erem cont ext os de rápida m udança t orna-se im prat icável definir um docum ent o final de requisit os nas prim eiras et apas do processo. (Teixeira, 2008)
Todos est es fact ores negat ivos levaram a que a indúst ria de ES procura-se m ét odos m ais flexíveis e que adapt em a requisit os dinâmicos.
Para colm at ar as falhas do desenvolviment o em cascat a surgiram as m et odologias it erat ivas e increm ent ais.
A ideia de desenvolvim ent o de soft w are a partir dest as m et odologias passa por t rabalhar inicialm ent e com um conjunt o reduzido de requisit os que permit am const ruir versões int erm édias, versões est as que são analisadas levando a um novo levant am ent o de requisit os e const rução de um a nova versão, est e processo é repet ido at é ser at ingida a versão final. (Videira, 2005)
Segundo (Videira, 2005) o desenvolvim ent o it erat ivo apresent a um a série de vant agens face ao desenvolvim ent o em cascat a:
Os riscos e dúvidas com m aior im port ância são ident ificados no início do project o, nas it erações iniciais onde ainda é possível t om ar medidas para os corrigir sem grandes cust os associados;
Os ut ilizadores t êm um a part icipação act iva, o que perm it e ident ificar os requisit os reais do sist em a;
A execução de t est es cont ínuos ao longo das várias versões perm it e um a avaliação object iva do est ado do project o;O desenvolvim ent o increment al perm it e aument ar a dim ensão do project o pouco-a-pouco ao longo das várias versões.
14 Figura 3 - Representação gráfica do desenvolvimento iterativo e incremental
As m et odologias increm ent ais e it erat ivas t êm com o desvant agem a burocracia e o volum e excessivo de docum ent ação e form alism os que são geradas ao longo das várias it erações. Em 2001 um a equipa de Engenheiros de Soft w are reuniu-se nos Est ados Unidos da Am érica para discut ir e desenvolver m et odologias alt ernat ivas que colm at assem as falhas dos m ét odos exist ent es at é ent ão.
Dest a reunião surgiram as met odologias ágeis com o respost a ao fact o das m et odologias já não conseguirem lidar com o rit m o de m udança e grau de incert eza que o m ercado act ual, dinâm ico e com pet it ivo requer. (Teixeira, 2008)
Em cont rapont o com os m ét odos m ais ant igos as m et odologias ágeis valorizam um processo de respost a rápido at ravés do envolvim ent o dos desenvolvedores em t em po real com os client es obt endo o seu feedback at ravés da apresent ação de soft w are funcional num a est rut ura alt am ent e flexível à m udança.
Os m ét odos ágeis t ent am m inim izar os riscos de falhas at ravés do desenvolvim ent o em curt os períodos de t em po, denom inados de it erações.
Cada it eração funciona com o o desenvolvim ent o de um pequeno project o, onde são im plem ent adas algum as das funcionalidades.
15 Figura 4 - Representação esquemática das metodologias ágeis
3.3.
Prototipagem
Na fase inicial do project o verificou-se que existiam alguns requisit os que não eram consist ent es e que poderiam vir a sofrer alt erações. Com o est e é um sist em a que est á a ser desenvolvido pela prim eira vez e com o não existem sist em as que sirvam de base de com paração o design e o int erface gráfico levant avam algum as dúvidas de funcionalidade. Para fazer face às condicionant es enum eradas em cim a opt ou-se por um a m et odologia evolut iva, em que o sist em a é const ruído em várias et apas. Cada um a das et apas é t est ada pelo client e, com a finalidade de avaliar os requisit os implement ados e descobrir novos requisit os para a et apa seguint e. Est e processo é repet ido at é se chegar a um a versão final onde sejam cum pridos t odos os requisit os.
Das m et odologias evolut ivas opt ou-se pela prot ot ipagem (Figura 5), est a m et odologia t em por base a const rução de prot ót ipos visuais, que podem ou não ser funcionais. Com est a m et odologia o client e consegue t er um a m elhor percepção da aplicação e das suas funcionalidades.
16 Figura 5 – Representação gráfica da metodologia de prototipagem
Ao longo do desenvolvim ent o do SI foram const ruídos inúm eros prot ót ipos, nem t odos funcionais, m as t odos gráficos, por form a a avaliar a melhor form a de int eracção.
Junt am ent o com est es prot ót ipos foi elaborada docum ent ação que regist a as evoluções, alt erações efect uadas e os requisit os das versões seguint es.
A Figura 6 represent a um dos prim eiros prot ót ipos não funcionais em que é definido o esquem a de navegação, concluída a validação por part e da equipa do GIBS passou-se à im plem ent ação do prot ót ipo.
17
4.
Análise e desenvolvim ent o
4.1.
Requisitos
O sucesso ou insucesso de um soft w are ou SI depende da form a com o é efect uado o levant am ent o de requisit os e da form a com o cum pre as espectat ivas dos ut ilizadores.
O processo de levant am ent o de requisit os não é um a t arefa sim ples e deve ser encarada com t oda a seriedade pois é o pont o-chave de t odo o softw are um a falha nest a fase poderá deit ar por t erra t odo o t rabalho realizado ao longo de meses.
Os requisit os devem com eçar a ser definidos depois de definas as rest rições do project o, quer sejam est as económ icas ou t ecnológicas, por form a a fazer o real enquadram ent o da solução propost a e a sat isfazer os object ivos da organização onde se insere. (Filom ena Cast ro Lopes, 2009)
Ao longo dos vários prot ót ipos por que passou o SI aqui apresent ado, foi const ruída um a list a de requisit os, em conjunt o com os orient adores do project o e fut uros ut ilizadores da aplicação. Est es requisit os foram ident ificados com o funcionais e não funcionais.
Requisit os funcionais são aqueles que descrevem os serviços que o sist em a deverá oferecer, de um a form a genérica são t odos aqueles que respondem à pergunt a “ O que faz o sist em a?” . (Teixeira, 2008)
Os requisit os não funcionais são aqueles que descrevem as rest rições na im plem ent ação do sist em a são expressos em t erm os de cust os, desem penho, segurança, fiabilidade, port abilidade e usabilidade. É est a classe de requisit os que limit a m uit as das vez a form a com o os requisit os funcionais são im plement ados. (Teixeira, 2008)
Da análise efect uada ao longo do project o definiu-se que o SI deveria cum prir os requisit os apresent ados na Tabela 1.
Descrição Tipo
Deve ser desenvolvido com o m ínim o cust o associado Não funcional
Deve garant ir a segurança de dados Não funcional
Deve ser m ult iplat aform a, independent e do sist em a operat ivo Não Funcional
Deve ser m ult ipost o Não funcional
Deve t er capacidade de funcionar com bases de dados locais, ou com bases de dados ext ernas alojadas nos servidores do GIBS.
Não Funcional A int erface gráfica deve ser com pat ível com a ut ilização de ecrãs t áct eis. Não Funcional Deve t er um ecrã de Login para o ut ilizador efect uar a aut ent icação,
at ravés da int rodução do nom e de ut ilizador e passw ord.
Funcional Deve perm it ir t rês t ipos dist int os de perfis de ut ilizador:
1- Adm inist rador; 2- Técnico; 3- Ut ilizador;
18
Um ut ilizador pode t er m ais do que um perfil. Funcional
O Adm inist rador deve t er privilégios para gerir ut ilizadores: 1- Criar novos Administ radores, Técnicos ou Ut ilizadores; 2- Act ivar/ Desact ivar Adm inist radores, Técnicos ou Ut ilizadores;
Funcional
O Adm inist rador deve poder alt erar os dados pessoais dos Pacient es. Funcional O Adm inist rador deve poder gerir os t est es dicót icos de dígit os e SSW:
1- Criar novos prot ocolos; 2- Act ivar/ Desact ivar prot ocolos; 3- Edit ar prot ocolos;
Funcional
A criação de prot ocolos é associada ao post o. Funcional
A criação de um prot ocolo SSW deve ser feit a apenas de form a m anual. Funcional A criação de um prot ocolo dicót ico de dígit os deve ser feit a de quat ro
form as dist int as: 1- M anual;
2- M anual com repet ição; 3- Sem iaut om át ica; 4- Aut om át ica;
Funcional
Os prot ocolos dicót icos de dígit os e SSW devem poder ser criados para efeit os de dem ost ração.
Funcional O Adm inist rador deve poder gerir os sons do SI:
1- Adicionar novo som ; 2- Act ivar/ Desact ivar som ; 3- Edit ar Som ;
Funcional
O Adm inist rador deve poder gerir os sons da calibração. Funcional Os sons adicionados na aplicação devem ficar associados ao post o. Funcional O Adm inist rador deve t er acesso às opções globais do SI. Funcional O Técnico deve poder efect uar a calibração de som da aplicação. Funcional Devem existir t rês sons de calibração dist int os. Funcional Os sons de calibração devem t er ident ificação das suas caract eríst icas
visíveis.
Funcional A calibração deve ser guardada associada ao post o. Funcional Deve ser possível alt erar os parâm et ros da calibração enquant o se
reproduzem os sons de calibração.
Funcional No caso de já exist ir um a calibração guardada, a calibração deve ser
carrega no início da aplicação.
Funcional
O Audiologist a ao alt erar a calibração deverá t er inform ação relat iva à calibração act ual e à calibração guardada.
Funcional A escala de som no painel de calibração deverá ser represent ada em
percent agem ent re 0% e 100%.
Funcional
O Técnico deve poder pesquisar pacient es. Funcional
O Técnico deve poder consult ar o hist órico dos pacient es. Funcional O Técnico deve poder gerir a sua agenda pessoal:
1- Consult ar agenda; 2- Efect uar m arcações;
Funcional
O Técnico deve poder realizar t est es dicót icos de dígit os e SSW. Funcional O Técnico deve t er acesso a um a breve descrição do funcionam ent o dos
t est es.
Funcional O Técnico deve t er opção de efect uar um t est e em m odo de
dem onst ração.
Funcional
19 som seguint e no final da reprodução do som ant erior.
No final de um t est e o t écnico deve poder descart ar ou guardar na base de dados os result ados do t est e.
Funcional O Ut ilizador deve poder gerir a agenda de t odos os Técnicos:
1- Consult ar agendas; 2- Efect uar m arcações;
Funcional
O Ut ilizador deve poder pesquisar Pacient es. Funcional
O Ut ilizador deve poder consult ar o hist órico dos Pacient es. Funcional O Ut ilizador deve poder regist ar novos Pacient es. Funcional Todos os ut ilizadores da aplicação devem poder alt erar a sua passw ord. Funcional O SI deve ser com pat ível com o car t ão do cidadão por t uguês. Funcional Um ut ilizador deve poder efect uar login na aplicação ut ilizando o cart ão
do cidadão por t uguês.
Funcional Deve ser possível preencher os form ulários de regist o de Pacient es,
Técnicos e Ut ilizadores, aut om at icam ent e at ravés da leit ura dos dados do cart ão do cidadão.
Funcional
Deve ser possível pesquisar pacient es at ravés do cart ão do cidadão. Funcional Deve ser possível im primir em format o de papel ou PDF o relat ório de um
det erm inado t est e de um Pacient e com as respost as cert as e erradas.
Funcional Um relat ório deve t er ident ificação do post o onde foi realizado o t est e e a
ident ificação do Técnico que realizou o t est e.
Funcional
Deve ser gerado um núm ero identificador único para cada post o aut om at icam ent e.
Funcional Deve ser desenvolvida um a aplicação com pat ível com um disposit ivo
m óvel e que perm it a a realização de t est es dicót icos de dígit os a pessoas que não consigam falar.
Funcional
Tabela 1 - Requisitos do SI
4.2.
Tecnologia utilizada no desenvolvimento da solução
Para o desenvolvim ent o do SI de form a a cum prir os requisit os não funcionais, foram ut ilizadas t ecnologias open source e m ult iplat aform a, dest a form a foi possível desenvolver o SI com o m ínim o de cust os associados garant indo que a aplicação é independent e do sist em a operat ivo em que é execut ada.
Em baixo é enum erada t oda a t ecnologia que foi ut ilizada para a const rução do Sist em a de Inform ação.
4.2.1. Java
20 Foi ut ilizada a versão 7, a m ais recent e exist ent e no início da im plem ent ação do SI, est a versão poderá causar alguns problem as de com pat ibilidade em com put adores com arquit ect uras m ais ant igas e que já não est ão disponíveis no m ercado act ualm ent e.
4.2.2. IDE’s de desenvolvimento
Para o desenvolvim ent o foram ut ilizados dois IDE’s dest int os, para a aplicação principal a escolha recaiu sobre o Net Beans, por ser um IDE que perm it e a const rução de am bient es gráficos de form a bast ant e eficient e, gerando sem pre o código associado a cada elem ent o, garant indo que os requisit os não funcionais associados aos cust os cont inuam a ser cum pridos. O segundo IDE foi ut ilizado para desenvolver um a aplicação m óvel para Android, a escolha recaiu sobre o Eclipse, por ser o IDE oficial de desenvolvim ent o para est a plat aform a, e porque à sem elhança do Net Beans garant e que os requisit os não funcionais são cum pridos. (Cinar, 2012)
4.2.3. Postgres SQL
O Post gres SQL foi o m ot or de base de dados escolhido, por ser grat uit o e por t er um conjunt o de funcionalidades que perm it em de form a fácil e int uit iva gerir os dados associados ao SI. Das funcionalidades que fizeram a escolha recair sobre o Post gres dest aco os t ipos de dados flexíveis que perm it em por exem plo criar um a coluna com dados arm azenados num vect or. (Post gres, 2012)
4.2.4. Cartão do Cidadão
O SI foi desenvolvido de form a a assegurar a compat ibilidade com o cart ão do cidadão port uguês, por considerar que est e é um a m ais-valia a qualquer sist em a de inform ação recent e.
Para im plem ent ação dest a funcionalidade foi ut ilizado o SDK fornecido pela ident idade gest ora do CC, e um leit or de cart ões sim ples.
21 O Android foi escolhido para o desenvolvim ent o de um a aplicação m óvel com pat ível com a aplicação principal, por ser um sist em a operat ivo livre e por exist irem diversos equipam ent os de baixo cust o no m ercado com est e sist em a operat ivo.
Out ro fact or considerado na escolha foi o fact o de a linguagem de program ação ut ilizada ser o Java.
4.3.
Interface Gráfica
A int erface gráfica que perm it e a int eracção hom em m áquina é um as das com ponent es m ais im port ant es num SI, um a int erface usável e agradável pode ser favorável à decisão de aquisição ou ut ilização de um SI, um a int erface sem est as caract eríst icas pode deit ar por t err a t odo um project o por m uit o bem im plem ent ado que est eja.
Um a int erface gráfica bem definida deve garant ir facilidade de int eracção por part e do ut ilizador, não deve exigir um t em po de aprendizagem m uit o grande sobre pena de redução de produt ividade e int rodução de erros inaceit áveis no SI, o que levará ao seu fracasso. (Teixeira, 2008)
Um dos requisit os não funcionais relat ivos à int erface gráfica prevê que a aplicação seja com pat ível com ecrãs t áct eis, opt ou-se por um a abordagem diferent e das aplicações t radicionais baseadas em barras de m enus, por form a a facilit ar a int eracção por part e do ut ilizador sem ut ilização do rat o.
Todo o am bient e gráfico t em com o inspiração a linguagem de design da M icrosoft , M et ro UI. A equipa da M icrosoft que desenvolveu est a linguagem inspirou-se nos sinais do M et ro de Seat t le onde a com panhia t em a sua sede e no est ilo de design Suíço desenvolvido na Suíça em 1950. (Burns, 2012)
O est ilo de design Suíço define a ut ilização dos seguint es elem ent os: t ipografia, iconografia e organização de elem ent os de form a proporcional.
Tipografia – A font e ut ilizada para o t ext o deve ser lim pa e sim ples sem adornos desnecessários que dist raiam o dest inat ário da m ensagem. (Burns, 2012)22
Organização proporcional dos elem ent os – De form a a m ant er a organização e a sim plicidade para que nada desvie a at enção do dest inat ário da m ensagem o cont eúdo é organizado em form as geomét ricas iguais ou que perm it am um a visualização com espaçam ent o igual ent re os elem ent os, o t am anho da font e ut ilizada no t ext o e os ícones é igual em t odos os object os. (Burns, 2012)Um dos pont os-chave do M et ro UI (Figura 7) é um a m elhor object ividade do cont eúdo das aplicações, recorrendo a cont eúdos gráficos coloridos e expressivos das funcionalidades é possível melhorar a experiencia de ut ilização. (Schooley, 2012)
A linguagem de design foi desenvolvida de form a a agrupar t arefas sem elhant es, e a eliminar m enus e out ros aspect os gráficos supérfluos, o que m elhora a velocidade de ut ilização. (Schooley, 2012)
Figura 7 - M etro UI do novo W indow s 8
4.3.1. Definição da interface gráfica
A int erface gráfica t eve com o inspiração o M et ro UI, no sent ido em que a int eracção do ut ilizador com a aplicação é feit a at ravés de grandes bot ões coloridos, t udo o rest o foi desenvolvido e planeado de raiz.
A int erface gráfica criada t em um a ident idade própria pois est á adapt ada ao m áxim o às funcionalidades requeridas, foi um dos grandes desafios no desenvolvim ent o do SI, e que cum pre na ínt egra o requisit o não funcional de que a aplicação deverá ser com pat ível com ecrãs t áct eis.
23 Caso o ut ilizador já est eja fam iliarizado com os novos sist em as da M icrosoft que recorrem ao M et ro UI a adapt ação à aplicação será feit a de f orm a nat ural.
O aspect o negat ivo dest a escolha recai sobre os ut ilizadores que não est ão fam iliarizados com produt os M icrosof t , pois a aplicação quando execut ada em sist em as operat ivos que não o Window s cont inuará a t er o m esm o aspect o gráfico, para est es ut ilizadores a curva de aprendizagem poderá ser um pouco superior.
Para um a m elhor com preensão da int erface desenvolvida segue-se um a explicação det alhada de t odas as suas caract eríst icas e funcionalidades (Figura 8).
Figura 8 – Definição da interface gráfica
1- Título – Ident ifica o painel onde se encont ra o ut ilizador.
2- Painel de agrupamento – Os painéis de agrupament o t êm no m áxim o quat ro bot ões visíveis t odos coloridos, não t endo as cores dos bot ões um significado específico at ribuído.
3- Botão de continuação – Bot ão apenas visível se o painel t iver cont inuação. Um painel t em cont inuação quando exist em m ais de 4 bot ões, no painel de agrupam ent o.
4- Barra de estados – Est a barra é const ant e ao longo de t oda a aplicação, é aqui que são apresent adas inst ruções ao ut ilizador e onde são exibidas m ensagens geradas pela própria aplicação.
A barra pode apresent ar 4 cores, que t em significados dist int os:
Cinzent o – Para inform ações sobre o funcionam ent o da aplicação;
Verde – Para operações realizadas com sucesso.
Am arelo – Para erros não crít icos, ou consult as à base de dados sem ret orno de result ados.24
5- Botão de retroceder – Est e bot ão perm it e navegar um nível para t rás nos painéis, at é ao painel de perfis. No painel de perfis o bot ão é subst it uído pelo bot ão de logout .
Figura 9 - Painel de tarefa
6- Painel de tarefa – (Figura 9) Painéis onde o ut ilizador realiza as t arefas da aplicação.
Figura 10 - Botões da aplicação
25 7.1 – Botão de agrupamento – Os bot ões de agrupam ent o são represent ados com t ext o no cant o inferior direit o e com um a im agem ilust rat iva no lado esquerdo. Os bot ões de agrupam ent o dão acesso a novos painéis de agrupam ent o ou a um painel de t arefa.
7.2 – Botão de tarefa – Os bot ões de t arefa seguem a m esm a represent ação gráfica dos bot ões de agrupam ent o, em bora sejam m ais pequenos. Est es bot ões apenas aparecem nos painéis de t arefa, e execut am a t arefa descrit a no t ext o.
7.3 – Botão de tarefa simples – Est es bot ões apenas aparecem nos painéis de t arefa durant e a realização de um t est e, não possuem t ext o e t êm com o única função m arcar um a respost a cert a ou errada.
Figura 11 - Janela de aviso
8- Janela de aviso – (Figura 11) Est a janela foi desenvolvida de origem para se enquadrar com o est ilo da aplicação, é apresent ada ao ut ilizador sem pre que pode ocorrer algum a alt eração no est ado da aplicação ou na est rut ura de dados. É com post a por um a m ensagem de aviso e por dois bot ões de t arefa.
4.4.
Descrição conceptual da solução implementada
A descrição da aplicação desenvolvida é apresentada de form a concept ual at ravés de diagram as de casos de uso por form a a t ornar m ais fácil a leit ura de t odas as funcionalidades disponíveis e por quem podem ser ut ilizadas.
Um diagram a de casos de uso descreve as funcionalidades de um sist ema, por out ras palavras pode afirm a-se que é um conjunt o de diagram as que descreve a sequência de event os que um act or ut iliza para com plet ar um processo. (Rosenberg, 2007)
26 Um act or é um hum ano ou um a m áquina que int erage direct am ent e com o sist em a para execut ar t arefas, é sem pre ext erno ao sist em a e est á exclusivament e ligado a casos de uso. Um caso de uso é um a especificação de um conjunt o de acção que o sist em a execut a e que produzem um result ado que pode ou não ser visível pelo ut ilizador. Os casos de uso são represent ados por um a elipse, com o nom e no seu int erior.
Os casos de uso podem ser relacionados ent re si de t rês form as dist int as, at ravés de um a ligação norm al, at ravés de um include ou at ravés de ext end.
As ligações norm ais represent am o fluxo de cont inuidade da aplicação, as ligações m arcadas com um include represent am casos que ocorrem obrigat oriament e, as ligações com ext end represent am casos de uso opcionais, ou seja que nem sem pre ocorrem.
As ligações norm ais são represent adas por set as e as ligações com include ou ext end são represent adas por set as que cont ém a descrição da sua função. (Rosenberg, 2007)
Nos casos de uso serão apresent ados 4 act ores dist int os:
Adm inist rador
Técnico
Ut ilizador
Pacient eA represent ação dos vários act ores no diagram a será dividida por m ódulos, por form a a m ant er o nível de com plexidade do diagram a baixo, sem pre que se just ificar serão incluídas com o form a de com plem ent o na descrição dos casos de uso, im agens reais da aplicação.
4.4.1. Sistema
27 Figura 12 – Diagrama de casos de uso do SI
Descrição dos casos de uso
Login com nom e de ut ilizador e passw ord – (Figura 13) O ut ilizador efect ua a aut ent icação na aplicação int roduzindo as suas credenciais, nom e de ut ilizador e passw ord.
Login com cart ão do cidadão – (Figura 13) O Ut ilizador depois de passar pelo m odo de aut ent icação com nom e de ut ilizador e passw ord pode escolher aut ent icar-se com CC m ediant e a int rodução de um código pin.
Figura 13 - Ecrãs de login da aplicação
Verifica leit or de cart ões – Ao escolher o mét odo de aut ent icação com CC a aplicação verifica a exist ência do hardw are necessário para efect uar a operação.
Verifica credenciais de acesso – A aplicação acede à base de dados e verifica se as credenciais int roduzidas est ão correct as.
28 t odos os perfis que t em associados à sua cont a. Os casos de uso represent ados no diagram a em form a de agregação correspondem a cada t ipo de perfil e serão explicados em det alhe.
Figura 14 - M enu de escolha de perfil
4.4.2. Perfil de Administrador
29 Figura 15 - Diagrama de casos de uso do perfil de Administrador
Descrição dos casos de uso
Gerir Ut ilizadores – Acesso às opções de gest ão de t odos os ut ilizadores do sist em a.
30 Figura 16 - Registo de um novo utilizador
Verifica Dados do Ut ilizador – É efect uada um a verificação dos dados inseridos no form ulário. Acesso à Base de Dados 1 – Caso a verificação ant erior seja realizada com sucesso é efect uado um acesso à base de dados, primeiro para verificar se o novo ut ilizador não é coincident e com um já regist ado e post eriorm ent e é efect uado o regist o.
Act ivar/ Desact ivar Ut ilizador – Permit e ao Adm inist rador desact ivar um ut ilizador do sist em a, um a vez desact ivado o ut ilizador deixa de se conseguir aut ent icar na aplicação.
Acesso à Base de Dados 2 – É feit o um acesso à base de dados para act ualizar o est ado do ut ilizador.
Gerir Pacient es – É efect uado um acesso à base de dados que perm it e ao Adm inist rador visualizar t odos os pacient es regist ados na aplicação.
Alt eração de Dados do Pacient e – O Administ rador pode alt erar os dados do Pacient e caso t enham sido int roduzidos de form a incorrect a.
Verifica Dados do Pacient e – É efect uada um a verificação à int egridade dos dados alt erados pelo Adm inist rador, por form a a verificar se não violam nenhum a das regras est abelecidas. Acesso à Base de Dados 3 – Caso a verificação ant erior t enha sido efect uada com sucesso é efect uado um acesso à base de dados para alt erar o regist o do Pacient e.
31 Gerir Calibração – Acesso ao m enu de gest ão de sons da calibração.
Upload e Verificação de Sons – O Adm inist rador efect ua o upload dos ficheiros de calibração para o sist em a, é feit a um a verificação ao t ipo de ficheiro, por form a a garant ir que o som est á no form at o WAV a 16 bit s.
Acesso à Base de Dados e Cópia dos Ficheiros para o Sist em a – Caso a verificação ant erior t enha sido realizada com sucesso os ficheiros são copiados para a past a de sist em a correspondent e e é efect uado o regist o do novo som na base de dados.
Opções da Aplicação – Acesso às opções da aplicação
Acesso à Base de Dados 4 – É efect uado o acesso à base de dados para act ualizar as opções da aplicação.
4.4.2.1. Gerir Protocolos Dicótico de Dígitos
Est e é o m ódulo onde é feit a t oda a gest ão dos prot ocolos dicót icos de dígit os (Figura 17).
Figura 17 - Diagrama de casos de uso da gestão de protocolos dicóticos de dígitos
Descrição dos casos de uso
32 M anual s/ Repet ição – (Figura 18) Criação de um prot ocolo de form a m anual, em que o ut ilizador escolhe t odas as sequências que pret ende, nest e m odo é garant ido que um a sequência já int roduzida no prot ocolo não pode volt ar a ser repet ida.
M anual c/ Repetição – Criação de um prot ocolo de form a m anual, em que o ut ilizador escolhe t odas as sequências que pret ende, nest e m odo é possível repet ir as sequências no prot ocolo, a única rest rição é não poder repet ir duas vezes seguidas a m esm a sequência.
Sem iaut om át ico – M odo que perm it e criar prot ocolos que repet em padrões de sequências definidas m anualm ent e pelo Administ rador, é necessário criar o prim eiro padrão e int roduzir o núm ero de repet ições do m esm o.
Aut om át ico – M odo que cria prot ocolos de form a aut ónom a, o Adm inist rador apenas t em de int roduzir o núm ero de sequências que pret ende.
Figura 18 - Construção de um protocolo de dígitos
Acesso à Base de Dados 1 – É efect uado um acesso à base de dados para guardar os pr ot ocolos grados.
Act ivar/ Desact ivar Prot ocolo – Perm it e ao Administ rador desact ivar um prot ocolo do sist em a, um a vez desact ivado o prot ocolo deixa de poder ser adm inist rado.
Acesso à Base de Dados 2 – É efect uado um acesso à base de dados para act ualizar o est ado do regist o do prot ocolo.
33 4.4.2.2. Gerir Protocolos SSW
Est e é o m ódulo onde é feit a t oda a gest ão dos prot ocolos dicót icos de dígit os (Figura 19).
Figura 19 - Diagrama de casos de uso da gestão de protocolos SSW
Descrição dos casos de uso
Novo Prot ocolo – Acesso ao m enu de escolha do m odo de criação de um novo prot ocolo. M anual s/ Repet ição – Devido às caract eríst icas especiais do t est e SSW apenas é possível criar prot ocolos de form a M anual e sem repet ição, o ut ilizador escolhe as sequências que pret ende int roduzir no prot ocolo e é garant ido que est as nunca se repet em .
Acesso à Base de Dados 1 – É efect uado um acesso à base de dados para inserir os dados relat ivos ao novo prot ocolo.
Act ivar/ Desact ivar Prot ocolo – Perm it e ao Administ rador desact ivar um prot ocolo do sist em a, um a vez desact ivado o prot ocolo deixa de poder ser adm inist rado.
Acesso à Base de Dados 2 – É efect uado um acesso à base de dados para act ualizar o est ado do regist o do prot ocolo.
34 4.4.2.3. Gerir Sons Dicóticos de Dígitos / SSW
A gest ão de sons dicót icos de dígit os e de sons SSW est á agrupada e é represent ada nest e diagram a, devido aos casos de uso serem exact am ent e os m esm os (Figura 20).
Figura 20 - Diagrama de casos de uso da gestão de sons
Descrição dos casos de uso
Novo Som – Acesso ao painel onde é possível efect uar a adição de um novo som ao sist em a. Upload e Verificação de Sons – O Administ rador efectua o upload dos ficheiros de som para o sist em a, é feit a um a verificação ao t ipo de ficheiro, por form a a garant ir que o som est á no form at o WAV a 16 bit s.
Acesso à Base de Dados e Cópia do Som para o Sist em a – Caso a verificação ant erior t enha sido realizada com sucesso os ficheiros são copiados para a past a de sist em a correspondent e e é efect uado o regist o do novo som na base de dados.
Act ivar/ Desact ivar Som – Permit e ao Adm inist rador desact ivar um som do sist em a, um a vez desact ivado o prot ocolo deixa de poder ser adm inist rado.
Acesso à Base de Dados 1 – É efect uado um acesso à base de dados para alt erar o est ado do regist o do som , e post eriorm ent e é efect uado out ro acesso para alt erar o est ado de t odos os prot ocolos que ut ilizem est e som .
Edit ar Som – Perm it e ao Adm inist rador edit ar os dados ident ificat ivos dos som .
35
4.4.3. Perfil de Técnico
Est e é o m ódulo de t écnico onde são det alhadas t odas as opções que um Técnico Audiologist a t em na aplicação (Figura 21).
Figura 21 - Diagrama de casos de uso do perfil de técnico
Descrição dos casos de uso
Calibração – Acesso ao painel de calibração, que perm it e configurar o volum e de som com que os t est es são reproduzidos.
Acesso à Base de Dados 1 – Caso t enha sido feit a algum a alt eração é efect uado um novo acesso à base de dados para act ualizar os valores correspondent es à calibração de som .
Pesquisa de Pacient es – Acesso ao painel de pesquisa de Pacient es
Acesso à Base de Dados – É efect uado um acesso à base de dados com base nos parâm et ros int roduzidos pelo Técnico.
Consult a de Hist órico de Pacient e – Depois de efect uada a pesquisa de Pacient e com sucesso é possível ao Técnico consult ar t odo o hist órico de t est es do Pacient e.
Im pressão de Relat órios – Caso seja necessário o t écnico pode im prim ir um relat ório com os result ados do t est e em PDF.
Agenda – Acesso ao painel de agenda pessoal do t écnico.
36 Acesso à Base de Dados 2 – É efect uado um acesso à base de dados para regist ar a m arcação do novo t est e.
Consult a – O t écnico pode a qualquer m om ent o consult ar a sua agenda pessoal.
Acesso à Base de Dados 3 – Na consult a à agenda de um Técnico é efect uado um acesso à base de dados que devolve t odos os t est es agendados, com os parâm et ros seleccionados.
Realização de Test es – Caso o Técnico pret enda pode iniciar direct am ent e a realização de um t est e a part ir da agenda, um a vez que os dados do Pacient e já est ão gravados no sist em a.
4.4.3.1. Testes
