Estudo de Viabilidade

Transcrição

1 Universidade Federal do Ceará Bacharelado em Computação cadeira de Engenharia de Software Estudo de Viabilidade Equipe: Carlos H. Sindeaux Edilson Júnior Emanuelle Vieira Franklin Chaves José M. Silveira Neto

2 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: É 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

3 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.

4 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.

5 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.

6 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.

7 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.

8 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.

9 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.

10 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.

11 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.

12 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.

13 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.

14 13. Riscos Definição Tipo Prob. Efeitos Estrátegias Preventiva Problemas de pessoal (Abandono da disciplina, doença) Servidor são suportar carga de acessos Não se tornar popular Inaptidão tecnológica Alteração de requisitos causando retrabalho Redução drástica na criminalidade Baixo uptime do servidor Indisponíblida de da API de mapas Pessoal Baixa Tolerável Estudos polivalentes. Terminar tarefas antes dos prazos Tecnológico Baixa Tolerável Contratar hospedagem de baixa letência e alta banda Estimativa Moderado Médio Publicidade da aplicação Pessoal Moderada Sério Estudo e treinamento Planejamento Alta Sério Esforços numa definição bem feita de requisitos Estrátegias Corretiva Sobrecarregar membros Mudar de servidor Mais publicidade Estudo e treinamento Cuidados para que o mesmo erro não se repita (lições aprendidas) Estimativa Baixa Catastrófico Tecnológico Baixa Sério Contratar um serviço de hospedagem de confiança Externo Baixa Fatal Pesquisar soluções alternativas Mudar de servidor Mudar de API

15 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.