Unb Rotas

Disciplina “Projeto em Sistemas de Produção 2”, do curso de Engenharia de Produção, da Universidade de Brasília (UnB).

Professora: Cláudia Melo

Integrantes: João Paulo Menezes, Lucas Danelon, Lucas Moreira, Vitor Hugo Nogueira e Yasmin Kalume.

Ano letivo: 1/2017

Resumo[editar | editar código-fonte]

Seguindo o conceito de Smart Cities, e com a problemática de utilizar tal conceito na área de mobilidade urbana, foi pensado um projeto a fim de ser um aplicativo para smartphones gratuito e de fácil acesso e entendimento, com o objetivo de facilitar o acesso do usuário às informações referentes ao transporte público em tempo real.

O projeto foi pensado com inúmeras reuniões e ideias, além de feedback da professora Cláudia Melo e de entrevistas feitas em campo. Tentando sempre aliar a funcionalidade da tecnologia da informação com o conceito de Smart Cities, o time desenvolveu o UnB Rotas.

A equipe ao tomar conhecimento do tema em questão, iniciou diversas pesquisas acerca do conceito de Smart Cities. Em seguida, realizou-se um Brainstorming a respeito dos diversos problemas que afligem os alunos da UnB que dependem do transporte público e este foi o grupo em questão a ser estudado.

Após essa dinâmica, o time se reuniu com o objetivo de definir o público foco do projeto. Depois de analisar os distintos grupos, a equipe chegou ao consenso de trabalhar com os alunos da UnB, usuários do transporte público que dependem do mesmo para ir e vir da universidade para casa e vice-versa, e também pelos problemas que alunos enfrentam diariamente, que, solucionados, possuem potencial para tornar Brasília uma "Smart City" no cenário supracitado.

Com essa decisão, a equipe focou em descobrir os problemas específicos do grupo escolhido. Para tal foram realizadas diversas entrevistas presenciais e aplicado um modelo de um aplicativo para celular em uma versão low definition a fim de obter-se um feedback do produto.

Após a análise das principais reclamações do grupo escolhido para estudo, os estudantes da UnB que utilizam o transporte público, foram feitos estudos sobre outros meios similares que procuram auxiliar o usuário a fim de encontrar a melhor utilidade para o projeto e melhorar sua funcionalidade.

Introdução[editar | editar código-fonte]

Baseado no conceito de Smart Cities e de como poderiam ser aplicados tais conceitos na cidade de Brasília-DF, foi pensado um modelo a fim de melhorar e esclarecer alguns serviços e informações de alunos da Universidade de Brasília que utilizam o transporte público para locomoverem-se.

De acordo com o site FGV Projetos, o conceito de Smart Cities é definido como sendo sistemas de pessoas interagindo e usando energia, tecnologia da informação, materiais, serviços e financiamento para catalisar o desenvolvimento econômico e a melhoria da qualidade de vida. Uma das principais ou, se não, a principal engrenagem de uma cidade inteligente que deve, necessariamente, possuir um bom funcionamento e ter total disponibilidade de meios tecnológicos informacionais, é o sistema de transporte público.

Focando no grupo dos universitários da Universidade de Brasília que não dispõem de muitas informações acerca dos serviços de transporte público e que necessitam utilizar o mesmo, foi pensado o UnB Rotas, um aplicativo gratuito para Android e iOS que visa melhorar o acesso do cliente às informações pertinentes ao uso do transporte público.

O aplicativo tem por função facilitar o acesso do usuário à informações como itinerários, trajetos e, por fim, a localização em tempo real dos ônibus de uma certa linha por um sistema de Global Positioning System (GPS) o que diminuirá contratempos como não saber os horários dos ônibus e atrasos decorrentes disso, além de poder diminuir substancialmente as filas e lotações.

Justificativa[editar | editar código-fonte]

O tema mobilidade urbana foi escolhido pelo falo de que é de alta margem para aplicabilidade e de alto impacto no cotidiano da população em geral. Nesse projeto, contudo, o nosso público alvo se limitou aos alunos da Universidade de Brasília que utilizam transporte público rodoviário, de modo que identificamos uma oportunidade de beneficiar essas pessoas no âmbito no campus Darcy Ribeiro. Como resultados pretendidos, esperamos que o aplicativo seja uma ferramenta que reduza significativamente a espera do usuário no ponto de ônibus na sua jornada em trajetos relacionados à UnB. Pretendemos também, a fim de gerar benefícios aos alunos, contemplar os feedbacks colhidos durante entrevistas que apontam problemas em aplicativos similares em circulação, de modo a proporcionar uma melhor experiência ao público alvo.

Objetivos[editar | editar código-fonte]

Tendo como base o conceito de Smart Cities, que se define como o uso da tecnologia a fim de melhoras a infraestrutura urbana e a qualidade de vida de uma cidade, o objetivo do grupo em questão é desenvolver, por meio do uso da tecnologia, uma ferramenta que auxilie os alunos da UnB a ter melhor acesso à informações referentes ao transporte público do qual os mesmos dependem.

Tendo como a problemática de atrasos no horários dos ônibus e a falta de acesso à informações referentes a trajetos e linhas, fora pensado um meio de aliar o uso da tecnologia e total acesso por todos os estudantes que, por ventura, quiserem utilizar tal meio. Com isso, o esboço do projeto fora pensado e, após reuniões e brainstorm, pensou-se na criação de um app para isso.

Com base na idéia do desenvolvimento de um app, houve a necessidade de se captar um feedback do cliente final, os alunos da UnB, para que se tenha uma idéia se o projeto é viável e útil. Com isso, foi elaborado um protótipo em low definition para demonstrar como funcionaria o produto final e se era útil e intuitivo para o usuário. Após isso, aferiu-se um maior interesse os alunos da UnB dependentes do transporte público pelo projeto e, assim, o objetivo tornara-se elaborar o app da forma mais intuitiva e de fácil acesso possível e saber quando o cliente o acessaria e quando que seu uso terminaria.

Além disso, houve muita disposição do grupo em pesquisar fontes para que se tivesse ideia de como funcionaria o app, e a principal problemática fora descobrir como tornar uma ferramenta de localização dos ônibus em tempo real possível. Este objetivo logo foi alcançado por meio de pesquisas e artigos de tecnologias de outrem e logo o projeto final estava prestes a ser concluído.

Por fim, tornar o acesso à informação referente ao transporte público aos alunos da UnB possibilitou um grande aprendizado e uma maior interação do grupo em quetão para com a Univesidade.

Gestão do Projeto[editar | editar código-fonte]

O gerenciamento do projeto teve como principal vértice a utilização de princípios ágeis, os quais foram aprendidos na matéria de Sistemas Informacionais em Engenharia de Produção, ministrada neste semestre também pela professora Claudia Melo. O método específico utilizado foi o da metodologia Scrum, o qual permitiu o time trabalhar com as adversidades e mudanças de escopo de maneira mais descomplicada e sempre focando no resultado.

Primeira etapa de gerenciamento - O projeto de PSP2 se dividiu em duas duas fases de gerenciamento: a tradicional e a ágil. Inicialmente, com a gerencia ágil, o trabalho foi dividido em horários de reunião semanais as quais o grupo deveria se reunir para produzir valor ao projeto, ao mesmo tempo que trabalhou-se com prazos e atribuições pouco detalhadas quanto à responsabilidade. Toda e qualquer novidade se tornava retrabalho.

Segunda etapa de gerenciamento - A segunda etapa começa quando se inicia a utilização de métodos de trabalho mais rápidas e adaptativas. O marco para essa mudança, além do aprendizado na matéria de SIEP, foi a constante mudança de escopo que o time enfrentou por não saber lidar de maneira eficiente com a demanda (bem como determiná-la precisamente). Assim, com a nova adoção, foi possível realizar progresso sempre crescente, gerando valor aos poucos e agregado desenvolvimento à cada etapa.

Pontos significativos de mudança[editar | editar código-fonte]

Escopo - foi tomado o enfoque de que a demanda deve emanar do cliente, e o papel da equipe de projeto é o de apenas auxiliar na determinação de uma possível solução. Para essa determinação, ferramentas como Elevator Pitch, Design Thinking e pesquisa e entrevista em campo foram utilizadas. Assim foi possível determinar qual seria o problema por uma aproximação bottom-up. Entrevistas

Entregas - As entregas, antes definidas por prazos limites, passaram a ser definidas no backlog do produto, onde foram definidas várias pequenas entregas, as quais deveriam ser entregues da maneira mais próxima da concluída possível (em questão de valor pelo menos). Assim, definiu-se também uma pessoa como a responsável por cada tarefa de maneira a facilitar o controle dos processos e garantir que o menor número de processos ocorresse ao mesmo tempo. A ferramenta utilizada com esse objetivo foi o Trello.

Reuniões - Uma vez que as entregas foram divididas em etapas menores, mais focadas, foi possível focar também o esforço do time na produção de valor enquanto separados, e nos momentos reunidos foi discutido apenas critérios relacionados à dúvidas, problemas, e discussões relacionados à como proceder em determinadas situações. Assim, os encontros rápidos do time entre os intervalos de aula serviram como Daily-Meting os quais variaram de 2 à 10 minutos, sendo raros os dias os quais não ocorreram. As reuniões semanais e em aula deram espaço para discussões mais profundas do projeto, bem como para validação do projeto (todas as quintas). Reuniões semanais

Validação - Uma vez que os processos foram divididos em entregas menores, foi possível tanto validar com o cliente principal, quanto com os usuários de maneira mais rápida da realização das atividades possível. Assim foi possível corrigir possíveis e eventuais desvios do foco do projeto. Essa foi uma mudança de processo crucial para a realização com sucesso do trabalho.

Protótipo - O time enfrentou certa resistência quanto ao teste do produto de maneira tão preliminar, uma vez que muito poderia ser desenvolvido antes do teste em campo. Porém, por recomendação da professora Claudia, o teste foi feito em low-definition e assim informações cruciais foram coletadas para que o projeto pudesse continuar de maneira ordenada e fluida.

Documentos - A gestão formal de documentos foi levada em conta de maneira não tão rigorosa com o intuito de não atrasar o projeto, porém os registros de tal natureza foram registrados no apêndice da entrega parcial. Quanto aos documentos utilizados no decorrer do projeto, foram utilizados os meios de email, WhatsApp e Google Drive para a gerência de todos os membros no grupo.

Problema Específico e Pontos de Vista[editar | editar código-fonte]

Por intermédio das entrevistas realizadas em campo, foi concluído que o perfil dos alunos da Unb se encaixavam em 6 pontos de vista distintos:

Em relação ao primeiro ponto de vista, foi notório que alguns alunos utilizavam-se de bicicletas para se locomover, porém, sentiam-se inseguros em relação à furtos e falta de iluminação nos trajetos. O segundo ponto de vista foi relacionado aos alunos que tinham um potencial de utilização das bicicletas, mas não as utilizavam porque não possuíam informações sobre o aluguel de bicicletas e os locais de bicicletários da Unb. O terceiro ponto de vista era específico aos moradores do entorno que tinham dificuldade de locomoção tendo em vista a frota de ônibus - que julgavam insatisfatória. O quarto ponto de vista foi relacionado aos alunos da Unb em geral que sentiam-se inseguros ao caminhar pelo campus, pois este não possui a devida iluminação em várias regiões. O quinto ponto de vista analisou os alunos usuários de ônibus que ficavam aflitos por não terem o conhecimento fidedigno da chegada de seus ônibus.

Logo, por meio da análise dos pontos de vista, foi definido que o problema específico seria abordar os alunos usuários de ônibus que ficavam aflitos pela imprecisão dos horários do transporte público, que os impediam de tomar melhores decisões referentes à espera no ponto de ônibus. Assim, foi possível identificar que, caso a precisão dos horários dos ônibus fosse ajustada, os alunos não ficariam mais apreensivos diante da espera de seus ônibus.

Concorrentes[editar | editar código-fonte]

DFTrans

O site DFTrans - DFnoPonto é voltado para a utilização do ônibus e fornece rotas, horários e tarifas das linhas. Permite que o usuário consulte seus trajetos por dois modos: ou por meio das localizações de origem e destino ou por meio da linha escolhida.

Moovit

O aplicativo Moovit é voltado para a utilização do transporte público, com foco em metrôs, ônibus e trens. Possui uma avaliação positiva na PlayStore – 4,3 estrelas a partir de mais de 490 mil votos – e cerca de 10 milhões de downloads. Permite planejar viagens de transporte público realizando estimativas do trajeto e tem um diferencial que é o alerta de quando descer do ônibus para chegar em seu destino.

Google Maps

O aplicativo Google Maps é voltado para utilização de transportes em gerais, assim, possui informações sobre carros, ônibus, metrôs, trens, bicicletas e a pé. Possui uma avaliação positiva na PlayStore – 4,3 estrelas a partir de mais de 8 milhões de votos – e cerca de 1 bilhão de downloads. Permite analisar e planejar viagens, relacionadas ao transporte em geral, realizando estimativas do trajeto.

Unb Rotas

O diferencial do aplicativo Unb Rotas é o fornecimento de informações seguras em tempo real por meio de um algoritmo de roteirização. Os concorrentes ainda não conseguem fornecer essas informações causando algumas inseguranças nos usuários e, principalmente, no grupo focal deste projeto. Tendo em vista isto, o resultado final é totalmente viável e pode ser um grande facilitador aos usuários.

Embasamento tecnocientífico[editar | editar código-fonte]

O aplicativo Unb Rotas utiliza dados sobre o posicionamento das unidades de transporte público de interesse do público alvo para fornecer insumos à tomada decisão referente à espera no acesso ao veículo. Para tal, foi necessário definir um embasamento teórico que norteasse a abordagem do grupo quanto ao método de rastreamento dos ônibus em relação ao usuário do aplicativo. Esse embasamento consiste na análise e alinhamento de artigos acadêmicos com foco no rastreamento de veículos de modo a utilizar tecnologia GPS (Global Positioning System) e GSM/GPRS, com vistas a permitir uma interface em um aplicativo de smartphone. Alguns trabalhos foram analisados, de modo que dois deles nos chamaram a atenção.

1º Referencial[editar | editar código-fonte]

O primeiro trabalho foi o “Design and Implementation of Vehicle Tracking System Using GPS/GSM/GPRS Technology and Smartphone Application”, realizado na cidade de Flint, EUA. Esse estudo tem como premissa revelar uma abordagem de rastreamento de veículo em tempo real com a possibilidade de aplicação em smartphone proporcionada por quatro requisitos:

Extração de dados de geolocalização e identificação do veículo em tempo real por meio de um módulo GPS;
Transmissão dos dados coletados a um web server por meio de conexão GSM/GPRS;
A existência de uma base de dados que organize os inputs que recebe;
A possibilidade de acesso e monitoramento das informações por um usuário em seu smartphone, utilizando interface Google Maps.

Os módulos de GPS e de GSM/GPRS estão representados a seguir:

O módulo GSM/GPRS necessita de um chip SIM para estabelecer uma conexão TCP/IP com um webserver.

O processo de rastreamento de veículo em tempo real consiste no recebimento de dados de GPS pelo módulo intraveicular. Em seguida, por meio da tecnologia GSM/GPRS, esses dados são enviados a um webserver com comunicação TCP/IP. Os dados de localização e os dados de identificação do veículo chegam ao servidor respeitando o seguinte esquema:

A informação de GPS que é obtida só faz sentido com o uso da base de dados da Google, que permite uma sincronização da localização do veículo com os dados de mapas que possui.

Em suma, o grupo avaliou bem tal método, pois fornece com precisão os dados de localização e tempo a um servidor com suporte a smartphone, que é exatamente o que se espera do projeto “Unb Rotas”. Contudo, esse método, por requerer tais hardwares em cada veículo, nos pareceu inadequado em nossa abordagem, pois não atende o requisito da viabilidade, dado a demanda de recursos e burocracia associada ao transporte público. Desse modo, o grupo analisou um outro estudo, que será explicado a seguir:

2º Referencial[editar | editar código-fonte]

O segundo estudo analisado foi o “EasyTracker: Automatic Transit Tracking, Mapping, and Arrival Time Prediction Using Smartphones”, realizado na University of Illinois, Chicago, EUA. Como o próprio nome do estudo já antecipa, a proposta de tal estudo foi desenvolver um método de rastreamento, mapeamento, previsão de chegada de veículos usando smartphones e em tempo real. Dessa forma, atende bem o que esperamos do nosso projeto, pois acreditamos que possui um potencial de reduzir o tempo que se espera na fila para acessar um ônibus, problema central abordado em nosso escopo. O diferencial do Easy tracker é a preocupação em propor um método de alta confiabilidade e baixo custo, de modo a atender requisitos de sustentabilidade, fator esse que é de grande valia atualmente. Isso se evidencia na escolha de smartphones para recolher dados de GPS, e não módulos, como foi abordado no outro projeto. Além disso, há uma busca pela maior automatização possível do tratamento dos dados através de algoritmos e uma posterior comparação com dados de programações oficiais.

Para atender tal proposta, o aplicativo possui quatro componentes:

Smartphone portado por motorista de ônibus ou instalado no veículo;
Processamento “batch processing” em um servidor “back-end” para transformar trajetórias em rotas, programações e previsões;
Processamento online em um servidor “back end” para associar informações em tempo real com as rotas;
Uma interface que permite ao usuário, em seu smartphone, ter acesso a essas informações.

O processo de obtenção da informação do EasyTracker possui três frentes em “’batch processing”: Extração de Rotas, Extração de pontos de parada e Extração de programação.

Extração de Rotas

Nesse ponto, expõe-se a preferência de utilizar rotas automaticamente geradas pelo próprio dispositivo, pois acredita-se que rotas externamente fornecidas não são satisfatoriamente dinâmicas, adaptáveis e certamente confiáveis. Para tal, analisaram-se por meio de traços de caminhos realizados pelos veículos (GPS), possíveis rotas, que posteriormente foram corroboradas com análises matemáticas, como uma estimativa de densidade Kernel, seguido do método “anti-aliasing” e do filtro Gaussiano para estimar uma dita “ densidade de rota” que aponta, pela frequência de passagem dos veículos, uma provável linha de ônibus. O algoritmo de Viterbi fornece uma baixa incidência de erros na estimativa de rotas que possuem intersecção, ao medir a probabilidade do ônibus percorrer um certo caminho. Além disso, o método “Welch t-test” realiza uma atribuição de diferenciar cada nova rota das que já foram processadas, de modo a evitar repetições. Por fim, para testar a validade das rotas encontradas, são comparados os resultados obtidos com dados oficiais da localidade.

Extração de pontos de parada

O método para encontrar paradas de ônibus nesse mapa dinâmico baseia-se no tempo em que o ônibus fica parado. O desafio está em diferenciar um ponto de parada do veículo com um semáforo fechado, ou um ponto de congestionamento, por exemplo. Para isso só aceitam-se como candidatos para uma parada de ônibus regiões com uma alta densidade de “imobilização” do veículo. Mais uma vez, os dados são comparados com referências oficiais.

Extração de programação

O desafio nesse ponto é estipular horários válidos para uma parada de ônibus. Para isso, é utilizado o algoritmo a seguir. O input para o algoritmo é um conjunto de paradas $S=\{s_{1},...,s_{|s|}\}$ e um conjunto de viagens $T_{D}=\{T_{1}^{D},T_{2}^{D},...,T_{|T_{D}|}^{D}\}$ no dia $D$ em uma determinada rota, em que cada viagem $T_{i}^{D}$ possui uma série de horários de chegada por parada na rota $T_{i}^{D}=\{a_{1}^{i},a_{2}^{i},...,a_{|s|}^{i}\}$ em que $a$ é o tempo de chegada na parada. O problema produz uma série de tempos de programação que são representados por $K_{s}^{D^{'}}=\{{k^{s}}_{1},{k^{s}}_{2},...,{k^{s}}_{|T_{D}^{'}|}\}$ , em que $D$ denota o dia de semana ou se é fim de semana ou não. Ao imaginar $K^{1}$ como a programação da primeira parada, é necessário expor que as programações subsequentes serão derivadas dessa, de modo a respeitar: $travel_{-}time(i,j,t)={\frac {1}{|D|}}{\sum _{D}a_{j}^{t}-a_{i}^{t}}$ sendo duas paradas $i$ e $j$ em uma viagem $t$ , $K_{s}^{=}\{k_{1}^{s}...k_{|T_{D}^{'}|}^{s}\}$ sendo que $k_{i}^{s}=k_{i}^{1}+travel_{-}time(1,s,i)$ $K_{s}$ é a programação em uma parada após $K_{1}$ .

Processamento Online

De posse das informações sobre rotas, paradas e programação, o mapa já está completo. Nessa etapa há a sincronização entre os dados em tempo real do ônibus e esse mapa, de modo a localizar esse veículo e realizar estimativas de tempo até a próxima parada.

Localização do Veículo

Para saber a localização do veículo em um universo de rotas, foi utilizada uma abordagem “Hidden Markov Model – HMM” de modo que cada rota é tratada separadamente de acordo com a permanência do veículo na rota conhecida. Quando ocorre uma coincidência de rotas, o algoritmo de Viterbi auxilia na escolha da rota correta através da designação de uma probabilidade dez vezes maior do que alguma outra rota. Se o veículo andar mais de sete quilômetros sem uma classificação, ele é denominado “ não-classificado”.

Previsão do tempo de chegada

Assumindo que cada veículo esteja com um aparelho smartphone em funcionamento de suas funções de GPS, a previsão do tempo de chegada do ônibus na próxima parada estipulada em sua rota é dada por:

$\gamma {travel_{-}time}(s_{prev+1},s_{i},t)+(1-\gamma )(s_{prev},s_{prev+1},t)$

Onde:

$s_{i}$ é a parada onde se deseja saber o horário de chegada;

$s_{prev}$ é a última parada que foi contemplada;

$\gamma$ é a distância entre $s_{prev}$ e $s_{prev+1}$ ;

$t$ é a viagem em questão.

Resultados

Após a comparação dos dados obtidos com referências oficiais, observou-se que o método tem um grande potencial, visto que apresentou resultados com margens de validação consideráveis, como tempo de espera pelo ônibus de cerca de 1 minuto e cerca de 97% de segurança na designação da rota que o ônibus está percorrendo.

Conclusão

Após a análise desses dois estudos, o grupo optou por adotar uma metodologia similar ao estudo “EasyTracker: Automatic Transit Tracking, Mapping, and Arrival Time Prediction Using Smartphones”, pois considerou ser inovadora e confiável a sua abordagem, além de contemplar um baixo custo proveniente do uso do smartphone como dispositivo de GPS. Com o alto índice de validade dos dados nessa metodologia, acreditamos que o dispositivo “UnB Rotas” estaria bem embasado tecnologicamente com essa abordagem de modo que os usuários de ônibus que esperam muito tempo na parada de ônibus teriam uma um tempo de espera reduzido e uma previsão confiável para a chegada de seu transporte. Além disso, dados como horários de cada parada de ônibus e rota em tempo real, que também são recursos pretendidos pelo aplicativo “UnB Rotas” também seriam contemplados nessa abordagem.

1º Protótipo[editar | editar código-fonte]

Levando em consideração os concorrentes e as pesquisar feitas sobre o funcionamento de um aplicativo em tempo real, o 1º protótipo em low definition foi feito:

Feedbacks[editar | editar código-fonte]

Procedimento padrão das entrevistas:

O grupo se apresenta, apresenta o curso e o projeto em questão. Pergunta se a pessoa em questão é aluna da Unb e se tem problemas por esperar muito em um ponto de ônibus.
O grupo apresenta o protótipo low definition do aplicativo quanto à sua interface e funções, de modo a fornecer um breve panorama com vistas a promover um entendimento preliminar.

Metodologia da entrevista:

O time estabelece que, após se apresentar e dar uma breve explicação sobre o protótipo, simula o uso desse aplicativo por parte do entrevistado. Essa abordagem foi escolhida em comum acordo pelos integrantes do grupo por acreditarem que seria a melhor forma de detectar dores e sugestões.

Feedback 1

Quando os entrevistados analisaram a funcionalidade de mapa do aplicativo, questionaram sobre como se conseguiria a informação da geolocalização e horários;
O uso de GPS para tal fim foi elogiado pelos entrevistados;
Houve preocupação dos entrevistados se o aplicativo contemplaria tanto os horários de ida como de volta da UnB;
Entrevistados alegam uso de aplicativos com o mesmo tema e apontam a existência de dados desatualizados como principal dor;
Entrevistados afirmam que o que eles mais esperariam desse aplicativo seria atualizações constantes de informações e dados válidos;
Entrevistados afirmam esperarem muito tempo no ponto do ônibus para irem para a UnB. Na volta, esse problema diminui, pois os ônibus chegam geralmente após a aula.

Feedback 2

Entrevistados elogiam sistema de GPS;
Entrevistado alega conhecer o aplicativo Mobli, de mesmo tema e afirma que os horários não são totalmente válidos. Dessa forma, aponta que o uso de dados confiáveis seria um diferencial do novo aplicativo;
Elogios à interface do sistema;
Entrevistado indagou se no aplicativo quando uma parada é selecionada todas as linhas de ônibus aparecem ou se só aparecem as linhas de ônibus dessa determinada parada;
Sugestão: Apontar pontos de referência relacionados a cada uma das paradas, a fim de promover um melhor entendimento por parte de usuário.

Feedback 3

Entrevistada pergunta sobre a validade dos dados e afirma que o “DF Trans” não fornece dados atualizados;
Entrevistada perguntou sobre gratuidade do aplicativo;
A entrevistada não usa nenhum aplicativo de mesmo tema e memoriza seus horários diários de ônibus.

Feedback 4

Entrevistada utiliza o aplicativo Google Maps para o mesmo fim;
Entrevistada afirma que faria um teste do aplicativo;
Diferencial em relação ao Maps: O “UnB Rotas” fornece quatro horários para a mesma linha, enquanto o aplicativo da Google fornece um horário para diversas linhas;
Entrevistada sugeriu que o aplicativo, depois de pronto, esteja na PlayStore pra download.

Blueprint[editar | editar código-fonte]

Durante as últimas aulas de PSP, a professora ensinou uma técnica de gerenciamento para facilitar a experiência do usuário e o serviço, em vez de usar uma abordagem top-down de controle. Essa técnica é chamada Blueprint. Assim, a jornada do cliente é analisada através do tempo e é experimentada por meio de canais. Ao analisar o quadro geral, pode-se mostrar para o cliente como algumas partes do serviço estão tendo um impacto, negativo ou positivo, em outras partes, que aparentemente não estavam relacionadas.

Após a análise do blueprint do projeto, a equipe conseguiu entender melhor como seria a experiência do cliente. Além disso, foi fundamental para a criação do 2º protótipo.

2º Protótipo[editar | editar código-fonte]

Uma vez que se foi obtido informações a respeito do protótipo 1, pôde-se trabalhar com maior convicção sobre algumas funções do app, bem como alterar outras que poderiam ter maior aplicabilidade. Assim o protótipo 2 pode ser encarado como, além de uma versão de maior definição, um produto de valor mais próximo do que os usuários tanto precisam: Uma plataforma simples e descomplicado para poder saber a hora dos ônibus de maneira precisa e elegante. O programa utilizado para produzir o app foi o Proto.io.

Usuário pode escolher melhor rota que deseja fazer. Clicando um uma rota abrem-se mais opções de interação.

Opções: Próxima linha, tempo restante, e ver mapa em tempo real são disponíveis para a linha da rota escolhida.

Feedbacks com os usuários[editar | editar código-fonte]

Diferentemente do primeiro Feedback com os usuários, procurou-se focar (no segundo) menos no critério de formalização e mais em buscar respostas para algumas de nossas dúvidas pontuais, bem como testar a facilidade da usabilidade do app. Dessa forma 10 pessoas deram suas opiniões quanto ao novo app.

A interação ocorreu da seguinte forma: primeiramente conversou-se sobre possíveis dificuldades que a pessoa enfrentaria por não saber da hora precisamente, afim de provar a necessidade do UnB Rotas. Em seguida explicamos o projeto e fizemos um teste com a versão preliminar do app afim de testar a facilidade e funcionalidade do mesmo. Por fim perguntamos se a pessoa usaria ou não o serviço.

Da pesquisa, a maioria dos usuários apontou a usabilidade do app como pouco intuitiva e de difícil compreensão. Por se tratar de um protótipo simples, já se era esperado algo nesse sentido, porém a repetição da mesma queixa por 8 vezes foi inesperada. Quanto à vontade de usar o app, 9 pessoas afirmaram que o utilizariam caso o projeto continuasse. Além disso, outras queixas não relacionadas ao assunto foram levantas. Essas queixas, apesar de terem grande potencial de aplicação em um app parecido com o UnB Rotas, não podem ser foco do projeto do momento, e ficam registradas nas considerações finais no intuito de integrarem uma versão final posterior.

Considerações Finais[editar | editar código-fonte]

Levando em consideração os objetivos do projeto, os feedbacks do protótipos e o processo de desenvolvimento das ideias de solução para o problema de mobilidade da UnB levantamos algumas considerações finais para o projeto.

Primeiramente, o ponto mais importante a se destacar é o de que o projeto tem como objetivo maior o aprendizado do time, por mais que o produto tenha potencial real de valor. Também por esse motivo, o escopo do projeto teve de se tornar bem direcionado, o que fez com que ideias boas não entrancem no desenvolvimento do protótipo 1 ou 2. Algumas dessas ideias, suportadas nas entrevistas de campo do feedback, são opções de segurança (reportar falta de iluminação no ponto, insegurança no ponto, assédio) e de conforto (denúncia de direção agressiva, rápida ou desrespeitosa do motorista e mecanismos para saber a lotação do veículo).

O app recebeu críticas construtivas quanto à mecânica backstage durante o feedback 1, e quanto ao visual no feedback 2. Como não se objetiva que o app seja melhor que outros apps concorrentes, mas sim estrategicamente diferente quanto à precisão do tempo, tem-se como prioridade a alteração visual do layout do app para que os usuários queiram utilizar o app em sua versão final.

Lições Aprendidas[editar | editar código-fonte]

Como um grupo de projetos, o grupo trabalhou de forma muito coesa e, embora tendo o revés de cada um morar em lugares diferentes e distantes, com eficiência. Ficam as lições aprendidas que cada um pôde ajudar de alguma forma a resolução do projeto e sempre respeitando a opinião do colega de grupo. As reuniões semanais também melhoraram a interatividade dos integrantes e, mesmo com alguns membros com indisponibilidade de horários, fizeram com que houvesse empatia em trabalhar em grupo, sendo em reuniões mais sérias ou descontraídas como um café ou happy-hour.

Pôde-se aprender a conviver com ideias divergentes que no fim, convergiram para um produto final bem-sucedido, onde houve o reconhecimento de erros e contratempos e com o trabalho em grupo, foram sanados, com a ajuda de feedbacks dos stakeholders. Assim, o desenvolvimento do projeto obteve um bom andamento com a ajuda de todos os integrantes, onde cada um contribuiu de alguma forma dentro e, de certa forma, além de sua disponibilidade e competência.

Houve, também, vários treinamentos a fim de melhorar o protótipo do produto e saídas a campo, o que tornou o trabalho mais dinâmico e interativo, pois entendeu-se as dificuldades do cliente final e pôde-se pensar em como sanar os mesmos. Ou seja, para que o projeto tenha uma boa receptividade, é necessário que haja o reconhecimento na fonte dos problemas a serem sanados e não apenas tentar resolvê-los longe de campo, no mundo das idéias.

Por fim, fica a lição de que, assim como um Sistema necessita que todas as suas partes independentes trabalhem em conjunto a fim de atingir um resultado razoável e eficiente, nosso grupo baseou-se nesta definição para elaborar, desenvolver e concluir um projeto que, na medida do possível, pôde ser um ponto de partida para tornar Brasília, ou ao menos uma pequena parte dela, nos moldes de uma smart city.

Referências[editar | editar código-fonte]

Aulas de PSP2

BIAGIONI, James Biagioni et al. EasyTracker: Automatic Transit Tracking, Mapping, and Arrival Time Prediction Using Smartphones.2011. 14 p. Design and Implementation of Vehicle Tracking System Using GPS/GSM/GPRS Technology and Smartphone Application (Computer Science)- Department of Computer Science, University of Illinois at Chicago, Chicago, IL 60607, USA, 2011. Disponível em:<https://www.cs.uic.edu/~jakob/papers/easytracker-sensys11.pdf>. Acesso em: 20 jun. 2017.

DFTrans No Ponto. Disponível em: <http://www.sistemas.dftrans.df.gov.br/horarios/src/mapas/index> Acesso em 10 mai. 2017.

FGV Projetos. O que é uma cidade inteligente? Disponível em: <http://fgvprojetos.fgv.br/noticias/o-que-e-uma-cidade-inteligente> Acesso em 4 jun. 2017.

LEE, SeokJu ; TEWOLDE, Girma ; KWON, Jaerock . Design and Implementation of Vehicle Tracking System Using GPS/GSM/GPRS Technology and Smartphone Application. 2014. 6 p. Design and Implementation of Vehicle Tracking System Using GPS/GSM/GPRS Technology and Smartphone Application (2014 IEEE World Forum on Internet of Things)- Electrical and Computer Engineering, Kettering University, Flint, MI, USA, 2014. Disponível em: <http://ieeexplore.ieee.org/abstract/document/6803187/?reload=true>. Acesso em: 20 jun. 2017.

POLAINE, Andy. Service Design Blueprinting – Workshop Handouts/Cheatsheet UX Australia 2013. Disponível em: <http://www.polaine.com/playpen/media/uxaus/apolaine_UXAustralia_workshop_handouts.pdf> Acesso em 24 jun. 2017.

Scipopulis. Disponível em: <http://www.scipopulis.com/> Acesso em 13 jun. 2017.