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
Universidade do Minho
Escola de EngenhariaDepartamento 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
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.
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.
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.
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
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 62.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.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.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
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 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
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 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 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
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
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
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:
1 Propósito do Projeto 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.
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
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.
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
2. Estado da Arte
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-deveu-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.
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
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.
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]
2. Estado da Arte
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,
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.
2. Estado da Arte
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
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.
2. Estado da Arte
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.
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.
2. Estado da Arte
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
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
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
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
“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.
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
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.
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;
3 Modelação e Riscos do Projeto
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.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
3 Modelação e Riscos do Projeto
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 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
3 Modelação e Riscos do Projeto
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
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.
3 Modelação e Riscos do Projeto
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
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.
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.
3 Modelação e Riscos do Projeto
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
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
3 Modelação e Riscos do Projeto
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
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
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
