Ricardo Filipe da Silva Costa -...

Universidade do Minho Escola de Engenharia Departamento de Informática

Ricardo Filipe da Silva Costa

Desenvolvimento de um sistema de software para gerir ocorrências em municípios

Dezembro 2015

Universidade do Minho Escola de Engenharia Departamento de Informática´

Ricardo Filipe da Silva Costa

Desenvolvimento de um sistema de software para gerir ocorrências em municípios Dissertação de Mestrado Mestrado em Engenharia Informática

Trabalho realizado sob orientação de João Miguel Lobo Fernandes

i

Agradecimentos

Um agradecimento muito especial ao Professor João Miguel Lobo Fernandes, por ter

aceite o meu pedido para orientador, mas também por toda a supervisão, sugestões e

críticas ao longo da investigação deste relatório.

Ao Vereador da Câmara Municipal de Vila Verde, Senhor Carlos Tiago, numa fase inicial

através da disponibilização de todo o tipo de informação necessária e relevante para o

projeto, mas também pelo apoio sempre prestado durante a elaboração do mesmo.

Aos meus pais que, ao longo de todo o percurso académico, sempre me ajudaram e

apoiaram. A todos os que não mencionei mas que, de certa forma contribuíram para que

este percurso tenha valido muito a pena, o meu maior agradecimento.

ii

Resumo

Reportar ocorrências relativas a espaços ou equipamentos públicos é uma tarefa essencial,

pois a identificação e a resolução dos problemas devem ser breves, de modo a evitar novos

como consequência da demora deste processo.

Atualmente, os cidadãos quando são confrontados com alguma ocorrência têm

dificuldade em saber como e onde participar a mesma para que esta seja resolvida.

Pretende-se, com o desenvolvimento deste projeto, criar um meio de comunicação

facilitador entre os cidadãos e as autarquias, que vise não só auxiliar os cidadãos a

reportarem as mais variadas ocorrências relativas aos espaços ou equipamentos públicos,

mas também permitir aos municípios gerir e monitorizar ocorrências reportadas nas

diversas áreas de intervenção dos serviços municipais.

O resultado do desenvolvimento deste projeto enquadra-se na criação de uma aplicação

móvel e de uma aplicação web.

iii

Abstract

Reporting incidents related to municipal spaces or municipal equipment is vital as the

identification and mitigation of the problem must be prompt, in order to avoid further

issues.

Nowadays, when citizens are faced with an incident they do not know how and where to

report it so that it gets fixed.

This projects aims to develop a communications channel between the council and its

citizens in order to, not only help citizens to easily report incidents related to municipal

spaces or municipal equipment, but also to allow councils to manage and monitor events

reported across the different areas in which the council has authority over.

Finally, the ultimate goal of this project is to create a mobile and web application that

hosts the concept introduced above.

.

iv

Acrónimos

ACF - Access Control Filter

API - Application Programming Interface

ART - Android Run Time

GPS - Global Positioning System

GUI - Graphical User Interface

HAL – Hardware Abstraction Layer

HTTP - Hypertext Transfer Protocol

IDE - Integrated Development Environment

IMAP - Internet Message Access Protocol

IP - Internet Protocol address

JSON - JavaScript Object Notation.

MVC - Model-View-Controller

MVP - Minimum Viable Product

ORM - Object-Relational Mapping

POP – Post Office Protocol

RBAC - Role Based Access Control

SMTP – Simple Mail Transfer Protocol

SRBA - Simpler Role Based Authorization

UML - Unified Modeling Language

XML - Extensible Markup Language

XP – eXtreme Programming

https://pt.wikipedia.org/wiki/Internet_Message_Access_Protocol

v

Conteúdo

CAPÍTULO 1 1

1 PROPÓSITO DO PROJETO 1

1.1 Introdução 1

1.2 Motivação 2

1.3 Objetivos 2

1.4 Plano de Trabalho 3

1.5 Estrutura da Dissertação 4

CAPÍTULO 2 6

2 ESTADO DA ARTE 6

2.1 Processo de Desenvolvimento de Software 6

2.2 Ferramentas e Tecnologias 10

2.2.1 Móvel 10

2.2.2 Web 18

2.3 Soluções Disponíveis 21

CAPÍTULO 3 23

3 MODELAÇÃO E RISCOS DO PROJETO 23

3.1 Modelo de Domínio 23

3.2 Os interessados 24

3.3 Diagrama Casos de Uso 27

3.4 Requisitos Funcionais 30

3.5 Requisitos Não-Funcionais 32

3.5.1 Requisitos de Aparência 32

3.5.2 Requisitos de Usabilidade 33

3.5.3 Requisitos de Desempenho 33

3.5.4 Requisitos Operacionais 33

3.5.5 Requisitos de Manutenibilidade e Suporte 34

vi

3.5.6 Requisitos de Segurança 34

3.5.7 Requisitos Culturais e Políticos 34

3.5.8 Requisitos Legais 35

3.6 Descrição dos Requisitos 35

3.6.1 MoSCoW 35

3.6.2 Top 10 36

3.7 Diagrama de Estados 37

3.7.1 Ocorrência 37

3.7.2 Utilizador 39

3.8 Diagrama de Atividades 41

3.8.1 Nova Ocorrência 41

3.8.2 Gestão de Ocorrências 42

3.8.3 Avaliação de Ocorrências 43

3.8.4 Privilégios de Utilizadores do Sistema 43

3.9 Diagrama de Sequências 45

3.9.1 Nova Ocorrência 45

3.9.2 Nova Intervenção 46

3.10 Modelo Entidade Relação 47

3.10.1 Móvel - SQLite 47

3.10.2 Web – MySQL 48

3.11 Riscos 50

CAPÍTULO 4 51

4 TRABALHO DESENVOLVIMENTO 51

4.1 Padrão de Arquitetura de Software 51

4.2 Aplicação Móvel 52

4.3 Aplicação Web 58

4.3.1 Estrutura da Aplicação Web 59

4.3.2 Controlo de Acesso ao Sistema 60

vii

4.3.3 Utilizador Autenticado 63

4.3.4 Utilizador Autenticado com Privilégios 75

4.3.5 Fluxo E-mails 78

4.3.6 Google Maps API 80

4.3.7 Web Services 82

CAPÍTULO 5 87

5 ANÁLISE DE RESULTADOS 87

5.1 Metodologia 87

5.2 Acesso à Aplicação 87

5.3 Novos Requisitos 88

5.4 Discussão 89

CAPÍTULO 6 91

6 CONCLUSÕES E TRABALHO FUTURO 91

6.1 Síntese do Trabalho 91

6.2 Trabalho Futuro 92

BIBLIOGRAFIA 94

ANEXO A – CARTÕES VOLERE 97

ANEXO B – CATEGORIZAÇÃO DOS RISCOS 121

Categorização dos Riscos 123

Mitigação dos Riscos 123

ANEXO C - PERSONAS 126

ANEXO D - WIREFRAMES 131

ANEXO E – CLASSE SINGLETON 132

viii

Lista de Tabelas

Tabela 1 – Elementos da aplicação Android 13

Tabela 2 - Métodos da classe activity 14

Tabela 3 - Classes Volley HTTP - Requests 16

Tabela 4 - Requisitos Funcionais 32

Tabela 5 - Requisitos de Aparência 32

Tabela 6 - Requisitos de Usabilidade 33

Tabela 7 - Requisitos de Desempenho 33

Tabela 8 - Requisitos Operacionais 33

Tabela 9 - Requisitos de Manutenibilidade e Suporte 34

Tabela 10 - Requisitos de Segurança 34

Tabela 11 - Requisitos Culturais e Políticos 34

Tabela 12 - Requisitos Legais 35

Tabela 13 - Top-10 36

Tabela 14 - Entidade-Relação - SQLite 47

Tabela 15 - Entidade-Relação - MySQL 48

Tabela 16 – Descrição dos riscos 50

Tabela 17 - Estrutura da framework Yii2 60

Tabela 18 - Estrutura dos pedidos 83

Tabela 19 - Registar Utilizador 84

Tabela 20 - Autenticar Utilizador 85

Tabela 21 - Criar Ocorrência 85

Tabela 22 - Escala de categorias para classificação de riscos 121

Tabela 23 - Categorização dos riscos 123

Tabela 24 - Mitigação do Risco 1 123



ix










x

Lista de Figuras

Figura 1 - Diagrama de Gantt - Plano de trabalho 3

Figura 2 – Modelo em Cascata (Fonte: wordpress.com) 7

Figura 3 – Quadro – Trello (fonte: trello.com) 10

Figura 4 - Android Stack (Fonte: developer.android.com) 11

Figura 5 - Ciclo de vida de uma activity Android (Fonte: developer.android.com) 13

Figura 6 - Ciclo de vida de um pedido (Fonte: developer.android.com) 17

Figura 7 - Singleton Pattern (Fonte: cs.unc.edu) 18

Figura 8 - Modelo de domínio 24

Figura 9 - Hierarquia dos atores do sistema 27

Figura 10 - Diagrama Casos de Uso - Utilizador sem privilégios 28

Figura 11 - Diagrama Casos de Uso - Utilizadores com privilégios 29

Figura 12 - Diagrama Casos de Uso - Gestão de Ocorrências - Utilizador Autenticado 29

Figura 13 - Diagrama Casos de Uso - Gestão de Ocorrências – Utilizadores com privilégios 30

Figura 14 – Método MoSCoW 35

Figura 15 - Diagrama de estados - Ocorrência 38

Figura 16 - Diagrama de estados - Utilizador 40

Figura 17 - Diagrama de atividades - Reportar ocorrência 41

Figura 18 - Diagrama de atividades - Gestão de ocorrência 42

Figura 19 - Diagrama de atividades - Avaliação de ocorrências 43

Figura 20 - Diagrama de atividades - Gerir privilégios de utilizadores 44

Figura 21 - Diagrama de sequência - Reportar ocorrência 45

Figura 22 - Diagrama de sequências - Nova intervenção 46

Figura 23 - Modelo Entidade Relação - Android 47

Figura 24 – Modelo Entidade Relação - Web 49

Figura 25 – MVC (Fonte: codeproject.com) 52

Figura 26 - Ocorrências - Marcadores 53

xi

Figura 27 - Notificação - Realizar Login 54

Figura 28 - Login 54

Figura 29 - Navegação Lateral 54

Figura 30 - Permitir verificar as informações 54

Figura 31 - Menu lateral - Dados do utilizador 55

Figura 32 - Nova Ocorrência 55

Figura 33 - Tirar Foto 55

Figura 34 - Adicionar foto 55

Figura 35 - Localização - GPS 56

Figura 36 - Localização - GMaps 56

Figura 37 - Preenchimento manual 56

Figura 38 - Lista de ocorrências reportadas 57

Figura 39 - Lista de ocorrências - Estados 57

Figura 40 - Sem ligação à internet 58

Figura 41 - Arquitetura de uma aplicação web 59

Figura 42 - Exemplo da utilização da classe AccessControl (Fonte: yiiframework.com) 61

Figura 43 - Erro HTTP - 403 Forbidden 63

Figura 44 - Página inicial - Aplicação Web 64

Figura 45 - Registo 64

Figura 46 - Notificação - Confirmar e-mail 65

Figura 47 - E-mail para confirmar da conta de utilizador 66

Figura 48 - Notificação de confirmação bem-sucedida. 66

Figura 49 - Login 66

Figura 50 - Formulário - Nova Ocorrência 67

Figura 51 - Address 68

Figura 52 - Notificação - Confirmação do envio do reporte da ocorrência 68

Figura 53 - E-mail de confirmação do envio da ocorrência 68

Figura 54 - Página Ocorrência 69

Figura 55 - Mapa das ocorrências 70

xii

Figura 56 – Winfo-Window - Marcador 71

Figura 57 - Lista das ocorrências reportadas 71

Figura 58 - Conta Utilizador 72

Figura 59 - Lista ocorrências e avaliações 72

Figura 60 - Formulário para reclamar ou solicitar ajuda 73

Figura 61 - Notificação - Sucesso 73

Figura 62 – Solicitar nova password 74

Figura 63 - E-mail - Solicitação nova password 74

Figura 64 - Repor password 74

Figura 65 - Adicionar Nova Intervenção 76

Figura 66 - Criar Nova Intervenção 76

Figura 67 - E-mail - Nova Intervenção 76

Figura 68 - Lista dos utilizadores do sistema 77

Figura 69 - Servidor E-mail (Fonte: serversmptp.com) 78

Figura 70 - Fluxo de E-mail – MailTrap (Fonte: mailtrap.com) 79

Figura 71 - Google Maps API 80

Figura 72 - InfoWindow - Ocorrência 81

Figura 73 - Estrutura Json - Ocorrência 81

Figura 74 - Google Maps - Áreas Administrativas 82

Figura 75 – Web Services REST – Esquema da comunicação 82

Figura 76 - Resposta JSON - Registo efetuado com sucesso 84

Figura 77 - Resposta JSON - Utilizador já existe 84

Figura 78 - Resposta JSON - Autenticação realizada com sucesso 85

Figura 79 - Resposta JSON - Password errada 85

Figura 80 - Resposta JSON - Listar Ocorrências 86

Figura 81 - Principais Wireframes – Aplicação Móvel 131

Figura 82 - Classe Singleton (Fonte: developer.android.com) 132

1 Propósito do Projeto

1

Capítulo 1


1.1 Introdução

No nosso quotidiano somos deparados com as mais variadíssimas situações relativas a

espaços públicos, que de certa forma queremos que sejam resolvidas com a maior

brevidade possível.

A participação de ocorrências na via pública torna-se uma tarefa essencial, uma vez que

a identificação e a resolução dos problemas devem ser breves, de modo que não advenham

novos como consequência da demora deste processo. Atualmente, os cidadãos e a

autarquia utilizam como principais meios o telefone, o correio eletrónico ou o contacto

direto para comunicar e gerir as ocorrências relativas a espaços públicos.

A utilização destas soluções consideradas tradicionais, pouco eficazes e pouco eficientes,

fazem com que os cidadãos não identifiquem ou não reportem os problemas de acordo

com a realidade observada. Também é observável que, várias vezes, o cidadão reporta

uma dada ocorrência, mas não recebe qualquer tipo de feedback sobre a mesma.

Perante tais circunstâncias, surgiu a ideia de desenvolver uma aplicação web e móvel.

Esta aplicação web será utilizada, principalmente, como meio para gerir e monitorizar as

ocorrências reportadas pelos cidadãos através da aplicação móvel.

O desenvolvimento desta aplicação móvel tem como objetivo retirar o máximo proveito

de certas potencialidades que o smartphone possui, mais especificamente do GPS e da

câmara fotográfica. O GPS servirá para a recolha da informação georreferenciada do local

onde o dispositivo se encontra e a câmara fotográfica para obter uma fotografia do local.

Juntamente a esta informação bastará acrescentar uma pequena descrição sucinta da

ocorrência e enviar toda a informação no momento.


2

1.2 Motivação

O ser humano tem vindo a sofrer várias alterações a nível comportamental relativamente

à utilização de meios para comunicar entre si. Esta é uma ação resultante do facto das

tecnologias utilizadas tornarem, efetivamente, a comunicação entre a civilização mais

cómoda e mais simples.

Perante a necessidade de encontrar uma melhor solução para a comunicação de

ocorrências relativas a espaços públicos como ruas, iluminação pública, limpeza,

sinalização de trânsito ou contentores, pensou-se ser do interesse comum desenvolver este

projeto para que fosse possível preservar espaços e equipamentos públicos do município

e, consequentemente, aumentar a satisfação dos cidadãos.

Pretende-se então que, esta solução contribua para a aproximação dos cidadãos ao

município bem como que o município seja capaz de fornecer a resposta mais rápida e

eficiente a todas as solicitações da comunidade. Com o auxílio desta solução, os

municípios beneficiam, também, de uma redução dos custos na utilização de recursos

para identificação de ocorrências.

1.3 Objetivos

O objetivo principal desta dissertação foi desenvolver uma solução que visasse não só

auxiliar os cidadãos a reportar e monitorizar as mais variadas situações relativas a espaços

públicos, mas também auxiliar a gestão e a monitorização das ocorrências nas diversas

áreas de intervenção dos serviços municipais.

Na utilização desta solução qualquer cidadão poderá reportar ocorrências de forma

simples, através da aplicação móvel ou web. As ocorrências serão enviadas para o

servidor web, na qual, posteriormente, são acedidas pelos serviços municipais que têm a

responsabilidade de gerir e de resolver a ocorrência. Os serviços do município têm acesso

à localização das ocorrências reportadas pela comunidade através da aplicação web. Nesta

aplicação, os serviços têm a possibilidade de executar funções administrativas para que a

ocorrência seja resolvida, adicionando intervenções para a sua resolução.


3

Todos os cidadãos que reportarem as ocorrências utilizando esta solução, podem

consultar e acompanhar o estado destas, através do smartphone, tablet ou pelo

computador. Na alteração do seu estado, o utilizador será notificado automaticamente por

e-mail sobre estado em que a ocorrência reportada se encontra. Após a resolução da

ocorrência, o utilizador tem a possibilidade de avaliar as intervenções realizadas durante

o processo, para que o município fique informado sobre a satisfação do cidadão após a

resolução.

O sistema de software não foi desenvolvido à medida para um município em específico,

mas como um produto de software. Os municípios apresentam diferenças no número de

departamentos e no número de áreas de intervenção dos serviços municipais, o que levou

ao desenvolvimento de um produto de software genérico, adaptado às diversas

necessidades de cada município. Assim, é possível criar categorias, departamentos,

subcategorias e definir áreas administrativas.

1.4 Plano de Trabalho

De forma a cumprir os objetivos estabelecidos e referidos anteriormente, o projeto

dividiu-se em diferentes etapas de trabalho com diferente gestão do tempo para que o

desenvolvimento do produto de software fosse conseguido com sucesso.

O diagrama de Gantt apresentado na figura 1 está dividido em diferentes etapas. São elas:

Figura 1 - Diagrama de Gantt - Plano de trabalho


4

Primeira etapa - Investigação sobre o tema: realizou-se um estudo mais

detalhado para uma melhor fundamentação da necessidade encontrada.

Segunda etapa - Pré-Dissertação: elaboração de um documento a delimitar e a

caraterizar o problema a tratar no âmbito da dissertação.

Terceira etapa - Análise e conceção: modelação e conceção de uma solução para

a necessidade encontrada de acordo com o estudo realizado inicialmente. Nesta

etapa foi elaborado, simultaneamente, um documento de requisitos e de riscos

associados a este projeto.

Quarta etapa - Construção: trabalho sobre as soluções encontradas, isto é,

desenvolvimento de uma aplicação web e de uma aplicação móvel.

Quinta etapa – Testes: realização dos testes que permitiram verificar se as

funcionalidades estão de acordo com os requisitos especificados inicialmente.

Última etapa - Escrita da dissertação: construção deste documento escrito que

veio a ser elaborado em paralelo com as outras etapas acima detalhadas.

Durante o desenvolvimento deste projeto houve um contacto direto e frequente, através

da realização de reuniões, com Vereadores e com o Departamento de Informática da

Câmara Municipal de Vila Verde o que permitiu conhecer melhor o domínio do problema.

1.5 Estrutura da Dissertação

A dissertação é constituída por sete capítulos. No primeiro capítulo é apresentado o

enquadramento ao tema, identificado e detalhado o problema e a sua respetiva resolução.

Segue-se a motivação para a realização deste projeto, os objetivos que se propuseram ser

alcançados e a calendarização do plano de trabalho assumido.

No segundo capítulo, intitulado Estado da Arte, são abordados temas relacionados com a

metodologia escolhida e mais adequada para o desenvolvimento deste projeto assim como

os instrumentos, as tecnologias e as ferramentas que foram utilizadas para a concretização

do mesmo.

No terceiro capítulo - Modelação e Riscos do Projeto, apresentam-se os modelos

essenciais para especificar os requisitos do sistema e ainda os riscos associados ao

desenvolvimento deste projeto.


5

O quarto capítulo - Trabalho desenvolvido, contém a apresentação teórica de forma mais

detalhada de todo o sistema desenvolvido para gestão e monotorização de ocorrências.

No quinto capítulo - Análise de resultados, apresentam-se os resultados obtidos no final

da implementação do sistema e ainda é feita uma descrição das melhorias efetuadas após

a obtenção do MVP.

O sexto capítulo intitulado - Conclusão e trabalho futuro, é dedicado às conclusões e ao

trabalho que deverá ser realizado futuramente na eventualidade da existência da

necessidade de adaptação de novos requisitos. Para finalizar, no último capítulo serão

disponibilizados todos os anexos.

2. Estado da Arte

6

Capítulo 2

2 Estado da Arte

Neste capítulo intitulado Estado da Arte, são abordados temas fundamentais para o

desenvolvimento deste projeto. Estes estão relacionados com a metodologia aplicada ao

processo de desenvolvimento de software, com as tecnologias e as ferramentas utilizadas

para o desenvolvimento do sistema e ainda com a descrição das soluções disponíveis no

mercado.

2.1 Processo de Desenvolvimento de Software

O processo de desenvolvimento de software pode definir-se como um conjunto de

atividades, normalmente organizadas em fases e tarefas, que são executadas de forma

sistemática e idêntica por intervenientes com responsabilidades bem definidas. Estas

visam a criação de um produto de software bem estruturado e de qualidade para que haja

uma boa manutenção do software. [13]

Existem várias metodologias para o desenvolvimento de software, no entanto, deve ser

realizada uma avaliação para verificar qual a metodologia mais adequada ao sucesso de

um projeto.

Um projeto que se baseie numa abordagem mais tradicional, em cascata, possui dois

aspetos principais que a caracterizam, nomeadamente o seu faseamento e a sua

sequencialidade. A figura 2 ilustra as diferentes fases que compõem o modelo em cascata.

2. Estado da Arte

7

Na utilização deste tipo de abordagem, as fases são concretizadas de forma sequencial e

linear, ou seja, a fase seguinte só é iniciada quando a anterior estiver finalizada.[13]

Assim, podem ser identificados problemas na utilização deste modelo de processo

tradicional uma vez que, sendo uma abordagem não iterativa e sequencial, o custo para

efetuar alterações em fases antecedentes aumenta exponencialmente ao longo do tempo

quando comparado a um modelo de processo iterativo e incremental.

O modelo em cascata apenas produz resultados satisfatórios quando os requisitos são

claros e a probabilidade de os modificar é muito baixa. O modelo incremental e iterativo

é baseado nas caraterísticas do modelo em cascata, porém este permite iterações para um

desenvolvimento incremental. [13] Este processo permite criar artefactos mais simples

uma vez que, a cada iteração, são acrescentadas ou melhoradas funcionalidades até que o

sistema seja finalizado.

Os métodos ágeis enquadram-se no âmbito deste modelo para o processo de

desenvolvimento de software, pois estes baseiam-se em conceitos consideravelmente

díspares relativamente aos modelos de processo de desenvolvimento de software mais

tradicionais, ou seja, não tentam implementar todos os requisitos o mais cedo possível,

toleram alterações dos requisitos durante o ciclo de vida do projeto e colocam menos

ênfase no planeamento inicial. A diferenciação não tem que ver, unicamente, com o

planeamento do projeto, mas também relativamente ao nível do envolvimento dos vários

stakeholders, pois as metodologias ágeis permitem o envolvimento dos stakeholders ao

longo do processo de desenvolvimento do software.

Atualmente, o mercado possui um ritmo acelerado e em constante mudança o que obriga

as organizações a aplicarem as melhores estratégias para o desenvolvimento de produtos

Figura 2 – Modelo em Cascata (Fonte: wordpress.com)

2. Estado da Arte

8

de software. Não basta apenas desenvolver e apresentar produtos inovadores para

marcarem a diferença no mercado. É necessária a existência da possibilidade de adaptação

de novas regras ou requisitos durante o desenvolvimento do produto com menor impacto

possível. Num mercado cada vez mais competitivo, a utilização do modelo em cascata

para o processo de desenvolvimento torna-se inadequado, pois neste tipo de ambiente

competitivo existe a necessidade de adaptar novas regras de negócio e novos requisitos

em tempo de desenvolvimento do projeto de forma a acompanhar as exigências do

mercado. [13]

O número de empresas, que adotam métodos ágeis no processo de desenvolvimento de

software, tem vindo a aumentar gradualmente. Atualmente, os métodos ágeis mais

utilizados em empresas de software são: SCRUM e o XP. [34][27]

Os engenheiros de software que desenvolvem individualmente produtos de software,

enfrentam desafios no planeamento e no controlo de qualidade do projeto. O SCRUM e

o XP são métodos que são adotados por equipas de desenvolvimento. [39] Apesar da

conceção deste projeto ter sido desenvolvida por uma pessoa (one-man), foi igualmente

importante também aplicar e utilizar técnicas e ferramentas dos métodos ágeis que as

empresas utilizam para o desenvolvimento de software. Esta medida justifica-se pelo

facto desta permitir melhorar o planeamento e a qualidade do projeto. Outra razão, deveu-

se ao facto de esta medida também permitir ao engenheiro de software adaptar-se ao

processo agile, caso futuramente seja integrado numa equipa de uma empresa em que se

aplicam métodos ágeis no processo de desenvolvimento de software.

Neste sentido, a metodologia aplicada para o processo de desenvolvimento deste projeto

foi a ágil, nomeadamente o método Personal eXtreme Programming. A escolha desta

metodologia, para além das razões acima descritas, prende-se ao facto de esta defender

que não existe a necessidade de implementar todos os requisitos o mais cedo possível,

tolerando alterações nos mesmos durante o ciclo de vida do projeto e colocando menos

ênfase no planeamento inicial. É ainda salientar também a importância da possibilidade

do envolvimento constante dos vários stakeholders ao longo do faseamento do projeto.

Personal eXtreme Programming

2. Estado da Arte

9

O XP defende um conjunto de valores, princípios e práticas para o rápido

desenvolvimento de software de boa qualidade, que visam proporcionar maior valor para

o cliente de forma mais rápida possível. [7]

O Personal Software Process (PSP) é um processo de desenvolvimento de software,

criado por Watts. S. Humphrey. Foi projetado para ser utilizado por engenheiros de

software cujo objetivo é melhorar a qualidade e a produtividade para a elaboração de

projetos individuais. Auxilia as pessoas a entender o seu desempenho pessoal através do

planeamento e na qualidade dos produtos desenvolvidos. [20]

O Personal eXtreme Programming (PXP) baseia-se na combinação de XP com PSP. O

PSP, à semelhança do XP, centra-se no desenvolvimento de produtos de qualidade bem

como no planeamento de qualidade através da melhoria de desempenho dos engenheiros

de software. O PXP introduz um conjunto de práticas do método XP, que devem ser

adotadas no desenvolvimento de software, para que este último tenha sucesso. No XP,

existe a prática de pair programming que obriga dois programadores a serem capazes de

trabalhar em simultâneo na mesma máquina. Esta prática requer trabalho em equipa, o

que neste caso em concreto, em desenvolvimento individual, é uma prática é inexequível.

As restantes práticas, podem ser adotadas na utilização do PXP [1][39]

Kanban

O Kanban é um processo de gestão de trabalho baseado nas práticas Lean, cujos objetivos

são evitar a falta ou excesso de produção, expor os problemas e definir o que deve ser

realmente feito. Este processo foi desenvolvido pela Toyota na década de 1950, e,

atualmente, tem sido utilizado pelas equipas de desenvolvimento ágil de software.

[18][26]

Uma das razões que levou à utilização do Kanban foi o facto deste permitir uma maior

transparência sobre o fluxo de trabalho, uma vez que, permite a qualquer pessoa

aperceber-se do que está a acontecer com o projeto a qualquer momento, e assim gerar

uma melhor comunicação entre os intervenientes e, por sua vez, estabelecer uma maior

confiança no processo.

2. Estado da Arte

10

O Trello foi a ferramenta utilizada para auxiliar o controlo do fluxo de trabalho. Nesta

ferramenta foi criado um Board ao qual se denominou Development, no qual foram

criadas três colunas cujos nomes atribuídos são: ToDo, In Progress e Done.

O ToDo conteve todos os cartões que identificaram as tarefas necessárias para obter um

MVP. No mesmo Board do Trello, o InProgress constam todas as tarefas que foram

arrastadas do ToDo. Na finalização das tarefas, que estão no InProgress, todas foram

arrastadas para o Done. A figura 3 representa um exemplo da utilização da ferramenta

Trello.

2.2 Ferramentas e Tecnologias

Nesta secção serão abordadas quais as ferramentas e as tecnologias utilizadas para o

desenvolvimento da aplicação web e móvel.

2.2.1 Móvel

Android

O Android é um sistema operativo (SO) para dispositivos móveis baseado no núcleo

Linux e desenvolvido pela Open Handset Alliance, liderada pela Google.[30]

A possibilidade de aumentar o meu conhecimento no desenvolvimento de aplicações

móveis Android foi uma razão que levou a escolher este SO.

Antes de iniciar o desenvolvimento da aplicação móvel, foi necessário conhecer alguns

conceitos básicos sobre a arquitetura do Android assim como verificar a constituição da

Figura 3 – Quadro – Trello (fonte: trello.com)

2. Estado da Arte

11

mesma. A arquitetura do SO Android apresenta-se dividida nas seguintes camadas, tal

como mostra a figura 4.

A arquitetura Android é composta por seis camadas: 1) Linux Kernel, 2) HAL, 3) ART,

4) Libraries, 5) Java API Framework e 6) System Apps. [3]

Figura 4 - Android Stack (Fonte: developer.android.com)

2. Estado da Arte

12

Linux Kernel: A camada Linux Kernel serve como base da arquitetura do SO e é

responsável por gerir a memória, processos, threaths, protocolos de rede e

recursos de segurança.

HAL: A camada HAL fornece interfaces padrão que permitem expor os recursos

de hardware do dispositivo, nomeadamente câmara fotográfica, Bluetooth,

sensores entre outros. Para cada recurso utilizado, o HAL irá utilizar a biblioteca

para implementar a interface do respetivo recurso.

ART: A camada ART permite instanciar a máquina virtual, Dalvik, para cada

aplicação executada no dispositivo através do ART. Esta máquina virtual é

otimizada para utilizar o menor consumo de memória para um melhor

desempenho e para executar vários processos em simultâneo.

Libraries: A camada Native C/C++ Libraries possui as bibliotecas C/C++ que

são utilizadas pelo sistema. Muitos componentes do sistema Android, tais como

ART e HAL, necessitam de bibliotecas nativas. Esta camada possui também

bibliotecas de multimédia, para visualização 2D e 3D, fontes bitmap e funções

para o acesso à base dados SQLite.

Java API Framework: A camada Java API Framework disponibiliza diversos

recursos através de APIs em Java. Os developers podem utilizar estes recursos

para o desenvolvimento de aplicações Android.

System Apps: Na camada System App localizam-se todas as aplicações essências

que são executadas no SO, como por exemplo: calendários, navegação internet,

contactos, calculadora entre outros.

As aplicações Android são compostas por um ou mais tipos de elementos, sendo que cada

tipo executa um papel diferente no comportamento geral da aplicação. Estes elementos,

bem como os requisitos da aplicação, devem ser declarados no ficheiro -

AndroidManifest.xml.

2. Estado da Arte

13

Existem os seguintes elementos da aplicação:

Funcionalidade Classe Base Java

Focar em coisas que o utilizador pode fazer Activity

Executar processos em background Service

Receção de mensagens BroadcastReceiver

Aceder a ou fornecer dados para a aplicação. ContentProvider

Tabela 1 – Elementos da aplicação Android

A atividade (Activity) é responsável pela interface para com o utilizador; o serviço

(Service) implementa operações com execução em background; o BroadcastReceiver

responde a eventos do sistema; e o ContentProvider armazena ou fornece dados para a

aplicação.

Uma activity é um componente da aplicação que providencia uma interface gráfica de

utilizador. Uma aplicação, normalmente, consiste em várias activities. A gestão do ciclo

de vida das atividades é controlada através da implementação de métodos de retorno

(callback methods). [30] O ciclo de vida de uma activity é retratado na figura 5.

Figura 5 - Ciclo de vida de uma activity Android (Fonte: developer.android.com)

2. Estado da Arte

14

Os métodos que constituem o ciclo de vida de uma activity apresentam-se na tabela 2.

Método Descrição

onCreate() Invocado quando uma activity é iniciada.

onStart() Invocado quando a activity fica visível para o utilizador.

onResume() Invocado quando o utilizador interage com a activity.

onPause() Invocado quando outra activity está preparada a iniciar.

onStop() Invocado quando a activity deixa de ser vivível para o utilizador e uma nova

activity é iniciada.

onDestroy() Invocado quando a aplicação necessita de finalizar uma activity.

onRestart() Invocado quando a activity está a ser utilizada novamente.

Tabela 2 - Métodos da classe activity

Android Studio

O Android Studio [10] é um IDE utilizado para desenvolvimento de aplicações nativas

Android. A razão desta escolha foi devido ao facto deste IDE possuir uma interface mais

intuitiva e melhor organizada para o desenvolvimento Android.

PlayStore

A PlayStore é uma plataforma utilizada para a divulgação e distribuição de aplicações

Android. Esta plataforma será fundamental para disponibilizar a aplicação móvel Android

desenvolvida.

SQLite

O SQLite [35] é uma pequena biblioteca, desenvolvida em linguagem C, que implementa

um amplo subconjunto do standard SQL 92, sendo a sua reputação proveniente da

combinação do motor de base de dados com a interface dentro de uma única biblioteca.

O SO Android possui suporte nativo para o SQLite.

Google Maps API

O Google Maps API [17] é um serviço fornecido e desenvolvido pela Google, utilizado

para a pesquisa e visualização de mapas. Esta API utiliza JavaScript como linguagem de

programação. A utilização desta ferramenta será essencial para auxiliar os utilizadores a

2. Estado da Arte

15

identificar a localização das ocorrências com maior rigor através do mapa fornecido por

esta API.

XML

O XML [31] é uma linguagem utilizada para transferir e manipular dados através da

internet de modo fácil e consistente. A escolha desta linguagem deve-se ao facto de esta

permitir criar a nossa própria estrutura, que depois pode ser interpretada por qualquer

software, independentemente da sua formatação. Esta linguagem também foi utilizada

para criar layouts no Android Studio, e permitem definir a estrutura visual da interface da

aplicação móvel.

JSON

O JSON é um padrão utilizado para escrever estruturas de dados em JavaScript. Surgiu

em 2001, especificado e definido por Douglas Crockford, e é descrito na RFC 4627. [23]

Estrutura utilizada para transferir dados pela rede de modo fácil e consistente utilizando

poucos recursos da rede. A utilização deste tipo de formatação será necessária para

transferir dados entre o cliente e o servidor.

GeoJSON

O GeoJSON é um formato utilizado para criar estruturas de dados geográficos. O

GeoJSON deriva da estrutura JavaScript Object Notation (JSON). Um objeto GeoJSON

pode representar uma geometria, uma feature, ou uma coleção de features. Este formato

suporta os seguintes tipos de geometrias: Point, LineString, Polygon, MultiPoint,

MultiLineString e MultiPolygon. [19] A utilização deste tipo de formatação será

necessária para o uso da geometria Polygon que servirá para marcar e limitar áreas

administrativas de um determinado município com o recurso do mapa fornecido pela

Google Maps API.

GSON

2. Estado da Arte

16

O GSON [9] é uma biblioteca disponibilizada pela Google para realizar o parsing

automático do JSON. Esta biblioteca permite converter dados JSON em objetos java e

vice-versa. O GSON fornece dois métodos dos quais são:

fromJson() – Converte dados JSON em objetos Java;

toJson() – Criar uma estrutura JSON a partir de objetos Java.

A utilização desta biblioteca foi fundamental para criar uma estrutura JSON da

informação gerada pela aplicação móvel, e também para converter dados JSON gerados

pelos Web Services.

Picasso

O Picasso [36] é uma biblioteca desenvolvida pela Square, responsável por descarregar

imagens de URL´s externos e apresentar na aplicação móvel Android. Quando a aplicação

móvel necessita de descarregar alguma imagem do servidor, a libraria Picasso ficará

responsável por apresentar a respetiva imagem na aplicação. A biblioteca Picasso permite

lidar com algum tipo de constrangimento que possa acontecer até apresentar a imagem na

aplicação, como por exemplo numa falha da ligação à internet ou na transformação da

imagem.

Volley

O Volley [11] é uma biblioteca HTTP que torna a ligação à internet das aplicações

Android mais simples e mais rápida. No uso desta biblioteca é possível abstrair dos

detalhes de baixo nível (HttpUrlConnection e HttpClient) utilizados na biblioteca HTTP,

e assim realizar requests HTTP REST de forma simples. Esta biblioteca possibilita a

realização de pedidos HTTP REST assíncronos, sem que a Main Thread fique bloqueada

e interfira negativamente na user experience.

Classe Descrição

JsonObjectRequest Utilizado para enviar e receber objetos em estrutura JSON do servidor.

JsonArrayRequest Utilizado para enviar e receber arrays em estrutura JSON do servidor.

StringResquest Utilizado para enviar e receber strings em estrutura JSON do servidor.

Tabela 3 - Classes Volley HTTP - Requests

2. Estado da Arte

17

A tabela 3 representa as classes que a biblioteca Volley fornece para a realização de

pedidos HTTP assíncronos.

Para utilizar o Volley é necessário criar RequestQueue e passar um Request dos requests

representados na tabela 3. O RequestQueue administra threads para executar operações

de rede. A biblioteca Volley trabalha com três diferentes níveis, e cada nível opera a sua

respetiva thread.

Main Thread;

Cache Thread;

Network Thread;

Na main thread é feito o pedido (request) e fornecida a resposta desse pedido. O Volley

efetua a gestão automática das transações HTTP e dos erros da rede. Quando é efetuado

um pedido, o Volley verifica se o pedido pode ser tratado na cache thread. Se o pedido

puder ser tratado a partir desta, a resposta é tratada nesta thread e é entregue novamente

a main thread. Se o pedido não puder ser tratado na cache thread, é então colocado na

queue de rede. A primeira network thread disponível trata do pedido, ao realizar a

transação HTTP e fornece assim a resposta à cache e posteriormente envia a resposta do

pedido para a main thread para entrega.

Figura 6 - Ciclo de vida de um pedido (Fonte: developer.android.com)

2. Estado da Arte

18

Na figura 6 está representado o ciclo de vida de um pedido realizado através da biblioteca

Volley.

Quando a aplicação móvel necessita estar em constante contacto com a internet, será mais

eficiente usar uma única instância de RequestQueue que irá durar até ao fim do ciclo de

vida da aplicação do que instanciar RequestQueue sempre que exista a necessidade de

efetuar um pedido. A abordagem utilizada para este efeito é implementação da Singleton

Pattern representado na figura 7.

O Singleton Pattern [2] garante que a classe seja instanciada apenas uma vez, isto é, evita

que a mesma seja instanciada várias vezes e assim evita perdas de desempenho. O

construtor é privado, porque só a própria classe Singleton pode instanciar. O método

getInstance() verifica se a variável instance já foi iniciada, caso contrário, instancia

apenas uma vez. Para a troca de mensagens entre classes, devemos de chamar o método

getInstance() através da seguinte forma: Singleton.getInstance().

Nos anexos deste documento será apresentado um exemplo da classe Singleton e como

esta foi utilizada para encapsular um RequestQueue.

2.2.2 Web

Framework - Yii2

A aplicação web foi desenvolvida na linguagem PHP com recurso ao framework Yii2, na

qual se enfatiza o padrão MVC. [40] Além do MVC, esta framework possui as seguintes

entidades e características:

ActiveRecord: Facilita a criação e o uso de objetos cujos dados requerem o

Figura 7 - Singleton Pattern (Fonte: cs.unc.edu)

2. Estado da Arte

19

armazenamento persistente com a BD. O ActiveRecord, através da técnica ORM,

mapeia os objetos em tabelas da base de dados. Cada objeto é associado a uma

linha específica de uma determinada tabela da base de dados. Os atributos são

mapeados para as colunas da tabela correspondente. Ao fazer referência a um

tributo ActiveRecord torna-se equivalente ao acesso à coluna da tabela

correspondente ao registo. Esta camada é utilizada para aceder ou manipular as

informações da base de dados. Cada classe possui os métodos Create, Read,

Update e o Delete (CRUD).

Autenticação: Processo de verificação da identidade do utilizador do sistema.

Essa verificação é realizada, através do username do utilizador e um token secreto

para determinar se o utilizador tem permissões para o acesso à informação. A

autenticação é efetuada no momento em que é realizado a autenticação.

Cache: Responsável por armazenar, temporariamente, os conteúdos de uma

página. Na utilização da cache permite reduzir o tempo que seria necessário para

gerar os dados novamente. A framework possui um conjunto de ferramentas para

suportar os vários tipos de caches: Cache de Dados, Cache de Fragmento, Cache

de Página, Cache de HTTP.

Filtro de controlo de acesso: É um esquema de autorização, baseado num

conjunto de regras, no qual verifica se um utilizador tem permissões para realizar

uma ação. A autorização é dada através do nome de utilizador, do endereço de IP

e do estado da autenticação.

Web Service: É implementado através da API RESTful do framework Yii sendo

chamada através de um URL. Esse URL descreve as ações a executar presentes

na camada controller. Para facilitar a manutenção dos Web Services, estes devem

ser desenvolvidos em Modules.

Module: É uma unidade de software independente que consistem em models,

views e controllers. Quando o module pertencem à aplicação principal, este é

caraterizado como sendo uma miniaplicação.

2. Estado da Arte

20

Widgets: São componentes que consistem na criação e configuração dos

elementos da interface que serão apresentados ao utilizador. Esses elementos

podem ser, por exemplo, um widget datepicker, no qual é mostrado um calendário

para os utilizadores selecionarem uma data de forma mais rápida, fácil e

agradável.

Assets: São utilizadas para definir tudo o que complementa os conteúdos das

interfaces da aplicação (views), ou seja, os assets são recursos dos estilos, das

fontes, dos scripts, das imagens de uma página Web. O framework Yii2 já contém

alguns desses recursos, como por exemplo: jQuery, Bootstrap entre outros.

ATOM

O Atom [5] é um editor de código desenvolvido pelo Github. Esta ferramenta permite a

integração do Git Control para o controlo de versões.

XAMPP

No desenvolvimento em ambiente web foi necessário recriar um servidor web. O XAMPP

[4] foi utilizado para instalar de uma só vez o Apache, o PHP e o MySQL.

Apache (Servidor HTTP) – Servidor Web;

PHP - Linguagem usada apenas para o desenvolvimento de aplicações do

lado do servidor, capaz de gerar conteúdo dinâmico na Web.

MySQL - Servidor de Base Dados;

PhpMyAdmin – Aplicação utilizada para manipular bases de dados;

MailTrap

Servidor SMTP fictício utilizado pelas equipas de desenvolvimento para testar e

visualizar os e-mails gerados quando o sistema ainda se encontra em fase de

desenvolvimento ou em testes, sem que os verdadeiros clientes recebam os e-mails

desnecessários.

2. Estado da Arte

21

A utilização da ferramenta MailTrap será importante, pois o sistema a ser desenvolvido

irá utilizar um fluxo elevado de e-mails a cada operação realizada no sistema. Com

utilização desta ferramenta, será possível comprovar o funcionamento do fluxo de e-mail

sem o envio desnecessário destes e-mails para os futuros utilizadores do sistema. [24]

POSTMAN

O Postman é uma ferramenta utilizada criar e enviar solicitações HTTP ao servidor. Esta

ferramenta permite também consultar as respostas retornadas pelo servidor após

realização de pedidos. [29] Com a utilização desta ferramenta é possível verificar se as

respostas fornecidas pelo servidor estavam de acordo com o pedido solicitado.

2.3 Soluções Disponíveis

Em investigação sobre possíveis soluções existentes no mercado, identificaram-se quatro

aplicações que se assemelham à essência deste projeto, das quais são: 1)“A minha

Rua”[28], 2) “No meu Bairro”[8], 3) “GeoEstrela”[16] e 4) “Alerta TVedras”[37].

Estas ferramentas permitem aos cidadãos comunicar as mais variadas ocorrências

relativas a espaços públicos, através do envio fotografias do local através do

preenchimento de um formulário fornecido.

As quatro soluções encontradas apresentam várias limitações quanto à sua usabilidade e

ainda relativamente ao tipo de comunicação que utilizam para o envio das informações

relativas às ocorrências reportadas. Seguidamente, serão apresentadas as informações

sobre algumas limitações identificadas na utilização das soluções disponíveis.

“A Minha Rua”

Limitações: Esta aplicação não explora a possibilidade dos utilizadores consultarem de

forma independente os seus reportes realizados, assim como não existe a possibilidade

de consultar um mapa com a localização de todos os reportes realizados por outros

utilizadores. Não existe qualquer mecanismo de controlo para a validação dos dados

pessoais dos utilizadores e também não permite a avaliação da ocorrência resolvida.

2. Estado da Arte

22

“No Meu Bairro”

Limitações: As limitações desta solução são identificadas desde logo na utilização da

aplicação, visto que não existe qualquer tipo de informação que possa ajudar o utilizador

a categorizar de forma pormenorizada, a respetiva localização do novo reporte. Não

existem qualquer tipo de controlo de utilizadores, o que permite que qualquer utilizador

mal-intencionado possa inserir qualquer tipo de dados na aplicação. A informação

relativa a reportes já realizados é implícita, o que pode levar a vários reportes relativos

ao mesmo problema. Toda a informação e fotografias das ocorrências são fornecidas

pelos utilizadores através do e-mail.

“GeoEstrela”

Limitações: Não existe qualquer tipo de informação que possa ajudar o utilizador a

categorizar, de forma pormenorizada, o novo reporte. Toda a informação e fotografias

fornecidas pelos utilizadores relativas às ocorrências são enviados para a Junta de

Freguesia via e-mail. O mesmo meio é utilizado para notificar o utilizador sobre o estado

do reporte realizado.

“Alerta TVedras”

Limitações: Esta aplicação não explora a possibilidade dos utilizadores consultarem, de

forma independente, os reportes realizados, como também não existe a possibilidade do

utilizador ser notificado sobre as ocorrências reportadas por outros utilizadores. Não há

qualquer tipo de mecanismo de controlo para validação dos dados pessoais dos

utilizadores.

3 Modelação e Riscos do Projeto

23

Capítulo 3


A modelação é essencial em Engenharia de Software e tem como principal objetivo

especificar os requisitos que foram obtidos relativamente ao domínio estudado.

Os modelos serão representados em UML, permitindo relacionar os conceitos do sistema.

Este tipo de especificação tem como objetivo efetuar a documentação e estruturação para

uma sub-visualização e, consequentemente, uma maior compreensão lógica do

desenvolvimento completo do sistema que é pretendido implementar.

3.1 Modelo de Domínio

O modelo de domínio, apresentado na figura 8, permite descrever o vocabulário e os

conceitos do sistema obtidos através do levantamento de requisitos. O modelo de domínio

permite ter uma noção mais concreta das entidades que envolvidas ao longo do projeto.

Para tal é necessário saber numa fase inicial, quais as características das entidades que

irão ser abordas, uma vez que todos os modelos que serão desenvolvidos a partir daqui,

serão construídos e fundamentados através do modelo de domínio apresentado na figura

8. Assim, após o levantamento dos requisitos foi necessário o tratamento destes, de uma

forma exaustiva, com a finalidade de retirar o máximo de informação possível, obtendo

desta forma aquilo o essencial e abstraindo a informação desnecessária.

Através deste modelo, consegue-se efetuar a ligação entre os vários elementos do sistema,

que descrevem a estrutura da informação, as relações entre as entidades e o papel que elas

desempenham nessa relação.


24

3.2 Os interessados

As partes interessadas são das mais importantes fontes de informação para a definição

dos requisitos do sistema. Estas representam qualquer pessoa que tenha um dado tipo de

interesse legítimo no sistema. O sistema de software é desenvolvido para satisfazer as

necessidades das partes interessadas.

Cidadãos

Os cidadãos são os principais interessados no desenvolvimento desta aplicação. São

caraterizados como público-alvo para a utilização desta aplicação porque são quem tem

a iniciativa e o dever de reportar as mais variadas ocorrências relativas ao espaço e aos

equipamentos públicos no município.

Figura 8 - Modelo de domínio


25

Câmara Municipal

A Câmara Municipal apresenta um órgão executivo do município composto pelo

Presidente da Câmara e pelos vereadores. Estes órgãos executivos têm como papel

principal gerir e planificar o rumo do município.

A Câmara Municipal Vila Verde possui um conjunto de departamentos e serviços cujas

responsabilidades estão divididas da seguinte forma:

Água e Saneamento:

a. Abastecimento de Água;

b. Roturas;

c. Saneamento.

Incêndios/Proteção Civil:

a. Acidente rodoviário;

b. Queda de árvore;

c. Deslizamento de terras;

d. Inundações;

e. Propriedade degradada;

f. Incêndios.

Vias:

a. Ausência de sinalização;

b. Buraco na estrada;

c. Viaturas abandonadas

d. Passadeira pouco visível;

e. Sinalização destruída;

f. Paragens de autocarros danificadas.

Iluminação pública;

Limpeza Urbana:

a. Recolha de resíduos;

b. Recolha de monos e monstros.


26

Ambiente, espaços Verdes e floresta;

Edifícios Municipais:

a. Cemitérios;

b. Parques;

c. Escolas.

Junta de Freguesia

Local principal onde os cidadãos se deslocam para reportar as ocorrências de problemas

nas suas freguesias. O órgão executivo da Junta de Freguesia é o responsável pela

transmissão às entidades ou às empresas das ocorrências de modo a encontrar possíveis

soluções para a resolução de problemas com a maior brevidade possível.

Bombeiros Voluntários, GNR, PSP e Polícia Municipal

São as principais entidades que podem intervir na resolução de qualquer ocorrência

quando a mesma esteja a pôr em perigo os cidadãos.

Outros interessados

Existem outros possíveis interessados que poderão utilizar ou ter algum interesse na nossa

aplicação, independentemente do grau de importância, dos quais são:

Empresas de construção;

Empresas de limpeza;

Empresas de sinalização;

Bibliotecas públicas;

Escolas públicas.


27

3.3 Diagrama Casos de Uso

Os Diagramas de Casos de Uso, seguidamente apresentados, correspondem a um

conjunto de sequências de ações, incluindo cenários alternativos, que o sistema inclui,

para produzir resultados observáveis com valor para cada ator. [25] Os casos de uso

apresentados nos diagramas descrevem as funcionalidades que podem ser realizadas por

diferentes tipos de utilizadores. Para além disto, estes servem também como meio de

comunicação entre o cliente e o gestor de projeto, sendo geralmente criados após o

levantamento de requisitos e refinados ao longo do projeto.

No sistema existem utilizadores com diferentes privilégios no acesso às mais variadas

funcionalidades disponibilizadas pelo sistema. Os atores são:

Administrador;

Responsável de Departamento;

Moderador;

Utilizador (Sem privilégios):

o Anónimo;

o Autenticado.

Estes atores seguem a hierarquia representada pela figura 9.

O Administrador tem acesso a um BackOffice, no qual poderá realizar tarefas

administrativas, nas quais se incluem a gestão de contas e de privilégios dos utilizadores

e a gestão de departamentos, de entidades e de categorias. O Administrador herda as

associações do Responsável de Departamento.

Anónimo

Autenticado

Moderador

Responsável de

Departamento

Administrador

Figura 9 - Hierarquia dos atores do sistema


28

O Responsável de Departamento tem acesso às informações relativas às ocorrências

reportadas pelo cidadão e validadas pelo Moderador. O Responsável de Departamento

poderá realizar a gestão das intervenções para a resolução das ocorrências. O Responsável

de Departamento herda as associações do moderador.

O Moderador tem acesso a funcionalidades que permitem avaliar as ocorrências

reportadas pelos utilizadores do sistema. Este ator tem, como responsabilidade de avaliar

as novas ocorrências reportadas, antes destas serem encaminhadas para o respetivo

departamento. Este tem a possibilidade de criar e gerir alertas ou noticias para os

cidadãos. O Moderador herda as associações do utilizador anónimo.

O Utilizador Autenticado tem acesso a todas as funcionalidades definidas pelo sistema,

desde reportar ocorrências, consultar de ocorrências, e avaliar de ocorrências. O utilizador

autenticado herda as associações do utilizador anónimo.

O Utilizador Anónimo tem acesso a um conjunto de funcionalidades do sistema sobre

as quais não é necessário estar autenticado, nomeadamente: consultar mapa das

ocorrências e pedir informações. Caso pretenda aceder a outras funcionalidades, este

deverá registar-se e autenticar-se no sistema.

A figura 10 representa o diagrama de casos de uso do utilizador sem privilégios, desde o

registo até à autenticação no sistema.

Figura 10 - Diagrama Casos de Uso - Utilizador sem privilégios


29

A figura 11 representa o diagrama com os packages com os casos de uso dos utilizadores

com privilégios.

A figura 12 representa o package de Gestão de Ocorrências do ator “Utilizador

Autenticado”.

Figura 11 - Diagrama Casos de Uso - Utilizadores com privilégios

Figura 12 - Diagrama Casos de Uso - Gestão de Ocorrências - Utilizador Autenticado


30

A figura 13 representa o package de Gestão de Ocorrências dos atores “Moderador”,

“Responsável de Departamento” e “Administrador”.

3.4 Requisitos Funcionais

Os requisitos funcionais são afirmações que descrevem as funcionalidades a serem

fornecidas aos utilizadores do sistema, caraterizando como este deve reagir a estímulos.

No levantamento dos requisitos para o sistema foram utilizadas as seguintes técnicas:

Entrevistas: Técnica mais comum e natural de levantamento dos requisitos,

sendo geralmente de natureza informal, transformando-se numa conversa entre

duas pessoas interessadas num mesmo objetivo. As entrevistas podem ser

estruturadas ou não e, se bem concebidas, permitem recolher informação relevante

para os projetos.

Criação de personas: Antes de desenhar uma aplicação é necessário entender o

que é necessário desenvolver para satisfazer as necessidades dos utilizadores.

Assim, é possível identificar as características e funcionalidades que farão o nosso

sistema ter sucesso. As personas são pessoas fictícias consideradas potenciais

utilizadores do sistema e são representantes de grupos de utilizadores com

Figura 13 - Diagrama Casos de Uso - Gestão de Ocorrências – Utilizadores com privilégios


31

diferentes características. [13] No anexo C, podem ser consultados os perfis das

personas.

A tabela 4, representa os requisitos funcionais que definem as funções que o software

deve executar. Este tipo de requisitos são declarações/afirmações dos serviços que o

sistema disponibiliza.

Requisito Descrição

R1 O utilizador regista-se no sistema.

R2 O utilizador autentica-se no sistema.

R3 O utilizador autenticado reporta ocorrências.

R4 O utilizador autenticado acede á lista ocorrências.

R5 O utilizador autenticado segue ocorrências reportadas de outros utilizadores.

R6 O utilizador autenticado altera dados pessoais.

R7 O utilizador autenticado avalia a ocorrência.

R8 O utilizador autenticado recebe notificações sobre o estado das suas

ocorrências reportadas.

R9 O utilizador autenticado acede a lista das intervenções realizadas na

ocorrência reportada.

R10 O utilizador autenticado recebe notificações relativas a novos reportes de

ocorrências de outros utilizadores.

R11 O utilizador autenticado pesquisar ocorrências por freguesia, categoria ou

estado da ocorrência.

R12 O utilizador autenticado anunciar a localização da ocorrência por escrito,

mapa, ou por localização automática (GPS).

R13 O utilizador envia pedido de informações no âmbito da gestão de ocorrências.

R14 O utilizador autenticado consulta os dados da ocorrência através do marcador

existente no mapa.

R15 O administrador gere as contas dos utilizadores.

R16 O administrador gere privilégios dos utilizadores autenticados.

R17 O administrador gere ocorrências.

R18 O administrador recebe notificações de novas ocorrências.

R19 O administrador gere entidades, departamentos, categorias e subcategorias.

R20 O sistema notifica automaticamente a GNR, Bombeiros, PSP, Polícia

Municipal e entidades com a informação detalhada da ocorrência reportada.

R21 A entidade gere intervenções.


32

3.5 Requisitos Não-Funcionais

Os requisitos não-funcionais correspondem a propriedades e restrições impostas no

sistema desenvolvido. Os requisitos não-funcionais foram classificados da seguinte

forma: 1) Aparência, 2) Usabilidade, 3) Desempenho, 4) Operacional, 5)

Manutenibilidade e Suporte, 6) Segurança, 7) Cultural e Politico e 8) Legal.

3.5.1 Requisitos de Aparência

Estes requisitos descrevem caraterísticas relacionadas com o aspeto visual e estético do

produto.

R22 O moderador avalia ocorrências reportadas pelos utilizadores.

R23 O moderador gere alertas/notícias.

R24 O moderador envia e-mail ao utilizador que reportou ocorrência.

R25 O responsável de departamento gere intervenções para a resolução da

ocorrência.

R26 O responsável de departamento encaminha a ocorrência para outro

departamento.

R27 O responsável de departamento é notificado por correio eletrónico de novas

ocorrências.

Tabela 4 - Requisitos Funcionais

Tabela 5 - Requisitos de Aparência


R28 O sistema deve ser atrativo para todas as faixas etárias

R29 O sistema mostra todos os marcadores num mapa relativos às ocorrências

reportadas.

R30 Os marcadores das ocorrências devem ser classificados de acordo com o

seu estado.

R31 Os marcadores do mapa das ocorrências com o estado “Finalizado” devem

tornar-se inviáveis após serem avaliadas com nota positiva.

R32 A lista das ocorrências deve apresentar cores diferentes para cada estado da

ocorrência.


33

3.5.2 Requisitos de Usabilidade

Estes requisitos definem a facilidade de utilização do produto e tudo o que este permite

para uma utilização mais agradável.

3.5.3 Requisitos de Desempenho

Estes requisitos referem-se à capacidade de o sistema responder a estímulos, isto é, o

tempo necessário para responder a eventos por unidade de tempo. Estes requisitos

retratam questões de rapidez, de capacidade de armazenamento e de correção de

execução.


R37 O tempo de resposta do sistema deve ser no máximo de 2 segundos.

R38 O sistema deve possuir um grau de disponibilidade elevado.

Tabela 7 - Requisitos de Desempenho

3.5.4 Requisitos Operacionais

Os requisitos operacionais definem aspetos que o produto deve fazer para funcionar

corretamente.


R33 Navegação fácil entre ocorrências.

R34 Interface apelativo ao utilizador.

R35 A interface dimensionada de acordo com o tamanho do ecrã do dispositivo.

R36 Deve ser fácil aprender a utilizar o sistema após ler tutorial de utilização.

Tabela 6 - Requisitos de Usabilidade


R39 Aplicação móvel a funcionar nas versões mais recentes Android.

R40 Aplicação web a funcionar nas versões mais recentes do Firefox, Google Chrome

e Internet Explorer.

Tabela 8 - Requisitos Operacionais


34

3.5.5 Requisitos de Manutenibilidade e Suporte

Estes requisitos definem o tipo de atributos que permitem que o produto seja reparado,

melhorado ou estendido.

3.5.6 Requisitos de Segurança

Estes requisitos referem-se à habilidade do sistema resistir a acessos não autorizados e

continuar a providenciar todos os serviços do sistema aos utilizadores autenticados.

3.5.7 Requisitos Culturais e Políticos

Estes requisitos referem-se a fatores relacionados com a cultura e os hábitos das partes

interessadas.


R41 Adaptação a novas necessidades de negócio

R42 Caso existam falhas no sistema, estas devem ser corrigidas num dia.

Tabela 9 - Requisitos de Manutenibilidade e Suporte


R43 Aplicação deve garantir que somente os utilizadores autenticados e autorizados

podem reportar novas ocorrências.

R44 Proteger a informação pessoal e credenciais dos utilizadores

R45 Evitar a criação de multi-contas.

R46 O utilizador confirma o sua conta por e-mail.

R47 Evitar a autenticação dos utilizadores bloqueados.

Tabela 10 - Requisitos de Segurança


R48 O produto deve usar a ortografia multi-língua.

Tabela 11 - Requisitos Culturais e Políticos


35

3.5.8 Requisitos Legais

Estes requisitos referem-se a fatores relacionados com leis, regras e normas que devem

ser aplicadas ao produto.

3.6 Descrição dos Requisitos

Na descrição dos requisitos foram desenvolvidos cartões de Volere. Todos os cartões

desenvolvidos podem ser consultados no Anexo A. Neste modelo é apresentada, no canto

superior direito, a letra correspondente à prioridade de implementação do requisito. Para

esse efeito foram consideradas técnicas de priorização de agrupamento que consistem em

distribuir os requisitos por diferentes grupos.

3.6.1 MoSCoW

O método de MoSCoW sugere quatro grupos que se classificam segundo a seguinte escala:

1) Must, 2) Should, 3) Could e 4) Won’t. [22] A figura 14 ilustra o método MoSCoW.


R49 O sistema deve autenticar todos os dados do utilizador

Tabela 12 - Requisitos Legais

Figura 14 – Método MoSCoW


36

Ao aplicar esta técnica, deve-se evitar que as partes interessadas classifiquem a maioria

dos requisitos como Must, pois invalidaria o efeito pretendido do uso deste método. Para

evitar desigualdades no número de requisitos entre os grupos, a solução foi aplicar

percentagens mínimas obrigatórias por grupo e, assim, obrigar as partes interessadas a

classificarem os requisitos com maior rigor. [21][13]

3.6.2 Top 10

Nesta técnica, cada parte interessada escolhe, a partir de um conjunto de requisitos

candidatos, os seus dez prioritários. Esta técnica foi utilizada devido ao número elevado

de partes interessadas. [13]

Na tabela 13 está representada a lista dos dez requisitos mais votados. Assim sendo, o

top-10 deste projeto ficou definido com a seguinte classificação:

Prioridade Requisito Nº

1º O utilizador regista-se no sistema 1

2º O utilizador confirma a sua conta por e-mail. 46

3º O utilizador autentica-se no sistema 2

3º O utilizador autenticado reporta ocorrências relativas a espaços

públicos.

3

4º O administrador pode gerir privilégios dos utilizadores autenticados. 16

5º O moderador avalia ocorrências reportadas pelos utilizadores. 22

6º O responsável de departamento gere intervenções para a resolução da

ocorrência.

25

7º O utilizador autenticado tem acesso á lista ocorrências. 4

8º O utilizador autenticado recebe notificações sobre as suas ocorrências

reportadas.

8

9º O administrador gere entidades, departamentos, categorias e

subcategorias.

19

10º A entidade gere intervenções. 21

Tabela 13 - Top-10


37

3.7 Diagrama de Estados

O Diagrama de Estados serve para especificar o comportamento de uma entidade ou

mostrar os vários estados pelos quais a mesma transita ao longo da sua vida. [25][14]

Neste projeto foram desenvolvidos dois diagramas de estados, um para a ocorrência e

outro para o utilizador.

3.7.1 Ocorrência

A ocorrência durante o seu ciclo de vida pode passar por oito estados diferentes, entre

eles:

Não Avaliada – Nova ocorrência reportada por um utilizador autenticado;

Aguardar Análise – Ocorrência validada ou ocorrência com avaliação negativa;

Pendente – Ocorrência com informação inválida ou incompleta;

Em Análise – Ocorrência em análise;

Em Execução – Ocorrência com intervenções a decorrer;

Cancelada – Ocorrência fictícia;

Concluída – Ocorrência concluída;

Oculta – Ocorrência avaliada com nota positiva pelo utilizador que a reportou.

A figura 15 representa o digrama de estados da ocorrência.


38

Quando o cidadão ao reporta uma nova ocorrência, esta encontrar-se-á no estado inicial -

Não Avaliada. Enquanto permanecer neste estado, o utilizador poderá editar os dados

fornecidos inicialmente.

O Moderador tem como responsabilidade verificar se as ocorrências reportadas pelos

cidadãos são válidas e pode consultar a lista das novas ocorrências. Poderá mudar o estado

das mesmas para Aguardar Análise, se ocorrência seja válida, ou para o estado

Pendente, caso a informação fornecida sobre a ocorrência seja inválida ou esteja

incompleta. O utilizador só pode editar as informações fornecidas se a ocorrência estiver

no estado Não Avaliada ou Pendente.

Quando a ocorrência se encontra no estado Pendente, o utilizador que fez participação

da ocorrência poderá realizar alterações na informação fornecida inicialmente. Caso o

utilizador realize as alterações necessárias, a ocorrência passará novamente para o estado

Não Avaliada, caso contrário a ocorrência passará para o estado Cancelada. Todas as

Figura 15 - Diagrama de estados - Ocorrência


39

ocorrências com estado Aguardar Análise, são encaminhas para o departamento

correspondente à categoria a que a ocorrência pertence.

O departamento responsável pela ocorrência pode alterar para o estado da mesma para

Em Análise, caso exista a necessidade de realizar um estudo de viabilidade. O

departamento responsável pela ocorrência pode adicionar intervenções para proceder à

resolução da mesma. Ao adicionar intervenções, o estado da ocorrência passa

automaticamente para Em Execução, se por sua vez o departamento rejeitar e determinar

que a ocorrência é inválida, poderá rejeitar a ocorrência e esta passará para o estado

Cancelada.

Quando são finalizados os trabalhos para a resolução da ocorrência apresentada, o

departamento responsável poderá alterar o estado da mesma para o estado Finalizado.

Quando a ocorrência passa para o estado Finalizado, o utilizado que reportou a

ocorrência tem a possibilidade de avaliar a mesmo de modo a obter feedback. Se avaliação

realizada pelo utilizado for negativa, a mesma passa automaticamente para o estado Não

Avaliada, caso contrário, a avaliação passará para o estado Oculta.

3.7.2 Utilizador

Os estados pelos quais passa um utilizador após o registo no sistema são: 1) Pendente,

2) Ativo, 3) Desativado e 4) Removido. A figura 16 representa o diagrama de estados

do utilizador.


40

O primeiro estado que um utilizador registado no sistema passa é o de Pendente. Este

estado traduz o facto de o novo utilizador ainda não ter realizado a verificação por correio

eletrónico para poder validar a sua conta e assim ter acesso às funcionalidades do sistema.

Quando o utilizador realiza a sua verificação por correio eletrónico, o estado do seu

registo passa a Ativo. O utilizador com estado Ativo pode ter acesso a todas as

funcionalidades do sistema de acordo com as permissões atribuídas.

É atribuído o estado Desativado, quando o Administrador, por algum motivo de

incumprimento de certa(s) regra(s), decidir suspender o utilizador.

Uma vez eliminada a conta de utilizador, o estado deste passa a estado Removido, sendo

este o ultimo estado no ciclo de vida de um utilizador do sistema.

Figura 16 - Diagrama de estados - Utilizador


41

3.8 Diagrama de Atividades

O Diagrama de Atividades servirá para modelar o comportamento do sistema, incluindo

a sequência e as condições de execução de ações. Este tipo de diagrama permite demostrar

o fluxo de controlo entre atividades dum determinado processo. [25][14]

3.8.1 Nova Ocorrência

Quando um utilizador autenticado no sistema pretende participar uma ocorrência, pode

realiza-lo através de um formulário de inserção para reportar a nova ocorrência. O

conjunto de ações a serem realizadas no sistema até que uma ocorrência seja validada

estão representadas pela figura 17.

O cidadão Reporta Ocorrência no sistema e aguarda a validação do Moderador. O

Moderador Analisa Ocorrência, e caso existam informações suscetíveis de criar

suspeitas do utilizador por não serem fidedignas ou pela falta de dados, o Moderador

altera o estado da ocorrência de modo a permitir que o cidadão possa proceder as devidas

alterações (Altera Informação da Ocorrência). No caso da não existência de

Figura 17 - Diagrama de atividades - Reportar ocorrência


42

incoerências nas informações fornecidas para a participação da ocorrência, o Moderador

aceita-a e a esta é encaminhada para o departamento responsável pela mesma.

3.8.2 Gestão de Ocorrências

Todas as ocorrências que são avaliadas e validadas pelo Moderador são encaminhadas

para o departamento responsável pela sua natureza. O conjunto de ações a serem

realizadas no sistema até que uma ocorrência seja resolvida estão representadas pela

figura 18.

O Responsável Departamento Analisa Ocorrência, caso exista a necessidade de realizar

um estudo de viabilidade. Após esta análise, o responsável pelo departamento pode

rejeitar ao Cancelar Ocorrência ou pode aceitar ocorrência ao Criar Nova Intervenção.

O Responsável Departamento pode criar várias intervenções até que a ocorrência esteja

Figura 18 - Diagrama de atividades - Gestão de ocorrência


43

resolvida. Neste caso, a entidade selecionada que ficará responsável pela intervenção,

Recebe Informação da Ocorrência. Quando a ocorrência estiver resolvida, a entidade

Notifica Resolução da Ocorrência para que o departamento mude o estado da ocorrência

(Altera o estado da ocorrência).

3.8.3 Avaliação de Ocorrências

A figura 19 representa o diagrama de atividades para a avaliação de ocorrências.

O cidadão que reportou a ocorrência pode Avaliar Ocorrência quando a mesma estiver

no estado “Finalizada”. Se o cidadão avaliar a ocorrência negativamente, a ocorrência

será encaminhada novamente para o departamento para que seja feita uma nova análise

(Analisa Ocorrência).

3.8.4 Privilégios de Utilizadores do Sistema

Figura 19 - Diagrama de atividades - Avaliação de ocorrências


44

A figura 20 representa o diagrama de atividades para atribuição de privilégios a

utilizadores.

O utilizador que se regista pela primeira vez no sistema possui o privilégio de “Cidadão”

por padrão. Por sua vez, o utilizador que possui o privilégio de “Administrador” tem a

possibilidade de gerir privilégios de outros utilizadores que estão registados no sistema.

No ato de atribuição de privilégios a utilizadores, são definidas responsabilidades para

cada tipo de utilizador que está registado no sistema. O conjunto das ações a serem

realizadas no sistema, até que sejam atribuídos privilégios aos utilizadores são

apresentadas de seguida através do diagrama de atividades.

No momento em que o cidadão faz “Criar Conta”, é gerado e enviado um e-mail para o

utilizador para que o mesmo confirme o seu e-mail (Confirma E-mail). O Administrador,

através da lista dos utilizadores que estão registados no sistema, pode selecionar um

determinado utilizador com estado ativo e atribuir privilégios (Atribui Privilégios) de

Moderador ou Responsável de Departamento. Nesta atribuição, o administrador terá de

selecionar o departamento a que este pertence ou pertencerá. Após atribuição de

Figura 20 - Diagrama de atividades - Gerir privilégios de utilizadores


45

privilégios, o utilizador cujos privilégios lhe foram atribuídos, receberá um e-mail a

informar os privilégios que o mesmo tem sobre o sistema.

3.9 Diagrama de Sequências

O Diagrama de Sequências serve para relevar como as várias entidades colaboram, dando

enfase ao fluxo de controlo e de dados entre eles. Através do diagrama de sequências é

possível representar as mensagens trocadas entre vários objetos num determinado

contexto. [25][14]

3.9.1 Nova Ocorrência

Como é possível observar na figura 21, o utilizador ao entrar na aplicação e após efetuar

o login, tem a possibilidade de reportar ocorrências relativas a espaços públicos,

selecionando a opção “Reportar Ocorrência”. Após esta seleção, será apresentado um

formulário que terá de ser preenchido, obrigatoriamente, com os dados relativos à

situação a apresentar. Juntamente com os dados fornecidos, o utilizador terá de anexar

Figura 21 - Diagrama de sequência - Reportar ocorrência


46

fotografias da ocorrência, para que seja feita uma melhor apreciação da mesma. Após o

preenchimento do formulário, o utilizador pode submeter a participação e receberá uma

notificação de confirmação de envio no seu e-mail.

3.9.2 Nova Intervenção

Como é possível observar na figura 22, o Responsável de Departamento tem acesso à lista

das ocorrências que foram avaliadas e validadas pelo Moderador. A todas as ocorrências

que constem nesta lista podem ser adicionadas novas intervenções para que as ocorrências

possam ser resolvidas. O Responsável Departamento pode encaminhar os reportes de

ocorrências para outros departamentos. O Responsável de Departamento ao adicionar

uma nova intervenção terá de selecionar a entidade que ficará responsável por intervir na

resolução da ocorrência. Este último procedimento pode ser repetido as vezes que forem

necessárias até que a ocorrência seja definitivamente resolvida.

Figura 22 - Diagrama de sequências - Nova intervenção


47

3.10 Modelo Entidade Relação

No desenvolvimento deste projeto foi necessária a criação de diferentes Modelos

Entidade Relação para cada aplicação desenvolvida. Neste caso foi desenvolvido um

modelo para a aplicação móvel e outro para a aplicação web.

3.10.1 Móvel - SQLite

A figura 23 apresenta as principais entidades e respetivas relações que foram utilizadas

para armazenamento de dados na aplicação móvel Android. Este armazenamento de

dados garante a persistência dos dados na aplicação. O SQLite foi o SGBD utilizado.

A tabela 14 contém a descrição do modelo entidade relação da aplicação móvel.

Entidade Descrição

occurrence Guarda os dados da ocorrência.

user Guarda os dados do utilizador.

subcategory Guarda o nome das subcategorias.

category Guarda o nome das categorias.

location Guarda a localização da ocorrência.

Tabela 14 - Entidade-Relação - SQLite

Figura 23 - Modelo Entidade Relação - Android


48

3.10.2 Web – MySQL

A figura 24 apresenta as principais entidades e as respetivas relações que foram utilizadas

para o armazenamento de dados da aplicação Web. O MySql foi o SGBD utilizado.

Utilizou-se, a tabela 15, para realizar a descrição do modelo entidade relação da aplicação

web.

Entidade Descrição

ocorrencia Guarda os dados da ocorrência.

utilizador Guarda os dados do utilizador.

estado Guarda o estado da ocorrência.

subcategoria Guarda o nome das subcategorias.

categoria Guarda o nome das categorias.

localização Guarda a localização da ocorrência.

tipo_utilizador Guarda os dados dos tipos de utilizadores do sistema.

dados_ocorrencia Guarda o caminho das fotografias da ocorrência.

intervencao_ocorrencia Guarda os dados das intervenções realizadas.

noticias Guarda os dados das notícias criadas.

municipio Guarda os dados do município.

freguesia Guarda os dados das freguesias do município.

marcadores Guarda informação dos ícones dos diferentes tipos de estado da

ocorrência.

avaliacao Guarda os dados da avaliação realizada à ocorrência.

entidade Guarda os dados da entidade.

departamento Guarda o nome do departamento.

contato Guarda os contatos das entidades.

tipo_contacto Guarda os dados do tipo de contato das entidades.

autor_tarefa Guarda os dados da atribuição das funcionalidades para

diferentes utilizadores.

autor_item Guarda os dados das funcionalidades que o utilizador pode

realizar no sistema.

Tabela 15 - Entidade-Relação - MySQL


49

Figura 24 – Modelo Entidade Relação - Web


50

3.11 Riscos

As circunstâncias potencialmente adversas que podem ter impacto negativo sobre a

qualidade do software final são chamadas de riscos. Na tabela 16 está representada a

descrição dos riscos associados ao projeto desenvolvido.

Risco Descrição

1 Má adesão por parte dos utilizadores à aplicação.

2 As ocorrências reportadas não serem enviados por falta de acesso a internet.

3 A informação das ocorrências conterem informação insuficiente.

4 Localização da ocorrência inserida incorretamente.

5 Um utilizador bloqueado tenta criar outra conta.

6 O utilizador reportar situações que não são do âmbito da aplicação.

7 Os detalhes da ocorrência da ocorrência serem diferentes da realidade.

8 Existir alguma avaria no servidor de armazenamento de dados.

9 Algum dos elementos da equipa abandonar o projeto.

10 Os utilizadores acharem a interface difícil de utilizar.

11 Existir roubo dos dados dos utilizadores.

12 Falta de investimento para a progressão do projeto.

Tabela 16 – Descrição dos riscos

Para cada risco anteriormente identificado, foi estimada a probabilidade e o impacto

associado. No anexo B, pode ser consultada a categorização e as técnicas para a mitigação

dos riscos associados ao projeto.

4 Trabalho Desenvolvido

51

Capítulo 4

4 Trabalho Desenvolvimento

Este projeto de dissertação, tal como já vem sido referenciado, tem como objetivo

desenvolver uma plataforma que permita reportar, monitorizar e gerir ocorrências

relativas a espaços públicos. Neste capítulo serão abordados temas relacionados com o

sistema que foi desenvolvido.

4.1 Padrão de Arquitetura de Software

A escolha da arquitetura a utilizar para o desenvolvimento das aplicações foi uma das

decisões mais importantes a tomar uma vez que esta irá influenciar não só a qualidade da

aplicação ao longo do tempo, mas também reduzir o tempo de desenvolvimento e de

manutenção da mesma.

MVC

O MVC (Model-View-Controller), representado pela figura 25, é um padrão de

arquitetura de software que separa a representação da informação da interação do

utilizador. Este padrão estrutura a aplicação em três componentes lógicos, ou seja, separa

a componente dados e regras de negócio (Model) da componente interface do utilizador

(View) usando um terceiro componente, controlador (Controller), que servirá de

intermediário entre as duas primeiras. [15]


52

O padrão MVC foi adotado no desenvolvimento das aplicações, mas existiu a necessidade

de ser readaptado no decorrer da construção da aplicação móvel, pois o Android fornece

um padrão MVC de forma rudimentar. Na adaptação do MVC ao Android foi necessário

dividir a estrutura do código de modo a respeitar o padrão MVC. Destacam-se as

seguintes:

View: A View é constituída por ficheiros em formato XML, responsáveis por

apresentar os layouts nos dispositivos móveis. Através destes layouts o utilizador

pode interagir com a aplicação.

Model: O Model representa os dados da organização e das regras de negócio.

Controller: O Controller é responsável por disponibilizar os dados do Model para

a View. As activities são as classes responsáveis pela comunicação que é realizada

entre a view com o model.

4.2 Aplicação Móvel

A aplicação móvel desenvolvida tem como objetivo facilitar a tarefa de reportar as

ocorrências de forma mais eficiente no fornecimento da informação relativa à localização

da ocorrência, uma vez que esta pode ser obtida automaticamente na utilização do GPS

do smartphone ou tablet.

Figura 25 – MVC (Fonte: codeproject.com)


53

O utilizador, quando confrontado com algum problema relativo à via pública, pode

participar a ocorrência através da aplicação móvel, caso o seu dispositivo se encontre com

ligação à internet.

Ao iniciar a aplicação, surgirá uma janela inicial de apresentação da aplicação. Esta janela

inicial será mantida enquanto a aplicação, em background, está a realizar algum tipo de

atualização dos dados relativos às ocorrências do município. Este processo inicial de

sincronização é realizado através de solicitações HTTP efetuadas pela aplicação móvel

ao servidor Web. Após finalizada a sincronização, surgirá a janela principal da aplicação

com o mapa, fornecido através da API da Google Maps. Este layout contém, não só as

áreas administrativas do município, mas também todos os marcadores que representam

as ocorrências reportadas.

Na figura 26 está representada a janela, na qual é possível ter acesso às funções principais

que a aplicação disponibiliza, como por exemplo:

Reportar Ocorrência;

Meus Reportes;

Avisos/Alertas;

Dados Pessoais;

Figura 26 - Ocorrências - Marcadores


54

Todas estas funções acima mencionadas, só poderão ser executadas se o utilizador estiver

autenticado na aplicação. Caso contrário, surgirá um aviso para a necessidade de o fazer

antes de realizar qualquer tipo de operação.

A autenticação dos utilizadores na aplicação funciona de forma similar a tantas outras

aplicações móveis existentes. O utilizador tem a possibilidade de realizar a autenticação

através da Google+, Facebook ou através do servidor. Na realização da autenticação

através das redes sociais, o utilizador terá de autorizar que a nossa aplicação possa aceder

à informação utilizada para o acesso das mesmas (ver figura 30).

Figura 30 - Permitir verificar as informações

Figura 29 - Navegação Lateral Figura 28 - Login Figura 27 - Notificação - Realizar Login


55

A autenticação pelo servidor é realizada através do preenchimento dos campos

obrigatórios fornecidos pela aplicação. A partir do momento em que a autenticação é

realizada com sucesso, o utilizador pode executar todas as funcionalidades fornecidas

pela aplicação.

No menu lateral da aplicação, estão presentes os dados do utilizador, nomeadamente a

fotografia, o username e o e-mail do utilizador para se efetuar a autenticação na aplicação

móvel.

O utilizador pode reportar uma ocorrência ao selecionar a opção para o efeito. Quando

selecionada surgirá uma janela com o formulário, de preenchimento obrigatório, no qual

o utilizador pode fornecer a informação relativa à ocorrência que pretende reportar. Neste

formulário, o utilizador deve carregar uma fotografia do local da ocorrência e, para tal,

basta ir ao ícone da câmara fotográfica (ver figura 32) e seguidamente a opção para

adicionar a fotografia. O utilizador pode escolher uma foto a partir da galeria de

fotografias ou pode adicionar uma nova fotografia retirada pela câmara fotográfica do

dispositivo.

Figura 33 - Tirar Foto Figura 34 - Nova Ocorrência Figura 32 - Adicionar foto

Figura 31 - Menu lateral - Dados do utilizador


56

Após completada esta etapa, o utilizador pode selecionar a categoria e a subcategoria de

forma a categorizar a ocorrência. Para uma melhor apreciação desta por parte dos serviços

administrativos da Câmara Municipal, o utilizador deve acrescentar uma pequena

descrição da mesma. O utilizador tem ao seu dispor duas opções para fornecer a

localização da ocorrência, nomeadamente através do GPS do dispositivo, onde são

recolhidas a automaticamente as coordenadas GPS (latitude e longitude) do local onde

está o dispositivo móvel, ou através do marcador na utilização da API GMaps. O mapa

da Google Maps pode ser utilizado para indicar o local da ocorrência através do arrastar

do marcador fornecido ou através da descrição da morada da rua onde a ocorrência se

encontra. Na figura seguinte é possível ver exemplos da aplicação móvel no fornecimento

da informação relativa à localização da ocorrência. Na primeira janela, é apresentado um

alerta a informar que a aplicação está a obter a localização do dispositivo. Quando

terminado este processo serão apresentados os valores da latitude e da longitude no

formulário da ocorrência. Na segunda janela, o utilizador poderá indicar com auxílio do

mapa, a localização da ocorrência. Na terceira janela, o utilizador poderá indicar a

localização da ocorrência ao preencher o campo acima e, automaticamente, surgirá o

marcador na localização fornecida.

Após a obtenção dos dados da localização da ocorrência, o utilizador poderá submeter a

sua participação, caso não haja nenhum constrangimento, surgirá um aviso de sucesso.

Os dados da participação são enviados para o servidor web, no qual, posteriormente, são

Figura 35 - Localização - GPS Figura 36 - Localização - GMaps Figura 37 - Preenchimento manual


57

analisados pelos serviços da Câmara Municipal. Este processo de envio dos dados da

participação é realizado através do uso do método POST do protocolo HTTP feito pela

aplicação móvel REST.

Como referido anteriormente, o utilizador que pretenda ter acesso às principais

funcionalidades da aplicação móvel, necessita de estar autenticado. Para evitar que o

utilizador realize o processo de autenticação todas as vezes que acede à aplicação, foi

necessário utilizar a biblioteca SharedPreferences com intuito de guardar os dados

persistentes da aplicação, nomeadamente, as credenciais de acesso à aplicação. A

utilização desta biblioteca permite manter os dados da sessão mesmo ao fechar a

aplicação. Assim, quando o utilizador efetuar a autenticação na aplicação, não tem

necessidade de voltar a repetir o mesmo procedimento de autenticação. Quando o

utilizador pretender terminar sessão ou iniciar sessão com outras credenciais, basta

escolher a opção “Sair” e surgirá automaticamente a layout “Login”.

Na aplicação, o utilizador tem a possibilidade de gerir as ocorrências reportadas e pode

consulta-las e verificar o seu estado através da lista fornecida.

Selecionada uma ocorrência que esteja na lista, surgirá um novo layout com o mapa e o

respetivo marcador que representa a ocorrência. Neste o marcador, pode ser consultada a

informação relativa à ocorrência reportada.

Figura 38 - Lista de ocorrências reportadas Figura 39 - Lista de ocorrências - Estados


58

De modo a obter a informação relativa às ocorrências foi necessário utilizar a biblioteca

Volley para realizar solicitações ao servidor. Para o retorno da resposta JSON, foi

utilizada a biblioteca GSON para realizar o parsing e assim apresentar a informação das

ocorrências. A biblioteca Picasso serviu não só para descarregar a imagem para o layout,

mas também para redimensionar a imagem.

Na utilização da aplicação, se o dispositivo perder a ligação à internet, surgirá um aviso

a informar o utilizador “Não foi possível estabelecer a ligação” (ver figura 40).

4.3 Aplicação Web

A aplicação web integra uma GUI cujo objetivo é fornecer uma plataforma prática na

qual o utilizador pode utilizar e interagir com o sistema. Na utilização desta plataforma

qualquer utilizador pode gerir ou monitorizar ocorrências relativas a espaços ou

equipamentos públicos.

A arquitetura da aplicação web representada na figura 41, apresenta-se dividida em

responsabilidades distintas para cada entidade, isto é, o cliente interage com o servidor ao

solicitar informações através de HTTP Requests, enquanto o servidor, software

responsável por aceitar os pedidos HTTP de clientes, geralmente web browsers, interpreta

Figura 40 - Sem ligação à internet


59

os pedidos recebidos e devolve-os através de HTTP Responses. Estas entidades que

constituem a arquitetura da aplicação web utilizam recursos da rede para realizarem a

comunicação entre si.

O servidor web, não tem capacidade para gerar páginas dinâmicas ou para gerir dados da

BD quando recebe pedidos de clientes. Assim, quando o utilizador acede a uma página

web através de um web browser, este último envia um pedido HTTP ao servidor, mas,

por sua vez, este necessita de executar a aplicação web para processar os pedidos e assim

devolver a respostas aos clientes de acordo a com a solicitação efetuada.

4.3.1 Estrutura da Aplicação Web

No desenvolvimento da aplicação web, foi utilizada a framework Yii2 advanced. Esta

framework enfatiza a utilização do padrão de arquitetura MVC. A estrutura do diretório

da aplicação web será apresentada na tabela 17. [40]

Figura 41 - Arquitetura de uma aplicação web


60

Estrutura do diretório

common config/ Configurações partilhadas;

mail/ Ficheiros de visualização para e-mails;

models/ Classes models utilizados no back-end e front-end;

console config/ Configurações da consola;

controllers/ Controladores da consola;

migrations/ Migrações da base de dados;

models/ Classes dos models da consola;

runtime/ Ficheiros gerados durante a execução;

back-end assets/ Ficheiros que ajudaram a melhorar a view, como é o caso do

Javascript e CSS;

config/ Configurações de back-end;

controllers/ Classes do controller;

models/ Classes dos models do back-end;


views/ Ficheiros de visualização da aplicação de back-end;

web/ Ficheiros de scripts e recursos da entrada da aplicação de back-

end;

front-end assets/ Ficheiros para visualização, como Javascript e CSS;

config/ Configurações do front-end;

controllers/ Classes do controller;

models/ Classes dos models do front-end;


views/ Ficheiros de visualização da aplicação de front-end;

web/ Ficheiros de scripts e recursos da entrada da aplicação;

widgets/ Widgets para visualização da aplicação;

Tabela 17 - Estrutura da framework Yii2

4.3.2 Controlo de Acesso ao Sistema

Na existência de atribuição de responsabilidades para alguns utilizadores do sistema,

tornou-se necessário recorrer a métodos que permitissem controlar o acesso distinto de

acordo com tipo de responsabilidades atribuídas aos diferentes tipos de utilizadores do

sistema. A utilização destes métodos, permite verificar se um determinado utilizador tem

permissão para visualizar ou executar alguma ação no sistema.


61

A framework Yii utilizada para desenvolvimento da aplicação web, fornece dois métodos

de autorização para o acesso diferenciado para cada tipo de utilizador, designadamente:

[40]

ACF;

RBAC;

O método ACF foi utilizado como filtro simples para restringir o acesso a alguns

utilizadores na realização de determinadas ações no sistema, de acordo com a lista de

regras definida para cada tipo de utilizador. A lista de regras de acesso determina se o

utilizador tem, ou não, autorização para executar a ação que solicitou.

Através da figura 42 é possível verificar como o ACF foi utilizado num controlador da

aplicação Web. Neste controlador estão as principais ações para realizar o “Login”,

“Logout” e “Signup”. Para a execução destas ações, serão aplicadas regras de ACF uma

vez que estas estão contidas na opção “Only”. Todas as outras ações que estejam no

controlador, mas não na opção “Only”, não serão aplicadas as regras do método ACF. Na

Figura 42 - Exemplo da utilização da classe AccessControl (Fonte: yiiframework.com)


62

opção “Rules” contém a lista de regras de acesso, onde são definidas quais as ações que

um determinado tipo de utilizador pode executar. No código acima, só os utilizadores não

autenticados, representados pelo símbolo “?”, podem executar as ações de “Login” e

“Signup”. Os utilizadores autenticados, representados pelo símbolo “@”, podem executar

a ação “Logout”. O valor que a opção “allow” pode ter, “true” ou “false”, irá determinar

se o utilizador tem autorização ou não para executar as ações que estão na opção

“actions”.

Quando o ACF determina que um utilizador não tem autorização para executar uma ação

que não lhe foi determinada a executar, são realizadas as seguintes medidas para o

utilizador anónimo ou para utilizador autenticado:

Se o utilizador for anónimo, será redirecionado para a página do login;

Se o utilizador está autenticado no sistema, surgirá uma notificação a informar

que lhe foi negado o acesso;

Devido à complexidade do sistema e à exigência da utilização de um número significativo

de diferentes tipos de utilizadores, foi necessário aplicar novas regras de controlo de

acesso a outras ações de outros controladores do sistema que não se baseiem, apenas no

utilizador autenticado ou não autenticado, mas também, a utilizadores que possuem

responsabilidades distintas sobre sistema. De modo responder a esta necessidade adotou-

se o método SRBA que serve como extensão ao método ACF, ou seja, aplicou-se o

método que permitiu acrescentar novas regras para os seguintes tipos de utilizadores do

sistema:

Utilizador Autenticado;

Moderador;


Administrador;

Cada tipo de utilizador acima referido possui responsabilidades bem definidas e

representam as ações que cada tipo de utilizador pode executar no sistema.


63

O método SRBA controla se um tipo de utilizador que esteja a operar o sistema está

autorizado a executar uma determinada ação. No caso de não estar autorizado, será

aplicado a medida preventiva, de modo a evitar que a mesma ação seja executada. Quando

o tipo de utilizador não está autorizado a executar uma determinada ação, surgirá o erro

HTTP “403 Forbidden” enviado pelo servidor web a informar que o utilizador não tem

permissão para o fazer.

O administrador é um tipo de utilizador que possui permissões para gerir os privilégios

de cada tipo de utilizador do sistema, ou seja, quando o administrador aplica uma regra a

um determinado utilizador, este ao utilizar sistema, o método SRBA irá determinar se o

mesmo tem autorização para executar as ações pretendidas. Para administrador possuir

este tipo de privilégio de atribuição de regras, também a ele lhe foi atribuído a regra de

“Administrador”, mas neste caso, teve de ser aplicado manualmente na base dados.

4.3.3 Utilizador Autenticado

O sistema disponibiliza um conjunto de funcionalidades aos utilizadores autenticados

para gerir e monitorizar as ocorrências reportadas.

Figura 43 - Erro HTTP - 403 Forbidden


64

Quando o utilizador acede à plataforma através do web browser, é apresentado o mapa

fornecido pela Google Maps API com as áreas administrativas do município e com os

respetivos marcadores que representam as ocorrências. Para reportar uma ocorrência, o

utilizador terá de autenticar-se através das redes sociais ou pelo servidor. Mo caso do

Figura 44 - Página inicial - Aplicação Web

Figura 45 - Registo


65

utilizador não possui credenciais de acesso, este pode efetuar o seu registo na área

destinada para o efeito.

A figura 45 representa o formulário para efetuar o registo. O utilizador deve preencher

obrigatoriamente todos os campos deste, nomeadamente:

Nome de utilizador (username): Neste campo o utilizador coloca o nome com o

qual deseja aceder à aplicação.

E-mail: Neste campo o utilizador coloca o seu e-mail.

Password: Neste campo o utilizador insere a palavra passe de preferência

alfanumérica e impessoal, para utilizar quando aceder ao site. No preenchimento

deste campo, a Aplicação auxilia o utilizador na criação de uma password robusta.

Captcha: É necessário colocar um visto no quadrado que antecede a frase “Não

sou um robô”. Esta operação tem como objetivo evitar spam ou criação de uma

conta por web robot1.

Concluído o preenchimento do formulário, o utilizador pode submeter os dados. Na

submissão dos dados, surgirá uma notificação a informar o utilizador que existe da

necessidade de validar a sua conta através da confirmação do seu e-mail antes de

autenticar no sistema (ver figura 46). Esta etapa foi definida para evitar que os utilizadores

utilizem e-mails de terceiros para reportarem ocorrências.

O utilizador confirma o seu e-mail através da sua caixa de correio eletrónico ao clicar no

link de confirmação que lhe é enviado após submeter os dados do registo. Na figura 47,

está representado o e-mail que o utilizador irá receber ao efetuar o registo.

1 Web robot: Software desenvolvido para simular ações humanas.

Figura 46 - Notificação - Confirmar e-mail


66

O utilizador ao selecionar o link fornecido, este será redirecionado para a página inicial

da aplicação com a notificação de que a confirmação da conta foi bem-sucedida (ver

figura 48).

Dada a confirmação, o utilizador pode realizar a autenticação preenchendo os campos

com as suas credenciais de acesso.

Caso a autenticação seja efetuada com sucesso, o utilizador poderá executar todas as

funcionalidades que lhe são permitidas, designadamente: criar ocorrências, monitorizar

ocorrências e consultar os dados pessoais da sua conta.

Figura 47 - E-mail para confirmar da conta de utilizador

Figura 49 - Login

Figura 48 - Notificação de confirmação bem-sucedida.


67

O utilizador para comunicar uma ocorrência, terá de preencher obrigatoriamente um

formulário representado na figura 50.

Neste formulário o utilizador pode selecionar a categoria e subcategoria para categorizar

a ocorrência a reportar, assim como adicionar uma imagem e fornecer a informação

relativa à sua localização. Para auxiliar o utilizador a fornecer os dados necessários à

participação este poderá indicar a localização da ocorrência através do marcador do mapa

Figura 50 - Formulário - Nova Ocorrência


68

ou através do preenchimento do campo “Address”. No preenchimento do campo Address

surgirão sugestões de moradas, de acordo com os campos que o utilizar está a preencher.

Após preenchidos os campos obrigatórios, o utilizador pode submeter os dados. Quando

a submissão dos dados é bem-sucedida, surgirá uma notificação a informar o utilizador.

No momento que surge a notificação representada na figura 52, o utilizador irá receber,

automaticamente, um e-mail de confirmação a descrever a ocorrência que o mesmo

reportou.

A figura 53 representa o e-mail de confirmação. A partir deste o utilizador poderá ter

acesso a toda a informação da ocorrência reportada ao clicar em “Here”, uma vez que

será redirecionado para a página da ocorrência.

Figura 52 - Notificação - Confirmação do envio do reporte da ocorrência

Figura 53 - E-mail de confirmação do envio da ocorrência

Figura 51 - Address


69

A figura 54 representa a página que contém toda a informação relacionada com a

ocorrência reportada. Nesta mesma página o utilizador tem a possibilidade de monitorizar

o estado da ocorrência, bem como o progresso das intervenções realizadas. Para facilitar

a leitura do seu estado, o marcador muda de cor de acordo com aquele em que se encontra.

No exemplo acima apresentado, a ocorrência encontra-se no estado “Não Avaliado” com

o marcador a cor vermelha. Quando a ocorrência ainda está no estado “Não Avaliado”, o

Figura 54 - Página Ocorrência


70

utilizador pode realizar alterações dos dados fornecidos inicialmente, caso exista a

necessidade de o fazer.

O utilizador tem a possibilidade de gerir ocorrências, e para isso basta consultar o mapa

fornecido pelo sistema para visualizar e consultar ocorrências que o mesmo reportou. Os

marcadores têm diferentes cores para diferentes estados em que os mesmos se encontram,

nomeadamente: Marcador vermelho: Não avaliada; Marcador Amarelo: Em Execução;

Marcador Verde: Finalizado. Esta diferenciação permite auxiliar o utilizador a analisar os

estados das ocorrências reportadas.

De modo a auxiliar o utilizador na análise do que cada marcador representa, o utilizador

poderá selecionar o marcador com interesse e surgirá uma pequena janela com uma

descrição relevante da ocorrência, como por exemplo: categoria, subcategoria, estado,

endereço e a data da última modificação do estado ou da última intervenção realizada (ver

figura 56).

Figura 55 - Mapa das ocorrências


71

A mesma página contém a lista das ocorrências que foram reportadas pelo utilizador.

Como referido anteriormente, cada ocorrência irá conter um estado e para cada estado

existem cores que permitem auxiliar o utilizador a identificar mais facilmente o estado

das mesmas na lista fornecida, tal como mostra a figura 57. Em cada ocorrência, existem

ações que o utilizador pode executar, nomeadamente visualizar e modificar a ocorrência.

Esta última ação só poderá ser vista e executada se a ocorrência estiver no estado “Não

Avaliado” ou “Pendente”.

Na conta pessoal, o utilizador tem a possibilidade de visualizar não só, os dados pessoais,

mas também o seu histórico de participação de ocorrências assim como as respetivas

avaliações realizadas nas ocorrências reportadas que estão no estado “Finalizado”.

Figura 57 - Lista das ocorrências reportadas

Figura 56 – Winfo-Window - Marcador


72

No perfil do utilizador é possível consultar os dados pessoais deste, bem como a

localidade da sua residência. A localidade e o número de telemóvel podem ser alterados

a qualquer momento, mas para isso deverá ser selecionado a opção “Change Profile

Data” (ver figura 58). O atributo “Parish” é um campo que o utilizador pode adicionar

após o seu registo no sistema. O utilizador ao selecionar a freguesia onde reside tem a

possibilidade de receber alertas dessa freguesia selecionada.

Na mesma página de perfil de utilizador, como referido, existe uma lista que contém todas

as participações e avaliações realizadas pelo utilizador autenticado.

O utilizador que tenha a necessidade de obter alguma informação sobre a plataforma ou

pretenda realizar alguma reclamação, poderá ir à área de contacto e preencher os campos

obrigatórios, como se apresenta na figura 60.

Figura 58 - Conta Utilizador

Figura 59 - Lista ocorrências e avaliações


73

Após submissão, surgirá uma notificação a informar o utilizador que o mesmo pedido foi

enviado com sucesso.

O utilizador que pretenda solicitar uma nova password, pode selecionar a opção “New

password” e basta preencher o campo e-mail e submeter. (ver figura 62)

Figura 61 - Notificação - Sucesso

Figura 60 - Formulário para reclamar ou solicitar ajuda


74

Após submeter o pedido, irá surgir uma notificação a informar o utilizador a verificar a

sua caixa de correio eletrónico e seguir as instruções para repor uma nova password.

Ao selecionar o link, que está no e-mail representado pela figura 63, o utilizador será

direcionado para a página de definição de uma nova password.

Ao submeter a nova password, surgirá uma nova notificação a informar que a password

foi guardada com sucesso caso contrário informará que ocorreu um erro ao guardar a nova

password.

Figura 62 – Solicitar nova password

Figura 63 - E-mail - Solicitação nova password

Figura 64 - Repor password


75

4.3.4 Utilizador Autenticado com Privilégios

O utilizador autenticado que possua privilégios tem acesso diferenciado para algumas

funcionalidades que o sistema fornece em relação a outros utilizadores que não possuem

privilégios, ou seja, existem funcionalidades de monitorização e de gestão de ocorrências

que só podem ser executadas por utilizadores que tenham privilégios, como é o caso do

Moderador, Responsável de Departamento e o Administrador.

4.3.4.1 Gestão de Ocorrências

As informações das ocorrências reportadas pela comunidade, apesar de, numa fase inicial,

serem validadas pelo sistema, não são garantia de que toda a informação submetida seja

do âmbito da aplicação. De modo a garantir a integridade do sistema, todas as ocorrências

reportadas pela comunidade são avaliadas por um ou mais utilizadores autenticados com

privilégios. Os utilizadores responsáveis pela avaliação das ocorrências são os que

possuem o privilégio de Moderador.

O Moderador tem acesso a todas as informações das ocorrências reportadas,

nomeadamente, categoria, subcategoria, foto, localização e data da participação

reportada. Este tipo de informação, pode ser facilmente consultada através da lista das

ocorrências ou pelo respetivo marcador no mapa disponibilizado pelo sistema. Este

utilizador pode também consultar os dados pessoais e o contato do cidadão que fez a

participação da ocorrência. Ao consultar essas informações, o Moderador pode tomar

decisões sobre a ocorrência, como por exemplo: alterar a categoria, a subcategoria ou o

estado.

4.3.4.2 Gestão Intervenções

Os utilizadores que possuam privilégios de Responsável de Departamento têm o mesmo

acesso às funcionalidades de gestão e de monitorização das ocorrências que o Moderador,

mas apenas o Responsável de Departamento tem a responsabilidade e a possibilidade de

adicionar intervenções para a resolução da mesma. O Responsável de Departamento só

poderá gerir as ocorrências reportadas cujas categorias são da sua responsabilidade, ou


76

seja, o Responsável de Departamento só tem acesso as ocorrências que pertencem ao seu

respetivo departamento.

O departamento responsável pela ocorrência pode adicionar uma nova intervenção ao

selecionar a opção “Add New Intervention”.

O Responsável de Departamento, ao criar uma nova intervenção, deve selecionar a

entidade que ficará responsável por intervir na ocorrência reportada.

No momento em que é criada uma nova intervenção, a entidade selecionada para intervir

receberá um e-mail com toda a informação da ocorrência. Após adicionar a nova

intervenção, o estado da ocorrência muda automaticamente para “Em Execução”. A

ilustração abaixo apresentada, representa o e-mail que é gerado automaticamente quando

é criada uma nova intervenção.

.

Figura 65 - Adicionar Nova Intervenção

Figura 67 - E-mail - Nova Intervenção

Figura 66 - Criar Nova Intervenção


77

Quando a ocorrência estiver resolvida, o departamento pode alterar o estado da mesma

para “Concluído”. Ao efetuar a alteração do estado para “Concluído”, o utilizador que fez

a participação da respetiva ocorrência irá ser notificado automaticamente por e-mail. A

ocorrência quando passar ao estado “Concluído”, o mesmo utilizador pode realizar

avaliação da ocorrência.

4.3.4.3 Gestão de Utilizadores

Os utilizadores que têm o privilégio de “Administrador”, tem a responsabilidade de gerir

os utilizadores registados no sistema. O Administrador pode realizar operações de gestão

de utilizadores, tais como atribuir privilégios ou bloquear utilizadores. Esta última

operação será efetuada se existir a necessidade de bloquear algum utilizador, com o

objetivo de aferir a seriedade do sistema.

Na figura 68, está representada a lista de utilizadores que estão registados no sistema.

Neste caso, todos os utilizadores que possuem o status “Active”, têm acesso ao sistema.

Caso exista a necessidade de bloquear um utilizador, o administrador pode alterar o

respetivo status para desativado, tornando o utilizador inacessível ao sistema.

Todos os utilizadores que se registem no sistema, possuem o privilégio padrão “Citizen”

sobre o sistema, exceto o administrador, que este tem a responsabilidade da atribuição de

privilégios para cada utilizador. O administrador pode atribuir os seguintes privilégios:

Figura 68 - Lista dos utilizadores do sistema


78

“Citizen”, “Moderator” e “Department”. Quando o administrador ao atribui o privilégio

“Department” a um utilizador este deve selecionar o departamento a que o mesmo

pertence.

4.3.4.4 Gestão de Alertas ou Noticias

Na plataforma existe a possibilidade dos utilizadores com privilégios (Moderador,

Responsável de Departamento e Administrador) criarem alertas ou notícias para os

cidadãos que estejam registados no sistema. Os alertas ou notícias podem ser direcionados

para todos os cidadãos ou apenas para os cidadãos de alguma freguesia em específico.

Na criação do alerta, existe a possibilidade de escolher a freguesia de modo a permitir

que apenas os utilizadores da freguesia selecionada recebam o alerta, ou a opção “Todas”

que faz com que todos os utilizadores recebam o alerta criado.

4.3.5 Fluxo E-mails

Este sistema utiliza o servidor de e-mail SMTP para proceder ao envio de e-mails aos

utilizadores do sistema.

Na imagem 69 é possível verificar o esquema e os protocolos utilizados desde o envio até

a receção dos e-mails gerados pelo sistema desenvolvido. O protocolo SMTP é utilizado

Figura 69 - Servidor E-mail (Fonte: serversmptp.com)


79

para o envio destes, enquanto o POP/IMAP servirá para descarregar os e-mails para o

utilizador destinatário.

Ao longo do desenvolvimento da aplicação web foi necessário lidar com um servidor de

e-mail SMTP fictício, para testar e consultar os e-mails gerados pelo sistema quando este

ainda se encontrava em fase de desenvolvimento ou em testes, sem que os verdadeiros

utilizadores recebam spam. O servidor SMTP fictício utilizado foi MailTrap. [32] A

figura 70 permite compreender o fluxo de e-mails gerados pelo sistema.

Os e-mails são gerados e enviados automaticamente pelo sistema nas seguintes situações:

Utilizador autenticado reporta uma ocorrência;

Ocorrência muda de estado;

O departamento responsável pela ocorrência reportada adiciona uma nova

intervenção;

Administrador bloqueia um utilizador;

Administrador atribui privilégios;

Criar novos avisos ou novas notícias.

Numa fase inicial, o sistema desenvolvido não integrará os sistemas de informação do

município, uma vez que este não se destina apenas a um município especificamente. O

município de Vila Verde apenas impulsionou o desenvolvimento e os testes da aplicação.

Figura 70 - Fluxo de E-mail – MailTrap (Fonte: mailtrap.com)


80

Este sistema foi desenvolvido de modo a possibilitar o seu uso por todos os municípios

que tenham interesse em adquirir o sistema.

4.3.6 Google Maps API

A Google Maps API representa o serviço mais importante para os utilizadores da

plataforma, pois este visa auxiliar na gestão e na monitorização de ocorrências.

Quando um utilizador reporta uma ocorrência, será possível verificar no mapa o marcador

correspondente à ocorrência reportada. Ao longo do ciclo de vida da ocorrência, o

marcador irá mudar de cor de modo a facilitar a perceção da mudança de estado da

mesma.

Através dos marcadores existe a possibilidade de identificar os locais das ocorrências no

mapa e, para que os marcadores correspondam à localização exata de cada ocorrência foi

necessário recorrer à estrutura JSON para guardar a informação relativa a localização bem

como ao estado em que a ocorrência se encontra.

Figura 71 - Google Maps API


81

De modo a facilitar o acesso às informações básicas de uma determinada ocorrência, o

utilizador pode escolher o marcador com interesse e, surgirá uma pequena janela, “Info-

Windows”, com a informação necessária, tal como demonstra a figura 72.

No exemplo anterior, os dados da localização e do estado das ocorrências foram

guardados numa estrutura JSON, mas também foi necessário utilizar a mesma estrutura

para guardar a informação para que a mesma fosse apresentada na info-windows.

Na figura 73 está representado o array JSON utilizado para o armazenamento de

múltiplos objetos que representam as ocorrências. O Google Maps só permite importar

informação para o mapa se a mesma se encontrar numa estrutura JSON.

Os municípios possuem áreas distintas de intervenção nas quais os serviços municipais

operam. De forma a criar limites das áreas administrativas de cada município, foi

necessário recorrer ao GeoJSON para suportar a geometria Polygon fornecida pelo

Google Maps API. Esta API fornece a classe Google.maps.Data que também segue a

estrutura do GeoJSON na representação de dados e facilita a exibição dos mesmos. O

método loadGeoJson() foi utilizado para importar facilmente os dados GeoJSON e exibir

marcadores e polígonos através de um URL utilizando o método addGeoJson().

Figura 72 - InfoWindow - Ocorrência

Figura 73 - Estrutura Json - Ocorrência


82

O Polygon é um objeto que permite criar formas geométricas no mapa através de conjunto

de coordenadas. Com a utilização deste será possível representar os limites das áreas

administrativas do município no mapa apresentado no sistema. Esta criação tem como

objetivo evitar que os utilizadores reportem ocorrências em locais que não pertencem às

áreas administrativas do município que esteja a utilizar este sistema.

Neste projeto, foram utilizados os limites das áreas administrativas do município de Vila

Verde.[12]

4.3.7 Web Services

Os Web Services REST desenvolvidos são responsáveis pela troca e partilha de

informação com aplicação móvel através da utilização de métodos HTTP. A figura 75

representa o esquema da comunicação entre aplicação móvel e os Web Services.

Figura 74 - Google Maps - Áreas Administrativas

Figura 75 – Web Services REST – Esquema da comunicação


83

Os Web Services REST recebem solicitações da aplicação móvel através de métodos

HTTP (GET, POST, PUT e DELETE) para a manipulação de recursos. A aplicação móvel

e os Web Services transferem dados entre si através do padrão de estrutura dados JSON.

[33]

O servidor retorna códigos de estados HTTP a indicar o sucesso (2xx), quando as

solicitações realizadas pelo cliente são aceites, mas nem todas as solicitações realizadas

por este obtém o resultado pretendido. O servidor retorna código de estado 404 (Not

Found) no caso da não existência do recurso solicitado ou 401 (Unauthorized) no caso o

utilizador não ter permissão para consultar ou modificar o recurso solicitado. [38]

A aplicação móvel contém funcionalidades que permitem a gestão de ocorrências, mas

para isso foi necessário considerar o desenvolvimento dos Web Services REST para as

seguintes ações:

Registo e Autenticação do Utilizador;

Criar Ocorrência;

Listar Ocorrências;

Consultar Ocorrência;

Listar Avisos/Alertas;

URI Método CRUD Parâmetros Descrição

/register POST CREATE username, e-mail,

tel e password

Registar utilizador

/login POST READ ONE e-mail e password Autenticar utilizador

/occurrences POST CREATE Occurrence Criar nova ocorrência

/occurrences GET READ ALL Listar ocorrências

/occurrences/id GET READ ONE Listar uma ocorrência

/occurrences/id PUT UPDATE Modificar ocorrência

/warnings-news GET READ ALL Listar notícias

Tabela 18 - Estrutura dos pedidos

Na arquitetura REST, os dados e as funcionalidades são considerados recursos, e esses

recursos podem ser manipulados através de URI´s.


84

Registo

O utilizador pode efetuar o seu registo através da aplicação móvel, mas para que isso seja

possível a aplicação terá de interagir com os Web Services de modo guardar os dados do

utilizador na BD.

URI Método Parâmetros

/api/v1/register POST username; e-mail; tel; password

Tabela 19 - Registar Utilizador

Quando o utilizador submete o seu registo, será enviado um pedido POST aos Web

Services e posteriormente será emitido uma resposta em JSON. Se registo do utilizador é

realizado com sucesso será devolvida a resposta JSON representada pela figura 76.

Quando o utilizador fornece um e-mail que já é existente na BD, será devolvida a resposta

JSON representada pela figura 77.

Autenticação

O utilizador pode autenticar-se através da aplicação móvel, mas para que isso seja

possível a aplicação terá também de interagir com os Web Services de modo a verificar

se credenciais de acesso fornecidas pelo utilizador permitem aceder às principais

funcionalidades da aplicação móvel.

Figura 76 - Resposta JSON - Registo efetuado com sucesso

Figura 77 - Resposta JSON - Utilizador já existe


85


/api/v1/login POST e-mail; password

Tabela 20 - Autenticar Utilizador

Quando utilizador realiza a autenticação com sucesso, será devolvida a resposta JSON

representada pela figura 78.

Esta resposta devolvida comprova que a autenticação foi bem-sucedida, permitindo assim

o acesso à aplicação móvel. Caso alguma das credenciais esteja incorreta, surgirá a

seguinte reposta.

A resposta devolvida comprova que o valor do parâmetro password está incorreto, o que

faz com que o utilizador não tenha acesso à aplicação. Se não existir nenhum utilizador

com username igual ao valor do parâmetro username a mensagem de erro será “User not

found”.

Ocorrência

Os Web Servives também são responsáveis por gerir ocorrências, ou seja, têm a

responsabilidade de criar e listar as ocorrências.


/api/v1/occurrences POST Occurrence

Tabela 21 - Criar Ocorrência

Quando os Web Services recebem a informação da ocorrência, será realizado um parsing

que permite converter dados JSON. Após a realização do parsing e após a inserção dos

Figura 79 - Resposta JSON - Password errada

Figura 78 - Resposta JSON - Autenticação realizada com sucesso


86

dados da ocorrência na BD, será emitida uma resposta em formato JSON para a aplicação

móvel a informar que a inserção foi bem-sucedida.

O utilizador pode consultar as ocorrências reportadas através da aplicação móvel. Os Web

Services ao receberem a solicitação da aplicação móvel para listar ocorrências, retornam

uma resposta JSON com a informação das ocorrências reportadas.

Na figura 80 é possível verificar a constituição da estrutura da resposta JSON para listar

as ocorrências. Esta resposta contém um array com objetos do tipo Occurrence no qual

se incluem as informações das mesmas.

Figura 80 - Resposta JSON - Listar Ocorrências

5 Análise de Resultados

87

Capítulo 5


Neste capítulo é feita a descrição da análise dos resultados obtidos através da solução

encontrada num contexto real e pelo qual este projeto foi desenvolvido. Também serão

abordados alguns aspetos que foram identificados na aplicação web e móvel e que,

futuramente, poderão ser aperfeiçoados.

5.1 Metodologia

No desenvolvimento da aplicação web e móvel, as principais funcionalidades foram

sujeitas a testes para compreender se apresentavam o resultado pretendido. Os dados

fornecidos e gerados nesses testes realizados são fictícios, ou seja, os dados eram relativos

a ocorrências, a utilizadores e a entidades fictícias.

Devido à existência de um número significativo de partes interessadas neste projeto, o

principal objetivo torou-se perceber o comportamento das soluções quando estas são

utilizadas em contexto real de uma autarquia. Neste sentido, a aplicação web e móvel

foram disponibilizadas algumas principais partes interessadas de modo a permitir efetuar

uma avaliação sobre as mesmas.

5.2 Acesso à Aplicação

As aplicações web e móvel foram disponibilizadas às principais partes interessadas num

ambiente controlado. De modo que as aplicações sejam acedidas por diferentes tipos de

utilizadores, a aplicação web foi disponibilizada através do servidor local. Os diferentes

tipos de utilizadores assumiram diferentes tipos de papéis:

Administrador;


88


Moderador;

Utilizador:

o Anónimo;

o Autenticado;

O acesso às aplicações foi realizado por fases, desde a comunicação da ocorrência até a

resolução da mesma. Neste caso, foi utilizada informação fictícia de uma ocorrência para

proceder à comunicação da mesma.

Na primeira fase, o utilizador anónimo, que não possui credenciais de acesso ao sistema,

efetua o seu registo e confirma a sua conta. O utilizador, já autenticado, reporta a

ocorrência fornecendo os dados relativos a ocorrência e ao submeter. Este utilizador pode

comunicar a ocorrência através da aplicação web ou através da aplicação móvel.

Na segunda fase, o Moderador tem acesso às funcionalidades que permitem avaliar as

ocorrências reportadas pelos utilizadores do sistema. Este ator avalia a nova ocorrência

reportada, antes desta mesma ser encaminhada para o respetivo departamento.

Na terceira fase, o Responsável de Departamento tem acesso às informações relativas à

ocorrência reportada pelo cidadão e validada pelo Moderador. O Responsável

Departamento poderá realizar a gestão de intervenções para a resolução desta.

Por último, o cidadão que reportou a ocorrência avalia a qualidade das intervenções

realizadas.

5.3 Novos Requisitos

A disponibilização das aplicações desenvolvidas, não só proporcionou que novos

requisitos surgissem como também possibilitou a identificação de melhorias que podem

ser efetuadas. Na evolução deste projeto serão implementados requisitos que no processo

de prioritização, foram considerados menos prioritários em relação aos implementados.

As observações efetuadas após a utilização da solução encontrada foram as seguintes:


89

O Presidente de Junta pode gerir ocorrências da freguesia ou do grupo de

freguesias que representa;

As entidades responsáveis pelas intervenções podem tirar fotografia do local da

ocorrência após a sua resolução e adicionar à informação da respetiva ocorrência;

Disponibilizar a aplicação móvel para as plataformas IOS e Windows Mobile;

Controlar quanto tempo é que uma determinada ocorrência irá demorar a ser

resolvida, ou quanto tempo foi gasto na resolução da mesma. Dar uma estimativa

de tempo relativamente ao número de horas gastas e ao número de horas restantes

para a resolução desta;

Apresentar ao utilizador a informação das intervenções bem como a percentagem

de resolução da ocorrência;

O utilizador pode enviar sugestões;

Gráficos nas páginas iniciais dos utilizadores com privilégios.

Através desta análise foi possível criar novos requisitos que serão especificados e

implementados na próxima versão desta solução.

5.4 Discussão

Tal como mencionado anteriormente, a metodologia aplicada ao processo de

desenvolvimento de software permitiu que os principais stakeholders se mantivessem

informados sobre o fluxo de trabalho. Este contacto frequente fez com que surgissem

novos requisitos e outros tivessem de ser modificados. Após a primeira utilização desta

solução, em contexto real, embora com reduzido número de utilizadores, é possível

afirmar que a mesma melhora não só a comunicação de ocorrências entre o cidadão e a

autarquia, mas também a gestão efetuada pelos serviços administrativos da Câmara

Municipal para a resolução das ocorrências.

É importante salientar que estas soluções visam não só contribuir para a aproximação dos

cidadãos ao município para que este seja mais eficiente e eficaz no fornecimento de

respostas a todas as solicitações da comunidade, mas também, na melhoria da gestão dos

recursos humanos e materiais para a identificação de ocorrências.


90

Esta solução pode também ser associada a indicadores de custos e de satisfação da

comunidade de cada município, através da utilização das informações relativas às

ocorrências e às respetivas intervenções realizadas, podendo assim classificar as

autarquias.

6. Conclusões e Trabalho Futuro

91

Capítulo 6

6 Conclusões e Trabalho Futuro

O desenvolvimento deste projeto foi motivado pela necessidade de gerir e monitorizar as

ocorrências reportadas pelos cidadãos com maior rigor e também pela não existência de

um meio de comunicação eficaz e eficiente para reportar as mesmas.

6.1 Síntese do Trabalho

Na fase inicial deste projeto foram realizadas várias reuniões com os principais órgãos

executivos da Câmara Municipal de Vila Verde e com outras partes interessadas com o

intuito de obter informações relativas às necessidades sentidas na gestão e na

monitorização das ocorrências do município. Durante as reuniões foi possível conhecer

melhor o domínio do problema o que possibilitou a elaboração de um documento de

requisitos. Com base na elaboração deste documento foi possível perceber a dimensão e

a natureza do problema o que, por sua vez, motivou o estudo de novos conceitos e a

utilização de novas tecnologias para desenvolver a solução pretendida para responder as

necessidades das partes interessadas.

Na fase inicial ficou decidido desenvolver apenas a aplicação móvel e fazer a integração

da mesma com o sistema de informação existente na Câmara Municipal, mas devido a

vários constrangimentos impostos pela entidade, foi necessário optar também pelo

desenvolvimento de uma aplicação web e de Web Services.

Sendo assim, a solução debruçou-se no desenvolvido de uma aplicação móvel e web. A

aplicação móvel pode ser utilizada por qualquer cidadão com a finalidade de reportar e

monitorizar ocorrências relativas à via pública. A aplicação web auxilia os órgãos

executivos que compõe a Câmara Municipal a gerir e monitorizar as ocorrências

fornecidas pelos cidadãos.


92

A aplicação móvel foi desenvolvida para a plataforma Android mas, não tendo

conhecimentos sobre o desenvolvimento em ambiente Android, foi necessário estudar

toda a arquitetura deste SO de modo a melhor compreender o seu funcionamento. No

primeiro contacto com o desenvolvimento Android foram efetuados alguns exercícios

para auxiliar o estudo desta nova plataforma. Após a realização de alguns exercícios,

iniciou-se o desenvolvimento da aplicação móvel no âmbito deste problema. Surgiram

algumas dificuldades, mas ultrapassadas, tornou-se possível obter um MVP para testar se

as funcionalidades executadas surtiam o efeito desejado. Com a obtenção deste MVP,

iniciou-se o desenvolvimento da aplicação web bem como os web services necessários.

6.2 Trabalho Futuro

No decorrer deste projeto as principais partes interessadas mantiveram-se informadas

sobre o fluxo de trabalho o que, de certa forma, fez com que surgissem novas ideias.

Alguns requisitos foram modificados no tempo definido para o desenvolvimento deste

projeto, mas também existiram novos requisitos que não foram implementados devido à

impossibilidade de serem implementadas no período de uma dissertação de mestrado. No

entanto, os novos requisitos propõem-se ser implementados futuramente para melhorar a

eficiência e o sucesso desta plataforma.

Como referido ao longo da dissertação, a aplicação móvel foi desenvolvida apenas para

plataforma Android. Mas, dependendo do sucesso da utilização desta plataforma, também

poderá ser desenvolvida para as plataformas IOS e Windows Phone na tentativa de

aumentar o número do público-alvo. Existem também aspetos não só ao nível gráfico,

mas também a nível do desempenho que devem ser melhorados na aplicação web e móvel,

de modo a melhorar a user experience.

Serão realizados testes de profiling na aplicação web através de ferramentas Web profilers,

para a obtenção de dados relativos à performance da aplicação quando esta está em

execução. Na utilização destas ferramentas irá possibilitar a averiguação da capacidade,

da robustez e da disponibilidade da mesma quando sujeita a picos de carga.


93

Após a implementação dos novos requisitos e melhorados alguns aspetos da aplicação

web e móvel, a solução será futuramente testada num contexto real, nomeadamente no

município de Vila Verde, responsável por impulsionar o desenvolvimento deste projeto.

Por fim, após a efetuar as melhorias, esta solução será comercializada para todos os

municípios com interesse na sua utilização.

6. Bibliografia

94

Bibliografia

[1] Agarwal, R., & Umphress, D. (2008). Extreme Programming for a Single Person Team.

Dunstan Hall.

[2] Allen Holub. (2004). Holub on Patterns: Learning Design Patterns by Looking at Code.

Apress.

[3] Android. (2016). Platform Architecture. Retrieved from Developers:

https://developer.android.com/guide/platform

[4] Apache Friends. (2016). XAMPP . Retrieved from

https://www.apachefriends.org/pt_br/index.html

[5] ATOM. (2016). Retrieved from Atom: https://atom.io/

[6] Beck, K. (1999). Embracing Change with Extreme Programming. Computer.

[7] Beck, K., & Andres, C. (2004). Extreme Programming Explained - Second Edition.

Boston: Addision - Wesley.

[8] Cidadania 2.0. (2016). No Meu Bairro. Retrieved from

http://cidadania20.com/projectos/no-meu-bairro/

[9] CODEPATH. (2016). Leveraging the Gson Library. Retrieved from CodePath:

https://guides.codepath.com/android/Leveraging-the-Gson-Library

[10] Developer Android. (2016). Retrieved from Android Studio:

https://developer.android.com/studio/index.html

[11] Developers Android. (2016). Transmitting Network Data Using Volley. Retrieved from

https://developer.android.com/training/volley/index.html

[12] DGT. (2016). CAOP. Retrieved from Carta Administrativa Oficial de Portugal:

http://www.dgterritorio.pt/cartografia_e_geodesia/cartografia/carta_administrativa_

oficial_de_portugal__caop_/caop_em_vigor/

[13] Fernandes, J. M., & Machado, R. J. (2016). Requirements in Engineering Projects.

Springer.

[14] Fowler, M. (2004). UML distilled: a brief guide to the standard object modeling

language 3nd edition. Boston: Addison-Wesley.

[15] Gamma, Helm, Johson, & Vlissides. (2000). Design Patterns - Elements of Reusable

Object-Oriented Software. Bookman.

6. Bibliografia

95

[16] GeoEstrela. (2016, Janeiro). GeoEstrela. Retrieved from https://www.jf-

estrela.pt/geoestrela/

[17] Google. (2016). Retrieved from Google Maps APIs: developers.google.com/maps

[18] Henrik Kniberg, M. S. (2010). Kanban and Scrum - Making the most of both. United

States of America : C4Media Inc.

[19] Howard Butler (Hobu Inc.), M. D.-C. (2016, 04). geoJSON. Retrieved from

http://geojson.org

[20] Humphrey, W. (2000). The Personal Software Process. Hanscom AFB: SEI Joint Program

Office.

[21] IEEE. (2014). A guide to the business analysis body of knowledge (BABOK guide).

Toronto: SWEBOK.

[22] Javed Ali Khan, I. U. (2015). Comparison of Requirement Prioritization Techniques to

Find Best Prioritization Technique. MECS .

[23] Json. (n.d.). Json. Retrieved from Json: https://json-csv.com/json

[24] MailTrap. (2016). MailTrap. Retrieved from mailtrap.io

[25] Martina Seidl, M. S. (2015). UML@Classroom : An Intruduction to Obejct-Oriented

Modeling. Suiça: Springer.

[26] Nor Azian Abdul Rahman, S. M. (2013). Lean Manufacturing Case Study with Kanban

System Implementation. Elsevier.

[27] Pete Behrens, Trail Ridge Consulting . (2006). Agile Project Management (APM) Tooling

Survey Results .

[28] Postal do Cidadão. (2016, Janeiro). A Minha Rua. Retrieved from

https://www.portaldocidadao.pt/web/agencia-para-a-modernizacao-administrativa/a-

minha-rua-comunicacao-de-ocorrencias-no-espaco-publico

[29] PostMan. (2016). POSTMAN. Retrieved from getpostman.com

[30] Queiroz, R. (2014). Desemvolvimento de aplicações professionais. FCA - Editora de

Informatica, LDA.

[31] Quin, L. (2016, 10 11). Extensible Markup Language (XML). Retrieved from W3C:

https://www.w3.org/XML/

[32] Railsware Products. (2016). mailtrap. Retrieved from mailtrap: https://mailtrap.io/

[33] Ruby, L. R. (2007). RESTful Web Services. United States of America: O’Reilly Media, Inc.

[34] Serena. (2007). An Introduction to Agile Software Development.

6. Bibliografia

96

[35] SQLite. (2016). Retrieved from SQLite - Documentation: https://sqlite.org/

[36] Square. (2016). Picasso. Retrieved from http://square.github.io/picasso/

[37] Torres Vedras. (2016, Janeiro). AlertaTVedras. Retrieved from http://www.cm-

tvedras.pt/alertas/

[38] W3C. (n.d.). Retrieved from Status codes - HTTP:

https://www.w3.org/Protocols/HTTP/HTRESP.html

[39] Yani Dzhurov, I. K. (2016). Personal Extreme Programming – An Agile Process for

Autonomous Developers. Bulgaria.

[40] Yii PHP Framework Version 2. (2016). The Definitive Guide to Yii 2.0. Retrieved from

Modules: http://www.yiiframework.com/doc-2.0/index.html

7. Suporte Material

97

Anexo A – Cartões Volere

Cartões Volere

Todos os requisitos do projeto foram descritos em cartões Volere. Nestes cartões, são

definidos o número do requisito, o tipo de requisito, a prioridade, a descrição, a razão, o

critério de ajuste, a origem e a história. Os cartões Volere criados apresentam-se

seguidamente:

Requisito: R1 Tipo de Requisito: 3.4 Prioridade: M

Descrição: O utilizador regista-se no sistema.

Razão: É importante que o utilizador se registe no sistema para que o mesmo guarde

os seus dados pessoais e os seus contactos.

Origem: Equipa de desenvolvimento

Critérios de

Ajuste:

Um utilizador insere através de um formulário de registo ou utiliza a sua

conta Facebook ou conta Gmail+ para o fazer. O sistema guarda esses dados

na base de dados.

História: Criado em Dezembro de 2015


Descrição: O utilizador autentica-se no sistema.

Razão: Reconhecer um utilizador perante o sistema, para que este possa aceder às

funcionalidades que necessitam de autenticação nomeadamente reportar,

consultar e avaliar ocorrências.


Critérios de

Ajuste:

O utilizador insere as suas credenciais de acesso num formulário de login.

Uma vez validado pelo sistema, o utilizador tem acesso às funcionalidades

principais.


7. Suporte Material

98


Descrição: O utilizador autenticado reporta ocorrências.

Razão: Será importante que todos os cidadãos reportem todas as ocorrências que

observam na via pública, em tempo útil, de modo que as entidades possam

intervir o mais rápido possível.

Origem: Carlos Tiago – Vereador da Câmara Municipal de Vila Verde

Critérios de

Ajuste:

O utilizador pode reportar a ocorrência da via pública fornecendo todos os

detalhes da mesma preenchendo formulário fornecido. Estes detalhes

devem ser acompanhados por uma fotografia.



Descrição: O utilizador autenticado acede à lista ocorrências.

Razão: Qualquer utilizador autenticado pode consultar a lista das ocorrências

realizadas de modo a reconhecer o estado em que as mesmas se encontram.


Critérios de

Ajuste:

Qualquer utilizador autenticado pode consultar a lista das ocorrências

reportadas, bem como toda a informação de cada ocorrência.


7. Suporte Material

99

Requisito: R5 Tipo de Requisito: 3.4 Prioridade: W

Descrição: O utilizador autenticado segue as ocorrências reportadas de outros

utilizadores.

Razão: Qualquer utilizador autenticado pode ter interesse em ser notificado de

eventuais alterações de estado de alguma ocorrência reportada por terceiros.


Critérios de

Ajuste:

O utilizador deve conseguir seguir qualquer ocorrência reportada por

terceiros quando esta é do seu interesse de modo obter informações sobre

eventuais mudanças do seu estado.


Requisito: R6 Tipo de Requisito: 3.4 Prioridade: S

Descrição: O utilizador autenticado altera os dados pessoais.

Razão: Os utilizadores podem ter a necessidade de alterar os seus dados, por várias

razões: fornecimento errado dos seus dados, mudança de contacto/e-mail

ou mesmo para alteração de password de acesso ao sistema. O utilizador

também pode adicionar a freguesia onde reside.

Origem: Equipa de desenvolvimento.

Critérios de

Ajuste:

O utilizador autenticado deve conseguir editar os seus dados através de um

formulário. Essas alterações serão guardadas na base de dados.


7. Suporte Material

100

Requisito: R7 Tipo de Requisito: 3.4 Prioridade: C

Descrição: O utilizador autenticado avalia a ocorrência.

Razão: O utilizador que não esteja satisfeito com a solução encontrada para a

resolução das ocorrências reportadas poderá manifestar a sua insatisfação

através da avaliação da mesma.


Critérios de

Ajuste:

O utilizador autenticado pode avaliar os serviços prestados através de um

formulário de satisfação fornecido pela aplicação.



Descrição: O utilizador autenticado recebe notificações sobre o estado das suas

ocorrências reportadas.

Razão: O utilizador será notificado de todas as alterações de estado de todas as suas

ocorrências descritas.


Critérios de

Ajuste:

O utilizador que reportar uma ocorrência poderá receber notificações sobre

eventuais mudanças de estado da mesma.


7. Suporte Material

101


Descrição: O utilizador autenticado acede a lista das intervenções realizadas na

ocorrência reportada.

Razão: O utilizador pretende consultar as intervenções que estão a ser realizadas

para resolver a ocorrência que reportou.

Origem: Vítor Silva – Presidente de Junta de Esqueiros – Vila Verde

Critérios de

Ajuste:

O utilizador pode consultar as intervenções que estão a ser realizadas na

ocorrência reportada através da consulta da respetiva ocorrência.



Descrição: O utilizador autenticado recebe notificações relativas a novos reportes de

ocorrências de outros utilizadores.

Razão: Novas ocorrências podem ser reportadas das mais variadas situações e, será

sempre do interesse dos utilizadores receberem algum tipo de informação

relativa a novas situações em espaços públicos.


Critérios de

Ajuste:

O utilizador recebe notificações de novas ocorrências que possam ser

reportadas sobre espaços públicos no município.


7. Suporte Material

102


Descrição: O utilizador autenticado deve ser capaz de anunciar a localização da

ocorrência por escrito, através de um mapa, ou por localização automática

(GPS).

Razão: Todos os utilizadores autenticados devem fornecer a localização de forma

válida de modo a permitir que as entidades/ empresas possam saber

exatamente o local da ocorrência.

Origem: Persona “O Reformado”

Critérios de

Ajuste:

Um utilizador autenticado pode utilizar as várias opções fornecidas pela

aplicação para o fornecimento da localização da ocorrência e para isso pode

descrever o nome da rua selecionando no mapa o local ou através da

localização automática (GPS) no caso do utilizador estivar a reportar a

ocorrência no local exato da mesma.



Descrição:

O utilizador autenticado pode pesquisar ocorrências por freguesia, categoria

ou estado da ocorrência.

Razão: Permitir ao utilizador encontrar reportes de ocorrências do seu interesse

filtrando os mesmos por uma localidade de preferência, categoria específica

ou estado da ocorrência.


Critérios de

Ajuste:

O utilizador pode procurar todas as ocorrências do seu município por

freguesia, categoria ou estado. A aplicação apresenta uma lista de

ocorrências que satisfazem o resultado da procura do utilizador.


7. Suporte Material

103


Descrição: O utilizador envia pedido de informações no âmbito da gestão de

ocorrências.

Razão: Para o sucesso do sistema é necessário fornecer ao utilizador forma de

estabelecer comunicação com o município.




Descrição: O utilizador autenticado consulta os dados da ocorrência através do

marcador existente no mapa.

Razão: Para uma consulta rápida dos dados principais da ocorrência.


Critérios de

Ajuste:

O utilizador autenticado consulta os dados de uma dada ocorrência através

dos marcadores existentes no mapa.


7. Suporte Material

104


Descrição: O administrador gere privilégios dos utilizadores autenticados.

Razão: Alguns utilizadores autenticados poderão interferir no estado de uma

ocorrência, pois o seu cargo no município pode permitir que o faça:

Presidentes de Junta, Presidente do Município, Vereadores, entidades

competentes ou empresas.


Critérios de

Ajuste:

O administrador pode atribuir privilégios a utilizadores para acesso a certas

funcionalidades que o sistema possui para a gestão interna de ocorrências.



Descrição: O administrador gere as contas dos utilizadores.

Razão: Para aferir a seriedade do sistema é necessário que os administradores

possam gerir as contas dos utilizadores do sistema, de modo a garantir que

o sistema seja utilizado de acordo com as regras estabelecidas.


Critérios de

Ajuste:

Os administradores podem gerir as contas dos utilizadores através do

registo e do rácio de cada utilizador, de modo a verificar se existe algum

abuso na sua utilização.


7. Suporte Material

105


Descrição: O administrador gere ocorrências.

Razão: O administrador poderá alterar o estado das ocorrências a qualquer

momento assim que se justifique.




Descrição: O administrador recebe notificações de novas ocorrências.

Razão: Necessidade do administrador gerir o tipo de utilização da aplicação e assim

certificar-se de que a sua utilização está de acordo com o propósito da

aplicação.


Critérios de

Ajuste:

O administrador poderá a qualquer momento aceder a toda a informação

relativa à utilização da aplicação bem como receber todas as notificações

relativas às novas ocorrências em espaços públicos de todo o município em

questão.


7. Suporte Material

106


Descrição: O administrador pode gerir entidades, departamentos, categorias e

subcategorias no sistema.

Razão: O administrador pode gerir entidades, departamentos, categorias e

subcategorias no sistema caso seja necessário adicionar ou modificar algum

dos campos anteriormente referidos.


Critérios de

Ajuste:

Somente o administrador terá acesso à área de gestão de entidades, de

departamentos, de categorias e subcategorias no sistema.

História: Criado em maio de 2016


Descrição: O sistema notifica automaticamente a GNR, os Bombeiros, a PSP, a Polícia

Municipal e as entidades com a informação detalhada da ocorrência

reportada.

Razão: Sempre que sejam adicionadas novas intervenções a uma ocorrência que

ocorre na via pública as entidades responsáveis são notificadas por correio

eletrónico com toda a informação detalhada da ocorrência.


Critérios de

Ajuste:

O departamento responsável pela resolução da ocorrência ao adicionar uma

nova intervenção, as entidades competentes serão notificadas por correio

eletrónico automaticamente.

História: Criado em dezembro de 2015

7. Suporte Material

107


Descrição: A entidade gere intervenções.

Razão: A entidade responsável pela ocorrência reportada pode fornecer

informações relativamente à intervenção que está a ser realizada podendo

mesmo alterar o estado da ocorrência caso esta esteja resolvida.




Descrição: O moderador avalia as ocorrências reportadas pelos utilizadores.

Razão: As ocorrências reportadas pelos utilizadores autenticados devem ser

analisadas pelo moderador antes de serem encaminhadas para o

departamento.


Critérios de

Ajuste:

O moderador pode selecionar uma das opções disponíveis para alterar o

estado da ocorrência: “Avaliado”, “Pendente” e “Cancelado”;


7. Suporte Material

108


Descrição: O moderador gere as alertas/notícias.

Razão: Caso o município tenha um alerta ou uma notícia para divulgar a

comunidade.


Critérios de

Ajuste:

Quando o administrador, o departamento ou o moderador criarem um alerta

ou uma notícia, todos os utilizadores registados no sistema são notificados

por correio eletrónico sobre os detalhes através de um alerta ou de uma

notícia.

História: Criado em Maio de 2016


Descrição: O moderador envia e-mail ao utilizador que reportou ocorrência.

Razão: O moderador pode ter interesse em comunicar com o utilizador que reportou

ocorrência de modo a obter informações mais detalhadas sobre a mesma.


Critérios de

Ajuste:

O moderador ao consultar a ocorrência reportada pode comunicar com o

utilizador que reportou a mesma.


7. Suporte Material

109


Descrição: O responsável de departamento gere intervenções para a resolução da

ocorrência.

Razão: O departamento pode gerir intervenções à ocorrência reportada para que as

entidades responsáveis possam resolver a mesma.


Critérios de

Ajuste:

O departamento pode selecionar a opção obter “Adicionar Nova

Intervenção” e depois pode escolher as entidades que irão ficar responsáveis

pela resolução da ocorrência.



Descrição: O responsável de departamento encaminhar a ocorrência para outro

departamento.

Razão: De acordo com a natureza da ocorrência reportada, pode existir a

necessidade de encaminhar o reporte da ocorrência para vários

departamentos.


Critérios de

Ajuste:

O utilizador pode selecionar a opção “Modificar Ocorrência” depois poderá

alterar o departamento ao escolher um dos departamentos disponíveis.

História: Criado em Maio de 2016

7. Suporte Material

110


Descrição: O responsável de departamento deve ser notificado por correio eletrónico

de novas ocorrências.

Razão: O moderador ao validar a ocorrência, notifica o departamento responsável

pela natureza da ocorrência por correio eletrónico de modo a ter acesso

rápido à informação da mesma.


Critérios de

Ajuste:

O departamento responsável pela ocorrência irá ser notificado por correio

eletrónico pelo moderador. Nesta notificação encontra-se a informação

básica da ocorrência bem como o link para a página da mesma.



Descrição: O sistema deve ser atrativo para todas as faixas etárias.

Razão: O sistema tem que estar preparado para que todas as pessoas consigam

compreender facilmente o seu conteúdo, independentemente da sua faixa

etária.

Origem: Persona “O Reformado”

Critérios de

Ajuste:

Uma amostra de utilizadores-alvo devem, sem qualquer estímulo

propositado, iniciar o uso do artigo dentro de três minutos após o primeiro

contacto com ele

História: Criado em 30 de Outubro de 2015

7. Suporte Material

111


Descrição: O sistema mostra todos os marcadores relativos às ocorrências reportadas

num mapa.

Razão: Para uma melhor perceção da localização das ocorrências e da quantidade

de ocorrências existentes no município.


Critérios de

Ajuste:

Durante a consulta das ocorrências pode ser apresentada a localização das

mesmas através de um mapa com os marcadores.



Descrição: Os marcadores das ocorrências devem ser classificados de acordo com o

seu estado.

Razão: Os marcadores modicam de cor de acordo com o estado da ocorrência para

uma mais fácil leitura do mapa fornecido pela Google Maps.



7. Suporte Material

112


Descrição: Os marcadores do mapa das ocorrências com o estado “Finalizado” devem

tornar-se inviáveis após serem avaliadas com nota positiva.

Razão: Para evitar o excesso de marcadores e de informações na listagem de

ocorrências com estado “Concluído”.




Descrição: A lista das ocorrências deve apresentar cores diferentes para cada estado.

Razão: As ocorrências têm que ser classificados de acordo com o estado em que se

encontram.



7. Suporte Material

113


Descrição: O sistema deve ter uma navegação fácil entre ocorrências.

Razão: Quando um utilizador está a consultar uma ocorrência, o acesso a outra tem

que ser fácil e intuitivo


História: Criado em 03 de novembro de 2015


Descrição: Interface apelativo ao utilizador.

Razão: A interface tem que ser simples e atraente para que o utilizador tenha

facilidade em utilizar as funcionalidades da ferramenta.


Critérios de

Ajuste:

O utilizador tem que ficar cativado com a interface do sistema


7. Suporte Material

114


Descrição: A interface da aplicação é dimensionada de acordo com o tamanho do ecrã

do dispositivo.

Razão: Ao ser acedida de dispositivos diferentes, a aplicação tem que se adaptar à

resolução de cada um deles.


Critérios de

Ajuste:

A aplicação tem que ter tamanhos de janela diferentes quando é acedida em

dispositivos com o tamanho de ecrã diferente



Descrição: Deve ser fácil aprender a utilizar o sistema.

Razão: A interface do sistema deve ser feita para que um utilizador com duas horas

de utilização consiga utilizar noventa por cento das funcionalidades


Critérios de

Ajuste:

No final de duas horas de utilização do sistema, um utilizador consegue

utilizar noventa por cento das funcionalidades


7. Suporte Material

115


Descrição: O tempo de resposta do sistema deve ser no máximo de dois segundos

Razão: O sistema tem que responder a um pedido de um utilizador no máximo em

dois segundos para que o utilizador tenha uma melhor experiência na

utilização do sistema.


Critérios de

Ajuste:

Quando o utilizador faz um pedido ao servidor este responde no máximo

em dois segundos.



Descrição: O sistema deve possuir um grau de disponibilidade elevado.

Razão: O utilizador tem que conseguir ter acesso ao sistema em qualquer hora de

qualquer dia do ano.



7. Suporte Material

116


Descrição: Aplicação móvel a funcionar nas versões mais recentes Android.

Razão: O sistema tem que ser possível de utilizar em dispositivos móveis, não só

para aumentar o número de utilizadores como também para melhorar a

experiência dos mesmos.


Critérios de

Ajuste:

Um utilizador pode aceder à aplicação móvel se estiver a utilizar um

dispositivo Android.



Descrição: Aplicação Web a funcionar nas versões mais recentes do Firefox, Google

Chrome e Internet Explorer.


História: Criado em 03 de Novembro de 2015

7. Suporte Material

117


Descrição: Adaptação a novas necessidades de negócio

Razão: O sistema necessita de se adaptar às novas necessidades de negócio para

que consiga responder e proporcionar a melhor experiência possível ao

utilizador.


Critérios de

Ajuste:

O sistema deve estar preparado para se adaptar às novas regras de negócio

da organização, para isso deverá permitir adicionar, modificar ou remover

módulos facilmente.



Descrição: Caso existam falhas no sistema, estas devem ser corrigidas num dia.

Razão: Quando existirem falhas no sistema, estas têm que ser corrigidas o mais

rapidamente possível para que os utilizadores possam voltar a utilizar o

sistema também o mais rápido possível.


Critérios de

Ajuste:

Caso o sistema esteja com uma falha, esta tem que ser corrigida no espaço

de um dia.


7. Suporte Material

118


Descrição: A aplicação deve garantir que somente os utilizadores autorizados podem

reportar novas ocorrências.

Razão: O sistema tem que ser robusto o suficiente para garantir que uma pessoa

que não esteja autenticada, não consiga aceder a certas funcionalidades do

sistema.


Critérios de

Ajuste:

Uma pessoa que não esteja devidamente autenticada não pode aceder a

funcionalidades do sistema que necessitem de autenticação.



Descrição: Proteger a informação pessoal e as credenciais dos utilizadores.

Razão: O sistema tem que ser seguro o suficiente para garantir que não é possível

aceder à informação pessoal nem às credenciais dos utilizadores


Critérios de

Ajuste:

Um utilizador não pode aceder à informação pessoal de outro utilizador nem

às credenciais do mesmo.


7. Suporte Material

119


Descrição: Evitar a criação de multi-contas.

Razão: O sistema tem que garantir, no momento da criação de uma nova conta, que

o utilizador não tem uma conta criada.


Critérios de

Ajuste:

Um utilizador necessita de um e-mail, de uma morada e dos seus dados

pessoais para que a criação de duas ou mais contas por parte do mesmo

utilizador seja evitada.



Descrição: O utilizador confirma o seu registo por e-mail.

Razão: É importante que o utilizador do sistema confirme o seu registo através do

seu e-mail evitando que sejam utilizados e-mails falsos, ou de outras

pessoas sem autorização. Desta forma é possível ter a certeza que o

utilizador é contactável através dessa mesma conta de e-mail.


Critérios de

Ajuste:

O utilizador recebe um e-mail com um link para validar o seu registo. Após

clicar no link a sua conta será “ativada” na base de dados.


7. Suporte Material

120


Descrição: Evitar a autenticação dos utilizadores bloqueados.

Razão: O sistema tem que garantir, no momento da criação de uma nova conta, que

o utilizador não tem uma conta criada.


Critérios de

Ajuste:

Um utilizador necessita de um e-mail, uma morada e dos dados pessoais

para que a criação de duas ou mais contas por parte do mesmo utilizador

seja evitada.



Descrição: O produto deve usar a ortografia multi-língua

Razão: O sistema pode ser utilizado por todos os cidadãos.




Descrição: O sistema deve autenticar todos os dados do utilizador.

Razão: O sistema tem que validar os dados dos utilizadores para garantir que o

utilizador inseriu os dados certos e a conta criada não é de um utilizador já

existente.


Critérios de

Ajuste:

Quando um utilizador cria uma nova conta, todos os dados inseridos pelo

utilizador são validados pelo sistema.


7. Suporte Material

121

Anexo B – Categorização dos Riscos

Impacto

Probabilidade

Menor

Moderado

Sério

Muito Sério

Extremo

Catastrófico

Quase certo Alto Alto Severo Severo Severo Severo

Provável Moderado Alto Alto Severo Severo Severo

Possível Baixo Moderado Alto Alto Severo Severo

Improvável Baixo Baixo Moderado Moderado Alto Severo

Raro Baixo Baixo Moderado Moderado Moderado Alto

Quase Impossível Baixo Baixo Baixo Moderado Moderado Moderado

Tabela 22 - Escala de categorias para classificação de riscos

7. Suporte Material

123

Categorização dos Riscos

A tabela 23 representa a categorização de cada risco identificado. Para cada risco foi

determinado o impacto, a probabilidade e o risco.

Número do risco Impacto Probabilidade Risco

1 Extremo Possível Severo

2 Sério Improvável Moderado


4 Menor Possível Baixo

5 Moderado Provável Alto

6 Menor Improvável Baixo


8 Catastrófico Improvável Severo

9 Menor Improvável Baixo

10 Moderado Possível Moderado

11 Extremo Improvável Alto

12 Muito Sério Possível Alto

Tabela 23 - Categorização dos riscos

Na tabela 23 é possível verificar que os riscos não são todos iguais, e que, desta forma

podem ser priorizados de acordo com o seu impacto. Na priorização podemos identificar

e aplicar técnicas de mitigação para os riscos que tenham maior impacto e assim não

gastar muito tempo na aplicação de técnicas de mitigação nos riscos com baixo impacto.

Mitigação dos Riscos

Nesta secção serão apresentadas as técnicas para mitigações dos riscos associados ao

projeto que foram identificados no capítulo Modelação e Riscos do Projeto.

Risco 1 Má adesão por parte dos utilizadores à aplicação

Mitigação Considerar oferecer aos utilizadores garantias de segurança

Considerar a realização de publicidade.

Tabela 24 - Mitigação do Risco 1

7. Suporte Material

124

Risco 2 Os reportes não serem enviados por falta de acesso a internet ou outras

razões.

Mitigação Considerar guardar previamente o formulário do reporte no telemóvel, caso

este não tenha acesso à internet para que posteriormente seja enviado quando o

utilizador tenha acesso à internet.


Risco 3 Os reportes de ocorrências conterem informação errada ou insuficiente.

Mitigação O utilizador que está a reportar a ocorrência recebe o relatório final do seu

reporte para a confirmação dos detalhes fornecidos.


Risco 4 Localização da ocorrência inserida incorretamente.

Mitigação Considerar a utilização do GPS do telemóvel para utilização da informação da

localização automática do local.


Risco 5 Um utilizador bloqueado tenta criar outra conta.

Mitigação Considerar verificar a existência do e-mail, morada e dados pessoais inseridos

pelo utilizador.


Risco 6 O utilizador reportarem situações que não se destinam à nossa aplicação.

Mitigação Considerar a criação de uma equipa responsável por avaliar as ocorrências

antes de serem encaminhadas para o departamento responsável.


Risco 7 O reporte de uma ocorrência é diferente da ocorrência reportada.

Mitigação Considerar oferecer ao utilizador a possibilidade de alterar os detalhes do seu

reporte após de este ter sido enviado.


7. Suporte Material

125

Risco 8 Existir alguma avaria no servidor de armazenamento de dados.

Mitigação Considerar a existência de uma arquitetura de servidores com redundância.

Considerar a realização de cópias de segurança.


Risco 9 Algum dos elementos da equipa abandonar o projeto.

Mitigação Considerar a existência de documentação sempre que concluída uma tarefa.


Risco 10 Os utilizadores acharem a interface difícil de utilizar.

Mitigação Considerar a utilização de uma interface mais amigável de modo a que todas

as faixas etárias a achem apelativa.


Risco 11 Existir roubo dos dados dos utilizadores.

Mitigação Considerar o desenvolvimento da aplicação com todas as normas de segurança

móvel conhecidas.


Risco 12 Falta de investimento para a progressão do projeto.

Mitigação Considerar a participação em programas de investimento.


7. Suporte Material

126

Anexo C - Personas

Personas

Antes de iniciar o processo de desenvolvimento do sistema foi necessário entender o que

era necessário para os utilizadores. Desta forma foi possível identificar as caraterísticas e

as funcionalidades que farão este sistema ter sucesso.

As personas são pessoas fictícias consideradas potenciais utilizadores do sistema e são

representantes de grupos de utilizadores com diferentes caraterísticas.

Neste sentido, foram criados quatro personas (“O Universitário, “A vereadora

competente”, “O Desportista”, e “O Reformado”) que serviram para definir os objetivos

e intenções dos utilizadores, orientando decisões importantes, como por exemplo em

relação à organização da interface, à usabilidade do sistema e às funcionalidades mais

úteis.

7. Suporte Material

127

1. “O Universitário”

NOME:

SEXO:

IDADE:

CARGO:

EMPRESA:

EDUCAÇÃO:

OBJETIVOS PESSOAIS:

OBJETIVOS PROFISSIONAIS:

Pedro Costa

Masculino

25

Estudante

Universidade do Minho

Estudante Universitário

Terminar o curso

Encontrar um bom emprego na sua área de formação.

O Pedro é estudante na Universidade do Minho, é um bom aluno e uma pessoa divertida. Neste

momento, durante o período de aulas ele vive em Braga com mais 3 amigos que frequentam o seu

curso. Ele e os colegas adoram videojogos e passam muito do tempo livre a jogar entre eles.

O Pedro gosta também de computadores e de redes sociais e é um utilizador frequente de aplicações

de notícias.

O Pedro quando vai para universidade vê que a maioria da sinalização da sua rua se encontra

coberta por uma vasta vegetação, fazendo com que não possa ver o que está no sinal de trânsito

mas, como este já conhece a rua e a sinalização já não se preocupa. O Pedro preocupa-se com as

pessoas que lá passam que não conhecem a estrada e a sua sinalização, tendo este a intenção de

intervir e de reportar a situação. No entanto o Pedro não tem disponibilidade para se deslocar à

Junta de Freguesia no horário que esta está aberta.

7. Suporte Material

128

2. “A Vereadora”

NOME:

SEXO:

IDADE:

CARGO:

EMPRESA:

EDUCAÇÃO:

Maria Silva

Feminino

33

Vereadora da cultura

Câmara Municipal de Vila Verde

Mestrado em Literatura Portuguesa

Solteira, gosta de sair à noite e fazer novas amizades.

Não tem conhecimentos muito avançados em tecnologias mas é utilizadora assídua do

computador.

Adora ler, pois considera que ler é a melhor forma de melhorar o conhecimento e ganhar cultura

geral.

Gostava de receber notificações atempadamente sobre variadas ocorrências relativas a espaços

públicos do seu município, de modo a intervir em tempo útil.

7. Suporte Material

129

3. “O Desportista”

NOME:

SEXO:

IDADE:

CARGO:

EMPRESA:

EDUCAÇÃO:

João Macedo

Masculino

25

Lojista

IKEA

12º ano de escolaridade

Solteiro. É uma pessoa que gosta de adrenalina e de experimentar coisas novas.

O João e os seus amigos de equipa, todos os dias ao início da manha, fazem exercício

cardiovascular, correndo durante uma hora por dia passando por várias freguesias do

município. Durante o percurso, deparam-se sempre com eletrodomésticos e lixo nas bermas. O

João e os seus amigos queriam reportar estes factos mas como eles não conhecem a maioria

dos caminhos e os nomes dos mesmos não conseguem fornecer a localização exata da

ocorrência.

O João e os seus amigos gostavam de reportar ocorrências sem ter a preocupação de saber o

nome da rua.

7. Suporte Material

130

4. “O Reformado”

NOME:

SEXO:

IDADE:

CARGO:

EMPRESA:

EDUCAÇÃO:

Vítor Cunha

Masculino

68

Reformado

--

12º Ano de escolaridade

Viúvo, com 2 filhos e 3 netos. Vive sozinho desde o falecimento da esposa e as formas que tem

para passar o seu tempo é assistir televisão, ler jornais e livros. Não gosta do computador mas

usa um Tablet que o neto lhe ofereceu e ensinou a utilizar para aplicações que permitem

visualizar coisas básicas como meteorologia, notícias, contas bancárias e e-mail.

O Senhor Vítor é dono de várias herdades no norte do país, mas não tem a possibilidade de se

deslocar todos os anos ao norte do país então, não pode verificar o estado dos seus terrenos. O

senhor Vítor recebe multas em casa, pois o município local onde se encontram os terrenos

recebeu várias denúncias dos habitantes que viam as suas habitações cercadas pela densa

vegetação do terreno vizinho.

Este senhor gostava de ser informado em tempo útil sobre as ocorrências perto dos meus

terrenos, de modo a intervir em tempo útil e assim evitar multas impostas pelo incumprimento

da lei da distância da vegetação das habitações.

7. Suporte Material

131

Anexo D - Wireframes

Wireframes

Nesta secção são apresentados os principais wireframes. Estes foram criados no software

Pencil Evolus e pretendem demostrar aquilo que se pretende implementar em cada layout

da aplicação móvel.

É de salientar que estes wireframes foram validados e alterados ao longo das várias

interações de design. Alterações essas que irão também ocorrer durante a fase de

desenvolvimento, de tal forma que é possível a existência de pequenas modificações de

interface caraterísticas de mudanças de âmbito que poderão acontecer durante as iterações

e validações da fase de desenvolvimento.

Figura 81 - Principais Wireframes – Aplicação Móvel

7. Suporte Material

132

Anexo E – Classe Singleton

Classe Singleton

A classe Singleton faz o encapsulamento da RequestQueue e outras funcionalidades do

Volley. De modo a garantir que a RequestQueue permaneça durante o ciclo de vida da

aplicação, esta deve ser instanciada de acordo com o contexto da aplicação

(getApplicationContext()) e não pelo contexto de uma activity (activity.this). Esta abordagem

garante que o RequestQueue não seja recriado sempre que uma activity é iniciada.

Figura 82 - Classe Singleton (Fonte: developer.android.com)

Ricardo Filipe da Silva Costa -...

Documents

Transcript of Ricardo Filipe da Silva Costa -...