PSP2: Smart Cities - Segurança

Esta página faz parte do Projeto sobre Cidades Inteligentes, da disciplina Projeto de Sistemas de Produção 2 ministrada pela professora Claudia Melo. O foco do projeto é "identificar, desenhar e implementar soluções (protótipos funcionais) para endereçar uma oportunidade latente ou necessidade/dor existente em Cidades Inteligentes no DF, buscando uma cidade mais sustentável."

Participam da equipe: Alberto Guimarães, Erica Byanca, Michel Melo, Rafael Vilela e Vinicius Coelho

Resumo:

Gestão do Trabalho

Prazos e riscos

Para o gerenciamento de prazos e riscos o grupo decidiu por usar o aplicativo de gerenciamento de projeto Trello (IMAGEM 1).

O nosso quadro no Trello foi divido em cinco listas: tarefa da semana, informações gerais, a fazer, fazendo e feito. Em tarefa da semana é postado a tarefa mais importante que foi definida durante a aula de sexta. Caso seja uma tarefa complexa ela é dividida entre atividades e é posicionada na lista "A Fazer" e posteriormente "Fazendo" e por fim em "Feito". Na lista de Informações gerais é postado informações de grande importância, atividades que duram todo o projeto, entre outros.

O Trello foi de extrema importância para definir prazos e alocar membros para atividades. Além disso as etiquetas foram usadas para classificar o senso de urgência e resolução de problemas encontrados.

Etiquetas utilizadas:

• Azul claro: Atividade opcional;
• Azul escuro: Atividade de prioridade média;
• Lilás: Atividade de prioridade alta;
• Vermelho: Atividade urgente;
• Amarelo: Atividade obrigatória para todos membros;
• Preto: Problema encontrado;
• Verde: problema resolvido/ tarefa da semana concluída.

Métodos ágeis

O projeto serviu como exercício para a aplicação de métodos ágeis. Brainstorming, Design Thinking, Scrum e diversos outros temas relacionados aos princípios de gestão ágil debatidos em sala de aula e fora.

Comunicação

Para a manutenção da comunicação o grupo decidiu reuniões semanais toda segunda-feira entre 18:00 e 19hrs. Outros recados foram passados por um grupo no aplicativo de mensagem instantânea Whatsapp.

Publico-alvo

Para este projeto entendemos como público-alvo dois grupos: cliente intermediário e cliente final.

O cliente intermediário é composto pela professora Claudia Melo e os alunos da disciplina de Projeto de Sistemas de Produção 2. Já o cliente final são os usuários da solução final da disciplina. É importante durante todo o processo de concebimento e prototipação receber feedback desses dois lados.

Definição do Problema

O que são cidades inteligentes?

O primeiro passo para a escolha de um problema específico dentro das áreas que abrange as discussões entorno das Smart Cities é a definição do que são essas cidades. Afinal, o que há de diferente entre elas e uma cidade "comum"?

Uma Smart City é muito mais que uma cidade tecnológica. É um espaço de criatividade, interação, inovação e, principalmente, que se baseia no conhecimento e sustentabilidade. O grande diferencial das cidades inteligentes está na participação engajada da comunidade, gerando uma relação positiva entre pessoas e governo.

Problemas das cidades

Os maiores problemas que envolvem uma cidade são complexos para resolverem. Há muitas variáveis e se mudadas podem implicar na criação de diversos outros problemas. A pobreza, equidade, nutrição em famílias de baixa renda, falta de moradia todos são Wicked Problems . Todos estão conectados, alguns de maneira não tão obvias. É importante frisar que não há soluções exatas, mas sim aproximações para estes problemas.

Assim, utilizando metodologias de design thinking e métodos ágeis as últimas cinco semanas foram caracterizadas por uma fase de imersão.

Brainstorming de Wicked Problems

Nessa fase tivemos a primeira aproximação com os problemas que cercam as cidades. A Imagem 1 ilustra as primeiras percepções do grupo acerca dos Wicked Problems das Smart Cities. O interesse inicial do grupo foram os temas "Filas e Burocracia" e "Lixo/Reciclagem".

A segunda fase do brainstorming foi relacionada aos problemas que atingem um grupo específico. Escolhemos como foco de entrevista o grupo "Estudantes" e "Residentes de Cidades Satélites".

Dados Coletados

Para a geração de dados foi realizado cerca de 30 entrevistas com pessoas de diferentes faixas etárias e posições social. As entrevistas preliminares seguiram o modelo de Design Thinking e englobaram todos os Wicked Problems.

Uma segunda entrevista foi realizada, adicionando aos dados 10 novas entrevistas. As dez últimas entrevistas foram focadas no tema Segurança. O questionário usado como base para a entrevista se encontra neste link.

Pontos de Vista

Com ajuda de post-its e com o modelo postado no Moodle, foram organizados diversos pontos de vistas observados nas entrevistas. Segundo ordens da professora , escolhemos três pontos de vistas, um para cada aluno do grupo presente na aula do dia 18 de abril. Para cada post-it, geramos cinco alternativas radicais para resolver os problemas descritos no ponto de vista (IMAGEM 4).

Problemas encontrados na definição do tema específico

Com os dados extraídos com os pontos de vista e entrevista com o professor Ari Ribeiro, a equipe decidiu que o melhor tema a ser trabalhado deveria ser o controle do fluxo de pessoas dentro do campus Darcy Ribeiro, com foco na criação de disciplinas durante o período noturno.

Este tema teve que ser alterado, pois após entrevistas feitas pelo time com seguranças da universidade e servidores da UnB, além de discussão com a professora sobre o projeto foram identificados problemas na procura de uma resolução viável, dentre eles:

• Modificar a grade horária e locais das aulas poderia gerar grande disputa política entre os departamentos dos cursos quanto a quem deve ter prioridade na escolha das salas;
• A solução iria cair no algoritmo do travelling salesman que té hoje não possui solução exata.
• Aumentar o fluxo de pessoas não suprime a sensação de insegurança.

Identificados esses problemas a única opção que o time teve foi especificar melhor o problema central de forma que sua solução seja viável. Para isso foi analisado novamente os dados coletados e extraído um novo ponto de vista (em destaque na IMAGEM 4).

O Problema específico

A última fase da definição do problema foi a criação de uma estrutura baseada no modelo do Elevator Pitch . A estrutura se encontra abaixo.

O Elevator Pitch foi concebido através de conversas informais com os cooperadores da segurança e também questionários realizado com estudantes. Mesmo com à alteração do tema conseguimos aproveitar grande parte dos dados coletados previamente, porém, não satisfeitos fomos atras de mais dados para dar fundamentos a pesquisa. Dessa vez de maneira formal fora obtido informações cruciais dos responsáveis pela segurança e mais uma vez a realização de pesquisa entre os usuários dos estacionamentos.

Para definir o problema, logo nas primeiras reuniões após o grupo ser formado, foi consenso que queríamos trabalhar uma solução para problemas dentro do campus, direcionada para a área de segurança.

Procurando outra solução com base nas respostas do questionário anterior e conversando com pessoas envolvidas na segurança da UnB em geral, como seguranças, funcionários, etc, as informações que obtivemos foram, principalmente:

• Funcionários da segurança de empresas terceirizadas têm atuação limitada, pois suas atividades são diferentes das da polícia;
• O nível de respeito com que são tratados também é diferente do da polícia;
• As ocorrências mais frequentes no interior dos prédios são assédio, pichação e consumo de drogas;
• Os assaltos, que eram a parte que chamou mais nossa atenção, são razoavelmente raros no interior dos prédios, sendo mais frequentes nos estacionamentos;
• Propor qualquer solução que implicasse mudança da infraestrutura ou de algum sistema informático seria muito desgastante e tomaria muito tempo, dado o nível de burocracia vigente na universidade.

Os problemas mais apontados pelos entrevistados sempre envolviam o número do efetivo de seguranças atuando no campus e falta na infraestrutura, onde eles se sentem mais sensíveis. Então tentamos sair de dentro dos prédios e buscar algum problema tratável - e que não fosse de infraestrutura - nos estacionamentos. O problema mais recorrente nos estacionamentos da UnB como um todo são os assaltos. Mesmo antes de iniciar a pesquisa nesse tema já ouvíamos de nossos colegas os problemas em vir para a UnB e deixar o carro num estacionamento mal posicionado, mal iluminado, superlotado e mal vigiado. Um dos nossos integrantes chegou a ter seu veículo violado no estacionamento da Faculdade de Tecnologia.

Dada essa situação, procuramos focar nessa linha de pensamento, em reduzir as principais causas dos assaltos nos estacionamentos. Como sempre caímos no mesma situação difícil de ter que lidar com a falta de infraestrutura do campus, chegamos a pensar em desistir de trabalhar no tema segurança, ou de trabalhar com uma solução dentro da UnB. Após refletir sobre o tema chegamos a uma solução acessível para minimizar o impacto da violência nos  veículos que circulam no campus, contando, é claro, com a colaboratividade dos alunos.

Sabemos, tanto por observação própria por circular no campus quanto com base nas pesquisas que os estacionamentos não são tão frequentemente vigiados pelos seguranças, principalmente à noite, por conta do efetivo considerado por eles mesmos insuficiente, dado o tamanho do campus. Também falta iluminação e espaço, e muitos lugares que estão sendo utilizados de pouco tempo pra cá devido superlotação ficam mal posicionados. Também há uma dificuldade quando se vê uma ocorrência, simples ou não, e se quer reportar a alguma autoridade competente, ou ao próprio dono do veículo, mas não há informação sobre quem seria esse proprietário, ou o ato de ir até as autoridades pode ser demorado. Tudo isso contribui para o fato de que, quando ocorre alguma coisa com um veículo, há um intervalo de tempo razoavelmente longo até que se perceba e se tome uma solução a respeito, o que faz com que as providências tomadas a partir de então percam eficiência, e, dependendo da situação, até mesmo a efetividade. Tomamos esse tempo de resposta longo como o nosso problema a ser resolvido.

Hipótese de Solução

Acredita-se que a afim de chegar a uma solução viável para o problema específico identificado, uma das alternativas de solução seria um aplicativo para celulares. Presumindo-se que grande parte dos estudantes possuem acesso a smartphones, e que tais meios eletrônicos são uma fonte de informação eficiente, devido ao acesso instantâneo, notificações e outros recursos, esta seria uma solução que atende as principais expectativas em relação ao projeto.

Criação do primeiro protótipo

No aplicativo idealizado o usuário pode reportar uma ocorrência (também de forma anônima) em relação a furto de veículos, podendo citar alguns aspectos:

1. Local específico da Universidade em que foi observada a ocorrência
2. Placa de identificação do veículo
3. Modelo/Marca do veículo
4. Cor do veículo
5. Tipo de problema observado

Ficheiro:Psp2seg Lofi.png

IMAGEM 8: Protótipo Lo-FI Materiais usados: Cartolina, folha A4 com botões impressos e cola.

Além disso seria possível anexar uma imagem, a fim de comprovar os fatos, ou suspeitas em relação à ocorrência.

Neste aplicativo o usuário também teria a opção de fazer um cadastro, de forma que o seu veículo seria cadastrado no sistema, e caso houvesse alguma ocorrência com o veículo cadastrado, o usuário receberia uma notificação em seu smartphone, a fim de averiguar o problema relatado. Esta mesma função poderia ser utilizada pelo serviço de segurança privada na Universidade, para que os mesmos estivessem cientes das ocorrências relatadas imediatamente, e pudessem atuar da forma apropriada.

O protótipo lo-fi

Para a criação do protótipo no papel foi dada prioridade ás funções primordiais e considerando um usuário ideal. Foram criadas cinco telas: tela inicial, cadastro, login, tela da mensagem da ocorrência e notificação do alerta. Todas telas se complementam.

A primeira tela conta com três botões com as funções mais essenciais do aplicativo: cadastro, login e reportar uma ocorrência (mesmo sem cadastro). É importante dizer que após o preenchimento das telas de login ou cadastro o usuário é transferido para a tela de ocorrência. Optamos por uma tela inicial minimalista para que o usuário final encontre com facilidade a sua necessidade.

A tela de cadastro fornece as informações necessárias para a tela de login. A primeiro modo, julgamos que "nome", "placa", "e-mail", "usuário", "senha" e "confirmar senha" são os dados essenciais para o funcionamento do sistema. pedir muita informação obrigatória pode carretar desistência de possíveis usuários.

A decisão do acesso á tela de ocorrência mesmo sem cadastro foi feita baseada em possíveis usuários sem carro e com consciência da existência do aplicativo e sua possibilidade de contato imediato com o dono do veículo identificado com problema.

Placa, modelo e cor formam os dados do carro. Sendo que, placa é o único obrigatório. Este será o dado usado para identificação do dono do carro com problema reportado. Presumimos que os dados optativos são importantes apenas como meio de validação do veículo pelo seu dono, a fim de corrigir erros.

Por fim, a notificação enviada para o dono do veículo e a segurança da UnB são os dados preenchidos na tela anterior mais o horário da ocorrência.

Além da parte visual, faz parte do nosso sistema um toque e vibração customizada. Assim, a informação é enviada e reconhecida automaticamente.

O protótipo foi baseado em aplicativos já em desenvolvimento por alunos da UnB, como o UnBAlerta!, Coral Campus e RUMOR.

Protótipo para apresentação parcial

Para a apresentação parcial foi criado, com auxilio do software Adobe Photoshop, um protótipo básico para melhor ilustração do nosso aplicativo.

Validação do Protótipo

Considerando que o protótipo atenderia as principais demandas dos usuários, foi feito um trabalho de validação, para avaliar o real interesse dos usuários no aplicativo, e quais eram as funções e utilidades que poderiam ser melhoradas, adicionadas ou customizadas, de acordo com o usuário final. Tendo em vista isso, foram feitas algumas abordagens para validar esse protótipo, entre elas:

• Um questionário de caráter Qualitativo, realizado nos estacionamentos do Campus Darcy Ribeiro, a fim de entender o real interesse dos usuários em baixar um aplicativo, e o nível de utilidade que o aplicativo teria; Foram entrevistados alunos da UnB que possuíam veículos, e que poderiam ou não ter sido vítimas de alguma ocorrência nos estacionamentos.
• Um Benchmarking de aplicativos da UNB que se assemelham ao protótipo, para identificar as boas práticas desenvolvidas pelos mesmos, e o real potencial em número de downloads que o aplicativo poderia ter;

Resultados da Validação do Primeiro Protótipo:

Questionário Realizado para validação:

	Questões
1	Já teve seu veículo furtado, roubado danificado na UNB? SIM ou NÃO
1.1	Você já recebeu algum suporte da Universidade que o ajudasse a resolver o problema de furto ou roubo? SIM ou NÃO
2	Numa escala de 0 a 5, quão útil seria esse aplicativo? (Sendo 5 muito útil)
3	Numa escala de 0 a 5, quão disposto você estaria a instalar esse aplicativo em seu celular. (Sendo 5 muito disposto)
4	Numa escala de 0 a 5, quão fácil de utilizar seria esse aplicativo? (Sendo 5 como muito fácil)
5	Qual aspecto (função) você considera mais importante nesse aplicativo?
6	Você acrescentaria ou retiraria algo do aplicativo?

Resultado das respostas obtidas com os 12 entrevistados:

		Questão
		1	1.1	2	3	4	5	6
Entrevistado	1	sim	Não	3	3	4	notificação
	2	sim	Não	4	4	5	notificação	receber outras ocorrencias
	3	sim	Não	4	4	5	mapa	opcao direta de chamar a policia, ou seguranca na hora da notificacao
	4	sim	Não	5	5	4	mapa
	5	sim	não	5	5	5	notificação
	6	não	Não	3	3	3	notificação
	7	não	Não	4	4	4	notificação
	8	não	Não	3	3	4	notificação
	9	não	Não	4	4	5	mapa
	10	não	Não	3	3	4	notificação
	11	não	Não	2	2	3	notificação
	12		Não	3	3	4	notificação

Feedback, aprendizados e considerações finais

Como feedback para a entrega final do projeto percebeu-se a necessidade de mudar a abordagem quanto a validação do protótipo, após uma avaliação junto a professora de que um questionário não seria a maneira correta, uma vez que o mesmo não leva em conta as dificuldades e dúvidas do usuário, e não mostra o verdadeiro potencial de eficiência do aplicativo, limitando a validação do mesmo.

Entrega Final

Os resultado da entrega final do projeto podem ser encontrados na página da Entrega Final.

Referências

• Rethinking Smart Cities From The Ground Up. Nesta. 2015
• Safe Cities: Using smart tech for public security. BBC Future. 2015
• Orchestrating infrastructure for sustainable Smart Cities. IEC. 2014