Estudo de Viabilidade

Universidade Federal do Ceará Bacharelado em Computação cadeira de Engenharia de Software

Estudo de Viabilidade

1. Título da Aplicação: "Foi Aqui" O nome foi escolhido visando ser fácil de lembrar pelo público alvo e  que encapsule o conceito principal da aplicação, que é a localização geográfica. O  nome Foi Aqui é curto, é em português, não possui caracteres especiais como  acentos ou cedilhas, o choque entre as palavras é entre duas vogais e não provoca  ambigüidades. Por se tratar de uma aplicação WEB alguns domínios estão cotados  para registro: www.foiaqui.com.br www.foiaqui.net www.foiaqui.org www.foiaqui.com É possível que com o registro do domínio o nome da aplicação  encorpore a sufixo do domínio, por exemplo, o nome da aplicação poderá passar a  “www.foiaqui.com.br”.

1.1. Logotipo O logotipo foi escolhido visando combinar com o título da aplicação  mas que também fosse fácil de ser identificado e que fosse flexível o suficiente  para ser impresso em qualquer paleta de cores. A seta foi escolhida por ser semelhante ao cursor do mouse. No fim  da seta fica um alvo que reforça a idéia de localização.

2.   Descrição da aplicação O Foi Aqui é uma aplicação onde uma pessoa vítima de assalto em  Fortaleza poderá localizar e gravar num mapa o local onde o crime ocorreu. Ela  poderá também compartilhar informações sobre esse evento, com uma descrição  mais detalhada do ocorrido. Essas operações poderão ser feitas sem a necessidade de cadastro. Um usuário poderá também visualizar os pontos onde já houve  assaltos na cidade.

3. Objetivo A aplicação gerará a partir das entradas do usuário um mapeamento  dos crimes na cidade. Esse mapeamento servirá para as pessoas comuns terem uma  visualização das regiões mais perigosas da cidade. É esperável que esse mapa também auxilie as autoridades  competentes de segurança a cumprirem seu trabalho.

4.   Justificativa Na atual forma de se realizar um boletim de ocorrência, o usuário não  tem um mapa detalhado e interativo para consulta e essa informação não fica  registrada com precisão. Essa informação é perdida. Mesmo depois que a polícia já tem um grande número de  informações, ela não tem como gerar rapidamente uma visualização desses dados  sob um mapa ou disponibilizar rapidamente essas informações para a população.

5. Solução proposta A parte mais importante do nosso sistema é a interface de mapa. Nós  iremos utilizar o Google Maps, que é uma API de mapas gratuita.  O restante do sistema seguirá o paradigma cliente/servidor. A base de  dados e o sistema em si ficará em nossos servidores e os clientes poderão o  acessar através de seu navegador.

6. Delimitação do Escopo O Foi Aqui será capaz de guardar e oferecer informações geográficas  acerca de assaltos na região de Fortaleza. Somente a cidade de Fortaleza estará  coberta na aplicação. Essas informações ficarão num detalhamento de alto­nível, não se  preocupando em guardar informações que possam levar a identificação da vítima,  ou seja, não haverá cadastro de usuários. A aplicação está focada nos crimes contra a pessoa que são  localizáveis, que podem ser apontados em um mapa, especialmente assaltos. A aplicação se sustenta fortemente no conceito de colaboração, onde  cada usuário poderá contribuir com um pouco de informação para construir um  todo mais detalhado e confiável. Não é nossa preocupação maior assegurar a veracidade dessas  informações pois acreditamos que uma informações falsas serão diluídas meio as  informações verdadeiras. Nos não iremos oferecer um mapeamento da violência  completo ou completamente confiável, mas vamos oferecer um mapeamento  razoavelmente confiável. Como trabalho futuro poderemos oferecer uma interface para o  boletim de ocorrência online da polícia civil e visualização dentro do nosso  sistema dos dados que a polícia já dispõe. Futuramente também pretendemos  oferecer uma maior confiabilidade através de um sistema de credibilidade  colaborativo e oferecer um sistema avançado de estatísticas.

8. Produtos Produtos Intermediários Entrega do planejamento do projeto ­ Documento com o cronograma do  projeto e distribuição das atividades. Entrega do estudo de viabilidade ­ Verificação se é possível implementar a  solução proposta no tempo, com escopo da aplicação e recursos  disponíveis. Entrega da especificação dos requisitos ­ Documento com todos requisitos  (funcionais, não­funcionais,  de usuário, de sistema e de domínio)  analisados e especificados . Entrega do projeto da aplicação com todos os seus diagramas ­ Documento  com os diagramas de classe, seqüência e estado gerados para a aplicação. Produto Final Entrega do código fonte ­ Códigos gerados em PHP e JAVASCRIPT,  devidamente comentado e documentado. Entrega do Executável ­ Aplicação final devidamente testada executando na  Web.

9. Público Alvo A aplicação tem como principal público alvo as vitimas de assaltos  em Fortaleza.  Também temos como público os cidadãos interessados em saber o  que está acontecendo na cidade e que lugares são violentos. Por exemplo alguém  que vai a um lugar pela primeira vez e quer saber se lá ocorrem muitos assaltos. Outro público alvo são turistas estrangeiros, já que a cidade possui e  explora sua potencialidade turística e portanto estes também estão sujeitos a  assaltos. Para alcançar esse público pretendemos disponibilizar versões do site em  outras línguas que não o português.

10. Restrições A aplicação poderá rodar em qualquer computador que disponha de  um navegador razoavelmente atualizado e uma conexão com a internet. Isso é  possível graças as escolhas de tecnologia que seguem os padrões definidos para  cada fim. A aplicação ficará inicialmente focada na cidade de Fortaleza,  portanto a maioria dos usuários deverão ser da própria cidade, ou turistas. A aplicação se sustenta na colaboração dos usuários para alimentar o  sistema com os dados para então gerarmos uma visualização. Sem essa  colaboração o sistema se torna ineficiente. É necessário a aquisição de um servidor web que ofereça suporte às  tecnologias utilizadas no lado servidor. Esse servidor pode ser comprado ou  alugado. Uma restrição importante é quanto a API de mapas utilizada. Nos  sempre ficaremos restritos as funcionalidades impostas pela API utilizada, no  caso, o Google Maps.

11. Alternativas Caso a API de mapas se torne indisponível ou não supra todas as  necessidades da aplicação será necessário encontrar uma outra API de mapas. Caso a linguagem PHP apresente alguma dificuldade mais séria ou  algum problema que não consigamos sanar poderemos utilizar a linguagem  Python. Caso a banco de dados MySQL não suporte a carga da aplicação  poderemos utilizar o PostegreSQL como alternativa.

12. Recursos Requeridos Será necessário ter na equipe do projeto pessoas capazes de aprender  e utilizar as linguagens e software citados abaixo. Linguagens: PHP será usada para a implementação da lógica da aplicação no lado do  servidor. PHP foi escolhida por ser uma linguagem amplamente utilizada  contanto com vasta documentação disponível. Outro ponto forte é sua  compatibilidade com a maioria dos servidores do mercado. JavaScript será usada para a implementação da lógica da aplicação no lado  do cliente. JavaScript é uma linguagem suportada por praticamente todos os  navegadores e se tornou um padrão de fato para este fim. Também é a  linguagem usada pela API do Google Maps. SQL será usada para a comunicação com o banco de dados. SQL é a  linguagem padrão para este fim. HTML/CSS será usada para construção da interface com o usuário. A dupla  de HTML e folha de estilo é o padrão para interfaces web. Servidor: Apache será usado para servir as páginas web. O Apache é um servidor  robusto, confiável e livre. É suportado por praticamente todas as empresas  de hospedagem e suporta bibliotecas de linguagens que iremos usar, como  PHP. MySQL será o software para banco de dados. O MySQL tem eficiência  suficiente para nossa aplicação e é fácil de manter e instalar, e está  disponível na maioria das empresas de hospedagem. Será contratada uma empresa que preste os serviços de hospedagem e  domínio de nome e que suporte as tecnologias citadas acima. Dessa maneira não iremos nos preocupar com os detalhes técnicos de  instalação e manutenção dessas ferramentas e poderemos nos focar no projeto em  si.

13 . Riscos

Definição Tipo Prob. Efeitos Estrátegias 

Preventiva Estrátegias Corretiva Problemas de 

pessoal  (Abandono da  disciplina,  doença)

Pessoal Baixa Tolerável Estudos  polivalentes.  Terminar tarefas  antes dos prazos Sobrecarregar  membros Servidor são  suportar carga  de acessos

Tecnológico Baixa Tolerável Contratar  hospedagem de  baixa letência e  alta banda

Mudar de servidor

Não se tornar 

popular Estimativa Moderado Médio Publicidade da aplicação Mais publicidade Inaptidão 

tecnológica Pessoal Moderada Sério Estudo e treinamento Estudo e treinamento Alteração de 

requisitos  causando  retrabalho

Planejamento Alta Sério Esforços numa  definição bem  feita de  requisitos Cuidados para que  o mesmo erro não  se repita (lições  aprendidas) Redução  drástica na  criminalidade

Estimativa Baixa Catastrófico ­ ­

Baixo uptime 

do servidor Tecnológico Baixa Sério Contratar um serviço de  hospedagem de  confiança Mudar de servidor Indisponíblida de da API de  mapas

Externo Baixa Fatal Pesquisar  soluções  alternativas

14. Modelo de Processo: Um modelo híbrido será utilizado. A princípio o modelo em cascata foi escolhido pois atende bem as  cobranças de datas que nos temos que cumprir. Porém dado a complexidade da aplicação é salutar que estejamos  sempre desenvolvendo protótipos da aplicação para amortizar o trabalho dedicado  no processo de implementação e testes. Nós usaremos um modelo misto entre cascata e evolucionário, onde  em cada etapa da cascata usaremos o modelo evolucionário.