Topo
pesquisar

APLICATIVO PARA DISPOSITIVOS ANDROID: “BAU’S”

Computação

Análise alguns dos problemas mais comuns relacionados com a mobilidade urbana na cidade de Brasília e propor um projeto de software como solução tecnológica adaptada a capital do país.

índice

  1. 1. RESUMO
    1. 1.1 ABSTRACT
  2. 2. INTRODUÇÃO
  3. 3. JUSTIFICATIVA
  4. 4. OBJETIVOS
    1. 4.1 OBJETIVO GERAL
    2. 4.2 OBJETIVOS ESPECÍFICOS
  5. 5. METODOLOGIA DA PESQUISA
    1. 5.1 REALIZAR ESTUDO SOBRE O TEMA
    2. 5.2 REALIZAR PESQUISA DE CAMPO
    3. 5.3 AVALIAR SOLUÇÕES DISPONÍVEIS
    4. 5.4 ESTUDAR O PROBLEMA
    5. 5.5 PROTOTIPAGEM DE UMA PROPOSTA DE APLICATIVO
    6. 5.6 DEFINIÇÃO DA ARQUITETURA
  6. 6. CRONOGRAMA
  7. 7. REFERENCIAL TEÓRICO
    1. 7.1 MOBILIDADE URBANA
      1. 7.1.1 Mobilidade Urbana em Brasília
      2. 7.1.2 APARELHOS CELULARES COMO FERRAMENTA DE MOBILIDADE
      3. 7.1.3 O Conceito de SmartPhones
      4. 7.1.4 O GPS
      5. 7.1.5 Geolocalização em aparelhos Android
    2. 7.2 SOLUÇÕES ATUAIS PARA APLICATIVOS DE MOBILIDADE URBANA
      1. 7.2.1 Aplicativo Próximo Ônibus – Curitiba
      2. 7.2.2 Aplicativo CittaMobi
      3. 7.2.3 Aplicativo Moovit
      4. 7.2.4 O aplicativo OneBusAway
      5. 7.2.5 Google Maps
      6. 7.2.6 Waze
      7. 7.2.7 Aplicativo Cadê o Ônibus?
    3. 7.3 O SISTEMA OPERACIONAL ANDROID
      1. 7.3.1 Android Studio
  8. 8. CAPÍTULO 1
    1. 8.1 PESQUISA DE ORIGEM / DESTINO
    2. 8.2 A PESQUISA REALIZADA PARA ESTE PROJETO
      1. 8.2.1 Dados Iniciais
      2. 8.2.2 Perfil do Entrevistado
      3. 8.2.3 Perfil do Entrevistado – Quanto ao Sexo
      4. 8.2.4 Perfil do Entrevistado – Quanto à idade
      5. 8.2.5 Perfil do Entrevistado – Quanto à escolaridade
      6. 8.2.6 Perfil do Entrevistado – Possui veículo próprio
      7. 8.2.7 Perfil do Entrevistado – Quanto a preferência
      8. 8.2.8 Preferência por motivo conforto
      9. 8.2.9 Preferência por motivo segurança
      10. 8.2.10 Deficiências do transporte público
  9. 9. CAPÍTULO 2
    1. 9.1 OUTRAS SOLUÇÕES PARA DESENVOLVIMENTO ANDROID
      1. 9.1.1 React Native
      2. 9.1.2 O Ionic
      3. 9.1.3 O Xamarin
    2. 9.2 DESENVOLVENDO COM O ANDROID NATIVO
      1. 9.2.1 Desenvolvimento Nativo x Desenvolvimento híbrido
      2. 9.2.2 O NDK
    3. 9.3 DECISÃO DE PROJETO
  10. 10. CAPÍTULO 3
    1. 10.1 DESCRIÇÃO DA PROPOSTA DE TRABALHO
    2. 10.2 RESULTADOS ESPERADOS
    3. 10.3 RESTRIÇÕES
    4. 10.4 RECURSOS NECESSÁRIOS
      1. 10.4.1 Hardware mínimo para desenvolvimento o projeto
      2. 10.4.2 Software mínimo para desenvolvimento do projeto
      3. 10.4.3 Profissionais necessários para iniciar o projeto
    5. 10.5 CUSTO PARA INICIAR O PROJETO
    6. 10.6 ESTIMATIVAS DE PRAZO DO PROJETO
  11. 11. CAPÍTULO 4
    1. 11.1 PLANO DE PROCESSO DE DESENVOLVIMENTO
      1. 11.1.1 Ciclo de vida do projeto
      2. 11.1.2 Métodos de Desenvolvimento e ferramentas CASE
      3. 11.1.3 A Orientação a Objetos
      4. 11.1.4 A UML
      5. 11.1.5 Linguagens de Programação
    2. 11.2 PLANO DE ACOMPANHAMENTO
      1. 11.2.1 Marcos de Pontos de Controle
      2. 11.2.2 Análise e gerência de risco
      3. 11.2.3 Categorização dos riscos
      4. 11.2.4 Estimativas de ocorrência
    3. 11.3 ESPECIFICAÇÃO DOS REQUISITOS
      1. 11.3.1 Descrição do Problema
      2. 11.3.2 Identificação dos interessados
      3. 11.3.3 Principais necessidades dos interessados
    4. 11.4 DESCRIÇÃO DAS CARACTERÍSTICAS DO SISTEMA
      1. 11.4.1 A escolha do nome
    5. 11.5 REQUISITOS DO APLICATIVO
      1. 11.5.1 Tela inicial
      2. 11.5.2 Seleção de Trajeto
    6. 11.6 NAVEGABILIDADE ENTRE AS TELAS
    7. 11.7 CONTEXTO DE UTILIZAÇÃO DO SISTEMA
    8. 11.8 REQUISITOS SUPLEMENTARES
      1. 11.8.1 Usabilidade
      2. 11.8.2 Desempenho
      3. 11.8.3 Procedimentos contra perda de dados
    9. 11.9 RESTRIÇÕES DO SISTEMA
    10. 11.10 VISÃO PRELIMINAR DA ARQUITETURA
      1. 11.10.1 Quanto ao Sistema
    11. 11.11 Quanto ao Servidor de Aplicação
    12. 11.12 Quanto a distribuição
    13. 11.13 REQUISITOS NÃO TÉCNICOS
    14. 11.14 POSSIBILIDADE DE EVOLUÇÃO FUTURA
    15. 11.15 MODELOS DE CASO DE USO
      1. 11.15.1 Fluxo principal
      2. 11.15.2 Visão geral dos casos de uso e atores
      3. 11.15.3 Descrição dos casos de uso
      4. 11.15.4 Caso de Uso Pesquisar
      5. 11.15.5 Caso de Uso Selecionar Transporte  
      6. 11.15.6 Caso de Uso Selecionar Rot          
      7. 11.15.7 Este caso de uso descreve o processo em que o usuário selecione qual meio de transporte será utilizado.
  12. 12. REFERÊNCIAS BIBLIOGRÁFICAS

1. RESUMO

Um dos grandes problemas urbanos de Brasília está relacionado com transporte público urbano. A necessidade cotidiana de locomoção, na capital do país, esbarra em inúmeras dificuldades, dentre elas, as grandes distâncias, a precária oferta de transporte público e, sobretudo, a falta de informações que dificultam com que a população escolha qual a melhor rota e meio de transporte para chegar a seu destino. O objetivo deste trabalho é estudar as soluções disponíveis em aplicativos móveis criados com a finalidade de facilitar esta locomoção e propor um protótipo, para aplicativo móvel voltado para plataforma Android e adaptada a realidade de Brasília.

Palavras-chave: mobilidade urbana, transporte público, aplicativos móveis, Plataforma Android.

1.1. ABSTRACT

One of the major urban problems is related to urban transport. The daily locomotion capital in the capital of the country encounters numerous difficulties, such as a long distance, a precarious supply of public transport and, above all, a lack of information that makes it difficult for a migration to choose the best route and means of transport to reach their destination. The objective of this work is to study how the easiest solutions to be launched automatically for the purpose of locomotion and to propose a prototype, for the mobile application focused on the Android platform and adapted to the reality of Brasilia.

Keywords: urban mobility, public transport, mobile applications, Android platform.

2. INTRODUÇÃO

Os dois últimos séculos têm como marca um notório e crescente desenvolvimento tecnológico. Isto é perceptível em todas as áreas do conhecimento humano. Carvalho (CARVALHO 1997, p.72) descreve que a Revolução Industrial foi o gatilho para o crescimento acelerado de conhecimentos em tecnologia. A partir daí a humanidade passou a acumular conhecimentos e acelerou ainda mais o processo de transformações sociais. Dosi descreve que processos de inovação estariam atrelados por paradigmas, e o rumo destes é determinado pelo conjunto de problemas e soluções consideradas previamente relevantes e que delimitam os esforços tecnológicos. Dosi ainda afirma que:

(...)Um paradigma tecnológico define contextualmente as necessidades a serem atendidas, os princípios científicos a serem usados para as tarefas e a tecnologia de materiais a ser empregada ( DOSI 2004, p. 71)

KUHN (1989) definiu o Paradigma científico como:

Àquilo que a ser partilhado por uma comunidade científica. O paradigma indica á comunidade o que é interessante investigar, como levar a cabo essa investigação, impondo como que um sentido ao trabalho realizado pelos investigadores e limitando os aspectos considerados relevantes da investigação científica (KUHN 1989, P. 147-162).

Em paralelo ao crescimento tecnológico, é visível também o crescimento populacional nos principais centros urbanos. Hoje, o planeta possui algo mais que 7,6 bilhões de habitantes (WORLDOMETERS, 2018), destes mais de 50% habitando nos grandes centros urbanos (ONU, 2015). De acordo com os relatórios da ONU de 2015, a população mundial deve atingir 9,7 bilhões até o ano de 2050, e mais de 60% desse viverão nas cidades.

Em 1960, Brasília foi fundada e planejada para comportar uma população de aproximadamente 500 mil habitantes nos inícios dos anos 2000. Mas na verdade é que esta marca foi atingida antes mesmo do início da década de 70 e, segundo o censo de 2015, ultrapassou a marca de 3 milhões de pessoas (IBGE, 2015). Com esta crescente populacional, os habitantes de Brasília sofrem com a precariedade do transporte público.

3. JUSTIFICATIVA

A finalidade acadêmica deste trabalho é produzir um estudo sobre a mobilidade urbana, especificamente voltada para a realidade da cidade de Brasília.

A escolha deste tema foi motivada pela divulgação de estudos recentes sobre a precariedade do transporte público urbano, na capital do país.

Este estudo atinge o cidadão brasiliense que faz uso de transporte público e ou privado para se locomover pelo Distrito Federal diariamente.

O pesquisador, por fazer parte do grupo populacional de Brasília, que se desloca quase exclusivamente utilizando transporte público urbano,  está totalmente inserido no contexto desta pesquisa. Observou de perto alguns dos problemas mas comuns envolvendo a mobilidade urbano nesta cidade.

Deste estudo, será proposto, através de um projeto de desenvolvimento de um protótipo para plataforma mobile que teria como principal finalidade, fornecer uma solução que apoie a mobilidade da população da Capital do País. Existem algumas soluções mobile que, de alguma forma, contribuem para melhorar a questão estudada, fornecendo informações sobre linhas de ônibus, trajetos para deslocamento em menor tempo ou até permitindo que o usuário solicite um transporte particular pago. O que se propõe é estudar as características destas principais soluções e apresentar um projeto adaptado a realidade local.

4. OBJETIVOS

4.1. OBJETIVO GERAL

O objetivo deste estudo é analisar alguns dos problemas mais comuns relacionados com a mobilidade urbana na cidade de Brasília e propor um projeto de software como solução tecnológica adaptada a capital do país.

4.2. OBJETIVOS ESPECÍFICOS

A partir do Objetivo Geral definido para este trabalho de pesquisa, serão definidos os seguintes objetivos específicos:

  • Estudar as deficiências mais comuns que impactam a mobilidade urbana da cidade de Brasília;
  • Identificar propostas de soluções práticas, em forma de aplicativos de celular, que ajudem a minimizar os impactos deste problema;
  • Construir um projeto de software que apresente uma solução voltada para a realidade de Brasília.

5. METODOLOGIA DA PESQUISA

Este capítulo tem como finalidade descrever a metodologia que será aplicada com intuído de chegar ao final deste projeto. Tal metodologia será composta por revisão bibliográfica de autores que trataram do tema estudado e de algumas fases descritas a seguir.

5.1. REALIZAR ESTUDO SOBRE O TEMA

Nesta etapa serão realizadas pesquisas nos autores escolhidos para favorecer um maior aprendizado no tema.

Serão consultados artigos, monografias, textos publicados e disponíveis na Web e vídeo aulas.

5.2. REALIZAR PESQUISA DE CAMPO

Nesta etapa pretende-se elabora um questionário de perguntas e respostas que será utilizado em pesquisa em locais onde o público interessado se encontra.

5.3. AVALIAR SOLUÇÕES DISPONÍVEIS

Nesta fase será realizado um estudo sobre as soluções tecnológicas em formato de aplicativos para celulares (mobile).

5.4. ESTUDAR O PROBLEMA

Nesta fase serão estudados quais as maiores dificuldades encontradas pela população no âmbito da mobilidade urbana. Trata-se de uma análise nas pesquisas realizadas em campo, confrontando-as com as informações compiladas anteriormente.

5.5. PROTOTIPAGEM DE UMA PROPOSTA DE APLICATIVO

Nesta fase serão produzidas as telas da solução para estudar os quesitos de usabilidade e navegabilidade.

5.6. DEFINIÇÃO DA ARQUITETURA

Neste momento será definida a arquitetura para a solução tecnológica. A arquitetura utilizada para suportar uma aplicação mobile é uma questão muito discutida na atualidade. Ela pode representar a diferença entre sucesso e fracasso do projeto.

6. CRONOGRAMA

Este capítulo descreve o planejamento das atividades deste projeto de pesquisa.

Tabela 1- Cronograma do Projeto

 

1º Semestre 2018

Etapas

Janeiro

Fevereiro

Março

Abril

Maio

Junho

Pesquisa de Campo

 

 

 

 

 

 

Análise de soluções existentes

 

 

 

 

 

 

Concepção do projeto

 

 

 

 

 

 

Elaboração projeto de Software

 

 

 

 

 

 

Produção da documentação TCC

 

 

 

 

 

 

 

2º Semestre 2018

Etapas

junho

Agosto

Setembro

Outubro

Novembro

Dezembro

Pesquisa de Campo

 

 

 

 

 

 

Análise de soluções existentes

 

 

 

 

 

 

Concepção do projeto

 

 

 

 

 

 

Elaboração projeto de Software

 

 

 

 

 

 

Produção da documentação TCC

 

 

 

 

 

 

7. REFERENCIAL TEÓRICO

A partir deste ponto será discutido como outros autores, relacionados ao tema, se posicionam. Quais as pesquisas mais relevantes ao escopo deste trabalho e uma comparação a proposta do protótipo já existentes.

7.1. MOBILIDADE URBANA

Segundo o Ministério das Cidades (2005), “a mobilidade urbana é o resultado da interação dos fluxos de deslocamento de pessoas e bens no espaço urbano, contemplando tanto os fluxos motorizados quanto os não motorizados”. Este Ministério, por meio de sua Secretaria Nacional de Mobilidade Urbana, que é responsável pelo projeto de mobilidade urbana no Brasil e que faz cumprir as diretrizes da Política Nacional de Mobilidade Urbana (Lei 12.587/2012).

A distância de deslocamento nos grandes centros cresceu consideravelmente fazendo com que a população se tornasse altamente dependente dos sistemas de transporte (FORUM MOBILIDADE 2015).

Segundo o PLAMOB (plano de Mobilidade Urbana, 2015), da década de 50 em diante, ocorreu um grande deslocamento da população para os grandes centros como resultados do crescimento acelerado destes centros urbanos como resultado do processo de industrialização do País.

7.1.1. Mobilidade Urbana em Brasília

Até o final da década de 80 era crença comum que Brasília, com suas longas avenidas de largas faixas, uma cidade urbanisticamente planejada, e com diversas facilidades para circulação de veículos, estaria livre dos problemas de trânsito conhecidos dos grandes centros (PDTU/DF).

A partir dos anos 2000, um grande número de veículos entrou em circulação e as dificuldades começaram a ser percebidas, chegando ao status atual. Hoje o deslocamento por Brasília, principalmente nos horários de pico, é bastante crítico. (RODRIGUES 2018).

O tratamento destinado à mobilidade Urbana, na capital da nação, é de responsabilidade da Secretaria de Estado de Mobilidade do Distrito Federal, que se responsabiliza por planejar, coordenar, executar e avaliar a gestão e as políticas de mobilidade do Distrito Federal. Decreto Nº 36.236, de 1º de janeiro 2015 (Art. 8; §1,IX). É este órgão do GDF que se responsabilizado por aplicar as políticas públicas relacionadas com mobilidade urbana na capital e entorno.

Uma pesquisa recente do Instituto de Americano Expert Market, coloca Brasília entre as 10 piores cidades no quesito transporte público (EXPERT MARKET). Esta pesquisa analisou situações críticas (VIDE ANEXO N) como:

  • Tempo de viagem;
  • Tempo de espera;
  • Distância a percorrer;
  • Custo mensal do transporte.

Do total dos moradores do Distrito Federal, 41,42% utilizam o próprio veículo para se deslocarem até o trabalho diariamente, seguidos por 38,07% que fazem uso de transporte público urbano (FORUM MOBILIDADE 2015).

A utilização de veículo particular para deslocamento é bastante alta, principalmente na população com maior poder aquisitivo (PDAD). O restante da população ainda depende do transporte público e enfrenta bastante dificuldade no deslocamento (VIDE ANEXO O).

Depois de um longo período sem significativos investimentos em infraestrutura para transporte coletivo, Brasília está caminhando para um cenário de caos urbano. Segundo simulações do Plano Diretor de Transporte Urbano e Mobilidade do Distrito Federal (PDTU), o trânsito pode entrar em colapso em 2020.

Segundo auditoria do Tribunal de Contas do Distrito Federal, executada em 2014, intitulada Auditoria operacional para avaliar a capacidade do governo local de gerir o novo sistema de transporte público coletivo é de que a gestão deste tema por parte do poder público é, no mínimo, inadequada, insuficiente e pouco abrangente no tocante em atender a crescente demanda populacional.

Existem ações visando a reversão deste cenário, como por exemplo, o programa Circula Brasília, que propõe 80 ações de gestão, obras e projetos, que se colocados em prática na próxima década, poderão adiar ou até mesmo reverter este cenário (PDTU).

7.1.2. APARELHOS CELULARES COMO FERRAMENTA DE MOBILIDADE

Desde o primeiro dispositivo móvel, até hoje, os esforços têm sido grandes para transformar, inovar, criar e aperfeiçoar tecnologias para facilitar e ajudar tarefas simples do dia a dia, como se comunicar com outras pessoas, pagar uma fatura em aberto no banco, e até mesmo nos momentos de entretenimento, como jogar, escutar música ou assistir a um filme.

E a popularização do aparelho não para de crescer, segundo dados da consultora IDC, no segundo trimestre de 2013 foram vendidos 8,3 milhões de smartphones no Brasil, um aumento de 110% da comercialização desses equipamentos em relação ao mesmo período em 2012 (IDC).

Segundo pesquisa da Fundação Getúlio Vargas, em maio de 2018, o percentual por habitante no Brasil que possuía um aparelho de celular era de 114%, maior que a média mundial neste mesmo período e ficando atrás somente da médica americana (VIDE ANEXO K). Já o percentual de smartphones por habitante no país chega a 106% e é uma crescente devendo ter um crescimento de mais de 25% em 2 anos (MEIRELLES 2018).

7.1.3. O Conceito de SmartPhones

O verbete smartphone vem sendo utilizado pela indústria como sinônimo para telefones celulares de altíssima tecnologia. Traduzindo ao pé da letra, smartphone significa “telefone inteligente”, em concordância à alta capacidade de processamento destes aparelhos. Torres (2009, p.393) os classificam como um “celular que oferece recursos avançados similares aos de um notebook”.

O aumento de dispositivos móveis conectados a internet aumenta exponencialmente ultrapassando os demais dispositivos. Os dados da pesquisa da FGV colocam o smartphone como principal dispositivo para acessar a internet ultrapassando em mais que o dobro em percentual dos demais dispositivos.

7.1.4. O GPS

O GPS ou Global Positioning System (Sistema de Posicionamento Global) foi colocado em funcionamento na década de 70 para atender a demandas do Departamento de Defesa dos EUA. É formada por um conjunto de 24 satélites em órbita da terra de modo que pelo menos 4 destes estão cobrindo qualquer ponto do globo a todo momento. Em 1995 este sistema foi considerado totalmente implementado e disponibilizado tanto para os usuários civis quanto militares.

O GPS (Global Positioning System) ou Sistemas de Posicionamento Global, atualmente, está sendo operada a partir três órbitas médias (aproximadamente 20.000 km) com oito satélites operando em cada uma. As órbitas foram projetadas de forma que cada ponto da Terra seja capaz de “enxergar” pelo menos quatro satélites em qualquer instante do dia. Este sistema possui estações de controle na superfície do globo, com a finalidade de acompanhar cada satélite para prever sua órbita e corrigi-la, se for o caso (VIDE ANEXO P). Correções de órbita demandam gastos de combustível e, por isso, cada satélite possui um tempo de vida média (DEVMEDIA).

Atualmente são dois tipos de uso para o Sistema GPS, o primeiro como cliente, onde ele só recebe sinal do satélite e apresenta localmente (no GPS) sua posição. E o segundo onde o GPS envia através dos satélites sua posição que é armazenada e processada por um servidor remoto. O uso do GPS para envio de dados para o servidor é relativamente caro, pois é tarifado por bytes enviados para o satélite. As empresas especializadas neste mercado cobram caro para fazer o uso do sistema tradicional (DEVMEDIA).

Figura 5 - Diagrama do funcionamento do Sistema GPS

https://arquivo.devmedia.com.br/REVISTAS/mobile/imagens/48/4/6.png

Fonte: Revista DevMedia

7.1.5. Geolocalização em aparelhos Android

A tecnologia do GPS trouxe novas soluções que popularizou a utilização dos dispositivos. Para dispositivos utilizando o Sistema Android foram disponibilizados APIs (Application Programming Interface) para que desenvolvedores tivesse acesso aos seus recursos e pudesse implementar em  suas aplicações(DEVMEDIA 2014).

A Google, em sua divisão de desenvolvimento disponibiliza uma grande quantidade de exemplos para que desenvolvedores possam construir suas aplicações utilizando recursos de geolocalização (MACHADO 2018).

O serviço GPS é útil em praticamente todas as situações e profissões em que seja necessário obter uma localização precisa, incluindo viagens em alto-mar, expedições em áreas remotas da terra e, principalmente, em todas as áreas da aviação (TECMUNDO 2012).

Para o nosso universo de estudos, o rastreamento tem a finalidade obter informação sobre a posição ou percurso efetuado de um determinado alvo, veículos de carga, por exemplo. O rastreamento consiste em um aparelho que obtém sua posição geográfica e as envia para um local (servidor) que as armazena e as disponibiliza para consulta, mostrando o local que se encontra ou que passou o veículo rastreado (DEVMEDIA).

7.2. SOLUÇÕES ATUAIS PARA APLICATIVOS DE MOBILIDADE URBANA

Existe uma considerável quantidade de aplicativos para dispositivos móveis criados para suprir alguma necessidade na mobilidade urbana (MOBILIZE 2018).

Este tópico tem como finalidade listar algumas dessas soluções que são relevantes para este projeto.

7.2.1. Aplicativo Próximo Ônibus – Curitiba

O aplicativo Próximo Ônibus – Curitiba é um aplicativo para celular, disponível para a plataforma Android e iOS que fornece aos seus usuários o próximo horário de um ônibus de uma determinada linha. Ele calcula quanto tempo falta para a próxima saída de um veículo se baseando em horários fixos (VIDE ANEXO F), diferenciando os horários de dias normais, sábado e domingo (ANDROID PLAY STORE 2018).

 A vantagem deste aplicativo é poder trabalhar de modo off-line se baseando em informações

Caso o usuário utilize a mesma linha com certa frequência, ele pode salvar suas linhas em favoritos para que obtenha os dados de forma mais rápida em um momento futuro. Apesar de tantas funcionalidades, o aplicativo não planeja a rota para o usuário caso o usuário não conheça todos os pontos perto de sua localização. Logo, se o usuário não conhecer seus destinos ou a localização do ponto mais próximo, ele não conseguirá fazer uso deste aplicativo (VIDE ANEXO G).

7.2.2. Aplicativo CittaMobi

O aplicativo CittaMobi foi projetado para atender as plataformas iOS e Android e tem como finalidade fornecer informações sobre a rota de ônibus calculando, em tempo real, quanto tempo um determinado ônibus leva para chegar até o local onde está o usuário. Este aplicativo aponta os pontos de ônibus mais próximos, considerando a localização do usuário.

A equipe de desenvolvimento deste aplicativo aposta nas boas práticas de utilização de redes sociais para fornecer uma funcionalidade interessante. Nela o usuário pode dar notas para o ônibus, comentar sobre o estado da linha, ruas e trajetos (CITTAMOBI).

Outro ponto interessante é que em sua mais recentes versão, ele implementa um filtro para exibir na tela os ônibus que têm adaptação para cadeirantes.

7.2.3. Aplicativo Moovit

O aplicativo Moovit oferece informações sobre para apoiar a mobilidade urbana fornecendo possibilidade de locomoção por meio de diferentes meios de transporte. O aplicativo exibe informações estáticas, e informações dinâmicas vindas dos próprios usuários. A posição onde um determinado meio de transporte está pode ser compartilhado e é possível comentar e dar notas às linhas, tornando o aplicativo uma mini rede social.

A distribuição deste aplicativo é bastante ampla sendo utilizando em diversas cidades do país e no exterior (MOOVIT 2018).

Figura 6- Aplicativo Moovit

Fonte: Moovit 2018

7.2.4. O aplicativo OneBusAway

Este aplicativo foi desenvolvido dentro do Campus da Universidade de Washington, e traz como diferencial se tratar de aplicativo de código aberto, e já foi tema de diversas publicações (ONEBUSAWAY 2017).

Há uma limitação quanto as cidades atendidas pela solução. Mas por se tratar de uma aplicação que permite acesso ao seu código fonte, novas soluções podem surgir para atender outros centros (Davis 2010).

7.2.5. Google Maps

Trata-se de uma das aplicações mais utilizadas pelos usuários do sistema operacional Android. Possuem também versão integrada para o sistema iOS. Com esta solução a Google não só disponibilizou uma aplicativo como também APIs para que os desenvolvedores de outras soluções pudessem agregar seus recursos aos aplicativos (TECMUNDO 2018).

Segundo o próprio blog oficial do Google Maps, “o aplicativo foi desenvolvido para ajudar as pessoas a navegarem e explorarem o mundo, promovendo direções, para que cheguem aos seus destinos por carros, bicicletas, a pé ou transportes públicos”.

Figura 7- Google  Maps oferece diferentes possibilidades de rotas

Fonte: Tecmundo 2018

7.2.6. Waze

Trata-se de um das soluções móveis para mobilidade no trânsito mais populares atualmente. Além de funcionar como um GPS e indicar rotas para destinos desconhecidos, ele também funciona com a colaboração dos usuários, como se fosse outra rede social, onde os motoristas atualizam informações de ruas e avenidas, como trânsito, acidentes ou presença da polícia. Tudo é compartilhado em tempo real pelos usuários e facilita ainda mais o caminho daqueles que estão utilizando o aplicativo (MOBIEBIT 2014).

7.2.7. Aplicativo Cadê o Ônibus?

Trata-se de uma solução disponibilizada para as plataformas iOS, Android e Windows Phone e tem como finalidade fornecer informações sobre as rotas e disponibilidades de ônibus na grande São Paulo. Permite que o usuário pesquise qualquer linha e ainda marque suas favoritas para consultas Futuras.

Este aplicativo foi o vencedor do prêmio Hackaton oferecido pela Secretaria de Municipal de Mobilidade e Transportes de São Paulo (SBTRANS 2018).

7.3. O SISTEMA OPERACIONAL ANDROID

O Android é um sistema operacional, inicialmente criado para smartphones e tablets, dispositivos móveis de um modo geral, porém pode ser encontrado em outros dispositivos como câmeras digitais, relógios, TVs e consoles de vídeo games. É baseado na arquitetura do Sistema Operacional Linux, utilizando uma máquina virtual customizada arquitetada para otimizar recursos de hardware e memória em um ambiente de dispositivo móvel (ANDROID 2017).

7.3.1. Android Studio

O Android Studio é um ambiente projetado para o desenvolvimento de aplicativos para a plataforma Android. Foi desenvolvido tendo como plataforma base a IDE IntelliJ Community, uma plataforma amplamente utilizada e conhecida pela comunidade de desenvolvedores de softwares através da IDE Eclipse e suas diversas versões (DEVMEDIA 2018).

Por meio desta ferramenta é possível construir a aplicação que irá ser executada na Plataforma Android. Dentro dela o desenvolvedor possui recursos para integração com as APIs, ferramentas para tratamento visual, integração com banco de dados e realização de testes e simulações (Android Studio 2018).

8. CAPÍTULO 1

A partir deste ponto será desenvolvido o tema desta monografia. Um estudo sobre o resultado das pesquisas de campo realizadas com intuito de avaliar a mobilidade urbana na capital do país.

8.1. PESQUISA DE ORIGEM / DESTINO

Para este tema, foram utilizadas as pesquisas realizadas por órgãos oficiais do Distrito Federal desde a implantação do Plano Diretor de Transporte Urbano e Mobilidade do Distrito Federal (PDTU/DF 2008).

Este trabalho de coleta de dados visava apresentar as atividades realizadas pelo Departamento Nacional de Infraestrutura de Transportes, DNIT no período de 26/07/2008 a 25/09/2008.

Neste período iniciou-se o planejamento da pesquisa origem destino domiciliar no Distrito Federal e Cidades do Entorno. Foi elaborado o formulário de pesquisa (VIDE ANEXO A) e estabelecida a população que seria pesquisada. A princípio foram incluídos no processo os domicílios familiares de todas as classes sociais, por amostragem, em todas as áreas administrativas do Distrito Federal. Foram excluídos neste universo pesquisado os:

  • hotéis, pensões e pensionatos;
  • domicílios em escolas, igrejas, templos (zelador, cuidador, padre);
  • alojamentos de militares;
  • alojamentos de trabalhadores (por exemplo, alojamentos em obras em construção);
  • embaixadas e consulados;
  • penitenciárias e reformatórios;
  • asilos e orfanatos e
  • mosteiros.

Um resultado compilado desta pesquisa se encontra disponível no Anexo B deste documento. De um modo geral os números de Brasília fecharam da seguinte forma:

Tabela 2- Pesquisa utilização de meios transporte

% de utilização

Ônibus

Automóvel

Utilitários

Metrô

Motocicleta

Bicicleta

A pé

Outros

38,07

41,42

0,19

2,64

2

1,22

9,88

4,58

De fato a população de Brasília vai para o trabalho e qualquer outro destino diário, em sua maioria, utilizando seus veículos automotores e mais recentemente por meio de contratação de transporte por aplicativo.

Levantamento semelhante foi realizado pela CODEPLAN que buscava entender os destinos da população e o percentual de uso dos principais meios de transporte.

Figura 8- Pesquisa CODEPLAN 2015

Fonte: CODEPLAN

O fato de 41% preferirem o veículo próprio no trajeto entre a casa e o trabalho ressalta que o transporte coletivo é colocado em segundo plano em Brasília. A população fazer uso de seu veículo particular, mesmo sabendo que ficará presa no congestionamento, a enfrentar as grades dificuldades apresentadas pelo transporte público (CNM 2017).

Em busca de mudar este cenário, o Governo Distrital vem tentando tornar o transporte público mais atraente. Diante do aumento do preço da gasolina, o GDF tenta buscar a integração dos sistemas de transporte, que, além de trazer economia, promete deixar o cidadão menos tempo na parada.

8.2. A PESQUISA REALIZADA PARA ESTE PROJETO

Mesmo havendo iniciativa do poder público buscando melhorar a experiência da população com o transporte público, a população que possui condições de possuir e custear seu próprio veículo automotor continua preferindo fazer uso de ele a utilizar o transporte público urbano. Esta pesquisa busca entender o motivo.

A pesquisa se baseia em um questionário de perguntas e respostas, realizada através de pesquisa em campo, nos locais onde se verifica o aglomerado de veículos estacionados. Próximo a regiões onde há um movimento de trabalhadores, como centros administrativos, repartições públicas e universidades.

A coleta dos dados desta pesquisa ocorreu entre os meses de outubro a dezembro de 2018. Entrevistando uma população de 454 pessoas de perfis variados e que se encaixam no levantamento inicial realizado por outras pesquisas que serviram de molde para esta tarefa.

Cada formulário possuía um contador para facilitar a sua identificação após a coleta de dados.

O formulário criado está disponível no Anexo C deste documento. Porém o resultado compilado será exibido a seguir.

8.2.1. Dados Iniciais

São informações preenchidas pelo próprio entrevistador e era composto por apenas 2 campos, data da entrevista e local da entrevista.

8.2.2. Perfil do Entrevistado

A população entrevistada, de um modo geral, é composta por indivíduos entre 18 a 65 anos de idade, trabalhadores e estudantes em sua grande maioria.

8.2.3. Perfil do Entrevistado – Quanto ao Sexo

Observa-se uma grande maioria de mulheres fazendo uso de transporte público urbano. São 63% dos pesquisados, mulheres contra apenas 34%.

Alguns entrevistados entenderam por bem não se enquadrar em nenhuma destas duas faixas, mesmo porque a pesquisar abria este tipo de possibilidade.

Tabela 3- Perfil entrevistados - Sexo

Sexo

Qtde.

Feminino

287

Masculino

154

Prefere não informar

13

Total

454

Figura 9- Perfil do Entrevistado - Sexo

8.2.4. Perfil do Entrevistado – Quanto à idade

Para esta pesquisa foram pesquisadas apenas pessoas maiores que 18 anos. Dentro deles a faixa de 35 a 44 anos é a maioria.

Tabela 4- Perfil Pesquisado - Idade

Idade

Qtde. Pesquisada

Maior ou igual a 65

6

Entre 55 a 64

22

Entre 45 a 54

78

Entre 35 a 44

155

Entre 25 a 34

124

Entre 18 a 24

69

Total

454

Figura 10- Perfil Entrevistado - Idade

8.2.5. Perfil do Entrevistado – Quanto à escolaridade

A maioria dos entrevistados possui ensino médio incompleto, porém ao contrário do que esperava-se, uma quantidade considerável possui ensino Superior Completo.

Tabela 5- Perfil Pesquisado - Escolaridade

Grau Escolaridade

Qtde. Pesquisada

Mestrado ou Doutorado

2

Superior Completo

109

Superior Incompleto

20

Ensino Médio Completo

131

Ensino Médio Incompleto

192

Ensino Fundamental Completo

0

Ensino Fundamental Incompleto

0

Apenas Alfabetizado

0

Analfabeto

0

Total

454

Figura 11- Perfil Pesquisado - Escolaridade

8.2.6. Perfil do Entrevistado – Possui veículo próprio

Os entrevistados que possuem veículo próprio, não estão entre a maioria. Grande parte faz uso do transporte público urbano o que nos faz crer que se trata de uma necessidade e não exatamente de uma preferência.

Tabela 6- Perfil Entrevistado - Possui veículo próprio

Possui veículo próprio ?

Qtde. Entrevistados

Sim

122

Não

329

Preferiu não responder

3

Total

454

Figura 12- Perfil Entrevistado - Possui veículo próprio

8.2.7. Perfil do Entrevistado – Quanto a preferência

Estabelecemos um grupo para escolha quanto a preferência de transporte para o deslocamento diário da população. Apesar da grande quantidade preferir se deslocar de ônibus ou de metrô (ou ambos), uma parcela considerável tem preferência por se deslocar de carro próprio, mesmo tendo sido entrevistado em locais onde aguardavam seus coletivos.

Tabela 7- Perfil do Entrevistado - Preferência de deslocamento

Preferências para deslocamento

Qtde. Entrevistados

A pé

2

Bicicleta

6

ônibus e ou metrô

239

Veículo próprio

106

Carona

46

Taxi

2

Serviço de Aplicativos

53

Total

454

 

Figura 13- Perfil do Entrevistado - Preferência de deslocamento

Tabela 8 – Resultado da pesquisa sobre a preferência no uso de veículo próprio

Qual motivo da preferência por veículo próprio

Conforto

Segurança

Deficiência

Outros

9%

28%

61%

2%

Figura 14- Resultado sobre a preferência no uso de veículos próprios

8.2.8. Preferência por motivo conforto

Foi colocado para o universo de pessoas pesquisado, que este item está relacionado com deixar de usar o transporte público por causa de conforto oferecido pelo veículo automotor próprio. Assinalaram que os pesquisados que consideram mais confortável dirigir até o trabalho ou universidade, do que se deslocar com qualquer outra forma de transporte público.

Entende-se que conforto também está relacionado com uma certa independência e autonomia do indivíduo que não quer ser dependente de horários dos transportes em massa, da possibilidade de realizar uma viagem em pé e o contato com os demais usuários daquele transporte.

É uma situação cultural e bem difícil de reverter para este 9% pesquisados. Mesmo se o transporte público tiver uma considerável melhora, este cidadão pode ainda ser resistente a aderir a esta nova modalidade.

8.2.9. Preferência por motivo segurança

Este grupo de pesquisados relatou exatamente o mesmo temor, que é o de sofrer assalto durante o trajeto. Segundo a Secretaria de Segurança do Distrito Federal, no mês de dezembro de 2017, foram registrados 149 assaltos a coletivos, uma estatística bem baixa se comparada com os 371 assaltos registrados em 2016. Na verdade uma queda da ordem de 59,8% (SSP-DF 2017).

Mesmo sendo percebida uma queda em crimes dirigidos ao transporte público, os meios de comunicação, impressa escrita, rádio e televisão, sempre estão noticiando casos de roubos a coletivos.

Para este grupo, somente uma melhoria no transporte público não é suficiente para convencê-los a deixar de usar seus carros. Mesmo que exista uma grande quantidade de registros de roubo ou furto de carros. Somente em dezembro de 2017, foram registrados 1087 furtos de veículos e 390 roubos de veículos, enquanto que no mesmo mês do ano de 2016, foram registrados 945 furtos e 471 roubos. A taxa de furtos aumentou em 15%. Sem contar furtos de partes do veículo como pneus e acessórios.

8.2.10. Deficiências do transporte público

Mais de 60% dos entrevistados prefere utilizar seus veículos, porque acreditam que o transporte público do Distrito Federal é um dos piores do país. Se sentem pouco ou nada motivados a ser deslocarem para o trabalho e dela para casa utilizando, ônibus ou metrô.

9. CAPÍTULO 2

Desenvolver aplicações para a plataforma Android é imergir em um sistema operacional que possui a sua própria API de desenvolvimento, ferramentas e cultura. Além de ser o nome que identifica o Sistema Operacional instalado numa grande quantidade de dispositivos móveis, Android também é nome que se dá a plataforma de desenvolvimento de soluções móveis (Google Developer).

9.1. OUTRAS SOLUÇÕES PARA DESENVOLVIMENTO ANDROID

Apesar da finalidade deste trabalho ser o desenvolvimento de solução mobile utilizando a plataforma de desenvolvimento fornecida pelo Google e utilizando a IDE Android Studio, para utilizar os conhecimentos adquiridos no curso, existem outras soluções que podem ser utilizadas para o mesmo objetivo.

9.1.1. React Native

O React Native é um projeto concebido pela equipe técnica do Facebook, composto por uma série de ferramentas que permitem a criação de aplicações móveis para a plataforma iOS e Android.

Figura 15- React Native multiplataforma.

Fonte: React Native

O React Native é um framework com muitas características interessantes para desenvolvedores. Foi implementado com funcionalidades muito práticas que aumentam a produtividade do processo de desenvolvimento. Uma delas permite que o programa fique rodando durante o processo de desenvolvimento. Toda vez o código sofre uma modificação a aplicação é atualizada em tempo real. Para o desenvolvimento mobile é um grande ganho, pois em outros frameworks nativos, a cada mudança no código, a aplicação precisava ser recompilada por completo, levando muito mais tempo (DEVMEDIA).

Figura 16- Diagrama de funcionamento do React Native,

Fonte: DevMedia

Outra vantagem para equipes de desenvolvimento é que é necessário contratar desenvolvedores para diferentes plataformas, iOS e Android, já que o framework  permite transpor o mesmo código para os dois mundos.

9.1.2. O Ionic

Trata-se de outro framework, open source, para desenvolvimento de aplicativos móveis multiplataforma. Seu forte é permitir a implementação de aplicativos fazendo uso de tecnologias empregadas no desenvolvimento Web tais como o HTML, CSS e o JavaScript. Além disto, traz recursos que simplificam ainda mais o desenvolvimento e permitem construir aplicações com aspecto mais profissional (DEVMEDIA 2018).

Figura 17- Diagrama estrutura Ionic.

Fonte: DevMedia

O Ionic disponibiliza um conjunto de componentes visuais para que realizemos a construção do front-end da solução. Além disto, o Ionic permite fazer uso de linguagens e frameworks para prover uma solução de mais alto nível em termos de código e, consequentemente, projeto. Neste caso o TypeScript e o Angular (School of Net 2018).

9.1.3. O Xamarin

Trata-se de plataforma de desenvolvimento para aplicativos mobile baseado na linguagem C# da Microsoft e como características de desenvolvimento multiplataforma.

Figura 18- Xamarin permite transporte para outras plataformas.

Fonte: Microsoft

As vantagens em utilizar esta plataforma se resumem em a permitir centralizar o código sem perder a possibilidade de ter detalhes específicos de cada Sistema Operacional. Outra está na utilização da linguagem C# que é amplamente  disseminada entre os desenvolvedores (DEVMEDIA).

Figura 19-Xamarin permite codificação baseada em C#

Fonte: Microsoft

8.1.4 – O Apache Cordova

Trata-se de uma plataforma para desenvolvimento de aplicativos móveis fazendo uso de tecnologias já consolidadas como o HTML, CSS e JavaScript para isso. Significa dizer que a partir de tecnologias de desenvolvimento Web, uma equipe de TI poderia transpor uma solução mobile.

Figura 20 - Arquitetura Cordova.

Fonte: DevMedia

Mesmo que o Cordova permita desenvolver a partir de uma visão Web, o usuário do aplicativo não percebe isso. Ele terá a impressão de que a aplicação realmente se comporta como se fosse um aplicativo nativo (DEVMEDIA).

9.2. DESENVOLVENDO COM O ANDROID NATIVO

Inicialmente, todo desenvolvimento é centralizado na IDE Android Studio, não é necessariamente obrigatório fazer uso desta IDE, mas ela possui todos os recursos e absorve satisfatoriamente a evolução da plataforma.

As linguagens utilizadas são o Java, amplamente difundida e reconhecida e a linguagem Kotlin. Esta última pode ser compilada para a Máquina virtual Java também pode ser traduzida para o JavaScript e transposta para código nativo Android.

9.2.1. Desenvolvimento Nativo x Desenvolvimento híbrido

Desenvolvimento Nativo significa dizer que o aplicativo será construído para uma plataforma específica, como iOS ou Android. O aplicativo produzido aqui será capaz de explorar todas as potencialidades da plataforma para a qual foi criado. Consegue ter acesso a diversos recursos dos aparelhos como GPS, câmera, calendário, lista de contatos, por exemplo. E nem sempre os aplicativos nativos precisam da internet para seu funcionamento.

Enquanto que o desenvolvimento do aplicativo híbrido tem características do desenvolvimento nativo e desenvolvimento Web, utilizando códigos de ambos para sua criação. Este modelo de desenvolvimento gera aplicações que podem usar recursos tanto da internet quanto do dispositivo e tem a capacidade de ser executado em diferentes plataformas. O problema é que um aplicativo desenvolvido por meio híbrido não consegue acessar muitas das funcionalidades do dispositivo diretamente, sendo necessário o uso de um framework para intermediar o acesso ao núcleo daquele sistema operacional.

9.2.2. O NDK

O Android Native Development, ou Desenvolvimento Nativo para Android, é um conjunto de ferramentas que permitem usar código nativo C e C++ em aplicativos Android (Android Developers 2018).

 O NDK pode integrar a base nativa que acessa os recursos do dispositivo e o SDK (Software development kit), o que significa dizer que podemos escrever o código em uma linguagem alto nível como o Java, utilizando as APIs nativas do Sistema Android, sem necessariamente ter que escrever em C ou C++ (VIDE ANEXO D).

9.3. DECISÃO DE PROJETO

Diante de uma vasta lista de opções para desenvolvimento da solução mobile proposta neste projeto, a escolha por desenvolver utilizando a IDE Android Studio com o NDK, está relacionado com o aprendizado proposto durante o curso de Pós Gradução. Não se trata da melhor ou pior opção, mas sim da busca de uma solução dentro do escopo acadêmico tratado durante o curso.

10. CAPÍTULO 3

A partir deste capítulo será proposta uma a criação de um protótipo para testar a viabilidade de uma solução mobília que possa apoiar o cidadão na utilização do transporte urbano no seu dia a dia.

10.1. DESCRIÇÃO DA PROPOSTA DE TRABALHO

Este trabalho tem como objetivo analisar, modelar e desenvolver o projeto de um protótipo de sistema de informação que tenha como finalidade colaborar no processo locomoção dos usuários de transporte público urbano.

Este sistema de informação deverá ser executado a partir de dispositivos mobile exclusivamente para a arquitetura Android.

O Sistema de Informação deverá prover informações sobre as possibilidades de locomoção para os usuários informado qual a melhor forma de chegar ao destino solicitado.

10.2. RESULTADOS ESPERADOS

Implementar um protótipo de Sistema de Informação capaz de orientar ao seu usuário escolher a melhor forma de locomoção urbana para a cidade Brasília e entorno incluindo a informação de estimativa de tempo e distância a percorrer além de sugerir qual o melhor meio de transporte utilizar.

Em resumo, os resultados esperados são:

  • Projetar uma aplicação mobile que seja executado na arquitetura Android;
  • Desenhar uma interface de usuário que seja capaz de apresentar para o utilizador, clareza, consistência, atraente e amigável;
  • Adaptar os casos de sucesso de outros aplicativos que possuam a mesma característica, para a cidade de Brasília.

10.3. RESTRIÇÕES

O Sistema não contempla, versão para ser executada em outros sistemas operacionais como iOS ou Windows Phone.

Não será projetada, para esta versão, uma solução integrada ou interface Web para que seja acessada de outros dispositivos que não aquelas com características móveis.

10.4. RECURSOS NECESSÁRIOS

Esta seção descreve qual a infraestrutura de ambiente, hardware, software e pessoal, precisa ser disponibilizada e organizada para produzir este sistema. Também descreve qual o hardware mínimo (dispositivo móvel) em que o sistema será executado.

10.4.1. Hardware mínimo para desenvolvimento o projeto

Entende-se por “hardware mínimo” o conjunto de dispositivos de hardware com o mínimo de características para garantir que o desenvolvedor possa desenvolver o projeto.

Tabela 9- Requisitos mínimos para máquina de desenvolvimento.

Descrição

Qtde

Valor unitário

Total

Computador Processador Intel Core i5-4460 Powered By ASUS - 8029 AS

1

2.541,06

2.541,06

Mínimo de 3 GB de RAM, 8 GB de RAM recomendados, mais 1 GB para o Android Emulator

Monitor LG LED 21.5´ Widescreen, HDMI/VGA/DVI

2

676,35

1.352,70

 

 

Total

3.893,76

Fonte: Disponível em: <http://www.kabum.com.br>. Acesso em 15 dez. 2018.

 

10.4.2. Software mínimo para desenvolvimento do projeto

Para o desenvolvimento deste projeto, serão necessários um mínimo de recurso de máquina e Sistema Operacional. No site de desenvolvedores oficial para a plataforma é informado que a IDE Android Studio exige no mínimo:

Tabela 10- Requisitos mínimo de sistema operacional instalado

 

Sistema

Versão

Memória

Unidade Armazenamento

Resolução vídeo

Windows

Microsoft® Windows® 7/8/10 (32 ou 64 bits)

Mínimo de 3 GB de RAM, 8 GB de RAM recomendados, mais 1 GB para o Android Emulator

Mínimo 2 GB de espaço livre em disco,
4 GB recomendados (500 MB para o ambiente de desenvolvimento integrado + 1,5 GB para o SDK do Android e as imagens do sistema do emulador)

1.280 x 800

MAC

Mac® OS X® 10.10 (Yosemite) ou versão posterior, até a 10.13 (macOS High Sierra)

Mínimo de 3 GB de RAM, 8 GB de RAM recomendados, mais 1 GB para o Android Emulator

Mínimo 2 GB de espaço livre em disco,
4 GB recomendados (500 MB para o ambiente de desenvolvimento integrado + 1,5 GB para o SDK do Android e as imagens do sistema do emulador)

1.280 x 800

Linux

Área de trabalho GNOME ou KDE
Testado no Ubuntu® 14.04 LTS, Trusty Tahr (distribuição de 64 bits capaz de executar aplicativos de 32 bits)

Mínimo de 3 GB de RAM, 8 GB de RAM recomendados, mais 1 GB para o Android Emulator

Mínimo 2 GB de espaço livre em disco,
4 GB recomendados (500 MB para o ambiente de desenvolvimento integrado + 1,5 GB para o SDK do Android e as imagens do sistema do emulador)

1.280 x 800

 

Fonte: Disponível em https://developer.android.com/studio/?hl=pt-br. Acesso em 15-12-2018

 

Uma pesquisa realizada no mercado permitiu estimar os valores dos Sistemas Operacionais caso sejam adquiridos.

Tabela 11- Valor estimado de licença

Sistema Operacional

Valor licença

Microsoft Windows

799,00

Mac OS

69,00

Linux

0,00

Fonte: Sites oficiais da marca. Acesso em 15-12-2018

 

Apesar de incluir neste levantamento, informações dos Sistemas Operacionais MacOs e Linux, o Sistema adotado foi o Microsoft Windows por questões de conveniência. Desta forma podemos estabelecer uma estimativa de custo a ser investido em equipamento e software para iniciar o projeto.

Outro software que precisa ser instalado é o Android Studio que é a IDE responsável por apoiar o desenvolvimento da solução. Os requisitos de Sistema Operacional é máquina já foram descritos, porém esta ferramenta precisa que sejam instalados também outros componentes sem os quais desenvolver seria impossível.

Tabela 12- Ambiente de desenvolvimento

Ferramentas necessárias

Descrição

Custo

JDK

Java Development Kit significa Kit de Desenvolvimento Java, e é um conjunto de utilitários que permitem criar sistemas de software para a plataforma Java.

0,00

Android SDK

O Android SDK ou Kit de Desenvolvimento de Software para Android é um pacote com diversas ferramentas utilizadas pelo Android Studio.

0,00

Android Studio

IDE para apoiar o desenvolvimento

0,00

Fonte: Site school of net acessão em: < schoolofnet.com/curso/android>

10.4.3. Profissionais necessários para iniciar o projeto

A equipe técnica necessária para iniciar o projeto deve ser composta por profissionais da área de TI com conhecimento multidisciplinar. Tendo em vista que um projeto de software produz algo mais do que simplesmente código de programa.

Tabela 13 - Estimativa de gasto com equipe técnica

Profissional

Função

Hora / Homem

Valor hora

Estimativa custo

Designer

Responsável por elaborar o desenho das interfaces do aplicativo, cuidando da usabilidade, fundamental para o sucesso do aplicativo.

200

15,80

3.160,00

Arquiteto de Software

Analisa as necessidades do projeto e define a arquitetura técnica que melhor se encaixa no projeto. É comum sua participação na programação do aplicativo, sendo responsável pelas partes mais complexas do projeto.

250

50,00

12.500,00

Analista de sistemas

É responsável por compreender a necessidade de negócio do cliente e especificar por escrito o que precisa ser feito no projeto. É um profissional com bagagem em desenvolvimento de software e, em alguns casos, também ajuda na programação.

360

50

18.000,00

Desenvolvedor / Programador

Transforma as especificações de negócio do aplicativo em código, seguindo as diretrizes técnicas do arquiteto e análise funcional do analista de sistemas. O código fonte faz a conexão com banco de dados e a camada visual, para leitura, gravação e exposição das informações. Essa parte representa em torno de 50% do esforço total de um projeto de desenvolvimento de aplicativo para celular.

Não pare agora... Tem mais depois da publicidade ;)

360

50,00

18000

Gerente de Projetos

Profissional que cria e acompanha o cronograma do projeto, distribuindo as tarefas para os profissionais.

360

72,00

25920

 

 

 

Total estimado

77.580,00

Fonte: ALVES 2018

10.5. CUSTO PARA INICIAR O PROJETO

A estimativa de custo para este projeto relaciona os valores de equipamentos, softwares e gastos com pessoal. O gasto com pessoal leva em consideração que todos os contratados trabalham em regime de prestação de serviço como profissionais liberais.

Tabela 14 - Estimativa de custo do projeto

Identificação

Valor Estimado

Despesas com hardware

3.893,76

Despesas com Software

799,00

Despesas com pessoal

77.580,00

Total

82.272,76

Obviamente por causa das características deste projeto, que tem a finalidade de produzir um protótipo funcional, muitos outros custos não foram arrolados. Afinal o que buscamos aqui é descrever um cenário com finalidades didáticas.

Outro ponto importante é que o projeto pode acabar saindo mais caro do que foi previsto, mesmo simplificando ao máximo o uso de recursos.

10.6. ESTIMATIVAS DE PRAZO DO PROJETO

A estimativa deste projeto é que tenha a duração de 6 meses onde espera-se que todo ciclo de desenvolvimento seja concluído.

11. CAPÍTULO 4

Este capítulo tratará do planejamento de um projeto de protótipo apresentado como foco deste documento.

11.1. PLANO DE PROCESSO DE DESENVOLVIMENTO

A finalidade de um plano de Processo de Desenvolvimento é definir as metas, ciclo de vida, recursos e ferramentas adotadas para organização do trabalho de desenvolvimento do software supra proposto.

11.1.1. Ciclo de vida do projeto

Para este projeto, a escolha foi o modelo de processo unificado, por propor ciclo de vida iterativo, que sugere um desenvolvimento organizado em iterações. Entende-se por iteração, como sendo um período de tempo finito e definido dentro deste projeto ao final do qual tenhamos produzido uma pequena porção do produto de software desejado, estável e em condições de executar, acompanhado de documentação de apoio, scripts para instalação e manutenção. Cada uma das iterações deve ser construída baseada em resultados da iteração anterior, produzindo um incremento do produto de software a caminho do seu formato final

Figura 21- Fases e Disciplinas do Processo Unificado

Para o desenvolvimento de nosso protótipo, será adotado, como base em uma adaptação do processo do Rational Unified Process (RUP) englobando as seguintes fases de projeto:

  • Concepção: nesta fase será proposto o escopo do projeto. A estimativa dos custos gerais, os requisitos e as restrições. Busca-se aqui o consenso entre todos os envolvidos sobre os objetivos do ciclo de vida do projeto;
  • elaboração: nesta fase busca-se produzir um estudo mais refinado sobre os requisitos com a finalidade de compreender o máximo possível o domínio do negócio, minimizando os riscos e promovendo uma estabilidade maior para a aprovação e início da fase de construção;
  • construção: propõe-se aqui promover a implementação para o que foi levantado nas fases anteriores. Buscando atingir um nível de qualidade aceitável com eficiência, otimizando recursos e evitando retrabalho. Trata-se de um processo de manufatura, em que a ênfase está no gerenciamento de recursos e controle de operações para aperfeiçoar custo, programações e qualidade; e
  • transição: busca-se promover a garantia que o produto de software fique disponível para os usuários finais e que estes juntamente com a equipe de manutenção se tornem aptos a utilizá-los.

Optou-se por utilizar, para modelagens dos processos, os artefatos disponíveis na Unified Modeling Language (UML), Linguagem Unificada de Modelagem que são recomendados pelo RUP com algumas e adaptações.

As atividades do projeto deste projeto foram divididas em oito iterações, compreendidas como:

Figura 22- Lista de  Iterações

Iteração

Atividade

1

Levantamento e especificação dos requisitos

Identificação dos requisitos críticos

2

Análise detalhada dos requisitos do Módulo de Controle de Acessos

Análise detalhada dos requisitos do Módulo de Controle de Acessos

Implementação do Módulo de Controle de Acessos

Testes de unidade do Módulo de Controle de Acessos

Testes de regressão do Módulo de Controle de Acessos

3

Análise detalhada dos requisitos do Módulo de Pesquisa de Destinos

Implementação dos módulos de Pesquisa de Destinos

Testes de unidade do Módulo de Pesquisa de Destinos

Testes de regressão do Módulo de Pesquisa de Destinos

4

Análise detalhada dos requisitos do Retorno de pesquisa

Implementação dos módulos de Retorno de pesquisa

Testes de unidade do Módulo de Retorno de pesquisa

Testes de regressão Módulo de Retorno de pesquisa

5

Teste de integração entre os módulos

6

Testes gerais do software

7

Entrega do produto de software

11.1.2. Métodos de Desenvolvimento e ferramentas CASE

Nesta seção será descrito as ferramentas que serão adotadas pela equipe do projeto para produzir os artefatos utilizados no desenvolvimento desta aplicação.

11.1.3. A Orientação a Objetos

A Orientação a Objetos é um paradigma para análise, projeto e programação de softwares que baseado na composição e interação entre unidades do programa chamadas de objetos.

A proposta do paradigma é estar o mais próximo possível da vida real quando define a descrição dos componentes que serão desenvolvidos modelados ao domínio do problema que se propõe resolver.

A finalidade deste modelo é produzir melhor organização, desempenho, sustentabilidade e reutilização dos componentes de software.

11.1.4. A UML

Trate-se de uma linguagem de modelagem, que permite aos desenvolvedores visualizarem os componentes do produto de software que está sendo construído por intermédio de uma série de artefatos que auxiliam na tarefa de modelar e documentar os sistemas orientados a objetos. (DevMedia 2018).

Por se tratar de uma linguagem de modelagem, o seu forte é fazer uso de digramas que podem ser interpretados por toda equipe de desenvolvimento e na maioria dos casos, pode-se apresenta-los ao cliente.

Figura 23- Exemplo UML, diagrama de atividades

11.1.5. Linguagens de Programação

Este será desenvolvimento utilizando somente tecnologia de software livre. Será adotada como base de desenvolvimento a linguagem Java, adaptada para desenvolvimento para a arquitetura Android.

11.2. PLANO DE ACOMPANHAMENTO

Esta seção descreve os processos a serem adotados com intuito de apoiar o controle e acompanhamento do desenvolvimento deste projeto.

11.2.1. Marcos de Pontos de Controle

Serão descritos os principais marcos que delimitariam o ciclo de vida deste projeto.

Tabela 15- Marcos e pontos de controle

Ordem

A ser produzido

Data prevista

1

Documento de especificação de requisitos

24-02-2019

2

Diagramas da análise (Casos de uso, Classes, Sequência, Estados)

01-03-2019

3

Protótipos de tela

25/03/2019

4

Entrega do módulo de controle de usuários

11/05/2019

5

Entrega do módulo de consulta

18/06/2019

6

Entrega do módulo de resultado de consulta

09/07/2019

7

Entrega do produto final, documentação e monografia

24/07/2016

As datas descritas na tabela acima, são estimativas para definirem-se marcos do projeto. Como não faz parte da finalidade deste documento de conclusão, estas datas não necessariamente precisarão ser cumpridas. Porém estão bastante próximo a realidade na produção de um projeto de software, levando-se em consideração que se trata de um projeto de 6 meses.

11.2.2. Análise e gerência de risco

Esta seção descreve os prováveis riscos identificados que, de alguma maneira, possam impactar no andamento do projeto e as ações que deverão ser tomadas para reagir a cada um deles.

11.2.3. Categorização dos riscos

A fim de definir uma categoria de riscos e seus impactos estabelecem-se os seguintes critérios:

  • Fatal, sua ocorrência decretaria o fim do projeto. Peso 2;
  • médio, sua ocorrência não poderia ser negligenciada, mas não decretaria o cancelamento do projeto de início. Peso 1; e
  • baixo, sua ocorrência poderia ser facilmente contornada. Peso 0.

Escolheu-se utilizar peso para ter-se como quantificar a categoria de risco a fim de permitir uma análise com valores.

Tabela 16- Categoria de Riscos

Descrição do Risco

Categoria atribuída

Escopo do projeto mal definido

Médio

Problemas ao estimar a necessidade do público alvo

Fatal

Equívoco na escolha da Tecnologia

Fatal

Problemas com gerência de da equipe

Médio

Custo do projeto mal definido

Fatal

Dificuldades em gerir tempo de projeto

Fatal

Falhas de integração do software ao ambiente de produção

Fatal

Equívoco na medição de produtividade

Baixo

Equívoco na avaliação dos artefatos

Baixo

11.2.4. Estimativas de ocorrência

Com a categoria conseguimos definir quais riscos são de maior ou menor impacto, será definido uma pontuação que nos ajude a descobrir quais dos riscos acima descritos tem maior ou menor chance de ocorrer durante o projeto.

Para que seja possível estimar de forma quantitativa, decidiu-se definir valores para quantificar a ocorrência do problema, descritas no quadro a seguir.

Tabela 17- Distribuição de valores

Valor

Justificativa

3

Grandes chances de ocorrer, algo acima de 60%.

2

Baixas chances de ocorrer, abaixo de 30%.

1

Ocorrência mínima, em torno de 1%.

Tabela 18- Estimativas de risco

Descrição do Risco

Categoria atribuída

Escopo do projeto mal definido

2

Problemas ao estimar a necessidade do público alvo

1

Equívoco na escolha da Tecnologia

1

Problemas com gerência de da equipe

3

Custo do projeto mal definido

1

Dificuldades em gerir tempo de projeto

1

Falhas de integração do software ao ambiente de produção

1

Equívoco na medição de produtividade

3

Equívoco na avaliação dos artefatos

2

O próximo quadro descreve uma comparação entre riscos e impactos propondo um cálculo para definir para qual risco será dispensado maior atenção.

Tabela 19- Impacto x chances de ocorrência

Descrição do Risco

Estimativa

Impacto

Resultado

Problemas com gerência de da equipe

3

3

6

Equívoco na medição de produtividade

3

3

6

Escopo do projeto mal definido

2

2

4

Equívoco na avaliação dos artefatos

2

2

4

Problemas ao estimar a necessidade do público alvo

1

1

2

Equívoco na escolha da Tecnologia

1

1

2

Custo do projeto mal definido

1

1

2

Dificuldades em gerir tempo de projeto

1

1

2

Falhas de integração do software ao ambiente de produção

1

1

2

Com esta estimativa, agora ordenada do maior resultado para o menor, será possível estabelecer um plano de contingência para definir a melhor estratégia de prevenção contra os riscos que foram elencados.

Tabela 20- Plano de Contingência

Para os problemas relativos a gerência da equipe

  • Promover o acompanhamento da equipe ao longo do projeto;
  • manter um controle próprio da produtividade de cada integrante com o que se espera que ele produza;
  • estabelecer metas alcançáveis;
  • procurar resolver o mais rápido, possíveis problemas de relacionamento;
  • manter uma lista atualizada de contato com cada um dos integrantes; e
  • manter uma lista de prováveis substitutos para cada integrante da equipe.

Para problemas com equívoco na escolha da Tecnologia

  • É muito importante que a escolha da tecnologia atenda aos requisitos do projeto, por isso uma atenção maior deve ser dispensada a este tópico logo no início, uma vez que tendo escolhido uma tecnologia inadequada não será possível migrar para outra ao longo do desenvolvimento.

Para problemas relativos a custo do projeto mal definido

  • Rever em períodos curtos de tempo os gastos realizados até o momento e as metas do projeto a fim de poder identificar o mais breve possível prováveis problemas.

Para problemas com equívoco na escolha da Tecnologia

  • É muito importante que a escolha da tecnologia atenda aos requisitos do projeto, por isso uma atenção maior deve ser dispensada a este tópico logo no início, uma vez que tendo escolhido uma tecnologia inadequada não será possível migrar para outra ao longo do desenvolvimento.

Para problemas relativos a custo do projeto mal definido

  • Rever em períodos curtos de tempo os gastos realizados até o momento e as metas do projeto a fim de poder identificar o mais breve possível prováveis problemas.

Para os problemas relativos ao tempo do projeto

  • Discutir o cronograma com toda equipe do projeto e com o cliente-contratante; e
  • Rever em períodos curtos de tempo os gastos realizados até o momento e as metas do projeto a fim de poder identificar o mais breve possível prováveis problemas.

11.3. ESPECIFICAÇÃO DOS REQUISITOS

11.3.1. Descrição do Problema

Atualmente, quando um usuário de transporte público urbano necessita se locomover pelo Distrito Federal e Entorno, precisa ter um prévio conhecimento acerca dos meios de transporte público disponíveis em sua localização.

Não há uma preocupação do gestor público em criar uma rede de informações acerca das linhas de ônibus, metrô ou outro tipo de forma de transporte público. Toda iniciativa de sucesso parte de idealizadores privados, estudantes das universidades locais ou soluções pensadas para outras cidades.

Existem aplicativos disponíveis, porém a grande maioria traz informação especializada em uma única forma de transporte.

11.3.2. Identificação dos interessados

Durante a pesquisa para confecção deste trabalho, levantou-se que existem um grupo de indivíduos da população do Distrito Federal que tem interesse na produção de um aplicativo como o que está se propondo.

  • População que trabalha longe de seu domicílio e que não dispõe de veículo próprio para locomoção. Estando totalmente dependente do transporte público urbano.
  • População que faz uso do transporte público urbano para se locomover para seu local de estudos. Geralmente população mais jovem.
  • Usuários triviais de transporte público urbano, como por exemplo, turistas.

11.3.3. Principais necessidades dos interessados

Listam-se aqui as principais necessidades do grupo de potenciais usuários a fazer uso da ferramenta.

  • Definir uma rota para seu destino com estimativa de horário de chegada com informação de diferentes formas de transporte público disponíveis em sua localização;
  • Localizar um determinado meio de transporte e estimar o tempo para chegar até sua localização;
  • Integrar a solução com outras já disponíveis e consolidadas como aplicativos de transporte privado (Uber e Cabify).

11.4. DESCRIÇÃO DAS CARACTERÍSTICAS DO SISTEMA

11.4.1. A escolha do nome

O termo baú, na região do Distrito Federal, é uma gíria que muito utilizada para ônibus. Este substantivo é usado amplamente pela população que se identifica com ele. Por este motivo, resolveu-se nomear o projeto do aplicativo como “BAU’s” como uma homenagem.

11.5. REQUISITOS DO APLICATIVO

Será descrito, nesta subseção, o grupo de funcionalidades inerentes a proposta para desenvolvimento do protótipo “BAU’s”.

O aplicativo “BAU’s será um sistema de informação desenvolvimento para ser executado exclusivamente em ambiente Android não sendo portando, neste versão, para outra plataforma. Não terá um painel para acesso e monitoração pela Web.

11.5.1. Tela inicial

A tela inicial, ou principal do aplicativo, exibirá as primeiras opções de navegação. Será sempre para esta tela que o usuário retornará ao final de um fluxo de navegação.

Ela será composta por:

  • Um campo de entrada com título, “Para onde vamos?”
  • No canto inferior será exibido um mapa, com layout default do Google Maps, com o apontamento para a localização atual.
  • No canto superior esquerdo será exibido um menu do tipo Menu Deslizante que dará acesso as principais opções das funcionalidades do aplicativo. Este Menu será replicado para outras telas.

O campo “Para onde vamos?” tem como finalidade permitir ao usuário informar um destino.

Figura 24 - Tela de acesso do BAU's

Retorno de Pesquisa

Esta funcionalidade tem como diretriz, montar a resposta da consulta realizada pelo usuário. Esta resposta trará, além do trajeto mais curto, sugestões de transporte público, o preço aproximado de cada meio de transporte e o tempo que levará para chegar ao destino de cada um.

11.5.2. Seleção de Trajeto

Ao optar por selecionar um determinado trajeto, o aplicativo retornar informações sobre as linhas de ônibus, metrô ou outro dentro do escopa da aplicação orientando como o usuário poderia chegar até o local onde embarcaria.

Para um ônibus, por exemplo, será exibida as paradas de ônibus mais próximas e como chegar caminhando até elas.

11.6. NAVEGABILIDADE ENTRE AS TELAS

A navegabilidade em aplicativos móveis é um tema ainda mais importante quanto complexo quando comparado com navegabilidade em websites.

Recentemente estudo feito com um população de 179 pessoas, realizado pelo Nielsen Norman Group, chegou a conclusão de que os menus de navegação são mais usados nos dispositivos móveis do que nos demais dispositivos (computadores desktop e notebooks.) (BUDIU 2017).

O protótipo que a ser construído terá sua navegabilidade estabilizada a partir dos submenus disparadosa partir do menu do tipo drawer lateral, comumente conhecido por Menu Hamburger. Esta decisão poderá trazer uma navegabilidade mais limpa e que prioriza pelo espaço livre que será disponibilizado na tela.

Figura 25- Menu navegação BAU's

11.7. CONTEXTO DE UTILIZAÇÃO DO SISTEMA

Quando um usuário deseja encontrar a melhor maneira de chegar ao seu destino, executa o aplicativo em seu dispositivo móvel e na tela inicial, informa a localização do seu destino. Esta localização pode ser um CEP, um endereço ou uma localidade conhecida.

Esta funcionalidade deverá retornar uma lista de opções para mobilidade, como linhas de ônibus com a localização as paradas mais próximas, estação de metrô, se for o caso, valor estimado para taxi e valor cobrado pelo trajeto a aplicativos de transporte.

11.8. REQUISITOS SUPLEMENTARES

São requisitos não funcionais que representam algum tipo de restrição tecnológica ou lógica que se aplica ao sistema como um todo. São organizados e categorizados de acordo com o modelo FURPS+ (Funcional, Usabilidade, Confiabilidade, Desempenho, Portabilidade + restrições). As Restrições incluem restrições físicas, de design, de implementação, de interface e regras de negócio. Segue abaixo uma descrição de cada um destes tipos de requisitos.

  • Requisitos Funcionais: incluem todos os requisitos que representam as principais características do sistema que são relacionados ao domínio do negócio ou aos requisitos tecnicamente orientados tais como auditoria, licenciamento, localização, correio, ajuda on-line, informes, segurança, gestão de sistema ou fluxo de trabalho;
  • requisitos de Usabilidade: são os requisitos baseados em fatores humanos e questões de interface de usuário tais como acessibilidade, estética da interface e consistência dentro da interface de usuário;
  • requisitos de Confiabilidade: incluem aspectos tais como disponibilidade, exatidão, previsibilidade, frequência de falhas ou a capacidade de recuperação do sistema às falhas de parada completa;
  • requisitos de Desempenho: relacionam as preocupações, como a taxa de transferência da informação através do sistema, tempo de resposta do sistema e uso de recursos; e
  • requisitos de Portabilidade: relacionam requisitos tais como compatibilidade e as habilidades para testar, adaptar, manter, configurar, instalar, escalonar e localizar.

O + do acrônimo FURPS+ relaciona as restrições, como restrições físicas, de design, de implementação, de interface e regras de negócio:

  • Restrições de Design: definem uma fronteira para os requisitos de estado e design na abordagem que deve ser feita no desenvolvimento do sistema;
  • restrições de Implementação: estabelecem limites sobre a codificação ou a construção (linguagens, ferramentas, plataforma ou padrões necessários);
  • restrições de Interface: requisitos necessários para interagir com os sistemas externos;
  • restrições Físicas: são os que tratam do hardware ou o empacotamento físico do sistema (forma, tamanho e peso); e
  • regras de Negócio: tratam das políticas ou decisões que governam as regras de negócio. Podem restringir os passos descritos nos fluxos de Casos de Uso.

11.8.1. Usabilidade

A usabilidade é um conceito trata da experiência de uso das pessoas com produtos, tendo também algumas limitações. Trata-se da forma como o usuário de relaciona com a solução de software.

Este protótipo deverá atender aos seguintes temas relacionados com a usabilidade.

  • Facilidade de aprendizado;
  • Ser fácil para memorizar o funcionamento da interface;
  • Permitir maximizar a produtividade;
  • Reduzir as taxas de erros;
  • E, tendo todos acima, sido atendidos, maximizar a satisfação do usuário.

11.8.2. Desempenho

Será definido como requisito de desempenho, para este protótipo, o tempo médio de resposta das funcionalidades em 1,33s. Este é o tempo médio para as funcionalidades, rolamento de tela, seleção de item em mapas ou abertura de menus, o tempo aceitável deverá cair para 0,2s.

11.8.3. Procedimentos contra perda de dados

Este protótipo, não possuirá funcionalidade que realize a persistência dos dados. Nesta versão, mesmo o cadastro de usuário terá informações perenizadas. Seu acesso será feito através de login em redes sociais ou e-mail.

Esta decisão de projeto foi tomada para reduzir o tamanho e complexidade do protótipo e poderá ser alterada em versões superiores.

11.9. RESTRIÇÕES DO SISTEMA

O sistema será desenvolvido em linguagem orientada a objetos baseada na plataforma Java e seus derivados a partir da IDE Android Studio.

As telas de usuário, mesmo obedecendo as boas práticas de navegabilidade, serão simplificadas para reduzir a complexidade

Não será utilizado qualquer Sistema Gerenciador de Banco de Dados (SGBD).

Este protótipo somente será executado em dispositivos onde esteja instalada versões do sistema Android.

11.10. VISÃO PRELIMINAR DA ARQUITETURA

11.10.1. Quanto ao Sistema

Trata-se de sistema informatizado composto por um dispositivo móvel onde esteja instalada o Sistema Operacional Android. Não possuirá painel de configuração online nem plataforma externa interligada.

11.11. Quanto ao Servidor de Aplicação

Ao contrário de aplicações Web, este protótipo depende apenas do ambiente fornecido pela plataforma Android nos dispositivos móveis do usuário.

11.12. Quanto a distribuição

Por ser tratar de um protótipo, sua distribuição será restrita a disponibilização do aplicativo para usuários instalarem. Nesta versão não será realizada distribuição pela Play Store.

11.13. REQUISITOS NÃO TÉCNICOS

O tempo de desenvolvimento deste sistema terá limite máximo de 6 meses. Não foram cogitadas possibilidade de buscar patrocinadores para a produção do protótipo.

Não foram definidas um padrão de cores para a identidade visual do protótipo.

11.14. POSSIBILIDADE DE EVOLUÇÃO FUTURA

Será listada aqui quais as possíveis evoluções em uma futura versão, quando a solução deixaria de ser um protótipo:

  • Para futuras versão, poderá desenvolvido uma melhor relação com o cadastro dos usuário para gerar dados estatísticos ou que possam vir a ser monetizados.
  • Poderá ser projetada uma estrutura de banco de dados para perenizar informações de navegação que poderiam ser recuperadas pelo usuário.
  • O aplicativo poderia ser monetizado exibindo propagandas.
  • A distribuição será realizada pela Google Play Store.
  • A aplicação poderia estabelecer algum tipo de relação entre seus usuários com a finalidade de estabelecer um rede de colaboração, nos moldes de redes sociais.
  • Seria interessante a construção de um painel para ser executado via aplicação Web com a finalidade de prover informações sobre a utilização do aplicativo em tempo real.

11.15. MODELOS DE CASO DE USO

Esta seção tem como finalidade descrever a modelagem que apresenta a interação entre os atores e o sistema a ser desenvolvido, baseando-se nos requisitos de software. Os Casos de uso serão utilizados para orientar todo o processo de produção do software, a partir de sua definição.

11.15.1. Fluxo principal

Neste ponto será descrito, por meio de um diagrama de negócio, o fluxo básico para navegação do protótipo.

Figura 26 - Fluxo principal

Sendo sempre o usuário o ator principal, dele sairá todos comandos para as funcionalidades da aplicação.

A tela de acesso, apenas solicita a permissão para continuar, tendo em vista que não foi previsto para este projeto a construção de algoritmo de login.

A tela principal permitirá a distribuição da navegação para os módulos principais.

11.15.2. Visão geral dos casos de uso e atores

Figura 27- Visão geral dos casos de uso

11.15.3. Descrição dos casos de uso

 Esta seção tem como finalidade fornecer artefatos que complemento a estrutura do caso de uso, já que somente o diagrama é insuficiente para dizer o que cada caso de uso faz.

Caso de Uso Realizar Acesso

Este caso de descreve o processo de acesso de um usuário ao Sistema.

ID do Caso de Uso:

UC 01

Nome do Caso de Uso:

Realizar Acesso

Autor:

 Mauro César Ferreira

Data da Criação:

05/01/2019

Objetivo:

Descrição do processo de identificação de usuário e acesso ao Sistema.

Atores:

Usuário do aplicativo

Prioridade:

Alta

Pré-condições:

Aplicativo foi executado e a tela de acesso é exibida.

Pós-condições

Tela principal vai ser exibida

Frequência de Uso:

Alta

Fluxo Principal:

1

O caso de uso se inicia quando o usuário seleciona o ícone do protótipo no seu dispositivo.

2

O Sistema carrega a tela de acesso;

3

O aplicativo solicita confirmação do usuário para prosseguir.[A1]

4

O sistema permite acesso ao usuário

5

O sistema carrega a tela principal,

6

O Caso de uso se encerra.

Fluxo Alternativo:

A1

Sair do Sistema;

Fluxo de Exceção:

Não se aplica.

Extensões:

Não se aplica.

Requerimentos Especiais:

Não se aplica.

Requerimentos Especiais:

Não se aplica.

Mensagens do Sistema:

M1

Confirma o acesso ?

Protótipo de Tela:            

          

            

     

11.15.4. Caso de Uso Pesquisar

Este caso de uso descreve o processo em que o usuário realiza uma pesquisa por destinos.

ID do Caso de Uso:

UC 02

Nome do Caso de Uso:

Pesquisar

Autor:

 Mauro César Ferreira

Data da Criação:

05/01/2019

Objetivo:

Descrição do processo em que o usuário realiza uma pesquisa por um destino.[M1]

Atores:

Usuário do aplicativo

Prioridade:

Alta

Pré-condições:

O usuário solicitou o acesso e a tela principal foi exibida.

Pós-condições

Pesquisar um destino

Frequência de Uso:

Alta

Fluxo Principal:

1

O caso de uso se inicia quando o usuário solicita o acesso ao aplicativo.

2

O Sistema carrega a tela principal;

3

O usuário escreve o destino desejado;

4

O sistema pesquisar o melhor trajeto e retorna redesenhando o mapa;

5

O usuário selecione uma rota e o meio de transporte.

6

O Caso de uso se encerra.

Mensagens do Sistema:

M1

Informe o seu destino

Protótipo de Tela:           

     

11.15.5. Caso de Uso Selecionar Transporte  

Este caso de uso descreve o processo em que o usuário selecione qual meio de transporte será utilizado.

 

ID do Caso de Uso:

UC 03

Nome do Caso de Uso:

Selecionar Transporte

Autor:

 Mauro César Ferreira

Data da Criação:

05/01/2019

Objetivo:

Descrição do processo em que o usuário escolhe qual o meio de transporte ele deseja utilizar.

Atores:

Usuário do aplicativo

Prioridade:

Média

Pré-condições:

O usuário recebeu o retorno da pesquisa.

Pós-condições

Informar o tempo até o destino.

Frequência de Uso:

Alta

Fluxo Principal:

1

O caso de uso se inicia quando o usuário recebe o retorno da pesquisa.

2

O Sistema exibe as formas de deslocamento;

3

O usuário seleciona uma forma de transporte;

4

O sistema recalcula o trajeto e informa no mapa;

5

O usuário confirma.

6

O Caso de uso se encerra.

Fluxo Alternativo:

Mensagens do Sistema:

M1

Selecione o meio de transporte que mais lhe agrada.

Protótipo de Tela:           

     

11.15.6. Caso de Uso Selecionar Rot          

11.15.7. Este caso de uso descreve o processo em que o usuário selecione qual meio de transporte será utilizado.

 

ID do Caso de Uso:

UC 03

Nome do Caso de Uso:

Selecionar Rota

Autor:

 Mauro César Ferreira

Data da Criação:

05/01/2019

Objetivo:

Descrição do processo em que o usuário escolhe qual a rota que ele deseja utilizar.

Atores:

Usuário do aplicativo

Prioridade:

Média

Pré-condições:

O usuário recebeu o retorno da pesquisa.

Pós-condições

Informar o tempo recalculado e quais meios de transporte poderá fazer uso.

Frequência de Uso:

Alta

Fluxo Principal:

1

O caso de uso se inicia quando o usuário recebe o retorno da pesquisa.

2

O Sistema exibe rotas alternativas além daquela mais curta informada;

3

O usuário seleciona uma das rotas alternativas;

4

O sistema recalcula o trajeto e informa no mapa;

5

O usuário confirma.

6

O Caso de uso se encerra.

Protótipo de Tela:           

     

CONCLUSÃO

A viabilidade do transporte público urbano, em qualquer cidade com um número considerável de habitantes, é sempre um grande desafio. Há tempos que as administrações públicas destas cidades buscam soluções para resolver este problema urbano, algumas com relativo sucesso, outras nem tanto. Com a tendência de crescimento populacional, o cenário pode vir a ser caótico num futuro próximo.

Todo este cenário, não é diferente na capital da República. Apesar da fama de cidade planejada, Brasília, uma cidade relativamente nova, já enfrente problemas quando se trata de locomoção urbana. O cenário é ainda pior se o indivíduo depende de transporte público urbano, reconhecidamente um dos piores do mundo.

Pesquisas realizadas por órgãos oficiais relatam uma crescente populacional e a dificuldade, igualmente crescente, da população que precisa se locomover diariamente. Uma pesquisa realizada para este trabalho tentou aprofundar ainda mais na realidade local. Os indivíduos pesquisados refletem todos bem os usuários de transporte público. O resultado, não foi muito diferente das demais pesquisas. Porém chega-se a conclusão que o brasiliense prefere usar seu veículo particular, seja por uma questão puramente cultural, mas na grande maioria, porque o transporte público se mostra ineficiente.

Aplicativos para celulares são de grande ajuda, não solução, mas um apoio para o enfrentamento deste transtorno. Apesar disto, muitos aplicativos foram projetados para atender a realidade de um determinado centro urbano. Mesmo aqueles construídos para atender a diversas localidades, pecam ao tentar atender o público local e com características bem regionalizadas.

Como proposta, deste trabalho, procurou-se analisar esta temática e chegou-se a conclusão de que um aplicativo voltando para o cenário local seria um diferencial. Haveria uma identificação cultural, e um cuidado com situações atípicas da estrutura urbana de Brasília, que não são encontradas em outras cidades, tornariam mais fácil a aceitação do aplicativo. Desta forma, chegou-se a conclusão que é bastante viável a construção deste aplicativo.

O protótipo construído, mesmo sendo bastante limitado, permitiu analisar o quanto uma solução como esta poderia trazer de benefícios para seus usuários. Os custos para elaboração de um projeto, totalmente funcional, não extrapolam o escopo estudado e, portanto são perfeitamente factíveis.

Assim sendo, conclui-se que os objetivos propostos para este trabalho, foram alcançados ao verificar-se a existência do problema social, aqui descrito, e que a proposta de construção da solução mobile se adequa a esta conclusão.

12. REFERÊNCIAS BIBLIOGRÁFICAS

ALVES, Marcelo. Qual o salário médio dos profissionais de TI no Brasil? 2018. Disponível em: < https://www.profissionaisti.com.br/2011/02/qual-o-salario-medio-dos-profissionais-de-ti-no-brasil/>. Acesso em 28 nov. 2018.

ANDROID PLAYSTORE. 2018. Disponível em: < https://play.google.com/store/apps>. Acesso em: 16 dez. 2018.

ANDROID STUDIO. 2018. Disponível em: < https://developer.android.com/studio/?hl=pt-br >. Acesso em: 22 dez. 2018.

ANDROID. O Sistema Operacional móvel mais conhecido do mundo . 2017. Disponível em: . Acesso em: 18 dez. 2018.

BIANCHI, Camille et al.

O impacto da inovação tecnológica na mobilidade urbana da cidade de São Paulo. 2018 Disponível em . Acesso em 29 dez. 2018.

BRANCO, Robson. Desenvolvimento Android utilizando a IDE Android Studio. jun. 2015. Disponível em: . Acesso em: 28 dez. 2018.

BRASIL. LEI Nº 12.587. 3 de janeiro de 2012. Institui as diretrizes da Política Nacional de Mobilidade Urbana. Disponível em: < http://www.planalto.gov.br/CCIVIL_03/_Ato2011-2014/2012/Lei/L12587.htm>. Acesso em: 01 dez. 2018.

BURSZTYN, M; ARAÚJO, C.H. Da utopia à exclusão: vivendo nas ruas em Brasília. Rio de Janeiro: Garamond; Brasília: Codeplan, 1997

CARVALHO, M. G. Tecnologia, Desenvolvimento Social e Educação Tecnológica. Revista Educação & Tecnologia. Curitiba: Centro Federal de Educação Tecnológica do Paraná, julho de 1997, semestral, p.70-87

CITTAMOBI. Disponível em: . Acesso em: 16 dez. 2018.

CNM - Mobilidade Urbana e os Objetivos de Desenvolvimento Sustentável. 2017. Disponível em: < https://www.cnm.org.br/cms/biblioteca >. Acesso em:

DAVIS, Scott. A rota para um trânsito inteligente. Jun. 2010. Disponível em: . Acesso em: 25 dez. 2018.

Design. Disponível em: . Acesso em: 14 dez. 2018.

DEVELOPER ANDROID. Android Studio. Disponível em:   . Acesso em: 29 dez. 2018.

DEVELOPER ANDROID. Arquitetura da plataforma. Disponível em:  . Acesso em: 29 dez. 2018.

DEVMEDIA. Série: Eu sobrevivo sem UML?. Disponível em:  . Acesso em: 03 jan. 2019.

DEVMEDIA. Traçando rotas no Android com a Google Directions. Disponível em . Acesso em 04 nov. 2018.

EXPERT MARKET. The Best and Worst Cities for Commuting. Disponível em: . Acesso em 30 out. 2018.

FERREIRA, Daniela. No DF, população usa mais carro do que ônibus para ir ao trabalho. set. 2017. Disponível em: . Acesso em: 03 dez. 2018.

FORUM MOBILIDADE. Disponível em . Acesso em 20 dez. 2018

GOOGLE MAPS PLATAFORM. Maps Object. Disponível em: . Acesso em 01 jan. 2019.

HENRIQUE, Matheus. 3 aplicativos que ajudam na mobilidade urbana. jan. 2015. Disponível em: . Acesso em: 01 jan. 2018.

IBGE, Instituto Brasileiro de Geografia e Estatística. Projeção da população do Brasil e das Unidades da Federação. Dados: Distrito Federal. 2015. Disponível em: http://www.ibge.gov.br/apps/populacao/projecao/. Acesso em: 9 nov. 2018.

IDC. Market Analysis.Disponível em: . Acesso em: 30 out. 2018.

JITARU, Cristina. Softpedia. Create Your Own App for Free - Stunning Features &

KUHN , T. A Estrutura das Revoluções Científicas. Rio de Janeiro: Perspectiva, 1987.

MACHADO, Jhonathan. O que é GPS? Disponível em: . Acesso em: 01 jan. 2019.

MARTINS, Rafael. DF - 40% da população utiliza transporte público para ir ao trabalho. Março-2018. Disponível em: . Acesso em 05 dez. 2018.

MEIRELLES, Fernando S. 29ª Pesquisa Anual do Uso de TI, 2018. Disponível em: < https://eaesp.fgv.br/sites/eaesp.fgv.br/files/pesti2018gvciappt.pdf >. Acesso em: 30 out. 2018.

MOBIEBIT. 2014. Disponível em: < http://mobilebit.com.br.rankank.com/ >. Acesso em: 16 dez. 2018.

MOBILIZE. Mobilidade Urbana Sustentável. Sites de Aplicativos de Mobilidade. Disponível em: . Acesso em: 19 dez. 2018.

MOOVIT. App de transporte público. 2018. Disponível em: < https://moovitapp.com/index/pt-br/transporte_p%C3%BAblico-Brasilia-1702 >. Acesso em: 16 nov. 2018.

NETO, Manoel P. de Andrade. Gestão do Novo Sistema de Transporte Público. Sumário Executivo. Disponível em:  < http://www.tc.df.gov.br/segecex/flip/sumarios/semag/gesttransppub/gesttransppub.pdf >. Acesso em 02 dez. 2018.

ONEBUSAWAY. The Open Source platform for Real Time Transit Info. 2017. Disponível em: < https://onebusaway.org/ >. Acesso em: 17 dez. 2018.

ORACLE. Java Platform, Standard Edition. Disponível em: . Acesso em: 29 dez. 2018.

PDAD. Pesquisa Distrital por Amostra de Domicílios. Disponível em: < http://www.codeplan.df.gov.br/pdad/ >. Acesso em: 30 out. 2018.

PDTU/DF. Plano Diretor de Transporte Urbano e Mobilidade do Distrito Federal. 22

PLANMOB. Caderno de referência para elaboração de plano de mobilidade urbana.

RODRIGUES, Gizella. Ordem no caos. Correio Braziliense. Brasília, 15 dez. 2018

SBTRANS. Mobilidade Sampa. 2018. Disponível em: . Acesso em: 17 dez. 2018.

SSP/DF – Secretaria de Segurança pública do Distrito Federal. Balanço da Segurança, ano de 2017. Disponível em: . Acesso em: 16 dez. 2018.

SSP/DF – Secretaria de Segurança pública do Distrito Federal. Balanço da Segurança, ano de 2017. Disponível em: . Acesso em: 16 dez. 2018.

TORRES, Cláudio. A Bíblia do Marketing Digital. São Paulo: Novatec editora Ltda., 2009

YUGE, Claudio. Google Maps ganha mais opções para explorar a cidade, veja como ficou. Jun. 2018. Disponível em: . Acesso em: 01 jan. 2019.

GLOSSÁRIO

Android

Trata-se de um Sistema Operacional, desenvolvido a partir do núcleo do Sistema Operacional Linux e mantido pela empresa Google.

Angular

Angular é um framework baseado na linguagem JavaScript que simplifica não apenas a construção da interface de usuário, mas também o desenvolvimento de toda a aplicação, sejam elas para a Web, mobile ou desktop.

C#

Linguagem de programação muito popular disponibilizada pela Microsoft.

Dispositivo Mobile

é um dispositivo de computação portátil, pequeno, geralmente equipado com um método de entrada e uma tela de exibição (tela sensível ao toque ou um mini teclado).

Entorno

É como são chamados os munícipios que ficam ao redor do Distrito Federal e possuem dependência econômica e social com o DF. A partir de 2018, o  entorno recebeu o status de região metropolitana.

Facebook

Rede social para contatos mais difundida no momento.

Framework

Trata-se de uma arcabouço que realiza uma abstração que une códigos comuns entre vários projetos de software provendo uma funcionalidade genérica.

Front-End

Dentro do contexto, trata-se de toda informação apresentada para o usuário, ou seja, a tela de navegação, a tela da aplicação do celular ou a tela de um determinado programa.

iOS

iOS é um sistema operacional móvel da Apple Inc. desenvolvido originalmente para o iPhone, também é usado em iPod touch e iPad.

JavaScript

O JavaScript é uma linguagem de programação interpretada pelos navegadores Web. Atualmente evolui para outras arquiteturas.

login

Termo, na língua inglesa, que significa ter acesso a uma conta de serviço, aplicativo, dispositivo, relacionado com informática.

Mobilidade urbana

é a condição em que se realizam os deslocamentos de pessoas e cargas no espaço urbano de uma cidade, aglomeração urbana e/ou metrópole

Multiplataforma

Recurso que está disponível em mais de uma “plataforma”, como por exemplo, linguagem de programação que permite gerar aplicativos para iOS e Android.

Sistema Operacional

Software base de qualquer dispositivo, seja computadores, celulares ou outros. Sua função básica é prover acesso a recursos da máquina traduzindo para as demais aplicativos que estiverem rodando.

TypeScrit

Linguagem criada a partir do JavaScript, pela Microsoft e que possui recursos para desenvolvimento orientado a objetos mais complexos que o próprio JavaScript.

Websites

Originado da junção das palavras Web, que significa rede e site, que significa lugar. Trata-se de uma referência a um determinado ponto de acesso na internet, através do protocolo WWW.

APÊNDICE A – FORMULÁRIO DE PESQUISA

APÊNDICE B – TELA LOGIN DO BAU’S

APÊNDICE C – TELA DE PESQUISA DE DESTINO

APÊNDICE E – MENU LATERIAL MÓVEL

APÊNDICE F – SELECIONAR MEIO DE TRANSPORTE

ANEXO A – PESQUISA ORIGEM / DESTINO

 

 

 

ANEXO B – RESULTADO DA PESQUISA ORIGEM / DESTINO

ANEXO C – CRESCENTE DA QUANTIDADE DE VEÍCULOS DE BRASÍLIA

 

Fonte: IBGE

ANEXO D – FLUXO DO NDK

Fonte: SoftPedia - 2017

Fonte: SoftPedia - 2017

ANEXO E – APLICATIVO PRÓXIMO ÔNIBUS –INFORMAÇÕES

ANEXO F – APLICATIVO PRÓXIMO ÔNIBUS –TELA DE CONSULTA

ANEXO G - APLICATIVO PRÓXIMO ÔNIBUS - GRADE DE HORÁRIOS

ANEXO H - APLICATIVO PRÓXIMO ÔNIBUS - DISTRIBUIÇÃO DE PARADAS

ANEXO I - CITTAMOBI – USUÁRIO COLABORA COM O APLICATIVO

ANEXO J – TELA DE MAPA DO APLICATIVO ONEBUSWAY

ANEXO K -  DISTRIBUIÇÃO DA UTILIZAÇÃO DE DISPOSITIVOS

Fonte: FGV 2018

ANEXO L - PESQUISA DISPOSITIVO CONECTADOS A INTERNET

Fonte: FGV

ANEXO M - PESQUISA DISPOSITIVO CONECTADOS A INTERNET

ANEXO N – CLASSIFICA DE BRASÍLIA COMO

Fonte: Expert Market.

ANEXO O - RESULTADO PESQUISA PDAD-DF

Fonte: PDAD

ANEXO P - DISTRIBUIÇÃO DE SATÉLITES PARA GEOPOSICIONAMENTO

https://arquivo.devmedia.com.br/REVISTAS/mobile/imagens/48/4/2.jpg

Fonte: Revista DevMedia


Publicado por: Mauro César Ferreira

  • SIGA O BRASIL ESCOLA
Monografias Brasil Escola