Upload
dinhdan
View
220
Download
0
Embed Size (px)
Citation preview
Aplicação Móvel para Notificação de Sinistros
André Salvador Ervedoso Ferreira
Dissertação para obtenção do Grau de Mestre em
Engenharia Electrotécnica e de Computadores
Orientadores: Prof. Dr. João Manuel Brisson Lopes
Prof. Dr. António Manuel Raminhos Cordeiro Grilo
Júri:
Presidente: Prof. Dr. Nuno Cavaco Gomes Horta
Orientador: Prof. Dr. João Manuel Brisson Lopes
Vogal: Prof. Dr. Alfredo Manuel dos Santos Ferreira Júnior
Novembro 2015
___________________________________________________________________________ iii
Agradecimentos
Após ter terminado esta dissertação, gostaria de fazer um especial agradecimento ao Professor
João Manuel Brisson Lopes pela sua valiosa contribuição, ajuda e paciência ao longo deste processo
e ao professor António Manuel Raminhos Cordeiro Grilo por ter permitido realizar esta dissertação e ter
sido muito prestável desde do primeiro momento que o abordei sobre a realização deste trabalho.
Um grande agradecimento aos meus amigos Ana Sofia, André Jerónimo, André Santos, André
Silva, Daniel Albuquerque, Elisabete Castro, Inês Parra, João Guerreiro, João Miguel Silva, João Torre,
Mauro Teixeira, Miguel Nunes, Miguel Tairum, Pedro Nunes, Pedro Ribeiro, Ricardo Azevedo, Ricardo
Bugalho, Tânia Pinto, aos meus gatos Menino e Menina e à minha namorada Catarina por me terem
aturado e ajudado à medida que desenvolvia e escrevia esta dissertação ao mesmo tempo que
trabalhava.
Por fim, um agradecimento especial aos meus pais por todo o apoio que me deram sempre e em
tudo.
___________________________________________________________________________ v
Abstract
This project goal was to create a mobile application for vehicle accident claim notification
supporting the agreed statement of facts on motor vehicles (ASOF). The information on the accident
report is collected on an Android mobile application. The current paper-based process is slow,
complicated and confusing due to the large number of elements required to fill the paper form and the
need to consult multiple documents at the same time. In a digital age, a mobile application for claim
notification is an alternative to the ASOF in paper. The application tries to provide a good user
experience in two completely different situations: one situation where the user may be affected
psychologically due to the occurrence of an accident and another where the application also functions
as a showcase for the products of the insurance company business. The application allows filling data
automatically, capture and attach accident images, know the user's location, contact roadside
assistance, search for points of interest, interoperability with insurer IT system and transmit information
between devices with the same application. Usability tests were performed and results show that the
mobile solution is able of complete the ASOF 2.1 times faster than on paper. Users preferred to do the
ASOF in the mobile application instead of do it in paper.
Keywords
Mobile App, Android, Insurance, Agreed statement of facts on motor vehicle accident, Usability
___________________________________________________________________________ vii
Resumo
Este projeto consistiu na criação de uma aplicação móvel para notificação de sinistros, sendo
atualmente suportado o caso da declaração amigável de acidente automóvel (DAAA), onde serão
inseridas as várias informações sobre a declaração amigável feita a partir de uma aplicação móvel
instalada num dispositivo Android. O processo atual, baseado em papel, é lento, complicado e confuso
devido ao elevado número de elementos necessários a preencher e ter que se recorrer a vários
documentos para o respetivo preenchimento. Numa era cada vez mais digital, a aplicação móvel para
notificação de sinistros surge como alternativa ao preenchimento da DAAA em papel. Tendo em grande
foco a experiência do utilizador e concebendo esta experiência para duas situações distintas, uma onde
o utilizador poderá estar afetado psicologicamente devido à ocorrência de um sinistro, por outro lado é
importante ter em atenção que a aplicação poderá funcionar como uma montra para os produtos e
negócio da seguradora. A aplicação permite preencher vários dados de forma automática, capturar e
anexar imagens do sinistro, saber a localização do utilizador, contactar a assistência em viagem,
pesquisar pontos de interesse, permite a interoperabilidade com o sistema informático da seguradora
e consegue transmitir informações entre dispositivos com a mesma aplicação. Foram efetuados testes
de usabilidade e inquéritos. Os resultados obtidos mostram que a solução consegue um desempenho
no preenchimento da aplicação móvel 2,1x mais rápida que o preenchimento da DAAA em papel. Os
utilizadores afirmaram preferir preencher a DAAA pela aplicação móvel em vez da DAAA em papel.
Palavras-chave
Aplicação móvel, Android, Seguros, Declaração amigável de acidente automóvel, Usabilidade.
___________________________________________________________________________ ix
Índice
1. Introdução ............................................................................................................................ 3
1.1 Enquadramento ............................................................................................................... 3
1.2 Problema ............................................................................................................................. 4
1.3 Motivação e Objetivos ......................................................................................................... 5
1.4 Estrutura do documento ...................................................................................................... 6
2. Estado da Arte ..................................................................................................................... 9
2.1 História e evolução do sistema operativo Android .............................................................. 9
2.2 Aplicações móveis e a sua importância ............................................................................ 11
2.3 Interação homem-máquina e User Interface ..................................................................... 12
2.4 Declaração amigável de acidente automóvel .................................................................... 17
2.5 Aplicações para notificação de sinistros ............................................................................ 18
2.6 Comparação dos vários produtos...................................................................................... 34
2.7 Desafios ............................................................................................................................. 35
3. Requisitos .......................................................................................................................... 39
3.1 Levantamento de Requisitos ............................................................................................. 39
3.2 Análise de Requisitos ........................................................................................................ 46
4. Arquitetura da Solução ...................................................................................................... 53
4.1 Estrutura Geral do Sistema ............................................................................................... 53
4.2 Conceitos tecnológicos ...................................................................................................... 53
4.3 Servidor ............................................................................................................................. 54
4.4 Aplicação móvel ................................................................................................................. 58
4.5 Envio da notificação para a seguradora ............................................................................ 64
4.6 Conclusões ........................................................................................................................ 65
5. Implementação .................................................................................................................. 69
5.1 Metodologia utilizada ......................................................................................................... 69
5.2 Planeamento...................................................................................................................... 70
___________________________________________________________________________ x
5.3 Servidor ............................................................................................................................. 71
5.4 Base de Dados .................................................................................................................. 71
5.5 Protótipos Finais ................................................................................................................ 72
5.6 Conclusões ........................................................................................................................ 78
6. Avaliação da Solução ........................................................................................................ 81
6.1 Testes com Utilizadores ..................................................................................................... 81
6.2 Inquérito aos utilizadores ................................................................................................... 84
6.3 Conclusões ........................................................................................................................ 85
7. Conclusões e Trabalho Futuro .......................................................................................... 89
7.1 Trabalho Desenvolvido ...................................................................................................... 89
7.2 Trabalho Futuro ................................................................................................................. 90
Referências ................................................................................................................................. 91
Anexos ........................................................................................................................................ 97
Anexo A1: DAAA (Portugal) ..................................................................................................... 97
Anexo A2: DAAA (Portugal) verso ........................................................................................... 98
Anexo B: Campos da DAAA .................................................................................................... 99
Anexo C: Lista de circunstâncias da DAAA .......................................................................... 100
Anexo D: Ciclo de vida de uma actividade no Android.......................................................... 101
Anexo E: Modelo ER da BD da seguradora .......................................................................... 102
Anexo F1: Esquema XML para interoperabilidade com as seguradoras .............................. 103
Anexo F2 (continuação) ........................................................................................................ 104
Anexo G: Pontos de Interesse ............................................................................................... 105
Anexo H: Menu de Login ....................................................................................................... 106
Anexo I: Plano do Acidente ................................................................................................... 107
Anexo J: Selecionar Oficina Recomendada .......................................................................... 108
Anexo K: Erros cometidos pelos utilizadores ........................................................................ 109
___________________________________________________________________________ xi
Lista de Figuras
Figura 1: Percentagem de uso das diferentes versões Android [2]. ........................................................................ 9
Figura 2: Evolução da quota de mercado global dos principais sistemas operativos para smartphone. ............... 10
Figura 3: O gráfico mostra o número de acidentes em Portugal entre os anos de 2005 e 2014 [35]. ................... 18
Figura 4: Alguns ecrãs presentes na aplicação eCliente Allianz Portugal. ............................................................ 21
Figura 5: Alguns ecrãs presentes na aplicação AAMI Claim Assist. ...................................................................... 23
Figura 6: Alguns ecrãs presentes na aplicação Shannons Claim Assistant. .......................................................... 25
Figura 7: Alguns ecrãs presentes na aplicação Direct. .......................................................................................... 27
Figura 8: Alguns ecrãs presentes na aplicação My Axa. ....................................................................................... 29
Figura 9: Alguns ecrãs presentes na aplicação AxiKit Accident Report Kit. ........................................................... 31
Figura 10: Alguns ecrãs presentes na aplicação Accident Report. ........................................................................ 33
Figura 11: Diagrama detalhado das principais actividades responsáveis na aplicação móvel para notificação. ... 40
Figura 12: Protótipos funcionais do módulo B a E. ................................................................................................ 43
Figura 13: Protótipos funcionais do módulo F a I. ................................................................................................. 44
Figura 14: Protótipos funcionais do módulo J a M. ................................................................................................ 45
Figura 15: Diagrama da Arquitetura geral da solução. .......................................................................................... 53
Figura 16: Esquema de autenticação do utilizador. ............................................................................................... 57
Figura 17: Esquema de troca de ficheiros entre os utilizadores por Bluetooth. ..................................................... 61
Figura 18: Esquema que exemplifica a adulteração da DAAA por parte do Condutor 2. ...................................... 62
Figura 19: Modelo que garante a integridade da DAAA para ambos os condutores na chegada às seguradoras. 63
Figura 20: Processo de envio da notificação para a seguradora. .......................................................................... 64
Figura 21: Fases do processo de implementação. ................................................................................................ 69
Figura 22: Diagrama de Gantt do planeamento..................................................................................................... 70
Figura 23: Aspeto do servidor online e ferramentas disponíveis. .......................................................................... 71
Figura 24: Base de Dados implementada no servidor. .......................................................................................... 72
Figura 25: Menu Principal (B) e de notificação de sinistro (C). .............................................................................. 72
Figura 26: Ecrã de Emergência (Q) e menu tipo de sinistro (D). ........................................................................... 73
Figura 27: Menu de sinistro automóvel (E) e menu da DAAA (F). ......................................................................... 74
Figura 28: Menu Informação Geral (G) e menu formulário do veículo (H). ............................................................ 75
Figura 29: Diálogos para selecionar hora e data. .................................................................................................. 75
Figura 30: Menu para indicar o ponto de embate inicial (I) e ecrã para indicar os danos visíveis (J). ................... 76
Figura 31: Menu circunstâncias do acidente (K) e lista para selecionar oficina (L). .............................................. 77
Figura 32: Menu para submeter a notificação (M) e ecrãs para rever e enviar notificação. .................................. 78
Figura 33: Esquema do acidente utilizado no caso de teste para avaliação da usabilidade. ................................ 82
Figura 34: Comparação do tempo de preenchimento da DAAA em papel com a aplicação móvel. ...................... 83
Figura 35: Comparação do número de erros na DAAA em papel com a aplicação móvel. ................................... 84
Figura 36: Documento da DAAA. .......................................................................................................................... 97
Figura 37:Verso da DAAA. .................................................................................................................................... 98
Figura 38: Ciclo de Vida de uma Actividade. ....................................................................................................... 101
Figura 39: Base de Dados de suporte à aplicação de notificação de sinistros. ................................................... 102
Figura 40: Lista de pontos de interesse. .............................................................................................................. 105
Figura 41: Menu de Login. ................................................................................................................................... 106
Figura 42: A actividade permite desenhar o plano do acidente. .......................................................................... 107
Figura 43: Mapa com oficinas recomendadas pela seguradora. ......................................................................... 108
___________________________________________________________________________ xiii
Lista de Tabelas
Tabela 1: Descrição dos vários campos da DAAA. ................................................................................................ 17
Tabela 2: Análise a algumas funcionalidades da aplicação eCliente Allianz. ......................................................... 20
Tabela 3: Avaliação da aplicação eCliente Allianz. ................................................................................................ 21
Tabela 4: Análise a algumas funcionalidades da aplicação AAMI Claim Assist. .................................................... 22
Tabela 5: Avaliação da aplicação AAMI Claim Assist............................................................................................. 23
Tabela 6: Análise a algumas funcionalidades da aplicação Shannons Claim Assistant......................................... 24
Tabela 7: Avaliação da aplicação Shannons Claim Assistant. ............................................................................... 25
Tabela 8: Análise a algumas funcionalidades da aplicação Direct. ........................................................................ 26
Tabela 9: Avaliação da aplicação My Axa. ............................................................................................................. 27
Tabela 10: Análise a algumas funcionalidades da aplicação My Axa. ................................................................... 28
Tabela 11: Avaliação da aplicação My Axa. ........................................................................................................... 29
Tabela 12: Análise a algumas funcionalidades da aplicação AxiKit Accident Report Kit........................................ 30
Tabela 13: Avaliação da aplicação AxiKit Aciident Report Kit. ............................................................................... 31
Tabela 14: Análise a algumas funcionalidades da aplicação Accident Report. ...................................................... 32
Tabela 15: Avaliação da aplicação Accident Report. ............................................................................................. 33
Tabela 16: Comparação de produtos existentes no mercado. ............................................................................... 34
Tabela 17: Descrição do levantamento de requisitos para a aplicação móvel. ...................................................... 42
Tabela 18: Prioridades dos requisitos segundo o método de MoSCoW. ............................................................... 46
Tabela 19: Análise dos requisitos funcionais. ........................................................................................................ 47
Tabela 20: Comparação entre as soluções SOAP e REST para implementar um Web Service. .......................... 55
Tabela 21: Características principais dos utilizadores de teste.............................................................................. 81
Table 22: Média das pontuações dos questionários. ............................................................................................. 85
Tablela 23: Nome dos campos presentes na DAAA em inglês e a sua correspondente localização na aplicação
móvel para notificação de sinistro. Também é indicado se estes podem ser ser preenchidos automaticamente.
...................................................................................................................................................................... 99
Tabela 24: Lista de circunstâncias da DAAA. ...................................................................................................... 100
Tabela 25: Detalhes sobre os erros cometidos no preenchimento da DAAA em papel e digital. ......................... 109
___________________________________________________________________________ xv
Lista de Abreviaturas
ASOF Agreed Statement of Facts on motor vehicles
ASQ After-Scenario Questionnaire
BD Base de Dados
DAAA Declaração Amigável de Acidente Automóvel
HCIL Human-Computer Interaction Lab
IDC International Data Corporation
IDE Integrated Development Environment
IDS Indeminização Direta ao Segurado
IHM Interação Homem-Máquina
ISO International Organization for Standardization
ISP Instituto de Seguros de Portugal
JSON JavaScript Object Notation
NNG Nielsen Norman Group
PUT Purdue Usability Testing
QUIS Questionnaire for User Interaction Satisfaction
SOAP Simple Object Access protocol
UI User Interface
USE Usefullness, Satisfaction and Ease of Use
XML eXtensible Markup Language
___________________________________________________________________________ 3
1. Introdução
No âmbito da disciplina de Dissertação em Engenharia Eletrotécnica e de Computadores do
Instituto Superior Técnico foi desenvolvido o projeto “Aplicação Móvel para Notificação de Sinistros”.
Na primeira parte deste trabalho é apresentado o âmbito e propósito no qual esta solução se insere.
São também descritos os problemas que conferem importância ao desenvolvimento deste sistema, é
apresentada a estrutura do documento e feita uma breve referência ao contexto em que esta
dissertação foi desenvolvida.
1.1 Enquadramento
A Declaração Amigável de Acidente Automóvel (DAAA) deve ser sempre preenchida em caso de
acidente, independentemente de haver ou não acordo amigável. Este documento tem como principal
objetivo descrever o acidente e os dados das pessoas envolvidas, bem como dos respetivos veículos.
No fundo, a DAAA serve para registar os fatos e participar o sinistro ocorrido. Se possível, deve ser
sempre procurado um acordo através do preenchimento pelos dois condutores da declaração, que
deverá ser assinada por ambos (o documento somente é classificado de DAAA se estiver assinado
pelos intervenientes) e entregue nas respetivas empresas de seguros para desencadear o sistema da
Indemnização Direta ao Segurado (IDS).
A Declaração Amigável é utilizada na participação de um sinistro automóvel com o intuito de
participar o acidente diretamente à seguradora e assegurar uma maior celeridade da análise das
circunstâncias em que o sinistro ocorreu. A declaração deverá ser enviada à seguradora no prazo de
oito dias após o sinistro e todos os envolvidos no acidente devem ficar com uma cópia do que foi
preenchido. A declaração amigável é válida para todos os países aderentes.
Apesar da DAAA ter o propósito de auxiliar e ajudar os condutores em ocasiões bastantes vezes
associadas a situações de stress e sensíveis, é normal os sinistrados encontrarem várias dúvidas
durante o preenchimento da declaração, não preencherem a totalidade da DAAA e não recolherem
corretamente todas as informações necessárias para dar início aos processos junto das seguradoras.
Estes são alguns dos principais problemas que os condutores encontram durante o preenchimento
Instituto de Seguros de Portugal (ISP), nos termos e ao abrigo do Decreto-Lei n.º 83/2006, de 3
de Maio [33], aprova o modelo da DAAA para participar o sinistro à seguradora e fixa a estrutura do
registo pelas empresas de seguros dos prazos dos processos de regularização de sinistros
participados, bem como a periodicidade e os moldes nos quais essa informação lhe deve ser prestada
[34]. No mesmo decreto-lei, é indicado que “a participação de um sinistro tanto pode ser feita em
impresso próprio fornecido pela empresa de seguros, de acordo com o modelo aprovado pelo
ISP, como através da utilização de outros meios de comunicação”, desde que fique registo escrito
ou gravado [33].
Ao existir uma alternativa à execução da DAAA através de outros meios de comunicação, sem
ser pelo habitual impresso próprio fornecido pelas seguradoras, é exequível propor uma solução que
___________________________________________________________________________ 4
venha minimizar ou acabar com os principais problemas mencionados anteriormente através da
construção de uma aplicação móvel para notificação de sinistros. A solução vem trazer algumas
possibilidades que antes não eram viáveis, como permitir reunir num só documento todas as
informações do sinistro, obter informações sobre os sinistrados automaticamente, criar um sistema que
permita a interoperabilidade entre os dispositivos dos clientes e as seguradoras e enviar a DAAA do
próprio local onde ocorreu o sinistro.
A aplicação trabalha explicitamente com a DAAA, mas houve desde o princípio a preocupação
de a tornar mais universal. A aplicação está preparada para adicionar outros tipos de notificações para
além de acidentes com veículos como, por exemplo, acidente pessoais, fogo, habitação e saúde. A
preocupação com a extensibilidade da aplicação vai para além da notificação de outro tipo de sinistro,
pois também está preparada para dar apoio ao sinistrado através de uma ligação com serviços como
oficinas, bombeiros, reboques e emergência médica.
Em suma, a aplicação pretende reduzir os problemas existentes e algumas das lacunas do
habitual preenchimento em impresso próprio. O principal público para esta solução são todos os
condutores que se deslocam no seu veículo privado ou comercial, em lazer ou em trabalho, e que em
caso de acidente utilizem a DAAA.
1.2 Problema
A utilização das aplicações móveis no quotidiano é uma realidade cada vez mais presente. Estas
conseguem suprir a necessidade constante do acesso à informação de uma forma simples e eficaz
trazendo diversos benefícios tanto a nível profissional como pessoal. Numa sociedade cada vez mais
marcada pela constante inovação, o uso do telemóvel tornou-se indispensável. A sua utilização passa
não só pela procura da comunicação, mas também pelo auxílio nas mais diversas tarefas do quotidiano.
O aumento do consumo e uma sociedade cada vez mais exigente, leva a uma melhor gestão e
cuidado com o bem mais precioso que o ser humano possui, o tempo. Atualmente o trânsito é um dos
maiores problemas para quem vive nas cidades afetando diretamente a gestão do tempo. Quando
acontece um acidente, os condutores querem que a situação os prejudique o mínimo tempo possível.
Porém, o preenchimento da atual declaração amigável de acidente automóvel em papel é lento. Surge
então neste contexto o desenvolvimento da aplicação móvel para notificação de sinistros, que não se
encontra ainda implementado em Portugal e outros países.
Alguns problemas essenciais de resolver são: em primeiro lugar permitir a diminuição do tempo
médio de preenchimento da DAAA e, em segundo lugar, criar uma interface com uma boa experiência
de utilização, capaz de ser entendida pelo maior número possível de utilizadores. Ambas as soluções
foram avaliadas através de testes e de ensaios com os utilizadores, para aferir se os objetivos foram
atingidos. Neste documento analisamos sistemas existentes, retendo e identificando as principais
fraquezas e vantagens, para construir um sistema com uma interface que reúna algumas das
informações que anteriormente foram adquiridas dos vários sistemas estudados.
___________________________________________________________________________ 5
Neste trabalho utilizou-se o sistema Android, pois como o desenvolvimento da prova de conceito
(aplicação móvel) tinha de ser efetuado num tempo limitado e existia o conhecimento prévio da
linguagem Java, foi tomada a decisão de realizar a prova no sistema operativo Android, para
desenvolver a Aplicação Móvel para Notificação de Sinistros. Tal levou a uma abordagem inicial mais
fácil de realizar e testar o protótipo em ambiente Android do que para outros sistemas. O sistema
Android é o mais utilizado globalmente (ver capítulo 2). Outros sistemas, como iOS e Windows Phone,
podem vir a ser utilizados num trabalho futuro, mas mais numa perspetiva de comercialização.
1.3 Motivação e Objetivos
A motivação para este projeto surgiu da possibilidade de realizar a dissertação em conjunto com
uma empresa que trabalha com o setor segurador e desenvolver um sistema, atualmente não utilizado
nesta área, que permita melhorar o processo de participação de sinistro e venha proporcionar uma
mais-valia tanto para as seguradoras como para os clientes. O objetivo principal é conceber e construir
uma aplicação móvel para notificação de sinistros e aplicar à área de negócio das seguradoras,
especificamente aos clientes destas, tendo em vista a otimização dos processos de notificação e
aumentar a satisfação dos clientes.
Permitir que através do recurso a uma simples aplicação móvel seja possível tornar a vida das
pessoas mais simples e minimizar o mal-estar em situações maioritariamente negativas, proporciona
uma grande satisfação e motivação para o desenvolvimento desta solução.
No panorama internacional ainda existem muito poucas aplicações adequadamente desenhadas
para notificação de sinistros. No panorama nacional destacam-se duas aplicações, a Direct e a eCliente
Allianz Portugal, que permitem notificar um sinistro. A maior parte destas, apesar de estarem
associadas a uma seguradora, parecem ainda ser um protótipo, como é o caso das aplicações eCliente
Allianz Portugal, My Axa e Accident Report.
Face aos problemas, às motivações e às oportunidades subjacentes enunciadas anteriormente,
resultou deste trabalho uma aplicação móvel que contempla os seguintes objetivos:
Definir e implementar uma aplicação móvel Android ao qual os utilizadores poderão
recorrer para recolher os elementos necessários para a notificação do sinistro à
seguradora;
Capturar e anexar imagens do sinistro;
Possibilitar o tratamento de dados dos sinistros num contexto de georreferenciação,
onde será descodificado o endereço do local do sinistro, e não apenas coordenadas;
Preencher automaticamente o máximo de informação possível para conseguir obter uma
declaração amigável;
Permitir que o utilizador recorra a atalhos de comunicação, como por exemplo SMS e
telefone, para contactar outras entidades (reboque, seguradora, emergência).
Conceder ao utilizador uma lista de contactos úteis dependentes da localização
(hospitais, farmácias, polícia, etc.);
___________________________________________________________________________ 6
Definir um sistema que possibilite a interoperabilidade entre a aplicação móvel e o
sistema da seguradora;
Criar uma base de dados cliente simples que permita recolher informações;
Tornar a aplicação bilingue, em inglês e português
A aplicação deverá apresentar uma boa usabilidade, em situações que os seus
utilizadores possam estar afetados psicologicamente por uma situação negativa;
A aplicação deverá ser mais rápida que do que o preenchimento da DAAA em papel;
Implementar um Servidor de demonstração que processe os dados enviados e recebidos
pela aplicação.
1.4 Estrutura do documento
Este documento encontra-se estruturado por capítulos e está organizado da seguinte forma:
Capítulo 2 – Estado da arte. Faz-se uma análise à evolução do sistema operativo
Android e a importância das aplicações móveis no quotidiano. É também efetuada uma
revisão das aplicações móveis já desenvolvidas para notificação de sinistros;
Capítulo 3 – Requisitos. Neste capítulo é descrito o levantamento e a análise de
requisitos;
Capítulo 4 – Arquitetura da Solução. É apresentada a arquitetura da solução proposta,
descreve-se a estrutura geral do sistema, bem como a tecnologia utilizada no
desenvolvimento da aplicação;
Capítulo 5 – Implementação. Neste capítulo é apresentada a metodologia e
planeamento seguidos para a implementação do trabalho desenvolvido, é abordado o
sistema desenvolvido, é detalhada as principais funcionalidades e todo o processo de
implementação adotado;
Capítulo 6 – Avaliação da Solução. É descrito o método pelo qual a avaliação da solução
proposta foi efetuada para validar a sua funcionalidade e usabilidade face aos requisitos
propostos. Analisamos as vantagens entre a solução desenvolvida e os métodos de
notificação de sinistros atuais.
Capítulo 7 – São apresentadas as limitações da solução, propostas de trabalhos futuros
e as conclusões obtidas durante o trabalho;
Referências bibliográficas – Todos os livros, artigos e outros documentos que
auxiliaram a elaboração deste trabalho.
___________________________________________________________________________ 9
2. Estado da Arte
Esta seção descreve resumidamente o sistema operativo Android e a importância das aplicações
móveis atualmente, é descrito o trabalho relacionado com as interfaces homem-máquina sucedida de
uma revisão às aplicações móveis para notificação de sinistros presentes no mercado, passando ainda
pela análise dos elementos necessários para o preenchimento da DAAA atualmente.
2.1 História e evolução do sistema operativo Android
O Android é um sistema operativo baseado em Linux e desenvolvido para ser utilizado em
dispositivos móveis. Em Outubro de 2003 foi fundada em Palo Alto, Califórnia a Android Inc. por Andy
Rubin, Rich Miner, Nick Sears e Chris White. O intuito da Android Inc. segundo um dos seus fundadores
Andy Rubin era a “criação de dispositivos móveis mais inteligentes e cientes da sua localização e que
atendam às preferências do seu utilizador” [1].
Em Junho de 2005 a Google realiza a compra da Android Inc., que na altura ainda não passava
de uma startup promissora. O intuito da Google com esta aquisição era a possibilidade de entrar para
o mundo dos dispositivos móveis, permitindo desta maneira divulgar os seus produtos num mercado
em constante expansão.
Os dispositivos Android não se limitam aos smartphones. Atualmente são vários os dispositivos
que suportam este sistema operativo, como por exemplo: tablets, netbooks e televisões que forneçam
serviços de Internet. Os tablets têm vindo a assumir uma grande preponderância no mercado sendo
considerados como um meio-termo entre um computador portátil e um smartphone.
Paralelamente ao desenvolvimento dos dispositivos móveis, o Android tem vindo também a
sofrer uma grande evolução, tendo surgido desde o primeiro lançamento sucessivas versões deste
sistema operativo.
Na figura 1, são mostradas várias versões do Android, bem como a quota de mercado que cada
uma ocupa (dados referentes a Fevereiro de 2015 [2]).
Android Version
Nome de código API Distribuição
2.2 Froyo 8 0.4%
2.33- 2.3.7
Gingerbread 10 7.4%
4.0.3- 4.0.4
Ice Cream Sandwich
15 6.4%
4.1.x
Jelly Bean
16 18.4%
4.2.x 17 19.8%
4.3 18 6.3%
4.4 KitKat 19 39.7%
5.0 Lollipo 21 1.6%
Figura 1: Percentagem de uso das diferentes versões Android [2].
___________________________________________________________________________ 10
Como é possível concluir da figura 1, aproximadamente 92% dos dispositivos Android no
mercado têm uma versão superior ou igual à versão 4.0 e cerca de 41% dos dispositivos smartphone
Android têm a versão 4.4 ou mais recente.
Num estudo realizado pela International Data Corporation (IDC) ao mercado de smartphones, é
revelado que em todo o mundo o número destes dispositivos cresceu 27,2% no segundo trimestre de
2014, sendo expectável que no final deste ano sejam vendidos cerca de 1,3 mil milhões de dispositivos
[3].
Das 335 milhões de unidades vendidas no segundo trimestre de 2014, o sistema operativo
Android lidera as vendas do mercado mundial de smartphones, com 283 milhões de unidades vendidas
e mais de 84% da quota de mercado no terceiro trimestre de 2014. O estudo realizado indica ainda que
a quota de mercado do sistema operativo iOS da Apple encontra-se em segundo lugar com cerca de
11,7% da quota de mercado e a Microsoft com o sistema operativo Windows Phone perto de 2,9% da
quota de mercado [3].
Na figura 2 é mostrada a evolução da quota de mercado global dos vários sistemas operativos
smartphones desde o terceiro trimestre de 2011 até ao terceiro trimestre de 2014.
Figura 2: Evolução da quota de mercado global dos principais sistemas operativos para smartphone.
É possível observar através da figura 2, que desde o terceiro trimestre de 2011 até ao terceiro
trimestre de 2014 o sistema Android é líder destacado, tendo crescido perto de 27 % e todos os outros
sistemas, à exceção do Windows Phone, têm tido uma diminuição da sua quota de mercado.
Conclui-se portanto que a nossa decisão de escolher o sistema operativo Android para
desenvolver a prova de conceito é uma boa decisão, porque atualmente o sistema é líder no mercado
de Smartphones. Enquanto os sistemas Windows Phone e IOs tem cotas consideravelmente mais
baixas de mercado. Caso se deseje que a aplicação móvel se torne comercial, esta ficará disponível
para o maior mercado atual.
___________________________________________________________________________ 11
2.2 Aplicações móveis e a sua importância
As aplicações móveis estão a desencadear uma mudança completa na maneira como as
pessoas abordam a tecnologia e usam os seus dispositivos móveis.
É notório que atualmente grande parte da população não passa sem o seu dispositivo móvel, já
que com ele é possível aceder a toda a informação necessária e tudo à distância de poucos cliques.
Esta constante procura de informação fez com que empresas de software e programadores
apostassem em força no mercado móvel.
O conceito de "estação de trabalho" ou mesmo de "desktop" deixou de ser suficiente. Um
indivíduo ou empresa, em tempo real, requer acesso imediato às suas aplicações profissionais ou
pessoais, e à possibilidade de tomar decisões a qualquer hora ou em qualquer lugar com a máxima
flexibilidade.
Estes requisitos deixam claro que um dos principais responsáveis pelo desenvolvimento e
crescimento das empresas de software na atualidade é a mobilidade. Num estudo efetuado pelo grupo
Promon é mostrado que as empresas, ao tornarem móveis as suas ferramentas, reforçam a sua
visibilidade no mercado, auxiliando e ao mesmo tempo familiarizando os utilizadores nas suas tarefas
diárias com os seus produtos [4].
Segundo Jakob Nielsen, um consumidor de aplicações móveis regular gasta mais tempo a
interagir com aplicações móveis dedicadas do que com o respetivo site móvel. Enquanto um site móvel
é bom, uma aplicação móvel é ainda melhor [5]. É claro que é mais caro para uma empresa construir
uma aplicação móvel específica, porque tem de trabalhar com versões diferentes para cada tipo de
sistema existente no mercado. No entanto, num estudo conduzido pelo Nielsen Norman Group (NNG)
foi medida uma taxa de sucesso de 76% quando as pessoas usavam aplicações móveis, o que é muito
maior do que os 64% de taxa de sucesso registados para sites móveis específicos [6]. A métrica “taxa
de sucesso”, é uma unidade amplamente reconhecida, explicada no artigo, de Jakob Nielsen, Success
Rate: The Simplest Usability Metric, como uma métrica de usabilidade que permite indicar qual a
percentagem de tarefas que os utilizadores concluem corretamente.
A forte aposta no mercado das aplicações móveis por diversas empresas de software ajudou a
atrair mais utilizadores e programadores. Atualmente a oferta é vasta e a procura não para de crescer.
As aplicações móveis vão assim tomando cada vez mais espaço no nosso quotidiano, competindo ao
programador encontrar possíveis necessidades que os utilizadores tenham e conseguir minimizar
essas necessidades através do desenvolvimento de novas aplicações.
No entanto, quando a aplicação móvel para notificação de sinistros não se encontra instalada no
dispositivo móvel, o site móvel torna-se uma funcionalidade e é uma opção interessante para os
utilizadores conseguirem executar o preenchimento da declaração amigável de acidente automóvel,
mesmo sem a aplicação estar instalada.
___________________________________________________________________________ 12
2.3 Interação homem-máquina e User Interface
A User Interface (UI) é a parte visual de uma aplicação através da qual o utilizador interage com
o software, esta determina como os comandos são dados ao programa e como a informação é
apresentada no ecrã. O campo que estuda como as interfaces do utilizador deverão ser projetadas, é
amplo e complexo. De forma a acompanhar a crescente complexidade das UI existem várias definições,
mais à frente estudadas, que permitem uma busca mais fácil de soluções robustas.
Por seu lado, a Interação Homem-Máquina (IHM) é descrita como a intercomunicação entre
utilizadores humanos e máquinas. A abreviatura IHM deve ser alargada consideravelmente, de modo
a cobrir os desafios de ergonomia apresentados pelos sistemas homem-máquina altamente complexos
e dinâmicos. O grau de automação no controlo de sistemas dinâmicos aumentou substancialmente nas
últimas décadas e a necessidade de melhorar a IHM é proporcional a esse grau de automação. Maior
complexidade e estruturas de controlo mais sofisticados exigem uma nova qualidade de comunicação
e cooperação entre homem e máquina. Do ponto de vista dum operador humano, as máquinas não são
apenas ferramentas, mas também agentes possivelmente autónomas e alguma coerência deve ser
mantida entre os seres humanos e máquinas independentemente da interface [7].
2.3.1 UI Design Pattern
A UI é bem conhecida por ser responsável por uma parte considerável do esforço de
desenvolvimento em sistemas interativos. No entanto, não existe um standard absoluto, ou pelo menos
uma notação comummente aceite para expressar representações técnicas de padrões de UI (UI
patterns), que transmita a solução de um modo abstrato e que possa ser aplicada em muitas situações
diferentes do projeto [8] [9].
User Interface Design Patterns (UI Pattern) são soluções recorrentes que resolvem problemas
de design comuns [10]. Há um interesse crescente na possibilidade de usar um padrão comum para
problemas semelhantes no design das interfaces de utilizador, no seu desenvolvimento e na sua
avaliação [11] [12]. Cada padrão (pattern) descreve um problema que ocorre uma e outra vez num certo
contexto e, em seguida, descreve o núcleo da solução para esse determinado problema, de tal maneira
que se pode usar esta solução um milhão de vezes, sem nunca fazê-lo da mesma forma duas vezes
[13].
A ideia de aplicar padrões em interação homem-máquina advém do trabalho de Norman [14] e
da Apple Human-Interface Guidelines [15], onde os padrões são referenciados como uma influência e
inspiração para o desenvolvimento centrado no utilizador e nas instruções da UI. Somente após o final
da década de 1990, depois de vários workshops, UPA'99 (Usability Professionals' Association) [16],
INTERACT'99 e CHI'2000 (Conference on Human Factors) [17] foi discutido especificamente a questão
da aplicação de padrões (UI patterns) na IHM.
UI patterns é um passo muito importante no sentido de promover a coerência e consistência. O
design da UI está cada vez mais a tornar-se numa tarefa complexa e exigente com o aparecimento das
aplicações com múltiplas informações [18] [19]. Portanto, a capacidade de identificar padrões da UI e
___________________________________________________________________________ 13
expressar a solução de um modo abstrato independente de uma implementação em particular é de
uma grande importância. Só assim podemos promover uma linguagem de padrões que substitui as
restrições de uma plataforma específica.
2.3.2 Avaliação da usabilidade
Atualmente, com a crescente omnipresença e dependência de sistemas interativos, a usabilidade
é cada vez mais uma questão importante. Pequenos problemas de usabilidade podem escalar e levar
a consequências económicas e sociais [20]. Tornado a interação entre utilizador e máquina cada vez
mais importante de ser estudada.
O termo “usabilidade” (usability) foi introduzido para substituir o termo “user friendly” que, por
volta do início de 1980, tinha uma conotação mais vaga e subjetiva [21] [22]. Usabilidade pode ser
definida como uma função da facilidade de utilização, aprendizagem (quando relevante), e
aceitabilidade do produto. A usabilidade determina o uso efetivo por um utilizador numa determinada
tarefa num contexto específico. Outros aspetos, tais como a “facilidade de uso”, determinam se o
produto pode ser utilizado e a “aceitabilidade" decide se e como irá ser efetivamente utilizado. Atributos
de um produto, desempenho e satisfação medem a facilidade de uso em um contexto particular. O
contexto consiste no utilizador, na tarefa e no ambiente físico/social.
Podemos analisar a UI por meio de técnicas de análise, procedimentos informatizados, métodos
empíricos e métodos heurísticos [23] [24]. No entanto, nem todos eles têm sido referidos como testes
reais para a usabilidade quando se trata de interface de utilizador. A lista seguinte mostra um conjunto
de avaliações, que foram estudadas com intuito de suportarem a avaliação da usabilidade do sistema
a ser desenvolvido, sobre a usabilidade da UI:
ISO 9241
É uma norma da International Organization for Standardization (ISO) que cobre a ergonomia da
IHM. Esta norma vem substituir a norma ISO 13407 e descreve seis princípios-chave para garantir que
o projeto é centrado no utilizador [37][38]: os utilizadores estão envolvidos em toda a concepção e
desenvolvimento, o projeto é conduzido e refinado por avaliação centrada no utilizador, o projeto é
baseado num entendimento explícito de utilizadores, tarefas e ambientes, o processo é iterativo, o
processo aborda toda a experiência do utilizador e a equipa do projeto inclui conhecimentos num
conjunto diversificado de tópicos. Os conteúdos presentes nesta norma são formados por especialistas
voluntários da indústria e são colocadas à disposição para uma melhor orientação no desenvolvimento
do projeto [39].
Questionnaire for User Interaction Satisfaction (QUIS)
O QUIS é uma ferramenta desenvolvida por uma equipa multidisciplinar de pesquisadores de
interação do Human-Computer Interaction Lab (HCIL) da Universidade de Maryland, College Park [25].
O QUIS foi desenhado para avaliar a subjetividade da satisfação do utilizador com aspetos específicos
da IHM. A equipa QUIS abordou com sucesso os problemas de confiança e validade encontrados em
outras medidas de satisfação, criando uma medida que é altamente confiável em muitos tipos de
___________________________________________________________________________ 14
interfaces. O QUIS contém um questionário demográfico, uma medida de satisfação global do sistema
ao longo de seis escalas e medidas hierarquicamente organizadas de 9 fatores de interface específicos
(fatores do ecrã, terminologia e feedback do sistema, fatores de aprendizagem, as capacidades do
sistema, manuais técnicos, exemplos online, multimédia, teleconferência, e instalação do software).
Cada área mede a satisfação geral dos utilizadores com a interface numa escala de 9 pontos. O
questionário é concebido para ser configurado de acordo com as necessidades de cada análise de
interface incluindo apenas as secções que são de interesse para o utilizador.
Technology acceptance model
Faz perguntas como “o que leva as pessoas a aceitar ou rejeitar as tecnologias da informação?”.
Entre as muitas variáveis que podem influenciar o uso do sistema, pesquisa anteriores sugerem dois
determinantes que são especialmente importantes. A “utilidade percebida” (perceived usefulness) é
definida como "o grau em que uma pessoa acredita que o uso de um determinado sistema aumentaria
seu desempenho no trabalho”, enquanto a “perceção de facilidade de utilização” (perceived ease of
use), que refere-se “ao grau em que uma pessoa acredita que o uso de um determinado sistema estará
livre de esforço” [26];
Atributos de usabilidade
Os atributos de usabilidade segundo Jakob Nielsen são definidos por cinco componentes de
qualidade [27]:
1. Capacidade de aprendizagem. Quão fácil é para os utilizadores realizarem tarefas básicas
na primeira vez que se deparam com o design da solução;
2. Eficiência. Depois dos utilizadores aprenderam sobre o design da solução, com que rapidez
estes conseguem executar tarefas;
3. Memorização. Quando os utilizadores voltam a reutilizar a solução após um período de não
utilização, qual a facilidade com que conseguem restabelecer uma boa habilidade na sua
utilização;
4. Erros. Quantos erros os utilizadores fazem, quão graves são e quão facilmente os
utilizadores conseguem recuperar desses erros;
5. Satisfação. Quão agradável é usar o design do projeto;
Heurísticas de Nielsen
É uma dos guias mais utilizados para verificar se a interface do utilizador é convenientemente
avaliada [28], onde Jakob Nielsen definiu um conjunto de 10 heurísticas. A avaliação heurística é feita
a partir duma inspeção sistemática à UI. O objetivo da avaliação heurística é encontrar problemas
relativos à usabilidade no design da solução, para que estes problemas sejam atendidos como parte
de um processo iterativo. As 10 heurísticas são:
1. Visibilidade do estado do sistema. O sistema deve sempre manter os utilizadores informados
sobre o que está a acontecer, através de um feedback apropriado e em tempo razoável;
___________________________________________________________________________ 15
2. Correspondência entre o sistema e o mundo real. O sistema deve falar a linguagem do
utilizador, com palavras, frases e conceitos familiares, em vez de termos orientados ao sistema;
3. Controlo do utilizador e liberdade. Algumas vezes os utilizadores escolhem funções do sistema
por engano e vão precisar de uma “saída de emergência” claramente marcada para sair
daquele estado indesejado;
4. Consistência e padrões. Os utilizadores não necessitam adivinhar que diferentes palavras,
situações ou ações significam a mesma coisa. Deverão ser seguidas as convenções da
plataforma;
5. Prevenção de erros. Ainda melhor do que boas mensagens de erro é um projeto cuidadoso
que impede em primeiro lugar que o erro ocorra. Eliminando as condições possíveis de erros
ou protegendo estas, apresentando aos utilizadores uma opção de confirmação antes de se
comprometerem com uma determinada ação;
6. Reconhecimento em vez de recordação. Minimizar a carga de memória do utilizador. Este não
deve ter que se lembrar da informação de uma parte do diálogo para outra. Instruções de uso
do sistema devem estar visíveis e serem facilmente recuperáveis quando necessárias.
7. Flexibilidade e eficiência de utilização. Aceleradores, invisíveis para um utilizador amador, para
permitir aos utilizadores mais experientes personalizarem ações frequentes, que podem
acelerar a interação;
8. Estética e design minimalista. Os diálogos não devem conter informações irrelevantes ou
raramente necessárias. Cada unidade extra de informação em um diálogo compete com as
unidades relevantes de informação e diminui a sua visibilidade relativa;
9. Ajudar os utilizadores a reconhecer, diagnosticar e resolver erros. Mensagens de erros devem
ser expressas em linguagem clara, indicar com precisão o problema e construtivamente sugerir
uma solução.
10. Ajuda e documentação. Mesmo que seja melhor que um sistema possa ser usado sem
documentação, pode ser necessário fornecer uma ajuda e documentação. Qualquer
informação deve ser fácil de ser pesquisada, com foco na actividade do utilizador, na lista de
passos concretos e não ser muito extensa.
After-Scenario Questionnaire (ASQ)
O ASQ deve ser dado a um utilizador depois de este ter concluído um “cenário” da interface em
condição normal [29]. O utilizador deve assinalar as suas respostas usando a escala fornecida de 7
pontos (quanto menor a pontuação selecionada, maior a satisfação da usabilidade do sujeito com o
sistema). Este questionário não foi utilizado;
Purdue Usability Testing (PUT) Questionnaire
O questionário PUT foi desenvolvido com base na teoria de processamento de informações
sendo identificados 8 fatores humanos [30]: compatibilidade, consistência, flexibilidade, capacidade de
aprendizagem, ação mínima, carga de memória mínima, limitação percetual e orientação ao utilizador.
Este questionário pode teoricamente ser aplicado a todos os sistemas homem-máquina. No entanto,
os itens do questionário PUT são principalmente focados em software com interface gráfica, que requer
___________________________________________________________________________ 16
monitor, teclado e rato. Deve ter-se algum cuidado ao utilizar o questionário para avaliar sistemas
interativos que consistem em som, voz, animação ou vídeo.
Usefullness, Satisfaction and Ease of use (USE) Questionnaire
O questionário USE, identifica a Utilidade, Satisfação, e facilidade de uso [31]. Estas são as três
dimensões que surgiram com maior força no início do desenvolvimento do questionário USE. Para
muitas aplicações, usabilidade parece consistir em utilidade e facilidade de uso. Ambos estão
correlacionados. Cada fator, por sua vez determina a satisfação do utilizador e frequência de uso. Os
utilizadores parecem ter uma boa noção do que é útil e que não é, e pode-se aplicar as suas métricas
internas em vários domínios;
Wizard of Oz
O Wizard of Oz é uma avaliação, baseada no utilizador, de tecnologia ainda não implementada,
onde, geralmente desconhecido para o utilizador, uma equipa humana está a simular algumas ou todas
as respostas do sistema [32]. Algumas vantagens desta avaliação são testar tecnologias futuras sem a
construção de um protótipo caro, enchendo com funcionalidades que ainda não estão prontas no
protótipo, iterações rápidas, mudanças particularmente menores de redação ou de fluxo de chamadas
são imediatamente possíveis de testar através deste modelo e permitem ao sistema ser avaliado
durante uma fase bastante inicial do processo de conceção.
2.3.3 Conclusão
Através deste estudo foi possível observar as diferentes alternativas que existem em relação a
testes de usabilidade. Vimos que estas devem ser escolhidas consoante os objetivos das avaliações e
como este projeto tem um grande foco na interface com o utilizador foram seguidas principalmente as
heurísticas de Nielsen. Este é um dos métodos mais utilizados no que toca à avaliação de interface do
utilizador, permite encontrar problemas relativos à usabilidade a partir do início da construção da
solução e à medida que esta vai sendo desenvolvida num processo iterativo.
Uma das formas mais adequadas para avaliar uma interface é considerar alternativas ainda em
fase de design, através da avaliação heurística em que se verifica se determinadas regras (heurísticas)
são ou não contempladas na solução e em que grau o são. As heurísticas de Nielsen são as mais
empregues nestas avaliações, ainda que outras existam. Em relação à realização de questionários aos
utilizadores é possível seguir os modelos do ASQ, PUT, ou USE, ou mesmo até, utilizar os atributos de
usabilidade.
___________________________________________________________________________ 17
2.4 Declaração amigável de acidente automóvel
A DAAA é constituída no verso pela Participação de Sinistro. Esta parte do documento só deverá
ser preenchido posteriormente aos intervenientes no sinistro terem preenchido e assinado, em conjunto
a primeira parte da DAAA que contém 15 campos, com informações gerais como data, hora e local do
acidente, dados sobre os tomadores do seguro, veículos, as companhia de seguros e os condutores.
No anexo A encontra-se uma DAAA portuguesa completa. A tabela 1 resume, os principais campos
disponíveis neste documento e a sua descrição.
Tabela 1: Descrição dos vários campos da DAAA.
Grupo Campo Descrição
Dados
Gerais
1.Data do acidente e
Hora Indicar a data e a hora do acidente
2.Localização Especificar o local do acidente (país, localidade e rua)
3.Feridos, mesmo ligeiros Indicar se existem feridos (mesmo que ligeiros) decorrentes
do acidente
4.Danos materiais Indicar se existem danos materiais noutros veículos que não
os da declaração e noutros objetos
5.Testemunhas Caso existam testemunhas do acidente, indicar os seus
dados de contacto (nomes, moradas e telefones)
Veículo A
ou B
6.Segurado/Tomador do
seguro
Indicar qual o segurado (de acordo com o documento de
seguro), e respetivos contactos
7.Veículo Assinalar dados do veículo
8.Companhia de seguros Identificar a seguradora, número da apólice (Carta Verde) e
respetiva validade, bem como outras informações
9.Condutor Colocar elementos da carta de condução, assim como os
dados pessoais
10.Ponto de embate
inicial Indicar por meio de uma seta o ponto de embate inicial
11.Danos visíveis Referir os danos causados na viatura
Dados
Gerais
12.Circunstâncias
Marcar com cruzes as circunstâncias que melhor descrevem
o sinistro. No final da lista deve ser assinalado o número
total de cruzes correspondente a cada veículo
13.Esquema do acidente Indicar o esquema do acidente no momento do embate
Veículo A
ou B
14.As minhas
observações
Referir observações adicionais que sejam pertinentes e que
complementem adequadamente as anteriores. Podem ser
também contestadas as declarações prestadas pelo outro
condutor
Dados
Gerais
15.Assinaturas dos
condutores
Assinar a declaração. Ambas as assinaturas devem ser
idênticas às constantes nos documentos de identificação
___________________________________________________________________________ 18
2.5 Aplicações para notificação de sinistros
Não existe dúvida que o trânsito é um dos tópicos que mais preocupam todos aqueles que usam
veículo próprio para se deslocarem. Apesar da constante evolução tecnológica que tem vindo a permitir
que ao longo dos últimos anos o número de acidentes tenha diminuído e da melhor formação cívica
dos condutores, ainda ocorrem muitos acidentes em todo o mundo e Portugal não é exceção [35].
Nesta situação o preenchimento da DAAA é quase obrigatória para permitir aos condutores dos
veículos recolherem o maior número possível de dados, para descrever mais adequadamente o
acidente.
Figura 3: O gráfico mostra o número de acidentes em Portugal entre os anos de 2005 e 2014 [35].
Nesta secção descreve-se o trabalho relacionado referente às aplicações para notificação de
sinistros existentes.
Como já mencionado na Introdução existem muito poucas aplicações desenhadas para
notificação de sinistros. No panorama nacional destacam-se duas aplicações, a Direct e a eCliente
Allianz Portugal, que permitem notificar um sinistro. A maior parte destas, apesar de estarem
associadas a uma seguradora, parecem ainda ser um protótipo, como é o caso das aplicações eCliente
Allianz Portugal, My Axa e Accident Report.
Foram analisadas 7 aplicações, todas elas para o sistema operativo Android. Tendo em conta o
trabalho a desenvolver são apresentados os seguintes tópicos:
Descrição;
Funcionalidades;
Algumas imagens (screenshots);
Vantagens e Desvantagens;
Avaliação
___________________________________________________________________________ 19
Em todas as aplicações é apresentado um quadro com algumas funcionalidades. Estas foram
extrapoladas maioritariamente a partir do estudo dos vários produtos:
1. Espaço de negócio, isto é, se de alguma forma é feita publicidade a produtos da
seguradora. A aplicação para além da notificação de sinistro também compreende que
existe uma oportunidade para difundir produtos;
2. Apresenta mais funcionalidades para além da notificação de sinistro;
3. Permite fazer a notificação de outros tipos de sinistros, ou seja, permite a notificação de
sinistros para além da DAAA;
4. Permite que dois utilizadores com a mesma aplicação troquem de alguma forma dados
entre dispositivos;
5. Acesso à BD da seguradora, isto é, o utilizador pode aceder à BD para obter informações
relevantes para o preenchimento dos vários dados da DAAA;
6. Possibilita chamar serviço de emergência, indicando a localização onde o utilizador se
encontra descritivamente e através de mapa;
7. Possibilita chamar reboque, indicando a localização do utilizador descritivamente e
através de mapa;
8. Permite saber a localização e morada mais próxima de onde ocorreu o sinistro;
9. Semelhança com DAAA. Este atributo pretende definir se os campos que estão
presentes no documento em papel da declaração amigável são também de algum modo
tratados na aplicação;
10. A aplicação permite preencher uma notificação mesmo sem acesso à internet no
momento do sinistro;
11. É possível selecionar uma oficina para enviar o veículo;
12. Depois de preenchida, a declaração amigável é apresentada ao utilizador para revisão;
13. Envia email para a seguradora com notificação de sinistro;
14. Cria XML ou outro tipo de ficheiro com os dados extraídos durante o preenchimento da
declaração amigável, para uma integração mais proficiente com a seguradora.
No final apresenta-se um quadro que resume e compara as várias aplicações para notificação
de sinistros em relação às suas principais funcionalidades.
A avaliação funciona numa escala de 0 a 5, sendo 1 muito mau e 5 muito bom, e 0 a inexistência
de tais funcionalidades. Esta avaliação foi efetuada considerando avaliações em sites da própria
aplicação, bem como um teste cuidado sobre cada uma das aplicações.
___________________________________________________________________________ 20
2.5.1 eCliente Allianz Portugal
Descrição
A aplicação eCliente Portugal pertence à seguradora Allianz e permite a um cliente aceder à sua
carteira de seguros através de uma ligação à internet. Das principais funcionalidades presentes
destaca-se o acesso a contactos de assistência automóvel caso seja necessário assistência na estrada.
Nesta aplicação também é possível consultar a oficina mais próxima do local onde o utilizador se
encontra. Caso o utilizador esteja registado no eCliente Allianz, poderá também consultar as suas
apólices, contactar o seu Mediador, abrir e consultar sinistros.
Funcionalidades
A aplicação apresenta algumas funcionalidades das quais se destacam:
Funcionalidade Detalhes
1.Espaço de negócio Existe para novos produtos e está presente em forma de texto
2.Mais funcionalidades que
notificação de sinistro
Sim, permite executar várias funcionalidades, por exemplo, indica
contatos de assistência e onde podemos encontrar uma agência
3.Notificação de outro tipo de
sinistros Não
4.Permite trocar dados entre
dispositivos com a mesma
aplicação
Não
5.Acesso à BD da seguradora Sim, é possível obter informações dos contratos de seguro do
cliente
6.Chamar Emergência (Indica
Localização descritiva e com mapa)
Sim, é apresentado o número de contacto de alguns serviços de
emergência, mas sem indicar a localização
7.Chamar Reboque (Indica
Localização descritiva e com mapa)
Sim, é apresentado o número de contacto da assistência, mas
sem indicar a localização
8.Pesquisar morada mais próxima
Sim, quando se deseja encontrar uma oficina, mediador ou
agente, a aplicação mostra o mapa, tendo integração com o
Google Maps. Porém, não indica a morada ou local
descritivamente
9.Semelhante à DAAA
Não. Aborda alguns tópicos, como por exemplo, danos causados
ao veículo. Mas na íntegra não tem os mesmos campos que a
DAAA
10.Possibilidade de fazer
notificação sem acesso à internet Não, porque o utilizar tem de fazer Login antes do preenchimento
11.Seleccionar oficina Não é possível
12.Revisão dos dados preenchidos Sim, possível consultar sinistros notificados anteriormente
13.Notificação enviada para a
seguradora via email Sim
14. Integração com seguradora Não existe qualquer tipo de funcionalidade para integração com a
seguradora
Tabela 2: Análise a algumas funcionalidades da aplicação eCliente Allianz.
___________________________________________________________________________ 21
Algumas imagens
Figura 4: Alguns ecrãs presentes na aplicação eCliente Allianz Portugal.
Vantagens e Desvantagens da Aplicação
Vantagens
Boa para utilizadores que utilizem a aplicação pela primeira vez, porque a notificação é
feita passo-a-passo (semelhante a um wizard). O processo é dividido em pequenas
etapas guiadas, proporcionando ao utilizador ajuda na interação com cada actividade.
Lista de contactos de assistência vasta;
Tem a possibilidade de mostrar informações, como a localização de agências, pelo
Google Maps ou através de uma lista.
Desvantagens
Interface gráfica algo pobre;
Impossibilidade de criar uma notificação de sinistro sem acesso à conta, é obrigatório ter
uma conta de cliente para se poder utilizar esta aplicação;
Lenta em algumas tarefas, como iniciar o preenchimento de uma notificação de um
sinistro, ou contactar emergência
Avaliação final
Categoria Classificação
Velocidade para notificar um sinistro 3
Ferramentas 3
Facilidade de Utilização 3
Interface gráfica 2
Tabela 3: Avaliação da aplicação eCliente Allianz.
___________________________________________________________________________ 22
2.5.2 AAMI Claim Assist
Descrição
A aplicação pertence à seguradora australiana AAMI e foi lançada em Agosto de 2014. Esta
solução pretende servir principalmente para notificar sinistros entre veículos e permite recolher várias
informações do local do acidente e enviar estes dados para a AAMI. Esta aplicação tem acesso à BD
da seguradora, para por exemplo, confirmar que o número da apólice colocada pelo utilizador está
correto. De forma a ser mais fácil reunir os dados do sinistro o utilizador é aconselhado a
definir/escrever o seu perfil antecipadamente para, no caso de acidente, estas informações já se
encontrarem preenchidas.
Funcionalidades
Funcionalidade Detalhes
1.Espaço de negócio Não existe
2.Mais funcionalidades que notificação
de sinistro
Não há ferramentas para além daquelas essenciais para
notificação dum acidente
3.Notificação de outro tipo de sinistros Não
4.Permite trocar dados entre
dispositivos com a mesma aplicação Não
5.Acesso à BD da seguradora Sim, é possível confirmar algumas informações, através do
número de apólice de cliente
6.Chamar Emergência (Indica
Localização descritiva e com mapa)
Sim, é possível chamar a emergência, no entanto não é
indicada a localização quando se deseja fazer esta ação
7.Chamar Reboque (Indica Localização
descritiva e com mapa)
Sim é possível chamar o reboque e é indicada a morada
automaticamente. Também é apresentado um mapa com a
localização do cliente
8.Pesquisar morada mais próxima Sim, encontra morada mais próxima automaticamente
9.Semelhante à DAAA Não, apesar de algumas informações iguais, pois a aplicação
é direcionada para o mercado australiano
10.Possibilidade de fazer notificação
sem acesso à internet Sim
11.Seleccionar oficina Não é possível
12.Revisão dos dados preenchidos Sim, enquanto se reúne os detalhes do sinistro é apresentado
um sumário das informações
13.Notificação enviada para a
seguradora via email Não
14. Integração com seguradora
Sim, é enviada através de um sistema que permita integrar
diretamente com a seguradora. No entanto, não há nenhuma
confirmação da sua recepção
Tabela 4: Análise a algumas funcionalidades da aplicação AAMI Claim Assist.
___________________________________________________________________________ 23
Algumas imagens
Figura 5: Alguns ecrãs presentes na aplicação AAMI Claim Assist.
Vantagens e Desvantagens da Aplicação
Vantagens
Interface clara e consistente;
Permite indicar automaticamente a localização do utilizador de uma forma simples;
O sistema identifica informações em falta de uma forma versátil e direta;
Desvantagens
Todo o preenchimento do formulário de sinistro baseado em escrita no dispositivo móvel,
não aproveitando talvez da melhor maneira outras tecnologias disponíveis;
Quando é enviada a informação para a seguradora, o cliente não recebe nenhuma
mensagem a notificar que esta foi submetida com sucesso;
Não possui funcionalidades para além da notificação de sinistro e algumas assistências.
Avaliação final
Categoria Classificação
Velocidade para notificar um sinistro 3 (caso o utilizador já tenha preenchido os dados de perfil)
Ferramentas 1 (só está preparada para notificar sinistros)
Facilidade de Utilização 4
Interface gráfica 5
Tabela 5: Avaliação da aplicação AAMI Claim Assist.
___________________________________________________________________________ 24
2.5.3 Shannons Claim Assistant
Descrição
A aplicação surgiu em Fevereiro de 2014 e pertence à seguradora australiana Shannons. Esta
solução permite ao utilizador recolher dados para fazer a DAAA e apresenta algumas funcionalidades
para ajudar durante o preenchimento desta. Quando a aplicação foi testada, o acesso à localização
não funcionou.
Funcionalidades
Funcionalidade Detalhes
1.Espaço de negócio Não existe
2.Mais funcionalidades que notificação
de sinistro
Sim, a aplicação tem como principal objetivo realizar a
notificação em caso de sinistro e apresenta uma lista de
contactos úteis em caso de sinistro
3.Notificação de outro tipo de sinistros Não
4.Permite trocar dados entre
dispositivos com a mesma aplicação Não
5.Acesso à BD da seguradora Sim, é possível confirmar algumas informações, através do
número de apólice de cliente
6.Chamar Emergência (Indica
Localização descritiva e com mapa)
Sim, é possível chamar a emergência, no entanto não é
indicada a localização quando se deseja fazer esta ação
7.Chamar Reboque (Indica Localização
descritiva e com mapa)
Sim, é possível chamar a emergência, no entanto não é
indicada a localização quando se deseja fazer esta ação
8.Pesquisar morada mais próxima Sim, indica que tem esta funcionalidade, todavia ao ser
experimentada não funcionou
9.Semelhante à DAAA Não, apesar de algumas informações iguais, pois a aplicação
é direcionada para o mercado australiano
10.Possibilidade de fazer notificação
sem acesso à internet Sim
11.Seleccionar oficina Não é possível
12.Revisão dos dados preenchidos Sim, é possível enquanto se reúne os detalhes do sinistro ver
um sumário dos dados preenchidos
13.Notificação enviada para a
seguradora via email Não
14. Integração com seguradora
Sim, é enviada através de um sistema que permita integrar
diretamente com a seguradora. No entanto, não há nenhuma
confirmação da sua recepção
Tabela 6: Análise a algumas funcionalidades da aplicação Shannons Claim Assistant.
___________________________________________________________________________ 25
Algumas imagens
Figura 6: Alguns ecrãs presentes na aplicação Shannons Claim Assistant.
Vantagens e Desvantagens da Aplicação
Vantagens
Interface clara e consistente;
Permite fazer a notificação sem ser necessário estar ligado à internet;
Notificação rápida de preencher, especialmente se já tiver os dados de perfil inseridos;
Desvantagens
Esta solução é semelhante à aplicação AAMI Claim Assist, no entanto apresenta menos
funcionalidades;
Não tem outras funcionalidades para além da notificação de sinistro.
Procura da localização não funciona;
Avaliação final
Categoria Classificação
Velocidade para notificar um sinistro 3 (caso o utilizador já tenha preenchido os dados de perfil)
Ferramentas 2 ( permite notificar sinistros, chamar reboque e emergência)
Facilidade de Utilização 4
Interface gráfica 3
Tabela 7: Avaliação da aplicação Shannons Claim Assistant.
___________________________________________________________________________ 26
2.5.4 Direct
Descrição
Esta solução pertence à seguradora AXA e foi lançada em Fevereiro de 2014. Com esta
aplicação o utilizador pode aceder aos contactos da assistência em viagem e enviar uma declaração
amigável em caso de acidente. A solução está muito focada em oferecer várias ferramentas
relacionadas com seguros ao utilizador, sendo a aplicação com mais funcionalidades para além da
declaração amigável de sinistro automóvel.
Funcionalidades
Funcionalidade Detalhes
1.Espaço de negócio Existe uma secção especial para mostrar novos produtos e
ofertas especiais
2.Mais funcionalidades que notificação
de sinistro
Sim, há uma extensa lista de ferramentas que em geral
funcionam convenientemente
3.Notificação de outro tipo de sinistros Não
4.Permite trocar dados entre
dispositivos com a mesma aplicação Não
5.Acesso à BD da seguradora Não
6.Chamar Emergência (Indica
Localização descritiva e com mapa)
Sim, é possível chamar a emergência, no entanto não é
mostrado um mapa, nem a localização onde o utilizador se
encontra
7.Chamar Reboque (Indica Localização
descritiva e com mapa)
Sim, é possível chamar o reboque, no entanto não é
mostrado o mapa, nem a localização do utilizador
8.Pesquisar morada mais próxima
Sim é possível indicar a morada mais próxima, porém esta
funcionalidade não está disponível para o envio da DAAA,
mas sim nas Ferramentas
9.Semelhante à DAAA
Não, a DAAA é bastante pobre em comparação ao respetivo
formato em papel. Na ferramenta Help chega mesmo a ser
indicado para usar a declaração em papel
10.Possibilidade de fazer notificação
sem acesso à internet Não
11.Seleccionar oficina
É possível encontrar oficinas próximas, no entanto não existe
a opção de selecionar para qual oficina se deseja enviar a
viatura
12.Revisão dos dados preenchidos Sim, é feita no email e pode ser editado no corpo do mesmo
13.Notificação enviada para a
seguradora via email Sim
14. Integração com seguradora Não existe qualquer tipo de funcionalidade para integração
com a seguradora
Tabela 8: Análise a algumas funcionalidades da aplicação Direct.
___________________________________________________________________________ 27
Algumas imagens
Figura 7: Alguns ecrãs presentes na aplicação Direct.
Vantagens e Desvantagens da Aplicação
Vantagens
Excelente interface gráfica, muito fácil de utilizar por qualquer utilizador;
Aplicação em português;
Permite ao utilizador configurar a suas utilidades favoritas;
Desvantagens
A notificação de sinistro tem poucos parâmetros para uma informação clara e consistente
do sinistro.
Só é possível aceder à aplicação com uma ligação à internet;
O preenchimento da declaração é tão simples que não chega a ter campos para colocar
as informações do outro condutor e veículo;
O envio por email é paupérrimo. Neste passo pode-se editar as informações anteriores.
Avaliação final
Categoria Classificação
Velocidade para notificar um sinistro 1
Ferramentas 5
Facilidade de Utilização 4
Interface gráfica 5
Tabela 9: Avaliação da aplicação My Axa.
___________________________________________________________________________ 28
2.5.5 My AXA
Descrição
Esta aplicação foi desenvolvida pela companhia de seguros AXA Portugal e foi lançada no final
de 2013 no Google Play. A solução permite aos utilizadores acesso a funcionalidades que pretendem
simplificar o dia-a-dia do utilizador, através da disponibilizações de vários serviços, como acesso às
oficinas recomendadas AXA, clínicas médicas, simulação/compra de produtos online, tirar fotografias
aos danos do veículo, entre outras funcionalidades.
Funcionalidades
Funcionalidade Detalhes
1.Espaço de negócio Existe um espaço publicitário logo no menu principal e permite
comprar/simular produtos da seguradora
2.Mais funcionalidades que notificação de
sinistro
Sim, apresenta diversas ferramentas, mas o utilizador é
reencaminhado para as páginas web da seguradora
3.Notificação de outro tipo de sinistros
É possível participar um sinistro Habitação. Também é possível
dentro de sinistros “Automóvel” participar sinistro quebra de
Vidros
4.Permite trocar dados entre dispositivos
com a mesma aplicação Não
5.Acesso à BD da seguradora Não
6.Chamar Emergência (Indica Localização
descritiva e com mapa)
É possível chamar a emergência, no entanto não está disponível
nem o mapa, nem a morada mais próxima de onde o utilizador se
encontra
7.Chamar Reboque (Indica Localização
descritiva e com mapa) Não existe nenhuma opção para chamar o reboque
8.Pesquisar morada mais próxima Não há a opção para encontrar a morada mais próxima
9.Semelhante à DAAA Não, apesar de alguns campos iguais à DAAA não é semelhante.
Falta, por exemplo, o ponto de embate inicial da viatura
10.Possibilidade de fazer notificação sem
acesso à internet Sim
11.Seleccionar oficina Sim
12.Revisão dos dados preenchidos Sim, a revisão dos dados é feita no próprio email, onde o
utilizador pode modificar as informações preenchidas no final
13.Notificação enviada para a seguradora
via email Sim, as imagem com os danos do veículo vão anexadas
14. Integração com seguradora Sim, permite guardar a notificação do sinistro e a informação
pessoal de forma automática através de recurso ao QR Code
Tabela 10: Análise a algumas funcionalidades da aplicação My Axa.
___________________________________________________________________________ 29
Algumas imagens
Figura 8: Alguns ecrãs presentes na aplicação My Axa.
Vantagens e Desvantagens da Aplicação
Vantagens
Sistema de histórico de sinistros muito simples e fácil de utilizar;
Declaração de sinistro rápida de preencher;
Disponível em português;
Desvantagens
A aplicação peca bastante por grande parte das suas funcionalidades principais não
passarem de ícones com ligação para as páginas web da seguradora AXA;
O utilizador fica com a sensação que faltam dados para notificar o sinistro de uma forma
completa durante a recolha de informações;
O envio de informações para a seguradora podia ser feito de uma forma mais
organizada. O envio da notificação de sinistro coloca os dados por extenso no corpo do
email a ser enviado para a seguradora.
Avaliação final
Categoria Classificação
Velocidade para notificar um
sinistro 5
Ferramentas 2 (imensas funcionalidade que acedem ao respetivo às páginas da web da
seguradora)
Facilidade de Utilização 3
Interface gráfica 3
Tabela 11: Avaliação da aplicação My Axa.
___________________________________________________________________________ 30
2.5.6 AxiKit Accident Report Kit
Descrição
A aplicação surgiu em Novembro de 2014 e pertence à empresa AxiKit que desenhou esta
aplicação móvel. O modelo de negócio desta aplicação é diferente de algumas aplicações já
referenciadas. A AxiKit pretende vender a solução a empresas com uma frota de automóveis, sendo
personalizada para cada empresa em particular. A aplicação tem a particularidade de orientar passo a
passo o utilizador durante a notificação de sinistro para que o utilizador entenda o que tem de fazer.
Para além de obter as informações descritivamente, a outra forma predominante de obtenção é através
da gravação de voz e fotos. Foi testada a versão de demonstração.
Funcionalidades
Funcionalidade Detalhes
1.Espaço de negócio
Quando adquirida por uma empresa poderá ser personalizada
para mostrar o símbolo dessa empresa, mas não é orientada
para esta funcionalidade
2.Mais funcionalidades que notificação
de sinistro Não
3.Notificação de outro tipo de sinistros Não
4.Permite trocar dados entre
dispositivos com a mesma aplicação
Não é possível trocar dados entre dispositivos com esta
aplicação
5.Acesso à BD da seguradora Não tem nenhuma ligação a qualquer seguradora
6.Chamar Emergência (Indica
Localização descritiva e com mapa)
É possível chamar a emergência. Não é mostrado um mapa,
mas tem um campo para indicar a morada automaticamente
7.Chamar Reboque (Indica Localização
descritiva e com mapa) Não tem esta opção
8.Pesquisar morada mais próxima
Sim, para chamar a emergência. Porém, não pesquisa esta
informação durante o preenchimento de informações para a
seguradora
9.Semelhante à DAAA A aplicação é desenhada para o mercado americano,
apresenta uma alternativa à DAAA
10.Possibilidade de fazer notificação
sem acesso à internet Não
11.Seleccionar oficina Não
12.Revisão dos dados preenchidos Sim, a revisão é feita no corpo do email antes da submissão
da notificação
13.Notificação enviada para a
seguradora via email Sim
14. Integração com seguradora Não existe qualquer tipo de funcionalidade para integração
com a seguradora
Tabela 12: Análise a algumas funcionalidades da aplicação AxiKit Accident Report Kit.
___________________________________________________________________________ 31
Algumas imagens
Figura 9: Alguns ecrãs presentes na aplicação AxiKit Accident Report Kit.
Vantagens e Desvantagens da Aplicação
Vantagens
Notificação de sinistro consideravelmente simple e rápida de efetuar;
Interface gráfica interessante e clara;
Sistema de ajuda de notificação útil e simples de entender pelo utilizador;
Desvantagens
Acesso à internet obrigatório para aceder à DAAA;
Antes da notificação ser enviada para a seguradora, a revisão das informações é feita
no corpo do email, e como grande parte da obtenção das informações advêm de
gravações áudio, estas informações no email só indicam se foi ou não feita uma
gravação;
É necessário pagar para obter a versão completa da aplicação.
Avaliação final
Categoria Classificação
Velocidade para notificar um sinistro 4
Ferramentas 2
Facilidade de Utilização 4
Interface gráfica 4
Tabela 13: Avaliação da aplicação AxiKit Aciident Report Kit.
___________________________________________________________________________ 32
2.5.7 Accident Report
Descrição
Esta aplicação foi lançada em Setembro de 2014 e não está associada a nenhuma seguradora.
A aplicação é um protótipo para o mercado Americano e foca-se simplesmente na notificação de
sinistro. Neste ponto a aplicação é fácil e engenhosa de utilizar em comparação às demais aplicações
analisadas. No entanto o grande foco no preenchimento da notificação prejudica a solução, tal como
demonstra a falta de uma lista de contactos úteis para chamar a emergência ou um reboque.
Funcionalidades
Funcionalidade Detalhes
1.Espaço de negócio Não existe
2.Mais funcionalidades que notificação
de sinistro
Não. Focada simplesmente na notificação de sinistro, sem
lista de contactos úteis, nem ferramentas extra
3.Notificação de outro tipo de sinistros Não
4.Permite trocar dados entre
dispositivos com a mesma aplicação Não
5.Acesso à BD da seguradora
Não existe nenhuma ligação à seguradora. No entanto, o
utilizador pode guardar os seus dados antecipadamente, para
depois preencher a notificação de forma automática
6.Chamar Emergência (Indica
Localização descritiva e com mapa) Não existe nenhum contacto com o número de emergência
7.Chamar Reboque (Indica Localização
descritiva e com mapa) Não existe nenhum contacto com o reboque
8.Pesquisar morada mais próxima Sim, é mostrado o mapa com a localização do utilizador
9.Semelhante à DAAA
Sim, vários campos semelhantes à DAAA, o que promove um
sentimento de confiança junto do utilizador enquanto este
preenche a notificação após um sinistro
10.Possibilidade de fazer notificação
sem acesso à internet Sim
11.Seleccionar oficina Não
12.Revisão dos dados preenchidos Sim, produz um documento pdf para o utilizador confirmar
que todas as informações estão corretas
13.Notificação enviada para a
seguradora via email Sim, é anexado um pdf com os vários dados preenchidos
14. Integração com seguradora Não existe qualquer tipo de funcionalidade para integraçãoo
com a seguradora
Tabela 14: Análise a algumas funcionalidades da aplicação Accident Report.
___________________________________________________________________________ 33
Algumas imagens
Figura 10: Alguns ecrãs presentes na aplicação Accident Report.
Vantagens e Desvantagens da Aplicação
Vantagens
A aplicação permite recolher muitos dos elementos utilizados numa DAAA;
Produz um documento pdf para o utilizador confirmar que todas as informações estão
corretas ;
Possível aceder a qualquer função com 3 a 4 cliques no ecrã. Cada actividade dispõe
das funcionalidades organizadas duma forma bem estruturada;
Desvantagens
Descrição do acidente é meramente feita por texto, não recorrendo a formas alternativas
como, por exemplo, áudio;
Não está preparada para mostrar outros produtos da seguradora aos utilizadores;
Aplicação focada na DAAA, sem nenhumas ferramentas extra;
Não tem lista de contactos úteis, nem de emergência, nem de reboque e não está
disponível para tablet;
Avaliação final
Categoria Classificação
Velocidade para notificar um sinistro 5
Ferramentas 1
Facilidade de Utilização 4
nterface gráfica 4
Tabela 15: Avaliação da aplicação Accident Report.
___________________________________________________________________________ 34
2.6 Comparação dos vários produtos
Na tabela seguinte são comparados todos os produtos de notificação de sinistro estudados
anteriormente. As características segundo as quais são comparados foram as presentes no tema
Funcionalidades.
Aplicações
eCliente Allianz
Portugal
AAMI Claim Assist
Shannons Claim
Assistant Direct My AXA
AxiKit Accident Report Kit
Accident Report
1. Espaço de negócio
Sim Não Não Sim Sim Não Não
2. Mais funcionalidades que notificação de sinistro
Sim Não Não Sim Sim Não Não
3. Notificação de outro tipo de sinistros
Não Não Não Não Sim Não Não
4. Permite trocar dados entre dispositivos com a mesma aplicação
Não Não Não Não Não Não Não
5. Acesso à BD seguradora
Sim Sim Sim Não Não Não Não
6. Chamar Emergência (Indica Localização descritiva e/ou mostra mapa)
Sim (Não/Não)
Sim (Não/Não)
Sim (Não/Não)
Sim (Não/Não)
Sim (Não/Não)
Sim (Não/Sim)
Não (-/-)
7. Chamar Reboque (Indica Localização descritiva e com mapa)
Sim (Não/Não)
Sim (Sim/Sim)
Sim (Não/Não)
Sim (Não/Não)
Não (-/-)
Não (-/-)
Não (-/-)
8. Pesquisar por morada mais próxima
Sim (mapa)
Sim Sim Não Não Sim
(emergência) Sim
9. Semelhante à DAAA
Pouco Pouco Pouco Não Pouco Relativamente Semelhante
10. Possibilidade de fazer notificação sem acesso à internet
Sim Sim Sim Não Sim Não Sim
11. Selecionar oficina
Não Não Não Não Sim Não Não
12. Revisão dos dados preenchidos
Sim (janela da
aplicação)
Sim(janela da aplicação)
Sim(janela da aplicação)
Sim (email)
Sim (email)
Sim (email)
Sim (pdf)
13. Notificação enviada para a seguradora por mail
Sim Não Não Sim Sim Sim Sim
14. Integração com a seguradora (XML ou JSON)
Não Sim
(ao enviar) Sim
(ao enviar) Não
Sim (QR code)
Não Não
Tabela 16: Comparação de produtos existentes no mercado.
Podemos indicar em relação às aplicações as seguintes conclusões: a maior parte das
aplicações apresenta uma lista de contactos úteis (emergência, reboque, polícia, etc.); Normalmente
só permitem a notificação da DAAA; Nenhuma aplicação consegue interagir com a mesma aplicação
de outro utilizador; Poucas soluções apresentam a DAAA na íntegra para os utilizadores preencherem;
o acesso à BD da seguradora, através da internet, não é um recurso utilizado com todo o potencial que
poderia ter; e cinco das aplicações vêm preparadas para a notificação do sinistro sem acesso à Internet.
___________________________________________________________________________ 35
2.7 Desafios
Após uma análise cuidada e exaustiva do trabalho existente, concluímos que a usabilidade nos
dispositivos móveis é um desafio recorrente para quem desenvolve aplicações móveis. Hoje em dia,
por norma, as aplicações móveis não são o foco do utilizador, porque geralmente este utiliza as
aplicações móveis entre tarefas e visualiza as informações estritamente necessárias e muitas vezes o
utilizador não chega a utilizar as funcionalidades da aplicação por completo. A aplicação móvel torna-
se portanto um foco secundário, pois o utilizador habitualmente consulta na aplicação o que necessita
momentaneamente e retoma a outra actividade. A importância da aplicação possuir uma boa
usabilidade de forma a prender o foco do utilizador torna-se assim vital.
As organizações estão mais preocupadas em suportar requisitos cada vez mais funcionais para
os utilizadores em vez de pensar em como organizá-las, e começa a ficar mais difícil integrar todas as
opções sob uma única UI, tornando-se confuso, esmagadora e difícil de operar. Outra questão é a falta
de normas ou padrões de interface de utilizador (UI patterns), que poderiam ajudar a resolver uma série
de problemas em relação à usabilidade. Por fim, as aplicações estudadas não conseguiam expor o
negócio e ao mesmo tempo permitir a notificação de um sinistro apelativamente. As aplicações ou eram
demasiado focadas na notificação, ou então tinhas várias ferramentas boas, mas que todavia tinham
uma notificação mediana.
Neste projeto, no processo de desenvolvimento da aplicação os maiores desafios residiam em
tentar superar as lacunas que outras aplicações previamente estudadas possuem. As aplicações que
os utilizadores podem encontrar atualmente no mercado, para uso pessoal ou comercial, apesar de
trazerem benefícios para o utilizador e permitirem dar início ao processo de uma DAAA, embora
interessantes, ainda se consegue questionar o seu valor legar por duas razões em especial. A primeira
razão advém das grandes diferenças entre os dados presentes numa DAAA oficial e a respetiva
notificação nas várias aplicações. É óbvia a falta de alguns dados específicos como o número da
apólice da outra pessoa envolvida no acidente, que é um dado fundamental para as seguradoras
submeterem uma avaliação do sinistro. A segunda razão é a validade e verosimilhança da declaração.
Atualmente as pessoas preenchem a declaração amigável e no fim são necessárias as assinaturas de
ambos os condutores envolvidos no acidente. Nas aplicações observadas não existe nenhum
mecanismo que permita confirmar o princípio de não-repúdio por parte dos intervenientes no acidente,
o que para uma seguradora é fulcral. Sendo esta razão um problema não considerado nos diversos
trabalhos avaliados, proporciona a este projeto o desafio de construir uma solução, pelo menos teórica,
sobre um sistema que permita confirmar o não-repúdio dos condutores.
Ao observar a tabela 16, verifica-se que nenhuma aplicação é perfeita em todos as áreas, mas
todas estas parecem ser ótimas em alguns campos específicos. Desta forma, é colocado o desafio de
integrar, com bons níveis de usabilidade, as várias funcionalidades interessantes observadas, como
permitir fazer a notificação sem ligação à Internet, obter a localização, indicar oficina, preparar a
aplicação para servir de “montra” publicitária, aceder a informações da seguradora e integração com
os sistemas das seguradora.
___________________________________________________________________________ 39
3. Requisitos
Este capítulo visa detalhar em profundidade a aplicação a construir em termos das suas
funcionalidades para os utilizadores finais. Para isso, são definidos os requisitos funcionais, requisitos
não-funcionais e prototipagem de cenários (mockups). A opção por definir o desenho funcional segundo
estes artefactos foi tomada por se ter considerado que são os mais adequados à modelação do sistema
em causa:
A prototipagem de cenários, por ser um método eficaz na demonstração do que é
esperado que sejam as funcionalidades e interações com o sistema final, dando a
possibilidade a quem desenvolve o projeto de transmitir a sua interpretação do mesmo,
antes que o esforço de implementar esses cenários tenha ocorrido;
O levantamento e priorização dos requisitos, por ser fundamental na definição das
funcionalidades que o sistema em causa deverá compreender.
3.1 Levantamento de Requisitos
Durante a fase inicial dos projetos realizaram-se diversas reuniões onde se debateram quais as
funcionalidades que o sistema deveria compreender. Assim, foi identificada grande parte dos requisitos
funcionais que serviram de base ao desenho dos protótipos funcionais. Ao serem debatidos os
protótipos, foram sendo levantados novos requisitos que deram origem a modificações nos próprios
protótipos, tendo sido uma tarefa iterativa até se atingir um conjunto de protótipos que satisfizesse o
âmbito e os objetivos pretendidos.
A aplicação móvel para notificação de sinistro foi implementada num sistema Android, porque
como visto anteriormente no ponto 2.1 o sistema é líder destacado no mercado das aplicações móveis,
o sistema Android é código aberto, havia já alguma familiaridade na programação na linguagem Java
e existia um acesso notavelmente superior a múltiplos tipos de aparelhos com o sistema Android do
que a aparelhos com o sistema iOS, ou Windows Phone.
Antes de começar o desenvolvimento dos protótipos funcionais foi proposto um diagrama que
pretende oferecer uma interpretação de alto nível do comportamento da aplicação móvel para
notificação de sinistros. Este esquema pode ser consultado na figura 11 (página 36), onde cada módulo
pode ser interpretado como uma actividade da aplicação. Uma actividade representa a camada de
apresentação de uma aplicação Android, por exemplo, um ecrã que o utilizador vê. Cada aplicação
Android pode ter várias actividades e pode alternar entre elas durante a sua execução. O esquema
pretende ilustrar as interações possíveis entre as várias actividades, tendo em foco especial as
actividades que permitem executar a notificação de sinistros.
___________________________________________________________________________ 40
3.1.1 Mapa de funcionalidades da aplicação
Em seguida é apresentado o diagrama de actividades sobre a notificação de sinistros. Cada caixa pode ser entendido como uma actividade (ecrã), a
que o utilizador irá aceder depois de efetuar uma determinada ação.
Figura 11: Diagrama detalhado das principais actividades responsáveis na aplicação móvel para notificação.
___________________________________________________________________________ 41
3.1.2 Protótipos funcionais
Num projeto com estas características a interface com os utilizadores é um requisito de extrema
importância, pois a facilidade de utilização determinará a satisfação dos clientes finais do produto.
Nesta secção são apresentados os protótipos funcionais criados. Estes demonstram o sistema
em termos das suas funcionalidades, possibilitam um melhor entendimento do mesmo, permitem
detetar erros graves de usabilidade, funcionalidades em falta, indicar especificações e descrever com
maior detalhe e facilidade os vários protótipos.
Esta fase de prototipagem (protótipos funcionais) e de teste com utilizadores foi feita em fase de
desenho e de implementação, com objetivo de detetar erros o mais cedo possível, quando estes são
mais fáceis de corrigir. No capítulo 6 são relatados os testes com utilizadores com recurso ao protótipo
final, onde a usabilidade foi avaliada.
Descrição de requisitos pretendidos
Antes de ser iniciado o desenvolvimento dos protótipos funcionais foi feito um pequeno esboço das
principais funcionalidades de cada actividade referentes à notificação de sinistro (módulo A a M) e
actividades complementares (módulos N a R). O levantamento de requisitos é apresentado na tabela
em baixo, onde são apresentados os botões, informações e alertas presentes nos vários protótipos. A
seguir a esta exposição são apresentados os múltiplos protótipos funcionais desenhados.
Módulo Botões Informações e Alertas
(A) Splash
screen . Sem botões
- Consiste numa janela que contém o logotipo da empresa.
- Não tem alertas.
(B) Menu
Principal
. Notificação de sinistro
. Perfil
. Mapas
. Reboque
. Produtos
. Telematics
. Assistência
. Emergência
. Log Off
. Ecrã para publicidade da
seguradora
. Definições
- Menu que pretende ter como principal intenção a notificação de
sinistro, como também a possibilidade de publicitar produtos da
seguradora. Ou seja, existe a vertente principal da notificação de
um sinistro, mas também uma componente de negócio que permite
acrescentar maior valor à solução.
- Alerta caso não exista ligação à internet.
(C) Menu de
Notificação
. Emergência
. Reboque
. Selecionar sinistro
. Notificações pendentes
- Início da notificação de sinistro. Permite ao utilizador, antes de
realizar a notificação, contactar a emergência, ou o reboque. Caso
existam notificações pendentes é possível saltar etapas referentes
à elaboração de um sinistro.
- Não tem alertas.
(D) Participar
Sinistro
. Botões relacionados com tipo
de sinistro (Automóvel,
Habitação, Saúde, etc.)
- Utilizador seleciona qual o tipo de sinistro que quer participar.
- Não tem alertas.
(E) Automóvel
Botões relacionados com o
sinistro automóvel (DAAA,
Quebra de vidros, Capotamento,
Avaria, etc.
- Permite ao utilizador selecionar mais especificamente o tipo de
sinistro que ocorreu.
- Não tem alertas.
___________________________________________________________________________ 42
Módulo Botões Informações e Alertas
(F) Declaração
Amigável
. Informação Geral
. Veículo formulário
. Ponto de embate inicial veículo
. Danos visíveis
. Circunstâncias do acidente
. Selecionar oficina
. Submeter Notificação
- Menu principal para gerar e submeter a DAAA. O utilizador acede às
várias componentes de preenchimento da declaração paralelamente.
- Alerta que questiona sobre o número de veículos envolvidos no
sinistro que possibilita saber no preenchimento da declaração o
número de formulários necessários para o utilizador completar (por
omissão o número a ser apresentado é 2);
(G) Menu
Informação
Geral
. Ver botões relacionados com a
secção 1 a 5 da DAAA no anexo B
- Informações gerais relacionadas com a data do acidente, hora,
localização, etc. Corresponde às secções 1 a 5 da DAAA oficial.
- Alerta lançado quando falta preencher dados.
(H) Menu
Formulário
Veículo
. Ver campos relacionados com a
secção 6 a 9 da DAAA no anexo B
. Obter dados da seguradora
. Carregar informação do veículo
. Selecione Condutor
. Guardar
. Enviar informação do veículo
- Informações gerais relacionadas com as secções 6 a 9 da DAAA
oficial. Permite ir buscar informações automaticamente à seguradora
através do login (email/password), receber e enviar um ficheiro com as
informações preenchidas neste menu para outro dispositivo com a
mesma aplicação.
- Alerta lançado quando falta preencher dados.
(I) Menu Ponto
de embate inicial
. Imagem
. Guardar
- Nesta actividade é apresentada uma viatura genérica com a vista de
cima (top view). Ao utilizado cabe clicar no local inicial de embate.
- Três alertas: Um para indicar o tipo de veículo; Outro confirma se o
utilizador pretende guardar a imagem. O último avisa que ainda não foi
selecionado o ponto de embate, mas o utilizador pretende gravar
(J) Menu Danos
Visíveis
. Veículo A (foto)
. Veículo B (foto)
. Local do acidente 1 (foto)
. Local do acidente 2 (foto)
. Guardar
- Permite fotografar o local do sinistro e danos nos veículos.
(K) Menu
Circunstância
do Acidente
. Lista de 18 circunstâncias, ver
anexo C.
. Esquema do acidente
. As minhas observações
- Neste ecrã escolhe-se o cenário e as condições em que ocorreu o
sinistro. Apresenta vários cenários de acidentes entre veículos. Permite
efetuar uma gravação áudio de algumas observações que o utilizador
pretenda. Possibilidade de desenhar o plano do acidente.
- Alerta apresentado no plano do acidente e nas observações.
(L) Menu
Selecionar
Oficina
. Procurar oficinas recomendadas
. Oficina indicada no perfil
. Indicar oficina manualmente
. Selecionar
. Eliminar morada
. Cancelar
- Possibilita ao utilizador selecionar uma oficina de uma lista de opções
(recomendada, indicada no perfil, manual) para enviar o seu veículo.
- A actividade L é um alerta, onde o utilizador pode selecionar as
opções mencionadas para enviar/levar o seu veículo.
(M) Submeter
Notificação
. Rever Documento
- Enviar Notificação
- Menu responsável pela revisão e submissão de dados preenchidos,
estas informações são enviadas por email à seguradora.
- Só é possível submeter a notificação quando pelo menos as
actividades (G) e (H) estão preenchidas, caso contrário é lançado um
alerta se o utilizador tentar. Também é lançado um alerta se o
utilizador tentar enviar a notificação sem primeiro rever o documento.
(N) Mapas
. Listas de pontos de interesse:
mecânicos, postos de combustível,
polícia, hospitais, etc.
- Permite ao utilizador aceder a uma lista de contatos úteis.
- Ao procurar pontos de interesse, pergunta que tipo de ponto de
interesse o utilizador deseja visualizar perto dele no mapa.
(O) Perfil
. Ver campos relacionados com a
secção 6 a 8 da DAAA no anexo B
. Condutor principal, ver secção 9
no anexo B
. Condutor secundário, ver secção 9
no anexo B
. Mecânico
- O Profile apresenta os dados do utilizador. Pretende-se que ao
utilizador sejam apresentados os dados disponíveis sobre si na BD da
seguradora na aplicação móvel. Também podem ser preenchidos
manualmente para depois serem utilizados no preenchimento das
declarações mesmo que não exista ligação à internet.
- Alerta pede ao utilizador para fazer login com intuito de obter os
dados do cliente.
(P) Logout . Log Off - Sai da conta do utilizador e vai para o ecrã de login.
- Não tem alertas;
(Q) Emergência
. My location button
. Chamar Emergência
. Enviar localização por SMS
- Assinala informações sobre georeferenciação e número de
emergência/reboque. O SMS a enviar para o número de
emergência/reboque contém informações sobre a localização.
- Alerta perguntando ao utilizador se pretende mesmo realizar o envio
de sms para a emergência ou seguradora. (R) Reboque
. My location button
. Chamar Reboque
. Enviar localização por SMS
Tabela 17: Descrição do levantamento de requisitos para a aplicação móvel.
___________________________________________________________________________ 43
Protótipos Funcionais
Em seguida são apresentados os principais ecrãs das actividades de notificação de sinistro cujo levantamento de requisitos foi efetuado na secção
anterior. Nas figuras 12, 13 e 14 são apresentados 12 mockups com base na descrição efetuada na tabela 17. Os mockups foram efetuados através do software
Balsamiq Mockups.
Módulo/
Actividade
B – Menu Principal C – Menu de notificação D – Participar Sinistro E - Automóvel
Mockups
Figura 12: Protótipos funcionais do módulo B a E.
___________________________________________________________________________ 44
Módulo/
Actividade
F – Declaração Amigável G – Menu Informação
Geral
H – Menu Formulário
Veículo
I – Menu Ponto de embate
inicial
Mockups
Figura 13: Protótipos funcionais do módulo F a I.
___________________________________________________________________________ 45
Módulo/
Actividad
e
J – Menu Danos Visíveis K – Menu Circunstância
do Acidente
L – Menu Selecionar
Oficina
M – Submeter Notificação
Mockups
Figura 14: Protótipos funcionais do módulo J a M.
___________________________________________________________________________ 46
3.2 Análise de Requisitos
Através da análise dos protótipos foi possível detalhar quais as funcionalidades que o sistema
irá ter e completar assim os requisitos funcionais. Foram também identificados nesta fase os requisitos
não-funcionais. Todos os requisitos estão classificados com diferentes prioridades uma vez que há uns
mais importantes para a resolução do problema e sucesso do projeto do que outros. Houve, portanto,
a necessidade de estabelecer uma escala de prioridades, segundo o método de MoSCoW [36],
apresentada na tabela seguinte:
Prioridade Descrição
Must Requisito de elevada prioridade e importância para o projeto; tem que ser
obrigatoriamente implementado.
Should Requisito de prioridade média; tem importância para o projeto, contudo a falha em
implementar esse requisito não compromete o sucesso do projeto.
Could Requisito de baixa prioridade; acrescenta valor ao projeto, mas só deverá ser
implementado se o orçamento for suficiente.
Won’t Requisito de prioridade muito baixa ou nula; é uma futura recomendação.
Tabela 18: Prioridades dos requisitos segundo o método de MoSCoW.
Devido a este projeto ter sido desenvolvido junto com uma empresa e uma faculdade, o
refinamento das prioridades foi feito maioritariamente com apoio dos orientadores que estavam a
acompanhar este trabalho, em conjunto com alguns utilizadores que me permitiram saber qual a
importância que tinha cada um dos requisitos.
3.2.1 Requisitos Funcionais
De seguida, são detalhados os principais requisitos funcionais identificados para a aplicação
móvel para notificação de sinistros.
ID Requisito Prioridade Descrição
1 Autenticar e recolher
informações dos clientes Must
O cliente ao aceder à aplicação necessita de introduzir o email e password
correspondente, de forma a confirmar a sua identidade e aceder aos seus
dados presentes na BD do cliente da seguradora
2 Recuperar password Could Sistema que permite ao utilizador obter a password caso este se tenha
esquecido.
3 Submeter notificação na
BD da seguradora Could Submeter dados do sinistro preenchido pelo utilizador na BD da seguradora.
___________________________________________________________________________ 47
4 Validar informações
submetidas Must
Os dados deverão ser validados o máximo possível pela aplicação, sendo
esperado, no entanto, que algumas informações sejam verificadas pela
própria seguradora.
5 Criar servidor Must Entre a seguradora e o cliente deverá existir um servidor que permita
autenticar e enviar dados para aplicação móvel.
6 Preenchimento
automático localização Must
Através do recurso à API do Google é esperado preencher automaticamente
o endereço/morada do local do sinistro.
7 Fotografar danos das
viaturas Must
Ao ocorrer um sinistro, será possível, através da chamada a funções do
sistema Android, executar a aplicação referente à câmara fotográfica do
aparelho.
9
Preenchimento
automático de algumas
informações do
formulário
Must Preenchimento de alguns campos do formulário é feito de forma automática,
devido a termos acesso à BD de clientes da seguradora.
10 Troca de informações
entre dispositivos Should
Possibilidade de ser feita uma troca de informações (formulário), caso as
pessoas envolvidas no sinistro tenham a mesma aplicação no seu aparelho.
11 Envio dos dados para a
seguradora Must
Os dados deverão ser enviados para a segurador num formato tipo ficheiro
ou email. Pode ser ainda utilizado o formato XML para posterior integração
com outros dispositivos
12 Conceder ao utilizador o
contacto de emergência Must
Em caso de sinistro a aplicação deverá questionar o utilizador se será
necessário uma ambulância e indicar o local do sinistro (coordenadas,
morada/endereço) e ligar automaticamente para linha de emergência.
13 Contactar Reboque Must Permitir ao utilizador ter acesso ao contacto do reboque.
14 Aceder a notificações
pendentes Should
Caso exista uma notificação incompleta, o utilizador tem a oportunidade de
aceder a esta diretamente sem ser necessário elaborar uma nova notificação.
15 Criar BD seguradora Should Criar uma BD seguradora fictícia, onde o utilizador vai buscar informações
referentes aos seus dados.
16 Possuir mais que uma
língua Could
A aplicação deverá ser bilingue, sendo possível visualizar a aplicação em
português ou inglês.
17
Aplicação com vertente
para publicidade dos
produtos da seguradora
Could
A aplicação deve mostrar uma solução muti-propósito, por uma lado deve ter
como principal objetivo realizar a notificação de sinistro, por outro lado
permitir que exista uma vertente para a seguradora expor os seus produtos
18 Criação de relatório Must Antes da notificação ser enviada à seguradora é criado um documento para o
utilizador poder rever todas as informações preenchidas.
Tabela 19: Análise dos requisitos funcionais.
___________________________________________________________________________ 48
3.2.2 Requisitos Não-Funcionais
Os requisitos não-funcionais estão relacionados ao uso da aplicação em termos de desempenho,
usabilidade, segurança, disponibilidade, manutenção e tecnologias envolvidas.
Apesar do âmbito do projeto ser o de um protótipo com foco apenas nas funcionalidades, não
sendo de momento uma preocupação da empresa o investimento em requisitos não-funcionais,
considerou-se importante a definição dos seguintes:
1) Ferramentas utilizadas para o desenvolvimento da aplicação em Android
Prioridade: Must
Tipo: Tecnológico e Implementação
Descrição: Aplicação será programada na linguagem Java, onde é utilizado:
o O IDE Eclipse para facilitar o desenvolvimento da aplicação;
o Android SDK fornece a API e ferramentas de desenvolvimento necessárias para
construir, testar e fazer debug das aplicações Android;
o O ADT é um plugin para o Eclipse IDE desenhado para permitir um ambiente de
desenvolvimento para construir aplicações Android.
2) Suportar múltiplos dispositivos
Prioridade: Must
Tipo: Tecnológico, Implementação e Portabilidade
Descrição: A aplicação deverá correr em dispositivos Android com versão igual ou superior à
versão 4.0 (que corresponde a mais de 90% do mercado atual, como visto no ponto 2.1 do
estado da arte). A solução deve estar pronta para ser utilizada tanto em smartphone, como em
tablet, ou seja, a aplicação deve suportar múltiplos tipos de ecrãs nestes tipos de aparelhos.
3) Implementação da BD da seguradora
Prioridade: Should
Tipo: Tecnológico
Descrição: A BD deve ser construída num servidor online gratuito, para qualquer utilizador da
aplicação poder aceder facilmente a esta através duma ligação à internet. A linguagem a utilizar
para trabalhar com a BD será MySQL devido à maior experiência na utilização desta linguagem
aliada à existência de inúmeros servidores online gratuitos com esta tecnologia.
4) Implementação do servidor online para transferência de dados
Prioridade: Should
Tipo: Tecnológico
Descrição: O servidor online vai funcionar como um simples Web Service entre a aplicação
móvel e a BD da seguradora concebida. O Web Service será escrito na linguagem PHP e tem
como principais responsabilidades realizar a autenticação do utilizador e enviar as informações
para o cliente.
___________________________________________________________________________ 49
5) Implementação do Modelo ER para modelar uma seguradora real
Prioridade: Could
Tipo: Tecnologia e Desempenho
Descrição: Desenvolver uma BD semelhante à de uma seguradora através do modelo ER. Esta
vai permitir um melhor desempenho do sistema e minimizar os conflitos de integração em caso
de produção do protótipo.
6) Persistência e Armazenamento das informações
Prioridade: Must
Tipo: Tecnológico e Desempenho
Descrição: Durante a utilização da aplicação é necessário ir armazenando os dados que o
utilizador vai preenchendo. Como estamos a trabalhar com poucos dados e estes são pouco
estruturados, pois variam muito de actividade para actividade, utilizou-se Sharedpreferences
para guardar as informações.
7) Interoperacional com os serviços da seguradoras
Prioridade: Should
Tipo: Tecnológico
Descrição: O sistema deve criar um ficheiro XML com os vários dados produzidos durante o
preenchimento do sinistro, ou seja, a solução deve ficar pronta para ser integrada o mais
facilmente possível com a seguradora.
8) Testes de usabilidade (KPI)
Prioridade: Must
Tipo: Desempenho
Descrição: Deverão ser efetuados testes de usabilidade de forma a compreender se a solução
é totalmente entendida pelo utilizador, sendo avaliadas as seguintes componentes: utilidade,
aprendizagem, memorização, eficiência e eficácia.
9) Preparação do sistema para implementação de mecanismos de segurança
Prioridade: Could
Tipo: Segurança
Descrição: O sistema deverá ficar preparado para que, em futuros desenvolvimentos, sejam
implementados mecanismos de segurança, nomeadamente para controlo de acesso a Web
Services, assim como para a encriptação da informação trocada através da rede.
___________________________________________________________________________ 51
4 Arquitetura da
Solução
___________________________________________________________________________ 53
4. Arquitetura da Solução
Depois de feita a análise de requisitos do sistema desenvolvido é agora indispensável definir a
estrutura que vai estar na base desse sistema e como cada módulo da arquitetura vai agir e interagir
de forma a implementar as funcionalidades requeridas que permitem resolver os problemas e objetivos
descritos na introdução.
Este capítulo tem como propósito definir claramente as funcionalidades técnicas utilizadas, os
conceitos tecnológicos, o mecanismo de autenticação, o modelo da base de dados, integração com o
servidor, envio das informações para a seguradora e o método de transmissão.
4.1 Estrutura Geral do Sistema
É agora apresentado o diagrama da arquitetura global da solução:
Figura 15: Diagrama da Arquitetura geral da solução.
A figura 15 ilustra o sistema de comunicação da arquitetura proposta para a aplicação móvel e
Servidor (Web Server e BD). Em seguida são detalhados os propósitos de cada um destes módulos e
as suas respetivas interações e tecnologias utilizadas.
4.2 Conceitos tecnológicos
Para a compreensão do desenvolvimento do protótipo é relevante definir alguns conceitos
importantes:
Actividade: representa um componente da aplicação que fornece um ecrã com o qual os utilizadores
podem interagir. Cada actividade corresponde a uma janela na qual é desenhada a interface para
___________________________________________________________________________ 54
comunicar com o utilizador. A janela normalmente preenche por completo o ecrã, mas pode haver várias
actividades sobre a mesma janela.
Intent: representa um pedido que é encaminhado ao sistema indicando uma “intenção”. Consoante
essa intenção é efetuada uma decisão, por exemplo, iniciar uma Actividade, enviar uma mensagem
para aplicações que correm noutros processos, ou fazer um broadcast.
Fragmentos: representa uma parte, ou um ecrã completo da UI. Os fragmentos permitem adaptar a
aplicação a uma variedade de dispositivos com diferentes tamanhos de ecrã, aumentar a reutilização
das actividades e permitem modificar a visão de uma actividade em tempo de execução. Os fragmentos
permitem a uma actividade funcionar como estivessem presentes várias actividades no mesmo ecrã.
Web service: solução utilizada na integração de sistemas e na comunicação entre aplicações
diferentes. Com esta tecnologia é possível que novas aplicações possam interagir com aquelas que já
existem e que sistemas desenvolvidos em plataformas diferentes sejam compatíveis. Os Web services
são componentes que permitem às aplicações enviar e receber dados em formato Extensible Mark-up
Language (XML), ou JavaScript Object Notation (JSON). Cada aplicação pode ter a sua própria
"linguagem", que é traduzida para uma linguagem universal, o formato XML/JSON.
Simple Object Access Protocol (SOAP): fornece uma forma de comunicação entre as aplicações em
execução em sistemas diferentes, com diferentes tecnologias e linguagens de programação. Este
protocolo permite comunicar entre aplicações sobre HTTP, pois este é suportado por todos os
navegadores e servidores Internet e é baseado em XML.
Representational State Transfer (REST): foi desenvolvido para permitir a comunicação entre duas
quaisquer aplicações, independentemente da sua plataforma/linguagem de desenvolvimento. O REST
usa o protocolo HTTP para troca de mensagens. Por ser implementado através do protocolo HTTP,
utiliza além dos métodos clássicos como POST e GET, métodos menos comuns como o PUT e o
DELETE.
SharedPreferences: fornece uma Framework geral que permite salvar e recuperar pares de dados
primitivos do tipo chave-valor. Os mesmos continuam armazenados, mesmo após a aplicação ter sido
encerrada.
Adapter: É um padrão que serve para adaptar duas interfaces incompatíveis. No caso do Android,
serve para adaptar uma lista de objetos para uma lista de elementos da interface gráfica, como as
linhas de uma ListView (exibe os componentes em forma de lista). O Android, através da classe
ListView, solicita um novo objeto View para cada linha da lista. A função do Adapter é criar um objeto
View que represente visualmente o objeto da posição específica da lista de objetos.
4.3 Servidor
O servidor tem a função de receber e enviar as informações pedidas pela aplicação, permitindo
a múltiplos utilizadores acederem a recursos relacionados com os seus dados através da interação do
servidor web com a base de dados. É importante referir que qualquer interação com o servidor é
validada por este.
___________________________________________________________________________ 55
4.3.1 Integração com o Servidor através de Web Service
Será em alguns casos necessário confirmar a autenticidade do utilizador para aceder a alguns
serviços da aplicação de notificação de sinistros como, por exemplo, o preenchimento automático de
partes do formulário da DAAA. Neste caso a aplicação móvel necessita de comunicar com um servidor
de forma a consultar e enviar informações sobre os clientes da seguradora.
A solução utilizada passa por integrar o sistema servidor com a aplicação móvel através de um
Web Service. Esta tecnologia permite à aplicação de notificação de sinistros interagir com o sistema
servidor. Os Web Services são componentes que permitem às aplicações enviar e receber dados em
formato XML ou JSON. Cada aplicação pode ter a sua própria linguagem que é traduzida para uma
linguagem universal no formato XML ou JSON. Esta solução traz agilidade para os processos, eficiência
no envio, consulta e atualização de informação.
4.3.2 Metodologia para Transferência de Dados
Existem duas soluções possíveis para aplicar Web Services, recorrendo ao protocolo SOAP, ou
através de REST. Em seguida resumimos quais as vantagens e desvantagens do emprego de SOAP
e de REST.
SOAP REST
Vantagens
Boa documentação
Melhor a lidar com erros
Curva de aprendizagem maior
Muito mais simples de desenvolver
Escalabilidade
Desvantagens
Difícil de desenvolver
Mais verbosa
Consome mais recursos que REST
Sobrecarga para serviços móveis
Falta de documentação
Usa o protocolo http, utilizando
maioritariamente 4 métodos (GET,
POST, DELETE e PUT).
Tabela 20: Comparação entre as soluções SOAP e REST para implementar um Web Service.
Na solução SOAP os dados poderão ser transferidos no formato XML, encapsulados pelo
protocolo SOAP, tipicamente sobre http. Atualmente o sistema Android não fornece qualquer tipo de
biblioteca SOAP oficial. Importa ainda referir que o SOAP introduz uma sobrecarga significativa para
os serviços web que pode ser problemático para dispositivos móveis. Tendo em conta estas
informações podemos concluir que a arquitetura REST apresenta a melhor solução para realizar a
integração entre aplicação móvel e o servidor.
4.3.3 Arquitetura do espaço de negócio
O servidor deve estar preparado para possibilitar à companhia de seguros mudar imagens
publicitárias e respetivas informações sem o utilizador necessitar de atualizar o sistema ou sair da
respetiva actividade Android, como se pode observar no protótipo funcional sobre o Menu Principal da
figura 12 na página 39.
___________________________________________________________________________ 56
Para resolver esta questão deverá ser utilizada a biblioteca API Fragmentos, que surgiu a partir
da versão 3.0 da API do Android. Os fragmentos são componentes reutilizáveis que auxiliam na criação
de layouts para dispositivos com diferentes dimensões de ecrã e representa uma parte da interface
gráfica da actividade que tem o seu próprio ciclo de vida (ver Anexo D), recebe os seus próprios eventos
de entrada e pode ser adicionado ou removido enquanto a actividade está em execução para modificar
a visão desta em tempo de execução.
Resolver o problema da atualização de uma actividade em tempo de execução permite à
aplicação ter uma componente de negócio disponível para a seguradora, pois a seguradora consegue
alterar os produtos exibidos na aplicação a qualquer momento através da alteração de alguns
parâmetros num simples ficheiro JSON colocado no servidor. O ficheiro tem a seguinte configuração:
{ "data": { "products": [ { "id": "id1", "name": "name1", "image_url": "url1" }, (…) { "id": "idN", "name": "nameN", "image_url": "urlN" } ] } }
A aplicação ao ser iniciada, com ligação à internet, vai obter o JSON do servidor e procurar as
imagens presentes no campo “image_url” e respetiva descrição presente no campo “name”. A partir
deste momento basta à seguradora alterar ambos os campos no JSON armazenado no servidor para
a seguradora mudar a sua “montra publicitária” na aplicação a qualquer momento.
4.3.4 Base de Dados
No âmbito inicial do projeto foi considerado o desenvolvimento de uma base de dados capaz de
conseguir modelar o mais fielmente possível a BD de uma seguradora real (requisito não-funcional
número 5, modelar uma seguradora real). O modelo ER pode ser visto no anexo E. Este objetivo foi
enunciado em conjunto com outro projeto de dissertação. Porém, devido a alguns problemas exteriores
ao projeto, esta BD nunca chegou a ser implementada e aproveitada por ambos os projetos.
No entanto, numa primeira fase e como o principal objetivo é construir um protótipo e demonstrar
que a prova de conceito da aplicação móvel para notificação de sinistro é uma alternativa à atual forma
de preenchimento de DAAA, foi criada uma BD com uma única tabela, com os dados indispensáveis
para realizar uma DAAA. Esta tabela possui os mesmos atributos que estão presentes nos campos do
anexo B mais os atributos email e a password. Estes dois últimos campos vão permitir realizar o login
e receber as informações pessoais armazenadas na BD da seguradora.
___________________________________________________________________________ 57
4.3.5 Processo de autenticação com a aplicação móvel
Ao realizar a autenticação, através do login, o utilizador recebe na aplicação móvel informações
sobre os campos que podem ser preenchidos na DAAA. Estes campos são referentes às seguintes
secções: Segurado/Tomador do Seguro; Veículo; Companhia de Seguros; Condutor.
As informações ficam armazenadas no dispositivo Android (ver ponto 4.4.2), o que implica que,
mesmo que não exista acesso à internet (utilizador está “offline”), pode usar estes dados que ficam
guardados a partir do primeiro acesso à BD da seguradora para uma futura notificação de sinistro.
Desta forma, torna-se possível preencher a declaração amigável de forma semiautomática. Se nunca
houve um acesso à internet o utilizador pode sempre preencher os dados do seu perfil e utilizá-los para
preencher a notificação no futuro.
No Menu de login o utilizador tem de inserir as suas credenciais e carregar no botão de Log in.
Uma vez o botão pressionado é lançado o componente de chamada ao Web Service, juntamente com
utilizador e senha digitados pelo utilizador. A actividade fica a aguardar resposta do Web Service. Assim
que receber a resposta decide se passa o utilizador para a próxima actividade ou, no caso de as
credenciais estarem incorretas, indica login errado.
Figura 16: Esquema de autenticação do utilizador.
Legenda da figura 16:
1 Envio de pedido HTTP para o web service, com o par email e password;
2 Web service executa consulta à BD com esta informação para testar a autenticidade do pedido;
3 Resposta da BD indicando a validade dos dados fornecidos;
4 Caso a combinação email e password seja inválida, o web service responde com mensagem
de erro de autenticação;
5 Caso a combinação email e password seja válida, o web service realiza novo acesso à BD para
consulta dos dados de cliente;
6 Web service recebe os dados do cliente, resultantes do passo 5;
7 Envio de mensagem HTTP para a aplicação contendo toda a informação referente à consulta
efetuada em 5.
___________________________________________________________________________ 58
4.4 Aplicação móvel
A aplicação móvel tem a função principal de permitir a um utilizador realizar uma notificação de
sinistro. Em seguida são apresentadas as opções feitas para a arquitetura da solução com base nos
detalhes técnicos apropriados para este projeto. Este capítulo descreve a estrutura da aplicação, como
são armazenados os dados, capturadas as imagens, a integração da aplicação com uma seguradora
real e outros tópicos.
4.4.1 Estrutura da aplicação
Uma aplicação Android contém o seguinte esquema por omissão:
src: Código fonte da aplicação;
gen: Código fonte gerado automaticamente;
assets: Ficheiros estáticos que podem ser incluídos na aplicação;
bin: Nesta pasta são guardados os ficheiros depois de compilados;
libs: Nesta pasta são guardados todos os arquivos JAR;
res: Pasta onde se encontram recursos como ícones, definição de layouts e imagens.
Os projetos Android também incluem um ficheiro AndroidManifest.xml, guardado na raiz do
projeto. Neste ficheiro fica definida a estrutura, os metadados e componentes da aplicação, e é um
elemento crucial de qualquer projeto Android que funciona como "índice" do projeto. É nele que são
declaradas as Actividades que definem cada um dos ecrãs que o utilizador poderá visualizar, os
Services, os Receivers, a versão do SDK e as respetivas permissões que a aplicação terá ao ser
instalada no dispositivo móvel.
Um Service é um componente da aplicação que permite realizar operações de longa duração
em background de forma a não afetar a interface do utilizador. Um determinado componente da
aplicação pode iniciar o serviço e o mesmo irá continuar a correr em background independentemente
do utilizador ter a aplicação a correr ou não.
O Service deve ser principalmente utilizado no cenário onde a aplicação precisa de fazer algo
importante em segundo plano e a actividade não pode morrer ou bloquear. Por outro lado, se for preciso
executar uma tarefa fora da thread principal, mas apenas enquanto o utilizador interage com a
aplicação, é melhor utilizar uma thread para correr essa tarefa em vez do Service. Esta pode ser criada
a partir de uma AyncTask ou HandlerThread.
A exibição de elementos em forma de lista é um padrão que se pretende implementar na
aplicação. Este é bastante comum em aplicações móveis. O utilizador vê uma lista de itens e pode
percorrê-los de uma forma organizada. De um ponto de vista técnico, para implementar esta
funcionalidade utiliza-se a classe ListView e um Custom Adapter. Este último permite suportar várias
views, ou seja, o adaptador permite controlar mais facilmente como a informação está organizada em
cada item da lista.
___________________________________________________________________________ 59
4.4.2 Guardar informações na aplicação móvel
Para guardar as informações surgem à partida duas possibilidades: SQLite e
SharedPreferences.
SQLite: Armazena grandes quantidades de dados estruturados. Como os dados são
estruturados e geridos pela base de dados, é possível obter resultados a partir de uma
determinada pesquisa, usando a linguagem de consulta SQL. Esta pesquisa de informação
influencia o desempenho, logo a leitura da base de dados é mais lenta que em comparação
com o SharedPreferences.
SharedPreferences: permite guardar informações a partir do uso de pares de dados primitivos
do tipo chave-valor. Para ler os dados é preciso saber a chave. Isso faz com que a leitura de
dados seja muito simples. É adequado utilizar este modelo para um número não muito grande
de valores. Porém, a sua maior vantagem é um melhor desempenho em comparação ao
SQLite.
Os dados da aplicação móvel vão ser armazenados através do SharedPreferences, porque a
aplicação só vai precisar de armazenar alguns valores e ser rápida a responder.
4.4.3 Aquisição de Mapas e Pontos de Interesse
O sistema Android permite incluir mapas, através da integração com o Google Maps. Esta
aplicação permite mostrar a localização do utilizador no mapa, ou definir rotas. Deste modo, é possível
conceder ao utilizador da aplicação de notificação de sinistros a sua georreferenciação, ou uma rota
até um ponto de interesse à sua escolha de uma lista de contactos úteis. Os pontos de interesse
escolhidos para procurar no mapa por intermédio da aplicação são: mecânico, posto de combustível,
polícia, hospital, agência de seguros, restaurantes e aeroportos.
No entanto, para obter as coordenadas geográficas ou a morada mais próxima dessas
coordenadas não é suficiente recorrer à aplicação Google Maps. É preciso utilizar a biblioteca Google
Maps Android API v2, ou a classe LocationManager e a classe Geocoder. As duas primeiras permitem
obter a localização a partir de dois “fornecedores”, o Network Provider e GPS Provider ou de uma
combinação das duas. A última classe permite converter uma localização geográfica para uma morada,
processo denominado por reverse geocoding.
Para integrar o mapa numa aplicação, a biblioteca Google Maps Android v2 fornece a classe
GoogleMap e MapFragment. A primeira é a principal classe da API e o ponto de entrada para todos os
métodos relacionados com o mapa. A outra é a maneira mais simples de colocar um mapa numa
aplicação, pois este componente pode ser adicionado a uma actividade criando simplesmente o layout
no ficheiro XML correspondente a essa actividade.
___________________________________________________________________________ 60
4.4.4 Capturar e anexar imagens
Faz parte dos objetivos deste trabalho dispor da funcionalidade para anexar as fotografias
tiradas pelo utilizador aos danos causados no sinistro (ponto 11 da DAAA). O Android inclui suporte
para câmaras, permitindo a captura de fotos. Para chamar a aplicação de fotografias, actividade exterior
à aplicação de notificação de sinistros, recorre-se à classe Intent que permite aceder às funcionalidades
de outras aplicações fora da actividade em que o utilizador se encontre.
Em relação ao armazenamento das imagens, estas devem ser de fácil acesso. Por esta razão é
criada uma pasta no dispositivo para agregar todas as informações referentes à notificação do sinistro.
As imagens devem ser arquivadas nessa pasta, conseguindo assim a aplicação aceder facilmente a
estas. As fotografias são possíveis de eliminar ou substituir diretamente na própria aplicação.
4.4.5 Aplicação bilingue
A arquitetura da solução está preparada para português e inglês, consoante as definições do
sistema. Para adicionar o suporte para estes dois idiomas, na pasta res é criada a pasta values-pt e
dentro do ficheiro strings.xml, onde são inseridos os elementos da língua portuguesa. A pasta values,
já criada por omissão, contém os elementos em inglês. O esquema da distribuição das pastas (res,
values e values-pt) e ficheiros (strings.xml) é apresentado em seguida :
MyProject/
res/
values/
strings.xml
values-pt/
strings.xml
4.4.6 XML padrão para comunicação com as seguradoras
A aplicação móvel está preparada para a interoperabilidade com o sistema informático de
qualquer seguradora. Este detalhe é alcançado devido à produção de um ficheiro XML que contém
todas as informações preenchidas durante a notificação de sinistro. Importa referir que os dados
contidos no ficheiro XML são os mesmos disponíveis na DAAA em papel.
Este ficheiro é criado ao mesmo tempo que o utilizador revê o documento PDF e é anexado ao
email da notificação de sinistro que será enviado para a seguradora. O ficheiro contém para além dos
campos descritivos (texto), também as imagens do ponto de embate inicial, dos danos dos veículos e
do esquema do acidente codificadas em base64. No evento da seguradora pretender observar estas
imagens, basta descodificá-las.
Como neste momento não se encontra definido um esquema XML padrão para a transmissão
de informações entre a aplicação móvel e as seguradoras, foi elaborado um possível esquema para
esta operação de comunicação. No anexo F é apresentado o esquema XML utilizado.
___________________________________________________________________________ 61
O recurso a um esquema XML permite uma integração simples e fácil de executar com qualquer
sistema informático de uma seguradora. Adicionalmente, como os campos presentes na aplicação para
notificação de sinistro são os mesmos da atual DAAA, a integração é direta, sem ser necessário à
seguradora colocar muitos “filtros” entre os dados que chegam ao seu sistema informático e aqueles
que são armazenados.
4.4.7 Troca de formulários entre sinistrados
Na eventualidade de ambos os sinistrados possuírem no seu dispositivo móvel a aplicação para
notificação de sinistro, estes podem trocar os dados dos formulários dos veículos (ponto 6 a 9 da DAAA)
com recurso à tecnologia Bluetooth. Deste modo, estão disponíveis nas actividades de formulário as
opções de envio e leitura dos ficheiros com as diversas informações preenchidas no formulário.
Com este modelo é mantida a privacidade dos sinistrados durante o preenchimento da DAAA,
sem nunca ser necessário o utilizador ter de entregar ao outro condutor envolvido no acidente o seu
dispositivo móvel. Em seguida é apresentado um esquema que pretende exemplificar este paradigma:
Figura 17: Esquema de troca de ficheiros entre os utilizadores por Bluetooth.
Esta ideia permite que não seja preciso preencher manualmente os dados dos outros sinistrados,
o que iria atrasar o processo de notificação do sinistro. Ao ultrapassar este grave problema, elimina-se
o maior ponto de estrangulamento presente na solução, porque é a actividade com maior número de
informações para completar obrigatoriamente.
___________________________________________________________________________ 62
4.4.8 Modelo de Assinaturas
O ponto 15 da DAAA refere-se às assinaturas dos condutores (ver anexo B). Através destas
ambos condutores concordam com todos os pontos assinalados na DAAA. Cada um dos condutores
fica com uma cópia igual da DAAA. Assim, caso um dos condutores tente alterar alguma informação o
outro poderá repudiá-lo. Na aplicação móvel não existe nenhum mecanismo para reproduzir o ponto
15 da DAAA, mas é proposto um modelo para permitir imitar o mecanismo de assinaturas.
Qual o problema de não haver assinaturas? Não tendo sido implementado um mecanismo de
assinaturas no dispositivo móvel, o problema surge quando ocorre a possibilidade de um dos
condutores alterar as suas informações após ambos terem revisto as declarações. A DAAA pode ser
alterada antes de chegar à seguradora sem consentimento de um dos condutores, ou seja, a
integridade da mensagem é posta em causa e a veracidade das informações também.
Na figura 18 é apresentado um esquema que exemplifica a situação problema, onde o Condutor
2 altera alguns dados da DAAA sem o Condutor 1 saber. A DAAA que chega à Seguradora do Condutor
2 (Seguradora 2) é diferente da DAAA que chega à Seguradora 1 (seguradora do Condutor 1). Esta
situação é péssima para as seguradoras, pois as declarações amigáveis são diferentes e o Condutor
2 prejudicou o Condutor 1.
Figura 18: Esquema que exemplifica a adulteração da DAAA por parte do Condutor 2.
As entidades presentes neste modelo são os Condutores 1 (C1) e 2 (C2), as respetivas
seguradoras 1 (S1) e 2 (S2) e um repositório (onde as seguradoras podem ir buscar as chaves privadas
dos seus clientes). O modelo proposto funciona no cenário de ambos condutores possuírem um
dispositivo móvel com a aplicação para Notificação de Sinistros.
Na figura 19 é apresentado um modelo que garante a integridade das DAAA ao chegarem às
seguradoras.
___________________________________________________________________________ 63
1. Os condutores C1 e C2 trocam entre si o documento da declaração amigável, mais o Hash das
DAAA cifrado com a chave pública do condutor que envia. A função de Hash garante que, se a
informação for igual o valor dado por esta função é igual, mas se de alguma forma houver qualquer
alteração, um valor completamente diferente é produzido pela função de Hash.
2. A aplicação móvel compara automaticamente a DAAA de C1 com C2 e indica se estas são iguais,
caso não sejam os campos devem ser modificados até ambas as DAAA serem iguais.
3. A mensagem enviada para as seguradoras contém a DAAA mais o Hash da DAAA do outro
condutor cifrado com a chave pública desse condutor. Por exemplo, C1 envia para S1 a sua DAAA,
mais o Hash da DAAA de C2 cifrada com a chave pública de C2. C1 não consegue modificar o
conteúdo desta parte da mensagem pois não tem acesso à chave privada de C2.
4. A seguradora vai buscar a chave privada de C2 ao repositório, decifra o conteúdo da segunda
parte da mensagem e compara o Hash de C2 com o Hash de C1. Se os valores forem iguais
significa que C1 não alterou a DAAA e uma mensagem é enviada a C1 a indicar que a DAAA foi
submetida com sucesso. No caso de os valores serem diferentes uma mensagem é enviada ao
Condutor 1 a dizer que houve alguma modificação e a DAAA não foi submetida.
Figura 19: Modelo que garante a integridade da DAAA para ambos os condutores na chegada às seguradoras.
Este modelo tem duas vantagens: os condutores trocam as DAAA, que permite verificar se
existem diferenças nos documentos, e a outra vantagem é garantir que as declarações submetidas às
seguradoras são iguais
1
2
3
4
___________________________________________________________________________ 64
4.5 Envio da notificação para a seguradora
Após serem preenchidos os vários dados do sinistro é necessário enviá-los para a seguradora.
A companhia de seguros ao receber o email de um cliente, envia por sua vez outro email a confirmar
que a notificação foi entregue com sucesso.
Figura 20: Processo de envio da notificação para a seguradora.
4.5.1 Elementos anexados ao email
A entrega do correio eletrónico é efetuada com os seguintes elementos anexados:
Documentos PDF e XML com a descrição dos diversos elementos preenchidos
durante a notificação de sinistro;
Imagens referentes ao ponto de embate inicial (ponto 10 da DAAA);
Imagens relativas aos danos visíveis (ponto 11 da DAAA);
Imagem do esquema do acidente no momento do embate (ponto 13 da DAAA);
Gravação áudio de observações dos sinistrados (ponto 14 da DAAA);
É ainda possível o utilizador adicionar alguma informação suplementar no corpo do correio
eletrónico.
4.5.2 Chamar uma aplicação cliente email
Para conseguir transferir a mensagem por correio eletrónico é utilizada uma aplicação cliente
email do próprio dispositivo móvel. Os dispositivos Android por omissão vêm incluídos com aplicações,
cuja principal funcionalidade é o envio de correio eletrónico. O utilizador dispõe da possibilidade de
escolher outra aplicação na situação de dispor de mais que um serviço de cliente de correio eletrónico.
A fim de chamar outra actividade fora da aplicação Android é utilizado um objeto criado a partir
da classe Intent. Este permite aceder às funcionalidades de outras aplicações exteriores à aplicação
de notificação de sinistros. Neste caso o intent permite chamar as aplicações que permitam o envio de
correio eletrónico.
___________________________________________________________________________ 65
4.6 Conclusões
Várias decisões a nível de arquitetura foram tomadas com base no estudo de vário fatores
técnicos analisados durante este capítulo, dos quais podemos destacar:
A utilização do protocolo REST para comunicar entre a aplicação móvel e o servidor;
Os dados são armazenados no dispositivo Android com recurso à classe
SharedPreferences, por uma questão de desempenho e para a aplicação ser rápida
durante uma situação de sinistro;
A aplicação permite trocar informações do formulário de veículo entre utilizadores com
recurso à tecnologia Bluetooth;
O envio da notificação para a seguradora é feito por email;
A definição de um esquema XML no sentido de possibilitar a integração da aplicação
com qualquer seguradora;
___________________________________________________________________________ 69
5. Implementação
Ao longo deste capítulo pretende-se descrever todo o processo de implementação dos requisitos
previamente estipulados. Será descrito em detalhe todo o processo de implementação da solução e é
introduzida a metodologia e planeamento adotados. Por fim, são analisados os protótipos finais. No
capítulo 3 (requisitos) já foram apresentados os protótipos funcionais.
5.1 Metodologia utilizada
Face ao contexto de realização do presente projeto considera-se como modelo de trabalho uma
metodologia tradicional com desenvolvimento iterativo. Este tipo de metodologia caracteriza-se por um
conjunto de etapas bem definido em que, de cada qual, resulta um output, que pode ser um documento,
um protótipo de software ou o produto final. Cada um desses resultados deve ser revisto e, consoante
as falhas detetadas, dever ser sujeito a melhorias. Esta metodologia permite avaliar mais cedo os riscos
e pontos críticos do projeto, e identificar medidas para os eliminar ou controlar.
Figura 21: Fases do processo de implementação.
No final das duas primeiras fases deve ter sido construído um documento que agregue a
definição clara de quais os requisitos (funcionais e não funcionais) que devem ser implementados, bem
como a prioridade de cada um deles. Para além disso, deve ser apresentado um protótipo que simule
o funcionamento do produto e que permita a compreensão clara daquilo que ele possibilita fazer.
O documento resultante deve gerar um debate de ideias entre aquilo que são as expectativas
quanto ao sistema (o que é concretizável) e definir claramente o que será realizado. Consoante os
resultados elabora-se uma proposta, definindo estratégias de implementação, estipulando quais os
processos e em que componentes devem ser criados.
A partir do momento que seja claros os requisitos e a forma de implementação pode-se
prosseguir para a fase de implementação que decorrerá de forma iterativa em função dos requisitos
definidos. Em função das decisões tomadas e dos possíveis problemas encontrados, pode haver
reformulação dos requisitos.
À medida que vão sendo implementadas as diversas funcionalidades, decorre logo em seguida,
com base na ajuda de alguns utilizadores, uma validação destas funcionalidades em que se detetarão
possíveis erros e falhas do sistema. Em função deles, devem ocorrer processos de implementação
para proceder à sua correção. No final, como output de todo o processo deve resultar o protótipo, apto
para utilização.
___________________________________________________________________________ 70
5.2 Planeamento
O planeamento do presente projeto, ilustrado na figura 19, evidencia a utilização desta
metodologia.
Figura 22: Diagrama de Gantt do planeamento.
Este diagrama está dividido por actividades, das quais importa explicitar o Desenho Funcional,
onde ocorreu o desenho da aplicação em termos das suas funcionalidades, tendo sido definidos os
requisitos funcionais e a prototipagem dos cenários. Já o Desenho Técnico, envolveu o desenho do
sistema de um ponto de vista mais baixo-nível, tendo já em conta como implementar as funcionalidades
identificadas no Desenho Funcional. Foi então definida a arquitetura do sistema, a especificação das
interfaces a utilizar para comunicação tanto com sistemas internos como externos à solução. As etapas
mencionadas atrás fazem parte da fase Requerimento e Projeto.
Em seguida, ocorreu a fase de Implementação, onde foram implementas as funcionalidades
definidas nos objetivos do trabalho (indicadas no Desenho Funcional). Por fim, foram feitos testes para
identificar eventuais problemas.
___________________________________________________________________________ 71
5.3 Servidor
O servidor para aplicação móvel para notificação de sinistros foi implementado num servidor
online de hospedagem gratuito. Esta decisão foi tomada para permitir a aplicação ser facilmente testada
em qualquer localização. Das várias ferramentas disponíveis para montar o servidor foram utilizadas o
File Manager (navegador que fornece uma interface gráfica para gerir pastas e ficheiros do servidor) e
o Database Manager que é explicado no capítulo 5.4.
Figura 23: Aspeto do servidor online e ferramentas disponíveis.
No File Manager foi implementado um Web Service REST na linguagem PHP. O Web Service é
responsável por receber as credenciais da aplicação móvel e devolver as informações disponíveis na
BD para os utilizadores (caso as credenciais estejam corretas). No evento das credenciais estarem
incorretas, é enviada a informação de que estas se encontram erradas.
O File Manager contém um ficheiro JSON com as informações que vão povoar a área de negócio
no menu principal. Este ficheiro é responsável por prestar as informações sobre a “montra” publicitária
presente no menu principal da aplicação móvel.
5.4 Base de Dados
No Database Manager foi criada uma BD MySQL. Esta é gerida pelo phpMyAdmin que é uma
aplicação web para administração do MySQL pela Internet. A partir deste sistema é possível criar e
remover base de dados, criar, remover e alterar tabelas, inserir, remover e editar campos, executar
queries, etc..
Através deste sistema foram inseridas algumas informações fictícias na BD para poder testar a
aplicação móvel. Como o principal objetivo é construir um protótipo e demonstrar que a prova de
conceito é uma alternativa à atual forma de preenchimento de DAAA, foi feita uma BD muito simples
com uma única tabela e todos os dados necessários para permitir obter uma DAAA completa.
___________________________________________________________________________ 72
Figura 24: Base de Dados implementada no servidor.
5.5 Protótipos Finais
Nesta secção é apresentada a implementação da aplicação para notificação de sinistros e alguns
ecrãs dos protótipos finais que foram desenvolvidos. Estes resultaram das avaliações que os protótipos
funcionais sofreram com base em testes efetuados com utilizadores à medida que a solução ia sendo
desenvolvida.
Figura 25: Menu Principal (B) e de notificação de sinistro (C).
Na figura 25 está representado o menu que permite ao utilizador aceder às principais
funcionalidades da aplicação: comunicar um sinistro, consultar o perfil do utilizador, procurar pontos de
interesse (ver anexo G) e chamar o reboque ou emergência. As duas últimas funcionalidades também
estão presentes no menu de notificação de sinistro (figura 25 direita). No topo do menu principal é
visível a secção correspondente à área de negócio. Nesta área vão ser apresentadas 5 imagens,
correspondente a 5 publicidades diferentes, que vão trocando consoante um tempo predefinido, ou
deslizando o dedo sobre a imagem.
___________________________________________________________________________ 73
No menu de notificação de sinistro (figura 25 direita) o botão de Emergência é ligeiramente maior
que o botão de Reboque, para o utilizador poder facilmente visualizar o botão. Neste menu também é
possível ir diretamente para as notificações que se encontram pendentes, sem necessitar passar pelos
menus de seleção de sinistro (figura 25 direita).
Figura 26: Ecrã de Emergência (Q) e menu tipo de sinistro (D).
A figura 26 (esquerda) representa o menu de Emergência. Nesta actividade estão presentes
as principais informações que podem influenciar o tempo de chegada da emergência. É possível
observar no mapa a localização atual do utilizador, onde são apresentadas as coordenadas geográficas
(latitude e longitude) e a morada mais próxima do local onde o utilizador se encontra. A morada e as
coordenadas poderão ser depois enviadas para o número de emergência via SMS, mas também existe
a possibilidade de o utilizador ligar diretamente.
A actividade “Chamar Reboque” presente na figura 26 é em tudo semelhante à actividade de
emergência. Porém, o botão de chamada e o envio de SMS são dirigidos para número de assistência
em viagem da companhia de seguros.
A figura 26 (direita) representa o menu “tipo de sinistro”. Após o utilizador carregar no botão
“Selecionar Sinistro” (figura 26 direita) é apresentado um menu simples, onde os ícones foram
escolhidos para uma maior apelabilidade visual. O tamanho dos ícones e da letra utilizada para indicar
o tipo de sinistro é relativamente grande. Este efeito tem o propósito de, numa situação de sinistro,
onde o sinistrado/utilizador poderá estar afetado psicologicamente, permitir uma perceção rápida das
informações por parte do utilizador.
Na figura 27 (esquerda) podemos visualizar uma actividade semelhante à mencionada
anteriormente. Esta actividade é responsável por escolher qual o tipo de sinistro que o utilizador
pretender comunicar, dentro dos sinistros relacionados com o automóvel.
___________________________________________________________________________ 74
Figura 27: Menu de sinistro automóvel (E) e menu da DAAA (F).
Na figura 27 (direita) encontra-se o menu com os vários elementos necessários para o
preenchimento da DAAA:
Informação Geral (campos 1 a 5 da DAAA);
Veículo A/B formulário (campos 6 a 9 da DAAA);
Ponto de embate inicial veículo A/B (campo 10 da DAAA);
Danos visíveis (campo 11 da DAAA);
Circunstâncias do acidente (campos 12 a 14 da DAAA);
Repare-se que os vários elementos listados na figura 27 (direita) seguem a mesma ordem da
DAAA em papel e também existe uma preocupação relativamente às cores. Enquanto as actividades
referentes ao utilizador do veículo A estão a Azul, as actividades da responsabilidade do veículo B
encontram-se a Amarelo, como na DAAA em papel. À medida que os utilizadores completem os vários
elementos da DAAA, o símbolo do lado direito do ecrã apresenta o símbolo check verde, que informa
o utilizador que o elemento está completo. O mesmo se passa com o elemento “Submeter Notificação”.
Só é possível aceder a este quando as informações obrigatórias estão preenchidas.
Todos estes pormenores proporcionam algumas vantagens como, por exemplo, caso o utilizador
já tenha visto ou preenchido uma DAAA, sentir-se-á familiarizado com o preenchimento desta numa
aplicação móvel; porque a declaração amigável na aplicação segue os mesmos pontos (1 a 14) e cores
da declaração em papel. Estas semelhanças com a DAAA em papel não só permitem a um utilizador
ficar mais confortável e confiante com o preenchimento da DAAA numa aplicação, como permite uma
integração mais fácil com os sistemas informático responsável pela DAAA nas companhias de seguros,
devido a estes sistemas terem exatamente os mesmos campos que são preenchidos nesta aplicação.
___________________________________________________________________________ 75
Figura 28: Menu Informação Geral (G) e menu formulário do veículo (H).
Na figura 28 (esquerda) podemos observar parte do menu para indicar a informação geral. Ao
pressionar a data ou a hora (ponto 1), são apresentados ao utilizador os diálogos disponíveis no sistema
Android criados propositadamente para as tarefas de seleção da data e da hora respetivamente. Usar
estes diálogos ajuda a garantir que os utilizadores possam escolher uma hora ou data válida,
corretamente formatada e ajustada para a sua localização. A figura 29 apresenta estes diálogos.
Figura 29: Diálogos para selecionar hora e data.
Ainda relativamente ao menu de informação geral, na morada (ponto 2) existe um botão para
encontrar a morada automaticamente. Para as questões mutuamente exclusivas (ponto 3 e 4) foram
utilizados botões de rádio para selecionar os elementos pretendidos. Em relação às testemunhas
(ponto 5) foi criada uma tabela para colocar os nomes, número de telefone e moradas.
___________________________________________________________________________ 76
A figura 28 (direita) apresenta parte do menu do formulário de veículo. Esta actividade tem um
desenho parecido ao ecrã do menu de informações gerais. Este menu é constituído pelo formulário de
veículo da DAAA (campos 6 a 9) e por 5 botões, que tencionam simplificar o processo de notificação:
Obter dados da seguradora: Permite obter as informações da seguradora caso o
utilizador esteja ligado à internet. Se o login ainda não foi efetuado irá aparecer o menu
de login (ver anexo H), onde o utilizador terá de inserir o seu email e password para
carregar as informações presentes na BD da seguradora. Se o utilizador não conseguir
aceder à internet, tem 2 opções, ou preenche os dados manualmente, ou completa os
dados a partir das informações guardadas no perfil.
Carregar informação do veículo: Quando outro utilizador enviar um ficheiro via
Bluetooth, este botão vai permitir obter as informações referentes aos campos 6 a 9
desse outro utilizador;
Selecione Condutor: Como uma viatura pode ter um ou dois condutores principais,
esta opção permite selecionar qual destes estava a conduzir a viatura no momento do
sinistro;
Guardar: Regista as informações preenchidas neste menu;
Enviar informação do veículo: Envia via Bluetooth um ficheiro XML para outro
utilizador com as informações do formulário de veículo preenchidas.
Figura 30: Menu para indicar o ponto de embate inicial (I) e ecrã para indicar os danos visíveis (J).
No menu da DAAA (figura 27 direita) ao selecionar o menu “Ponto de embate inicial do veículo
A/B”, o utilizador é questionado sobre qual o veículo que estava a conduzir, se um automóvel, motociclo
ou veículo de mercadorias. Depois de selecionar o respetivo veículo vai para a actividade da figura 30
(esquerda), onde irá indicar o ponto de embate inicial. Após clicar no ecrã aparece uma seta. A seta é
móvel para permitir ao utilizador indicar com maior precisão o ponto de embate inicial.
___________________________________________________________________________ 77
A figura 30 (direita) representa o menu “Danos Visíveis”, a que o utilizador pode associar 4
fotografias: uma foto aos danos do veículo A; outra foto aos danos do veículo B; e duas fotos ao local
do acidente. Para tirar uma foto basta o utilizador clicar nos botões presentes na aplicação. A foto
guardada vai aparecer onde antes se encontrava o botão. Se o utilizador pretender apagá-la, tem de
pressionar longamente a fotografia, aparecendo o alerta a perguntar se o utilizador deseja apagar a
fotografia.
Figura 31: Menu circunstâncias do acidente (K) e lista para selecionar oficina (L).
A figura 31 (esquerda) representa o menu de circunstâncias do acidente. Aqui estão presentes
as circunstâncias da DAAA em papel (ver anexo C). A lista de circunstâncias vem já preparada com um
placeholder para colocar as imagens das respetivas circunstâncias. O botão no canto inferior esquerdo
envia o utilizador para uma actividade que permite desenhar o esquema do acidente no momento de
embate (ver anexo I). O botão no canto inferior direito permite ao utilizador indicar informações que
sejam consideradas adequadas por gravação áudio. Após a gravação é possível o utilizador ouvir a
registo feito pressionando o mesmo botão.
Na figura 31 (direita) é possível visualizar o menu Selecionar Oficina. Esta é uma funcionalidade
extra colocada no menu da DAAA, com a intenção de indicar, caso selecionada, qual a oficina para
enviar a viatura, ou a que o sinistrado pretende dirigir-se para efetuar uma peritagem ao veículo. O
utilizador tem à disposição 3 opções:
Procurar oficinas recomendadas: Esta opção permite ao utilizador consultar as
oficinas recomendadas a partir da visualização das oficinas no mapa (ver anexo J);
Oficina indicada no perfil: É indicada a oficina guardade nos dados de perfil;
Indicar oficina manualmente: Caso o utilizador selecione esta opção, o campo
“Escrever morada aqui” fica desbloqueado e utilizador pode escrever a morada da oficina
pretendida.
___________________________________________________________________________ 78
Figura 32: Menu para submeter a notificação (M) e ecrãs para rever e enviar notificação.
Por fim, na figura 32 (esquerda) é apresentado o menu para submissão do sinistro para a
seguradora. Neste menu o utilizador pode enviar a notificação para a companhia de seguros, mas só
após o utilizador rever o documento. Caso o utilizador pretenda enviar a notificação sem antes rever o
documento surge um alerta a avisar que deve obrigatoriamente rever o documento em primeiro lugar.
Na figura 32 (centro) é possível visualizar a primeira página do documento criado a partir dos
dados preenchidos. Este documento tem cerca de 15 páginas e pretende centralizar num único local
todas as informações da DAAA.
Na figura 32 (direita) encontra-se presente o email que vai ser enviado para a seguradora. Neste
email constam os seguintes ficheiros em anexo: as fotografias sobre os danos visíveis, as imagens do
ponto de embate inicial de ambos os veículos, o esquema do acidente no momento do embate, a
gravação áudio efetuada, um ficheiro pdf e outro xml com todas as informações do acidente.
5.6 Conclusões
Terminada a fase de implementação da solução proposta várias conclusões podem ser retiradas
deste processo apresentado.
Em primeiro lugar o cumprimento de todos os requisitos funcionais explicitados no capítulo 3 de
nível must e o cumprimento de alguns requisitos da categoria Should, ou seja, os requisitos de maior
importância e prioridade foram executados. Em segundo lugar o sucesso na construção do servidor, da
base de dados e da aplicação móvel, conseguindo integrar todos estes módulos e conceber um
sistema, a partir do qual se consegue convenientemente avaliar a prova de conceito. Por fim, os
protótipos finais encontram-se coerentes com os protótipos funcionais.
No capítulo seguinte é efetuada uma bateria de testes referentes à usabilidade da aplicação com
utilizadores.
___________________________________________________________________________ 79
6 Avaliação da
Solução
___________________________________________________________________________ 81
6. Avaliação da Solução
Neste capítulo apresentamos a avaliação final a que a solução foi submetida e descrevemos
detalhadamente como foram efetuados os testes com utilizadores. Por fim, analisamos os resultados
destes testes.
6.1 Testes com Utilizadores
De modo a obter sucesso nos testes é fundamental escolher adequadamente o número e
características dos utilizadores, o material necessário e o procedimento a efetuar. No entanto, deve
notar-se que, devido a se tratar de uma prova de conceito que funciona sobre uma aplicação móvel, foi
escolhida uma amostra maioritariamente jovem para testá-la e que apresenta alguma experiência no
uso das aplicações móveis. A seção a seguir descreve o protocolo para os testes de usabilidade,
incluindo detalhes sobre os participantes, os papéis de cada participante sobre os testes de usabilidade,
o procedimento e métricas de desempenho.
6.1.1 Perfil dos Utilizadores
Os testes ao protótipo foram realizados por 10 indivíduos de ambos os sexos com idades
compreendidas entre os 21 e 25 anos. Somente 2 em 10 utilizadores tinham preenchido pelo menos
uma vez a DAAA. Na tabela 21 encontra-se as características principais dos participantes neste teste.
Utilizador Sexo Idade Profissão Experiência com
aplicações móveis
Alguma vez
preencheu a
DAAA?
A1 Masculino 23 Estudante Alta Não
A2 Masculino 23 Estudante Alta Sim
B1 Masculino 23 Engenheiro
Informático Alta Não
B2 Masculino 23 Engenheiro
Informático Alta Não
C1 Masculino 23 Professor Média Não
C2 Masculino 21 Prestador de
Serviço Back Office Baixa Não
D1 Masculino 22 Engenheiro de
Redes Média Não
D2 Masculino 23 Engenheiro
Eletrotécnico Alta Sim
E1 Feminino 24 Engenheiro de
Redes Alta Não
E2 Feminino 25 Desempregado Média Não
Tabela 21: Características principais dos utilizadores de teste
___________________________________________________________________________ 82
6.1.2 Procedimento
De seguida, descrevemos a metodologia utilizada durante a realização dos testes. Estes foram
realizados na casa de um dos participantes e o procedimento utilizado é explicado com base nos
tópicos que passamos a descrever em seguida:
1) Distribuição da apk da aplicação Notificação de sinistros pelos utilizadores:
Antes de se iniciar os testes de usabilidade a aplicação foi enviada para cada um dos utilizadores,
para que estes pudessem instalá-la no seu dispositivo Android. Todos os utilizadores tinham um
aparelho cuja versão era superior à versão 4.0. Os próprios utilizadores instalaram a aplicação de
notificação de sinistros nos seus dispositivos. De modo a instalar a aplicação é essencial aceder à
secção “Segurança” no menu de “Definições” do aparelho e selecionar a opção “Fontes desconhecidas”
que autoriza a instalação da apk enviada.
2) Explicação do caso de teste
Em seguida explicou-se aos utilizadores como o teste iria ser realizado. Primeiro foi exposta a
situação exemplo de acidente entre duas viaturas ligeiras (A e B). O acidente ocorreu quando a viatura
B estava parada no sinal vermelho e o veículo A embateu na traseira do veículo B. Não houve feridos
nem testemunhas. Ambos os condutores possuíam a aplicação móvel para notificação de sinistros e
comunicaram o sinistro às seguradoras no próprio local do acidente. Importa referir que ambos tinham
um dispositivo móvel com acesso à internet, com máquina fotográfica e acesso à localização.
O caso de teste foi desenhado numa folha A4 para ser exemplificado aos participantes. A imagem
do caso de teste pode ser visualizada na figura 33.
Figura 33: Esquema do acidente utilizado no caso de teste para avaliação da usabilidade.
Tal como numa situação real os testes foram realizados com 2 participantes (condutores) ao
mesmo tempo. Um dos participantes fazia de condutor do veículo A, enquanto o outro participante fazia
de condutor do veículo B. Na tabela 21 os utilizadores identificados com a mesma letra correspondem
ao par que efetuou o teste em conjunto. Por exemplo, o utilizador A1 realizou o teste com utilizador A2,
o utilizador B1 realizou o teste com utilizador B2 e por assim em diante.
Os utilizadores receberam um email e password para conseguirem aceder aos seus dados na
BD seguradora.
___________________________________________________________________________ 83
3) Materiais para realizar o teste
Durante o teste os participantes tinham os seguintes materiais: uma DAAA em papel; o bilhete
de identidade ou cartão do cidadão, a carta verde dos seus veículos e a carta de condução. O registo
dos erros e hesitações foi efetuado à medida que os testes iam decorrendo pelo autor deste documento
com auxílio de um computador. Não existiu qualquer intervenção com os participantes durante os
testes.
4) Obtenção dos tempos de preenchimento da DAAA em papel e na aplicação;
Os testes de usabilidade consistiram primeiro no preenchimento da DAAA em papel e só depois
na aplicação Notificação de Sinistros. No formato em papel o tempo foi cronometrado a partir do
momento em que um dos participantes iniciava o preenchimento da DAAA. Na aplicação móvel o tempo
foi cronometrado a partir do momento em que um dos utilizadores invocava a aplicação móvel no seu
dispositivo.
No formato em papel o tempo a ser cronometrado parava quando os 2 utilizadores tivessem
completado os vários dados da DAAA. Na aplicação móvel o tempo cronometrado parava de contar
quando a aplicação fosse enviada por email para a seguradora pelos 2 utilizadores.
5) Questionário ao utilizador sobre os testes efetuados.
No final foi efetuado um questionário aos participantes. Foi pedido para darem a sua opinião
sobre algumas características da aplicação Este questionário é apresentado em 6.2.
6.1.2 Tempo de preenchimento da DAAA
Em seguida são apresentados os tempos obtidos nos testes com utilizadores no preenchimento
da DAAA em papel e na aplicação móvel.
Figura 34: Comparação do tempo de preenchimento da DAAA em papel com a aplicação móvel.
___________________________________________________________________________ 84
6.1.3 Número de erros durante o preenchimento
De seguida são apresentados o número de erros e hesitações ocorridas durante o
preenchimento na DAAA em papel e na aplicação móvel. Ao contrário da medição do tempo, os erros
foram contabilizados individualmente por utilizador. Para mais detalhes sobre os erros ver anexo K.
Figura 35: Comparação do número de erros na DAAA em papel com a aplicação móvel.
6.1.4 Análise dos resultados
O tempo médio de preenchimento da DAAA em papel é de 25,4 minutos e o tempo médio de
preenchimento na aplicação móvel é de 12 minutos. O desempenho na aplicação móvel é 2,1 vezes
mais rápido do que em comparação com o respetivo preenchimento da DAAA em papel para estes
utilizadores. Deste modo, é possível concluir que os resultados do preenchimento da DAAA em papel
são mais lentos que o respetivo preenchimento da DAAA na aplicação (como é possível observar na
figura 34).
Como se pode observar do número de erros ocorridos durante o preenchimento da DAAA é
possível concluir que em geral a maior parte dos participantes erraram mais no formato em papel do
que em comparação com a aplicação móvel. Devido ao tempo entre testes, à DAAA não ser exatamente
igual na aplicação móvel e no papel, nenhum dos utilizadores ter utilizado a aplicação antes dos testes
e os erros/hesitações que se verificaram com a DAAA em papel ocorrerem em locais onde na aplicação
móvel são preenchidos automaticamente, permite desprezar o efeito de memória durante estes testes.
O número de erros médios da DAAA em papel é 2,8 erros e o na aplicação móvel a média é de 1,4
erros. Portanto é possível concluir que o número de erros que ocorram durante o preenchimento da
DAAA em papel é precisamente o dobro dos erros que ocorrem na aplicação móvel para estes
utilizadores.
6.2 Inquérito aos utilizadores
No final dos testes foram colocadas algumas questões relativas à satisfação de preenchimento
da DAAA a cada um dos utilizadores individualmente. Estas questões têm como propósito uma
avaliação subjetiva de como os utilizadores se sentem em relação ao sistema aplicação móvel. A
satisfação do utilizador é um dos fatores mais importantes e vai influenciar a sua decisão em relação à
aprovação ou não da aplicação móvel. Nas perguntas 1 a 3 foi utilizada uma escala quantitativa com 5
___________________________________________________________________________ 85
valores: 1 (péssimo), 2 (mau), 3 (sofrível), 4 (bom) e 5 (muito bom) e as perguntas 4 e 5 são de resposta
de Sim ou Não.
A lista de questões efetuadas aos participantes foi a seguinte:
1. O que achou da interface gráfica?
2. O que achou da facilidade de utilização?
3. O que achou em geral da aplicação?
4. Acha que este sistema iria trazer uma mais-valia para uma companhia de seguro?
5. Utilizaria este sistema em vez da DAAA em papel?
Na tabela 22 encontram-se as médias das respostas dadas pelos participantes para cada
questão.
6.3 Conclusões
Terminada a fase de testes aos protótipos finais e tendo em consideração também os inquéritos
de satisfação feitos junto dos utilizadores podemos afirmar que a aplicação móvel para notificação de
sinistro cumpriu alguns dos objetivos colocados no início deste trabalho. Como por exemplo, os testes
executados demonstram que o preenchimento da DAAA na aplicação móvel é mais rápida do que o
correspondente preenchimento em papel e o número de erros da aplicação móvel é mais reduzido do
que no preenchimento em papel. Estes resultados permitem aferir que em situações em que o utilizador
esteja afetado psicologicamente, o recurso à aplicação móvel pode minimizar os erros e hesitações e
tornar uma situação negativa mais curta.
Alguns do erros principais que ocorrem e que a aplicação de notificação de sinistro ajuda a
diminuir são por exemplo: falta de espaço nos vários campos da DAAA; não haver rasura durante o
preenchimento; encontrar as informações nos documentos, espacialmente na carta verde e na carta
de condução, que são documentos que utilizadores normalmente não estão habituados a ver. O acesso
à base de dados da BD da seguradora ajuda bastante neste último ponto.
Alguns atributos de usabilidade como a aprendizagem e memorização não foram considerados,
pois o tempo entre dois acidentes é suficientemente longo para que o efeito de memória se desvaneça
e o utilizador esqueça e, por isso, não se repetiu o teste ao fim de alguns minutos ou horas porque esse
intervalo de tempo não corresponderia à realidade.
Em toda a fase de desenvolvimento da solução tentou-se sempre envolver os utilizadores no
processo de desenvolvimento fazendo com que a sua conceção fosse centrada ao máximo nas
necessidades e características dos seus potenciais clientes. Foi utilizado vários dispositivos Android
durante a construção da solução para garantir sempre a melhor apresentação e usabilidade no maior
número máximo de dispositivos. O que se veio a confirmar, pois todos os utilizadores tinham aparelhos
diferentes, de diferentes marcas e ecrãs com tamanhos diferentes.
Pergunta 1 2 3 4 5
Resposta 4,0 4,5 4,1 10 Utilizadores disseram que sim 10 Utilizadores disseram que sim
Table 22: Média das pontuações dos questionários.
___________________________________________________________________________ 87
7 Conclusões e
Trabalho Futuro
___________________________________________________________________________ 89
7. Conclusões e Trabalho Futuro
Este capítulo de conclusões apresenta uma síntese das principais actividades desenvolvidas e
resultados encontrados. Apresenta-se como foram atingidos os objetivos e as áreas de trabalho futuro
que podem ser desenvolvidas em trabalhos posteriores.
7.1 Trabalho Desenvolvido
O presente trabalho desenvolveu-se com foco num objetivo fundamental, criar uma aplicação
móvel para notificação de sinistros com foco na Declaração Amigável de Acidente Automóvel. O
principal objetivo é a aplicação móvel tornar-se uma alternativa ao atual paradigma de preenchimento
de DAAA em papel.
Foram efetuadas várias reuniões com elementos envolvidos neste projeto e foi pedida, durante
a fase de desenvolvimento, a opinião a várias pessoas. O objetivo de debater antecipadamente
eventuais problemas e soluções, deve-se ao fato de permitir encontrar e corrigir prováveis erros o mais
atempadamente possível e saber quais as funcionalidades que a aplicação deverá conter. Esta
estratégia, que foi usada durante toda a fase de implementação, em conjunto com uma pesquisa
detalhada e testes a outras aplicações de notificação de sinistros, proporcionou a obtenção de uma
aplicação transversal em relação às funcionalidades oferecidas na aplicação Notificação de Sinistros.
Com o intuito de demonstrar que a prova de conceito oferece uma alternativa viável e uma mais-
valia às companhias de seguros e para os seus clientes, foi desenvolvido um sistema com 3 peças
fundamentais: uma base de dados, um servidor e uma aplicação móvel Android. Este sistema permite
testar a aplicação móvel como se o utilizador estivesse ligado a uma seguradora real. Desta forma é
possível realizar testes de usabilidade para medir o desempenho da solução e analisar a satisfação
dos utilizadores.
A avaliação produziu bons resultados, pois os testes demonstram que a aplicação móvel é
aproximadamente 2 vezes mais rápida do que a correspondente DAAA em papel e os resultados
referentes ao número de erros cometidos pelos utilizadores durante o preenchimento permitem aferir
que quem utiliza aplicação móvel apresentou sensivelmente 2 vezes menor número de erros do que
com a DAAA em papel. A satisfação dos clientes foi conhecida a partir da realização de um inquérito,
cujos resultados obtidos foram bastantes bons. Os utilizadores acharam a interface gráfica e facilidade
de utilização boa e afirmam que utilizariam a aplicação móvel para preencher a DAAA em vez da DAAA
em papel.
Por conseguinte, é possível confirmar que a prova de conceito construída (base de dados,
servidor e aplicação móvel Android) apresenta uma alternativa viável ao preenchimento da DAAA em
papel. Numa época em que as aplicações móveis são cada vez mais utilizadas, uma seguradora que
venha a implementar este sistema vai com certeza obter algumas vantagens, como maior satisfação
dos clientes, transferir uma imagem de inovação aos cliente e, muito provavelmente, uma diminuição
dos custos da empresa.
___________________________________________________________________________ 90
7.2 Trabalho Futuro
O trabalho realizado até momento é apenas o começo, podendo vir a ser melhorado em vários
aspetos. Todas as conclusões retiradas, todo o trabalho efetuado neste projeto é só o inico de uma
ideia que no futuro pode inspirar na construção de uma aplicação móvel para notificação de sinistros.
Em seguida são apresentados alguns tópicos que podem vir a ser abordados a partir da
continuação deste trabalho:
Permitir comunicar outo tipo de sinistro para além da DAAAA. Como mencionado várias
vezes, a aplicação foi criada com o intuito de resolver digitalmente esta questão. Porém,
houve sempre uma preocupação em relação à extensibilidade da solução, ou seja, a
aplicação já se encontra preparada para acrescentar novos tipos de notificações;
A actividade de desenho do esquema do acidente (ponto 13) ter alguns objetos
disponíveis, por exemplo o veículo A e B e sinais de trânsito. O utilizador só teria de
arrastar os objetos pelo ecrã principal e coloca-los conforme a disposição do sinistro;
Transmitir as informações entre os sinistrados pela tecnologia NFC (em dispositivos
Android) em vez da atual utilização em Bluetooth e testar o desempenho das duas
tecnologias de comunicação sem-fios;
Permitir ao utilizador consultar o estado da notificação de sinistro após o seu envio e até
ao término do processo de notificação;
Caso o utilizador tenha vários veículos ou uma frota, permitir que este escolha o veículo
que esteve envolvido no acidente. Neste momento a um número de apólice está somente
associado um único veículo;
A aplicação móvel servir de carta verde. Ou seja, todas as informações que estão na
carta verde estarem disponíveis na aplicação e poderem ser utilizados pela polícia.
Apresenta-se em seguida um exemplo hipotético: no caso de operação stop, ser
necessário apresentar este documento. O utilizador só tem, a partir de uma tecnologia
de comunicações sem-fios de curto alcance (Bluetooth ou NFC), de transmitir as
informações da carta verde para um aparelho da polícia;
Criar uma área de negócio personalizada para o cliente;
Implementação da aplicação em iOS e Windows Phone;
Implementação prática de um modelo de assinaturas legalmente aceite.
___________________________________________________________________________ 91
Referências
[1] Kovach, S. (2013, August 13). History Of Android - Business Insider. Obtido em 22 de Fevereiro de
2015, de Business Insider: http://www.businessinsider.com/history-of-android-2013-8?op=1.
[2] Dashboards. Android Retrieved Obtido em 22 de Fevereiro de 2015, de Android Developers:
http://developer.android.com/about/dashboards/index.html?utm_source=ausdroid.net.
[3] IDC. IDC: Smartphone OS Market Share, 2015 Q2. Obtido em 22 de Fevereiro de 2015, de IDC:
http://www.idc.com/prodserv/smartphone-os-market-share.jsp.
[4] Teleco, Pingarilho, C., & Faro, L. (n.d.). Mobilidade A grande tendência do futuro. Acedido pela
útlima vez em 17 de Setembro de 2015, de Teleco Inteligência em Telecomunicações:
http://www.teleco.com.br/promon/pbtr/Mobilidade_4Web.pdf.
[5] Budiu, R. (2015, March 22). The State of Mobile User Experience. Obtido em 17 de Setembro de
2015, de NN/g Nielsen Norman Group Evidence-Based User Experience Research, Training, and
Consulting: http://www.nngroup.com/articles/mobile-usability-update/.
[6] Nielsen, J. (2001, 18 de Fevereiro). Success Rate: The Simplest Usability Metric. Acedido pela útlima
vez em 17 de Setembro de 2015, de NN/g Nielsen Norman Group Evidence-Based User Experience
Research, Training, and Consulting: http://www.nngroup.com/articles/success-rate-the-simplest-
usability-metric/.
[7] Gunnar Johannsen. Human-machine interaction.
[8] Jan O Borchers. A pattern approach to interaction design. AI & SOCIETY, 15(4):359–376, 2001.
[9] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design patterns: Ab- straction and
reuse of object-oriented design. Springer, 1993.
[10] UI-Patterns.com. Acedido pela útlima vez em 17 de Setembro de 2015, de User Interface Design
patterns: http://ui-patterns.com/.
[11] Lon Barfield, Willie van Burgsteden, Ruud Lanfermeijer, Bert Mulder, Jurrienne Ossewold, Dick
Rijken, and Philippe Wegner. Interaction design at the utrecht school of the arts. ACM SIGCHI Bulletin,
26(3):49–86, 1994.
[12] Martijn Van Welie and Hallvard Trætteberg. Interaction patterns in user interfaces. In 7th Pattern
Languages of Programs Conference, volume 13, páginas 16, 2000.
[13] Christopher Alexander, Sara Ishikawa, and Murray Silverstein. A pattern language: Towns,
buildings, construction (center for environmental structure series). 1978.
[14] Donald A Norman. The design of everyday things. Basic books, 2002.
___________________________________________________________________________ 92
[15] Don Mills, England Amsterdam Bonn, and Sydney Singapore Tokyo Madrid San Juan. Macintosh
human interface guidelines. 1992.
[16] Asa Granlund, Daniel Lafrenie`re, and David A Carr. A pattern-supported approach to the user
interface design process. In Proceedings of HCI International, volume 1, 2001.
[17] Richard Griffiths, Lyn Pemberton, Jan Borchers, and Adam Stork. Pattern languages for interaction
design: Building momentum. In CHI’00 extended abstracts on Human factors in computing systems,
pages 363–363. ACM, 2000.
[18] PedroJ. Molina, Santiago Melia ́, and Oscar Pastor. User interface conceptual patterns. In Peter
Forbrig, Quentin Limbourg, Jean Vanderdonckt, and Bodo Urban, editors, Inter- active Systems:Design,
Specification, and Verification, volume 2545 of Lecture Notes in Computer Science, páginas 159–172.
Springer Berlin Heidelberg, 2002.
[19] Erik G Nilsson. Design patterns for user interface for mobile applications. Advances in Engineering
Software, 40(12):1318–1328, 2009.
[20] Deborah J. Mayhew. The usability engineering lifecycle. In CHI ’99 Extended Abstracts on Human
Factors in Computing Systems, CHI EA ’99, páginas 147–148, New York, NY, USA, 1999. ACM.
[21] Nigel Bevana, Jurek Kirakowskib, and Jonathan Maissela. What is usability? In Proceedings of the
4th International Conference on HCI, 1991.
[22] D Spencer. What is usability? University of Melbourne, Melbourne, páginas 108–115, 2004.
[23] Jakob Nielsen. Heuristic evaluation. Usability inspection methods, 17:25–62, 1994.
[24] Jakob Nielsen and Rolf Molich. Heuristic evaluation of user interfaces. In Proceedings of the SIGCHI
conference on Human factors in computing systems, páginas 249–256. ACM, 1990.
[25] John P Chin, Virginia A Diehl, and Kent L Norman. Development of an instrument measuring user
satisfaction of the human-computer interface. In Proceedings of the SIGCHI conference on Human
factors in computing systems, páginas 213–218. ACM, 1988.
[26] Fred D Davis. Perceived usefulness, perceived ease of use, and user acceptance of information
technology. MIS quarterly, páginas 319–340, 1989.
[27] Jakob Nielsen. Usability engineering. Access Online via Elsevier, 1994.
[28] Jakob Nielsen. Heuristic evaluation. Usability inspection methods, 17:25–62, 1994.
[29] James R Lewis. Ibm computer usability satisfaction questionnaires: psychometric evaluation and
instructions for use. International Journal of Human-Computer Interaction, 7(1): 57–78, 1995.
[30] Gary Perlman. Practical usability evaluation. In CHI’97 Extended Abstracts on Human Factors in
Computing Systems, páginas 168–169. ACM, 1997.
___________________________________________________________________________ 93
[31] Arnold M Lund. Measuring usability with the use questionnaire. Usability interface, 8(2):3–6, 2001.
[32] Niels Ole Bernsen, Hans Dybkjær, and Laila Dybkjær. Wizard of oz prototyping: How and when.
Proc. CCI Working Papers Cognit. Sci./HCI, Roskilde, Denmark, 1994.
[33] Seguradores, A. P. (2006, May 3). Diário Da República - 1 Série -A N.85. Retrieved September 17,
2015, from apseguradores: https://www.apseguradores.pt/.
[34] Pensõs, A. d. (2006, August 30). NORMA REGULAMENTAR N.º 7/2006-R, DE 30 AGOSTO.
Acedido pela útlima vez em 17 de Setembro de 2015, de ASF - NORMA REGULAMENTAR N.º 7/2006-
R, DE 30 AGOSTO: http://www.asf.com.pt/NR/exeres/8C7A83FE-4D1B-431D-90AF-
29A7289EBCAD.htm.
[35] Autoridade Nacional Segurança rodoviária, Maio de 2014, Principais indicadores de sinistralidade
no continente.
[36] DSDM Consortium, “MoSCoW Prioritisation.” [Online]. Available: http://dsdm.org/content/10-
moscow-prioritisation. [Acedido: 24-Jan-2015].
[37] ISO. Acedido pela útlima vez em 17 de Setembro de 2015, de ISO - International Organization for
Standardization: http://www.iso.org/iso/home.html.
[38] Travis, D. (6 de June de 2011). ISO 13407 is dead. Long live ISO 9241-210! Obtido em 10 de Maio
de 2015, de Userfocus: http://www.userfocus.co.uk/articles/iso-13407-is-dead.html.
[39] Brooks, P. (24 de Março de 2015). What on Earth is ISO 9241? Obtido em 10 de Maio de 2015, de
uxbooth: http://www.uxbooth.com/articles/what-on-earth-is-iso-9241/.
___________________________________________________________________________ 97
Anexos
Anexo A: DAAA (Portugal)
Figura 36: Documento da DAAA.
___________________________________________________________________________ 98
Anexo A: DAAA (Portugal) verso
Figura 37:Verso da DAAA.
___________________________________________________________________________ 99
Anexo B: Campos da DAAA
Devido ao elevado número de campos presentes na declaração amigável de acidente automóvel,
foi construída a seguinte tabela com informações sobre os dados do formulário para preenchimento da
declaração amigável. A coluna “Campo” é apresentada com o nome presente na DAAA em Inglês e a
coluna “Actividade que implementa” é referente ao diagrama da figura 11.
Secção da Declaração
Campo Actividade que implementa na
aplicação Preenchimento automático
1 Date of accident
(G) Menu Informação Geral
Não
1 Time Não
2 Place (exact location of accident)
Não
3 Injuries even if
slight Não
4 Property Damage other than to the vehicles A and B
Não
5 Witnesses Não
6 Insured
Name
(H) Menu Formulário Veículo
Sim
First name Sim
Address Sim
Phone No. Sim
7 Vehicle
Make, type Sim
License plate country
Sim
License plate Sim
8 Insurance company
Name Sim
Policy No. Sim
Agent (or broker) Sim
Green Card No. Sim
Valid until Sim
Is damage to the vehicle insured?
Não
9 Driver
Name Sim
First name Sim
Address Sim
Driving Licence No.
Sim
Valid from___to____
Sim
10 Indicate by an
arrow the point of initial impact
(I) Menu Ponto de embate inicial Não
11 Visible damage (J) Menu Danos Visíveis Não
12 Circumstances
(K) Menu Circunstâncias do Acidente
Não
13 Plan of the accident
Não
14 Remarks Não
15 Signatures of the
drivers X X
Tablela 23: Nome dos campos presentes na DAAA em inglês e a sua correspondente localização na aplicação
móvel para notificação de sinistro. Também é indicado se estes podem ser ser preenchidos automaticamente.
___________________________________________________________________________ 100
Anexo C: Lista de circunstâncias da DAAA
Em seguida é apresentado a lista de circunstâncias da DAAA oficial em português e inglês.
Circunstâncias Português Inglês
1 Estava estacionado/Parado Parked (at the roadside)
2 Saía de estacionamento/
Abria uma porta Leaving a parking place (at the roadside)
3 Ia estacionar Entering a parking place (at the roadside)
4
Saía de um parque de
estacionamento, de local
privado ou de um caminho
particular
Emerging from a car park, from private
grounds, from a track
5
Entrava num parque de
estacionamento, local
privado ou num caminho
particular
Entering a car park, private grounds, a track
6 Entrava numa rotunda ou
praça de sentido giratório Entering a roundabout (or similar traffic system)
7 Circulava numa rotunda ou
praça de sentido giratório Circulating in a roundabout etc.
8
Embateu na traseira de
outro veículo que circulava
no mesmo sentido e na
mesma fila
Striking the rear of the other vehicle while going
in the same direction and in the same lane
9
Circulava no mesmo
sentido, mas numa fila
diferente
Going in the same direction but in a different
lane
10 Mudava de fila Changing lanes
11 Ultrapassava Overtaking
12 Virava à direita Turning to the right
13 Virava à esquerda Turning to the left
14 Recuava Reversing
15
Circulava na parte da faixa
de rodagem reservada à
circulação em sentido
contrário
Encroaching in the opposite traffic lane
16
Apresentava-se pela direita
(num cruzamento ou
entroncamento)
Coming from the right(at road junctions)
17
Não respeitou um sinal de
dar prioridade ou um
semáforo vermelho
Not observing a right of way sign
Tabela 24: Lista de circunstâncias da DAAA.
___________________________________________________________________________ 101
Anexo D: Ciclo de vida de uma actividade no Android
A figura ilustra os ciclos e caminhos que uma actividade pode ter entre os diferentes estados. Os
retângulos representam os métodos que podem ser implementados para executar as operações
quando a actividades transitam entre os estados.
Figura 38: Ciclo de Vida de uma Actividade.
A Imagem foi retirada da página http://developer.android.com/guide/components/activities.html.
___________________________________________________________________________ 102
Anexo E: Modelo ER da BD da seguradora
Figura 39: Base de Dados de suporte à aplicação de notificação de sinistros.
___________________________________________________________________________ 103
Anexo F: Esquema XML para interoperabilidade com as seguradoras
O XML apresentado propõe um esquema padrão a usar na operação de comunicação entre a
aplicação móvel e respetivas seguradoras.
<?xml version="1.0" encoding="UTF-8"?> <claim type="car_asof"> <general_information> <date_accident>03/30/2015</date_accident> <time>23 h : 21 m</time> <place_accident>rua</place_accident> <latitude>0.0</latitude> <longitude>0.0</longitude> <injuries>2131034368</injuries> <property_damage>2131034372</property_damage> <witnesses_list> <witness id="1"> <name /> <phone /> <address /> </witness> <witness id="2"> <name /> <phone /> <address /> </witness> </witnesses_list> </general_information> <person id="A"> <insured> <surname>Ferreira</surname> <name>Andre</name> <address>Rua Miguel Pais</address> <phone>913642142</phone> <zip_code>2844-356</zip_code> <email>[email protected]</email> <country>Portugal</country> <id>208599833</id> </insured> <vehicle> <make>Seat</make> <type>Ibiza</type> <license_plate>38-IS-38</license_plate> <license_plate_country>PT</license_plate_country> </vehicle> <insurance_company> <name>Proteccao Total</name> <policy_number>31/415-316</policy_number> <green_card> <number>P/000111222134</number> <valid_from>03/02/2015</valid_from> <valid_until>03/02/2016</valid_until> </green_card> <agent> <name>Seguro Seguro</name> <address>Av. Afonso Henriques,3</address> <zip_code>1100-431 Lisboa</zip_code> <country>Portugal</country> </agent> <phone_number>203341561</phone_number> <email>[email protected]</email> </insurance_company> <driver> <surname>Ferreira</surname> <name>Teodoro Filipe</name> <address>Av. Das Beiras, 3-4 ESQ</address> <birth_date>25/03/1960</birth_date> <driver_licence> <number>C-123456</number> <valid_from>20/02/2008</valid_from> <valid_until>30/02/2050</valid_until> </driver_licence> <group>B</group> <issued_by>Escola Conducao Lisboa</issued_by> <zip_code>3000-111 Coimbra</zip_code> <country>Portugal</country> <phone_number>985553431</phone_number> <email>[email protected]</email> </driver> </person> <person id="B"> <insured> <surname>Joao</surname> <name>Miguel</name>
___________________________________________________________________________ 104
Anexo F (continuação)
<address>Rua Miguel Pais</address> <phone>913632342</phone> <zip_code>2820-356</zip_code> <email>[email protected]</email> <country>Portugal</country> <id>208599878</id> </insured> <vehicle> <make>Ferrari</make> <type>La Ferrari</type> <license_plate>01-IS-28</license_plate> <license_plate_country>PT</license_plate_country> </vehicle> <insurance_company> <name>Proteccao Total</name> <policy_number>31/415-316</policy_number> <green_card> <number>P/000111222134</number> <valid_from>03/02/2010</valid_from> <valid_until>03/02/2011</valid_until> </green_card> <agent> <name>Seguro Boas Maos</name> <address>Av. Afonso Teodoro 3</address> <zip_code>1100-431 Lisboa</zip_code> <country>Portugal</country> </agent> <phone_number>203341561</phone_number> <email>[email protected]</email> </insurance_company> <driver> <surname>Joana</surname> <name>Filipa</name> <address>Av. Das Beiras, 3-4 ESQ</address> <birth_date>25/03/1960</birth_date> <driver_licence> <number>C-123456</number> <valid_from>20/02/2008</valid_from> <valid_until>30/02/2050</valid_until> </driver_licence> <group>B</group> <issued_by>Escola Conducao Lisboa</issued_by> <zip_code>3000-111 Coimbra</zip_code> <country>Portugal</country> <phone_number>985553431</phone_number> <email>[email protected]</email> </driver> </person> <intial_impact_list> <intial_impact vehicle="a"> <picture>NO PICTURE</picture> </intial_impact> <intial_impact vehicle="b"> <picture>NO PICTURE</picture> </intial_impact> </intial_impact_list> <visible_damage> <vehicle id="a"> <picture>NO PICTURE</picture> </vehicle> <vehicle id="b"> <picture>NO PICTURE</picture> </vehicle> <place_accident id="1"> <picture>NO PICTURE</picture> </place_accident> <place_accident id="2"> <picture>NO PICTURE</picture> </place_accident> </visible_damage> <circumstances_list> <SITUATION1>NOT SELECTED</SITUATION1> <SITUATION2>NOT SELECTED</SITUATION2> <SITUATION3>NOT SELECTED</SITUATION3> <SITUATION4>NOT SELECTED</SITUATION4> <SITUATION5>NOT SELECTED</SITUATION5> <SITUATION6>NOT SELECTED</SITUATION6> <SITUATION7>NOT SELECTED</SITUATION7> <SITUATION8>NOT SELECTED</SITUATION8> <SITUATION9>NOT SELECTED</SITUATION9> <SITUATION10>NOT SELECTED</SITUATION10> <SITUATION11>NOT SELECTED</SITUATION11> <SITUATION12>NOT SELECTED</SITUATION12> <SITUATION13>NOT SELECTED</SITUATION13> <SITUATION14>NOT SELECTED</SITUATION14> <SITUATION15>NOT SELECTED</SITUATION15> <SITUATION16>NOT SELECTED</SITUATION16> <SITUATION17>NOT SELECTED</SITUATION17> <SITUATION18>NOT SELECTED</SITUATION18> <plan_of_the_accident> <plan>NO PICTURE</plan> </plan_of_the_accident> <remarks> <audio_recording>NO REMARKS MADE</audio_recording> </remarks> </circumstances_list></claim>
___________________________________________________________________________ 105
Anexo G: Pontos de Interesse
Neste menu é exibida uma lista de pontos interesses que em seguida direciona o utilizador para
a aplicação Google Maps.
Figura 40: Lista de pontos de interesse.
___________________________________________________________________________ 106
Anexo H: Menu de Login
Menu que permite aceder à conta do utilizador para obter os seus dados.
Figura 41: Menu de Login.
___________________________________________________________________________ 107
Anexo I: Plano do Acidente
O objetivo deste ecrã é desenhar o plano do acidente. Para isso são disponibilizadas algumas
ferramentas para facilitar o desenho ao utilizador. As várias funcionalidades disponíveis nesta
actividade são:
Novo desenho - Ao pressionar este botão o utilizador é questionado se quer apagar o
desenho atual e substituir por uma página em branco;
Lápis - Permite selecionar a espessura deste para produzir o desenho;
Borracha - Permite selecionar a espessura desta para apagar o desenho;
Gravar – Regista o desenho efetuado.
Na parte de baixo do ecrã encontra-se disposta uma palete de cores. O utilizador pode selecionar
uma das 12 cores disponíveis.
Figura 42: A actividade permite desenhar o plano do acidente.
___________________________________________________________________________ 108
Anexo J: Selecionar Oficina Recomendada
Ao ser selecionada a hipótese “Procurar oficinas recomendadas” é chamada uma actividade que
permite escolher uma oficina recomendada a partir do mapa.
Figura 43: Mapa com oficinas recomendadas pela seguradora.
___________________________________________________________________________ 109
Anexo K: Erros cometidos pelos utilizadores
São aqui indicados os erros que foram cometidos pelos utilizadores separando o preenchimento
em papel e via digital (aplicação móvel) e são quantificados os erros segundo a sua natureza/tipo. Os
erros pressupõem qualquer ação do utilizador que conduza a resultados incorretos ou que o obrigue a
retroceder ou reiniciar a tarefa ou, devido à natureza deste trabalho, que o utilizador demore um tempo
exagerado (mais de 30 segundos) na busca de uma informação ou não a encontre. O tipo do erro é
quantificado com base numa escala com 3 fatores: pouco provável (A), provável (B) e muito provável
de ocorrer (C).
Utilizador Erros cometidos na DAAA em papel (tipo do erro) Erros cometidos na DAAA digital (tipo do erro)
A1/A2
- Escrita de informações fora dos sítios apropriados e
rasuras (C);
- Esqueceu preencher as circunstâncias referentes ao
seu veículo (ponto 12 da DAAA) (A);
- Não preencheu os dados referentes à agência (ponto 8
da DAAA) (C);
- Dificuldade ao gravar o ponto de embate inicial
(A);
- Dificuldade ao transferir formulário da DAAA por
Bluetooth (C);
B1/B2
- Escrita de informações fora dos sítios apropriados e
rasuras (C);
- Esquema do acidente não representa o sinistro
adequadamente (B);
- Erro no número da carta verde (A);
- Numero total de circunstâncias não preenchido (A);
- B2 não entendia a caligrafia do outro condutor (B);
- Ao selecionar o ponto de embate inicial alguma
dificuldade para gravar (A);
- Não gravou o desenho do esquema do acidente
tendo voltado a repetir esta ação (A);
- Dificuldade ao transferir formulário da DAAA por
Bluetooth (C);
C1/C2
- Escrita de informações fora dos sítios apropriados e
rasuras (C);
- Não preencheu o NIF, pois o tomador de seguro era
diferente do condutor e não obteve a informação (B);
- Desconhecia se os Danos materiais (ponto 8 da
DAAA) estão ou não cobertos (B);
- Ao selecionar o ponto de embate inicial alguma
dificuldade para gravar (A);
- Dificuldade ao transferir formulário da DAAA por
Bluetooth (C);
D1/D2
- Escrita de informações fora dos sítios apropriados e
rasuras (C);
- Ponto de embate inicial mal indicado (A);
- Dificuldade ao transferir formulário da DAAA por
Bluetooth (C);
- Alguma confusão ao preencher as circunstâncias
(A);
E1/E2
- Escrita de informações fora dos sítios apropriados e
rasuras (C);
- Circunstâncias selecionadas erradas (A);
- Não se apercebeu que a aplicação estava
disponível em duas línguas e perdeu imenso
tempo à procura de como mudar esta opção (B);
- Dificuldade ao transferir formulário da DAAA por
Bluetooth (C);
Tabela 25: Detalhes sobre os erros cometidos no preenchimento da DAAA em papel e digital.