Aplicação Móvel para Notificação de Sinistros · Mauro Teixeira, Miguel Nunes, Miguel Tairum, Pedro Nunes, Pedro Ribeiro, Ricardo Azevedo, Ricardo Bugalho, Tânia Pinto, aos

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

___________________________________________________________________________ ii

___________________________________________________________________________ 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.

___________________________________________________________________________ iv

___________________________________________________________________________ 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

___________________________________________________________________________ vi

___________________________________________________________________________ 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.

___________________________________________________________________________ viii

___________________________________________________________________________ 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

___________________________________________________________________________ xii

___________________________________________________________________________ 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

___________________________________________________________________________ xiv

___________________________________________________________________________ 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

___________________________________________________________________________ xvi

___________________________________________________________________________ 1

1 Introdução

___________________________________________________________________________ 2

___________________________________________________________________________ 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.

___________________________________________________________________________ 7

2 Estado da Arte

___________________________________________________________________________ 8

___________________________________________________________________________ 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


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


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


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



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


12.Revisão dos dados preenchidos Sim, enquanto se reúne os detalhes do sinistro é apresentado

um sumário das informações


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

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


Velocidade para notificar um sinistro 3 (caso o utilizador já tenha preenchido os dados de perfil)

Ferramentas 1 (só está preparada para notificar sinistros)



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




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




5.Acesso à BD da seguradora Sim, é possível confirmar algumas informações, através do

número de apólice de cliente









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




12.Revisão dos dados preenchidos Sim, é possível enquanto se reúne os detalhes do sinistro ver

um sumário dos dados preenchidos


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

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


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)



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


1.Espaço de negócio Existe uma secção especial para mostrar novos produtos e

ofertas especiais


de sinistro

Sim, há uma extensa lista de ferramentas que em geral

funcionam convenientemente




5.Acesso à BD da seguradora Não




mostrado um mapa, nem a localização onde o utilizador se

encontra



Sim, é possível chamar o reboque, no entanto não é

mostrado o mapa, nem a localização do utilizador


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


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


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



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

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



Ferramentas 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


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


É 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


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

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


Velocidade para notificar um

sinistro 5

Ferramentas 2 (imensas funcionalidade que acedem ao respetivo às páginas da web da

seguradora)



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


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


de sinistro Não



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



É possível chamar a emergência. Não é mostrado um mapa,

mas tem um campo para indicar a morada automaticamente


descritiva e com mapa) Não tem esta opção


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


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



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

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



Ferramentas 2



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




de sinistro

Não. Focada simplesmente na notificação de sinistro, sem

lista de contactos úteis, nem ferramentas extra




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


Localização descritiva e com mapa) Não existe nenhum contacto com o número de emergência


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


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



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


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

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



Ferramentas 1


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.

___________________________________________________________________________ 36

___________________________________________________________________________ 37

3 Requisitos

___________________________________________________________________________ 38

___________________________________________________________________________ 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


. 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


. 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.

___________________________________________________________________________ 50

___________________________________________________________________________ 51

4 Arquitetura da

Solução

___________________________________________________________________________ 52

___________________________________________________________________________ 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;

___________________________________________________________________________ 66

___________________________________________________________________________ 67

5 Implementação

___________________________________________________________________________ 68

___________________________________________________________________________ 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

___________________________________________________________________________ 80

___________________________________________________________________________ 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.

___________________________________________________________________________ 86

___________________________________________________________________________ 87

7 Conclusões e

Trabalho Futuro

___________________________________________________________________________ 88

___________________________________________________________________________ 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/.

___________________________________________________________________________ 94

___________________________________________________________________________ 95

Anexos

___________________________________________________________________________ 96

___________________________________________________________________________ 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.

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


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);


Bluetooth (C);

C1/C2


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);


Bluetooth (C);

D1/D2


rasuras (C);

- Ponto de embate inicial mal indicado (A);


Bluetooth (C);

- Alguma confusão ao preencher as circunstâncias

(A);

E1/E2


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);


Bluetooth (C);

Tabela 25: Detalhes sobre os erros cometidos no preenchimento da DAAA em papel e digital.

Documents

Aplicação Móvel para Notificação de Sinistros · Mauro Teixeira, Miguel Nunes, Miguel Tairum, Pedro Nunes, Pedro Ribeiro, Ricardo Azevedo, Ricardo Bugalho, Tânia Pinto, aos