Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
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
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
Tabela 25 - Mitigação do Risco 2 124
Tabela 26 - Mitigação do Risco 3 124
ix
Tabela 27 - Mitigação do Risco 4 124
Tabela 28 - Mitigação do Risco 5 124
Tabela 29 - Mitigação do Risco 6 124
Tabela 30 - Mitigação do Risco 7 124
Tabela 31 - Mitigação do Risco 8 125
Tabela 32 - Mitigação do Risco 9 125
Tabela 33 - Mitigação do Risco 10 125
Tabela 34 - Mitigação do Risco 11 125
Tabela 35 - Mitigação do Risco 12 125
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 Propósito do Projeto
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.
1 Propósito do Projeto
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.
1 Propósito do Projeto
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
1 Propósito do Projeto
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.
1 Propósito do 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
3 Modelação e Riscos do Projeto
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.
3 Modelação e Riscos do Projeto
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
3 Modelação e Riscos do Projeto
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.
3 Modelação e Riscos do Projeto
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.
3 Modelação e Riscos do Projeto
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
3 Modelação e Riscos do Projeto
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
3 Modelação e Riscos do Projeto
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
3 Modelação e Riscos do Projeto
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
3 Modelação e Riscos do Projeto
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.
3 Modelação e Riscos do Projeto
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
Requisito Descrição
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.
3 Modelação e Riscos do Projeto
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.
Requisito Descriçã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.
Requisito Descrição
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
Requisito Descrição
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
3 Modelação e Riscos do Projeto
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.
Requisito Descrição
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
Requisito Descrição
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
Requisito Descrição
R48 O produto deve usar a ortografia multi-língua.
Tabela 11 - Requisitos Culturais e Políticos
3 Modelação e Riscos do Projeto
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.
Requisito Descrição
R49 O sistema deve autenticar todos os dados do utilizador
Tabela 12 - Requisitos Legais
Figura 14 – Método MoSCoW
3 Modelação e Riscos do Projeto
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
3 Modelação e Riscos do Projeto
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.
3 Modelação e Riscos do Projeto
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
3 Modelação e Riscos do Projeto
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.
3 Modelação e Riscos do Projeto
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
3 Modelação e Riscos do Projeto
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
3 Modelação e Riscos do Projeto
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
3 Modelação e Riscos do Projeto
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
3 Modelação e Riscos do Projeto
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
3 Modelação e Riscos do Projeto
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
3 Modelação e Riscos do Projeto
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
3 Modelação e Riscos do Projeto
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
3 Modelação e Riscos do Projeto
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
3 Modelação e Riscos do Projeto
49
Figura 24 – Modelo Entidade Relação - Web
3 Modelação e Riscos do Projeto
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]
4 Trabalho Desenvolvido
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)
4 Trabalho Desenvolvido
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
4 Trabalho Desenvolvido
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
4 Trabalho Desenvolvido
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
4 Trabalho Desenvolvido
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
4 Trabalho Desenvolvido
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
4 Trabalho Desenvolvido
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
4 Trabalho Desenvolvido
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
4 Trabalho Desenvolvido
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;
runtime/ Ficheiros gerados durante a execução;
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;
runtime/ Ficheiros gerados durante a execução;
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.
4 Trabalho Desenvolvido
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)
4 Trabalho Desenvolvido
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;
Responsável de Departamento;
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.
4 Trabalho Desenvolvido
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
4 Trabalho Desenvolvido
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
4 Trabalho Desenvolvido
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
4 Trabalho Desenvolvido
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.
4 Trabalho Desenvolvido
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
4 Trabalho Desenvolvido
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
4 Trabalho Desenvolvido
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
4 Trabalho Desenvolvido
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
4 Trabalho Desenvolvido
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
4 Trabalho Desenvolvido
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
4 Trabalho Desenvolvido
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
4 Trabalho Desenvolvido
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
4 Trabalho Desenvolvido
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
4 Trabalho Desenvolvido
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
4 Trabalho Desenvolvido
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
4 Trabalho Desenvolvido
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)
4 Trabalho Desenvolvido
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)
4 Trabalho Desenvolvido
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
4 Trabalho Desenvolvido
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
4 Trabalho Desenvolvido
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
4 Trabalho Desenvolvido
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.
4 Trabalho Desenvolvido
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
4 Trabalho Desenvolvido
85
URI Método Parâmetros
/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.
URI Método Parâmetros
/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
4 Trabalho Desenvolvido
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
5 Análise de Resultados
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;
5 Análise de Resultados
88
Responsável de Departamento;
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:
5 Análise de Resultados
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.
5 Análise de Resultados
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.
6. Conclusões e Trabalho Futuro
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.
6. Conclusões e Trabalho Futuro
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
Requisito: R2 Tipo de Requisito: 3.4 Prioridade: M
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.
Origem: Equipa de desenvolvimento
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.
História: Criado em Dezembro de 2015
7. Suporte Material
98
Requisito: R3 Tipo de Requisito: 3.4 Prioridade: M
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.
História: Criado em Dezembro de 2015
Requisito: R4 Tipo de Requisito: 3.4 Prioridade: M
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.
Origem: Carlos Tiago – Vereador da Câmara Municipal de Vila Verde
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.
História: Criado em Dezembro de 2015
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.
Origem: Carlos Tiago – Vereador da Câmara Municipal de Vila Verde
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.
História: Criado em Dezembro de 2015
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.
História: Criado em Dezembro de 2015
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.
Origem: Carlos Tiago – Vereador da Câmara Municipal de Vila Verde
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.
História: Criado em Dezembro de 2015
Requisito: R8 Tipo de Requisito: 3.3 Prioridade: M
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.
Origem: Carlos Tiago – Vereador da Câmara Municipal de Vila Verde
Critérios de
Ajuste:
O utilizador que reportar uma ocorrência poderá receber notificações sobre
eventuais mudanças de estado da mesma.
História: Criado em Dezembro de 2015
7. Suporte Material
101
Requisito: R9 Tipo de Requisito: 3.4 Prioridade: C
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.
História: Criado em Dezembro de 2015
Requisito: R10 Tipo de Requisito: 3.4 Prioridade: W
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.
Origem: Vítor Silva – Presidente de Junta de Esqueiros – Vila Verde
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.
História: Criado em Dezembro de 2015
7. Suporte Material
102
Requisito: R12 Tipo de Requisito: 3.4 Prioridade: S
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.
História: Criado em Dezembro de 2015
Requisito: R11 Tipo de Requisito: 3.4 Prioridade: C
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.
Origem: Vítor Silva – Presidente de Junta de Esqueiros – Vila Verde
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.
História: Criado em Dezembro de 2015
7. Suporte Material
103
Requisito: R13 Tipo de Requisito: 3.4 Prioridade: C
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.
Origem: Equipa de desenvolvimento
História: Criado em Dezembro de 2015
Requisito: R14 Tipo de Requisito: 3.4 Prioridade: C
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.
Origem: Equipa de desenvolvimento
Critérios de
Ajuste:
O utilizador autenticado consulta os dados de uma dada ocorrência através
dos marcadores existentes no mapa.
História: Criado em Dezembro de 2015
7. Suporte Material
104
Requisito: R16 Tipo de Requisito: 3.4 Prioridade: M
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.
Origem: Carlos Tiago – Vereador da Câmara Municipal de Vila Verde
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.
História: Criado em Dezembro de 2015
Requisito: R15 Tipo de Requisito: 3.4 Prioridade: M
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.
Origem: Carlos Tiago – Vereador da Câmara Municipal de Vila Verde
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.
História: Criado em Dezembro de 2015
7. Suporte Material
105
Requisito: R17 Tipo de Requisito: 3.4 Prioridade: S
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.
Origem: Carlos Tiago – Vereador da Câmara Municipal de Vila Verde
História: Criado em Dezembro de 2015
Requisito: R18 Tipo de Requisito: 3.4 Prioridade: S
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.
Origem: Equipa de desenvolvimento
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.
História: Criado em Dezembro de 2015
7. Suporte Material
106
Requisito: R19 Tipo de Requisito: 3.4 Prioridade: M
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.
Origem: Equipa de desenvolvimento.
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
Requisito: R20 Tipo de Requisito: 3.4 Prioridade: C
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.
Origem: Equipa de desenvolvimento.
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
Requisito: R21 Tipo de Requisito: 3.4 Prioridade: M
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.
Origem: Equipa de desenvolvimento
História: Criado em dezembro de 2015
Requisito: R22 Tipo de Requisito: 3.4 Prioridade: M
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.
Origem: Equipa de desenvolvimento.
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”;
História: Criado em maio de 2016
7. Suporte Material
108
Requisito: R23 Tipo de Requisito: 3.4 Prioridade: C
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.
Origem: Equipa de desenvolvimento.
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
Requisito: R24 Tipo de Requisito: 3.4 Prioridade: S
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.
Origem: Equipa de desenvolvimento.
Critérios de
Ajuste:
O moderador ao consultar a ocorrência reportada pode comunicar com o
utilizador que reportou a mesma.
História: Criado em maio de 2016
7. Suporte Material
109
Requisito: R25 Tipo de Requisito: 3.4 Prioridade: M
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.
Origem: Equipa de desenvolvimento.
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.
História: Criado em maio de 2016
Requisito: R26 Tipo de Requisito: 3.4 Prioridade: S
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.
Origem: Equipa de desenvolvimento.
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
Requisito: R27 Tipo de Requisito: 3.4 Prioridade: C
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.
Origem: Equipa de desenvolvimento.
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.
História: Criado em maio de 2016
Requisito: R28 Tipo de Requisito: 3.5 Prioridade: S
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
Requisito: R29 Tipo de Requisito: 3.5 Prioridade: S
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.
Origem: Carlos Tiago – Vereador da Câmara Municipal de Vila Verde
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.
História: Criado em dezembro de 2015
Requisito: R30 Tipo de Requisito: 3.5 Prioridade: S
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.
Origem: Equipa de desenvolvimento.
História: Criado em dezembro de 2015
7. Suporte Material
112
Requisito: R31 Tipo de Requisito: 3.5 Prioridade: C
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”.
Origem: Equipa de desenvolvimento.
História: Criado em maio de 2016
Requisito: R32 Tipo de Requisito: 3.5 Prioridade: S
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.
Origem: Equipa de desenvolvimento.
História: Criado em Dezembro de 2015
7. Suporte Material
113
Requisito: R33 Tipo de Requisito: 3.5 Prioridade: S
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
Origem: Equipa de desenvolvimento.
História: Criado em 03 de novembro de 2015
Requisito: R34 Tipo de Requisito: 3.5 Prioridade: W
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.
Origem: Equipa de desenvolvimento.
Critérios de
Ajuste:
O utilizador tem que ficar cativado com a interface do sistema
História: Criado em 03 de novembro de 2015
7. Suporte Material
114
Requisito: R35 Tipo de Requisito: 3.5 Prioridade: C
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.
Origem: Equipa de desenvolvimento.
Critérios de
Ajuste:
A aplicação tem que ter tamanhos de janela diferentes quando é acedida em
dispositivos com o tamanho de ecrã diferente
História: Criado em 03 de novembro de 2015
Requisito: R36 Tipo de Requisito: 3.5 Prioridade: S
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
Origem: Equipa de desenvolvimento.
Critérios de
Ajuste:
No final de duas horas de utilização do sistema, um utilizador consegue
utilizar noventa por cento das funcionalidades
História: Criado em 03 de novembro de 2015
7. Suporte Material
115
Requisito: R37 Tipo de Requisito: 3.5 Prioridade: C
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.
Origem: Equipa de desenvolvimento.
Critérios de
Ajuste:
Quando o utilizador faz um pedido ao servidor este responde no máximo
em dois segundos.
História: Criado em 03 de novembro de 2015
Requisito: R38 Tipo de Requisito: 3.5 Prioridade: S
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.
Origem: Equipa de desenvolvimento.
História: Criado em 03 de novembro de 2015
7. Suporte Material
116
Requisito: R39 Tipo de Requisito: 3.5 Prioridade: S
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.
Origem: Equipa de desenvolvimento.
Critérios de
Ajuste:
Um utilizador pode aceder à aplicação móvel se estiver a utilizar um
dispositivo Android.
História: Criado em 03 de novembro de 2015
Requisito: R40 Tipo de Requisito: 3.5 Prioridade: S
Descrição: Aplicação Web a funcionar nas versões mais recentes do Firefox, Google
Chrome e Internet Explorer.
Origem: Equipa de desenvolvimento.
História: Criado em 03 de Novembro de 2015
7. Suporte Material
117
Requisito: R41 Tipo de Requisito: 3.5 Prioridade: S
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.
Origem: Equipa de desenvolvimento.
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.
História: Criado em 03 de Novembro de 2015
Requisito: R42 Tipo de Requisito: 3.5 Prioridade: S
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.
Origem: Equipa de desenvolvimento.
Critérios de
Ajuste:
Caso o sistema esteja com uma falha, esta tem que ser corrigida no espaço
de um dia.
História: Criado em 03 de Novembro de 2015
7. Suporte Material
118
Requisito: R43 Tipo de Requisito: 3.5 Prioridade: M
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.
Origem: Equipa de desenvolvimento.
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.
História: Criado em 03 de Novembro de 2015
Requisito: R44 Tipo de Requisito: 3.5 Prioridade: M
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
Origem: Equipa de desenvolvimento.
Critérios de
Ajuste:
Um utilizador não pode aceder à informação pessoal de outro utilizador nem
às credenciais do mesmo.
História: Criado em 03 de novembro de 2015
7. Suporte Material
119
Requisito: R45 Tipo de Requisito: 3.5 Prioridade: M
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.
Origem: Equipa de desenvolvimento.
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.
História: Criado em 03 de novembro de 2015
Requisito: R46 Tipo de Requisito: 3.5 Prioridade: M
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.
Origem: Equipa de desenvolvimento.
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.
História: Criado em 03 de Novembro de 2015
7. Suporte Material
120
Requisito: R47 Tipo de Requisito: 3.5 Prioridade: M
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.
Origem: Equipa de desenvolvimento.
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.
História: Criado em 03 de novembro de 2015
Requisito: R48 Tipo de Requisito: 3.5 Prioridade: C
Descrição: O produto deve usar a ortografia multi-língua
Razão: O sistema pode ser utilizado por todos os cidadãos.
Origem: Equipa de desenvolvimento.
História: Criado em 03 de novembro de 2015
Requisito: R49 Tipo de Requisito: 3.5 Prioridade: M
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.
Origem: Equipa de desenvolvimento.
Critérios de
Ajuste:
Quando um utilizador cria uma nova conta, todos os dados inseridos pelo
utilizador são validados pelo sistema.
História: Criado em 03 de novembro de 2015
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
3 Sério Improvável Moderado
4 Menor Possível Baixo
5 Moderado Provável Alto
6 Menor Improvável Baixo
7 Sério Improvável Moderado
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.
Tabela 25 - Mitigação do Risco 2
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.
Tabela 26 - Mitigação do Risco 3
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.
Tabela 27 - Mitigação do Risco 4
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.
Tabela 28 - Mitigação do Risco 5
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.
Tabela 29 - Mitigação do Risco 6
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.
Tabela 30 - Mitigação do Risco 7
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.
Tabela 31 - Mitigação do Risco 8
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.
Tabela 32 - Mitigação do Risco 9
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.
Tabela 33 - Mitigação do Risco 10
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.
Tabela 34 - Mitigação do Risco 11
Risco 12 Falta de investimento para a progressão do projeto.
Mitigação Considerar a participação em programas de investimento.
Tabela 35 - Mitigação do Risco 12
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)