Apresentação do Termo de Abertura de Projeto Projeto Supervisionado de Análise e Engenharia de Software Apresentação do Termo de Abertura de Projeto Sistema de Rastreamento Veicular para Auxilio no Atendimento de Ocorrências Policiais http://groups.google.com.br/group/sislodim 05 de março de 2009

Sumário Apresentação Institucional Apresentação da Disciplina Visão geral do Projeto Produto do Projeto Escopo do Projeto Escopo do Produto

Sumário Equipe do Projeto Premissas Restrições Riscos Plano de Teste de Aceitação

Sumário Apresentação Institucional Apresentação da Disciplina Visão geral do Projeto Produto do Projeto Escopo do Projeto Escopo do Produto

Por que Idez? I – representa a informação remetendo também aos conceitos de inovação, iniciativa entre outros. DEZ – traduz o maior resultado acadêmico possível, aludindo ao padrão de excelencia na qualidade de ensino que a faculdade pretende atingir.

Sua História Anteriormente Faculdade IBRATEC, a iDEZ surgiu a partir de um grupo de Professores da Paraíba, aliado a um grupo Educacional sólido e amplamente reconhecido na Região Norte: o grupo SEAMA de educação. A Faculdade iDEZ oferece cursos de pós-graduação, graduação, técnicos e de extensão.

Proposta da Faculdade IDEZ A Faculdade IDEZ , tem como proposta contribuir com o progresso regional e nacional, através da Educação, nasce da vontade e empreendedorismo de um grupo de professores, aliado a um grupo educacional sólido e amplamente reconhecido na região norte: Grupo Seama de Educação.

Principal objetivo da IDEZ Criar um veículo que cumprisse com a missão de se tornar um canal de aproximação e integração de toda a comunidade acadêmica e sociedade em geral.

Principal objetivo da IDEZ Além disso, esse canal de informação foi construído, com uma tecnologia atual e dinâmica, pensado para ser mais um instrumental de comunicação institucional e com o mercado de trabalho.

Sumário Apresentação Institucional Apresentação da Disciplina Visão geral do Projeto Produto do Projeto Escopo do Projeto Escopo do Produto

Objetivo da Disciplina Inserir o aluno no dia a dia de trabalho de um gerente de projetos, trazendo para sala de aula o ambiente de processos, ferramentas e técnicas consagradas pelo mercado.

Objetivo da Disciplina O aluno irá desenvolver práticas associadas as fases de Iniciação, Planejamento, Execução, Monitoramento e Encerramento de um projeto, aumentando assim significativamente suas habilidades gerais de gerenciamento.

Competência C1 Saber desenvolver um Termo de Abertura de Projeto baseando-se no PMBoK.

Competências C2 Saber selecionar e aplicar processos de gerencia de projetos e engenharia de software em um projeto de desenvolvi-mento de software.

Competências C3 Saber atuar como gerente de projetos em um projeto de desenvolvimento de software.

Sumário Apresentação Institucional Apresentação da Disciplina Visão geral do Projeto Produto do Projeto Escopo do Projeto Escopo do Produto

Objetivo Superior Permitir o rastreamento de viaturas através de um dispositivo GPS para agilizar o atendimento aos chamados de ocorrências policiais. Localizar as viaturas policiais mais próximas a área onde houve a ocorrência.

Justificativa Conhecer a localização das viaturas mais próximas a uma determinada ocorrência para que a solicitação possa ser atendida mais rapidamente.

Justificativa Apresentação da rota mais rápida entre a localização atual da viatura até o local da ocorrência.

Justificativa A consulta será realizada unicamente pelos integrantes do CIOP (Centro integrado de operações policiais) acessando o modulo web do produto. Neste módulo, o atendente definirá o quadrante da região onde houve a ocorrência.

Interessados Centro integrado de operações policiais – CIOP. João Pessoa

Sumário Apresentação Institucional Apresentação da Disciplina Visão geral do Projeto Produtos do Projeto Escopo do Projeto Escopo do Produto

Módulo Web Permitirá cadastrar solicitantes; Cadastro de viaturas que serão rastreadas; Localização em tempo real das viaturas;

Módulo Web Localização por quadrante das viaturas utilizando mapas online (com opção de imagens via satélite); Gerenciar usuários para acesso ao sistema;

Módulo Móvel Responsável por enviar a localização em tempo real de uma viatura.

Sumário Apresentação Institucional Apresentação da Disciplina Visão geral do Projeto Produto do Projeto Escopo do Projeto Escopo do Produto

Escopo do projeto O escopo do projeto descreve o conjunto de ferramentas e linguagens que serão utilizadas durante o desenvolvimento do produto

Escopo do projeto Esse documento serve como guia para os membros da equipe e formaliza a escolha de ferramentas para o projeto.

Requisitos do projeto RP01 - Google Code Todo o código deve estar disponível no Google Code para fácil acesso de todos os integrantes do projeto.

Requisitos do projeto RP02 – Persistencia de dados Para armazenamento de dados será utilizado no projeto o MySQL juntamente com as tecnologias JPA e TopLink.

Requisitos do projeto RP03 - Servidor web O projeto necessita de servidores web estes obrigatoriamente tem que dar suporte ao JBOSS.

Requisitos do projeto RP04 - Aplicar Padrões de Projeto Com objetivo de termos um projeto extensível , portável e de fácil manutenção. Será aplicado o padrão de projeto MVC.

Requisitos do projeto RP05 - Criação de Layout Definir a camada de apresentação web com a exportação para formato XHTML e CSS.

Sumário Apresentação Institucional Apresentação da Disciplina Visão geral do Projeto Produto do Projeto Escopo do Projeto Escopo do Produto

Escopo do produto Definição: Refere-se às características do produto ou serviço que se quer como resultado do projeto. Ele é explicitado por meio das especificações.

Escopo do produto Administrar usuários Administrar viaturas Gerar relatório de rotas percorridas por veículo Visualizar localização da viatura em tempo real utilizando mapas Visualizar a rota da viatura a partir da área de saída da área de atuação

Requisitos do Produto Enviar informações sobre localização atual através de um dispositivo GPS Administrar setores Autenticação de usuários Definir a viatura mais próxima da ocorrência

Sumário Cronograma Equipe do Projeto Premissas Restrições Riscos Plano de Teste de Aceitação

Cronograma O cronograma é um documento com as tarefas, os tempos previstos para sua realização e a data de início. Com ele, é possível visualizar e definir as principais tarefas que serão realizadas para a entrega de uma release, além de permitir estimar um prazo para sua conclusão.

Sumário Cronograma Equipe do Projeto Premissas Restrições Riscos Plano de Teste de Aceitação

Desenvolvedor WEB Analisar arquitetura e tecnologias que serão usadas no desenvolvimento web Responsáveis: Theoziran Lima Samuel Aguiar

Gerente de Testes Gerenciar equipe e aborda as principais metodologias de testes que serão efetuados no projeto e também será responsável por definir os casos de testes junto com sua equipe Responsável: Edmilson Ferreira

Testador Definir junto com o gerente os casos de testes que serão utilizados no sistema. Responsáveis: Josafá Filho Pablo Trajano

Engenheiro de Software Gerenciar de requisitos e criação dos diagramas Responsáveis: Glauco Soares Leonardo Dornelas

Gerente de Projeto Gerenciar a equipe, escopo e prazos. Responsável: Emmanuel Alves

Desenvolvimento para Dispositivos Móveis Desenvolver MIDLets para dispositivos móveis usando Java (JME) e desenvolver estudos sobre Java API Location. Responsáveis: Fábio Moura Ricardo Silvestre

Gerenciamento de Configuração Gerenciar a documentação do sistema. Responsáveis: Kerlen Panhoce Juliana Passamani

Administrador de Dados Analisar arquitetura dos dados, modelar e codificar o banco de dados . Responsáveis: Paulo Medeiros Mário Dias

Sumário Cronograma Equipe do Projeto Premissas Restrições Riscos Plano de Teste de Aceitação

Premissas Premissas Define-se premissa como uma idéia ou argumento hipotético considerado verdadeiro. Dicionário Houais: “ponto ou idéia de que se parte para armar um raciocínio.”

Premissas do projeto Utilizar a linguagem JAVA. Utilização dos recursos técnicos da faculdade. Desenvolver o projeto fora das dependências da faculdade. Utilização do Google Code como repositório.

Premissas do projeto O software não será comercializado até a conclusão da disciplina. Uso de HTTPS no projeto. Integração com o Google Maps. Utilização de GPS. Indepêndencia de plataforma.

Sumário Cronograma Equipe do Projeto Premissas Restrições Riscos Plano de Teste de Aceitação

O que são restrições São condições ou situações que limitam planejamento e desenvolvimento, não podendo ser alterada ou eliminadas no decorrer do projeto.

Restrições Possuir um celular com GPS para permitir os testes e implementação correta do sistema.

Restrições O uso dos equipamentos da faculdade IDEZ, LAB A7, para configurar o ambiente de desenvolvimento.  

Sumário Cronograma Equipe do Projeto Premissas Restrições Riscos Plano de Teste de Aceitação

O que são riscos? São eventos ou condições incertas que, se ocorrerem, terão um efeito positivo ou negativo sobre pelo menos um objetivo do projeto.

Por que identificá-los? Para maximizar os resultados de eventos positivos e minimizar as conseqüências de eventos negativos.

Análise qualitativa dos riscos R1: Dificuldade com os testes Criticidade: Alta Plano de Resposta Preliminar: Busca de conhecimento junto aos especialistas em testes de software.

Análise qualitativa dos riscos R2: Falta de motivação da equipe Criticidade: Média Plano de Resposta Preliminar: Rodízio de atividades

Análise qualitativa dos riscos R3: Falta de conhecimento em Java API Location. R4: Falta de conhecimento em JPA. R5: Falta de conhecimento na API do Google Maps. R6: Falta de conhecimento em JME R7: Falta de conhecimento em JSF

Análise qualitativa dos riscos Criticidade: Média Plano de Resposta Preliminar: Buscar conhecimento específico junto aos especialistas da área e em materiais de estudo (livros, apostilas). Pesquisar na internet.

Análise qualitativa dos riscos R8: Releases não serem entregues no prazo estabelecido Criticidade: Média Plano de Resposta Preliminar: Monitorar as atividades e fazer ajustes nas equipes se preciso. Entregar as tarefas inacabadas e incluir no escopo da próxima release.

Análise qualitativa dos riscos R9: Problemas com o rodízio de funções Criticidade: Média Plano de Resposta Preliminar: Manter um dos membros antigos da equipe para reter o conhecimento e ajudar na transição dos novos membros.

Análise qualitativa dos riscos R10: Indisponibilidade de um celular com Java Api Location Criticidade: Baixa Plano de Resposta Preliminar: Utilizar o emulador do WTK (wireless toolkit)

Análise qualitativa dos riscos R11: Não aquisição de um celular com GPS embarcado. Criticidade: Alta Plano de Resposta Preliminar: Usar um emulador de GPS.

Análise qualitativa dos riscos R12: Indisponibilidade do serviço de internet R13: Falha na infra-estrutura nos laboratórios da faculdade R14: Indisponibilidade do protocolo HTTPS Criticidade: Alta

Análise qualitativa dos riscos Plano de Resposta Preliminar: Levar esse problema ao suporte da faculdade. Utilização dos notebooks na praça de alimentação com o serviço de Wi-Fi, ou na própria faculdade com o serviço de internet 3G.

Análise qualitativa dos riscos R15: Falta de conhecimento no uso do SVN Criticidade: Alta Plano de Resposta Preliminar: Disponibilização de tutorias por parte de alguns membros da equipe.

Análise qualitativa dos riscos R16: Despadronização de ferramentas Criticidade: Alta Plano de Resposta Preliminar: Chegar a um consenso entre os membros do projeto para definir quais as ferramentas(IDE) serão utilizadas pela equipe.

Sumário Cronograma Equipe do Projeto Premissas Restrições Riscos Plano de Teste de Aceitação

Plano de Teste de Aceitação O que é? Descrevem cenários que devem ser suportados pelo sistema. Para que serve? Para garantir que o produto esteja de acordo com a necessidade do cliente.

Plano de Teste de Aceitação RF01 – Administrar Usuários TA1.1 – Criar Usuário TA1.1.1 – Cadastrar um usuário com todos os seus dados corretos (Cadastro Efetuado com Sucesso)‏ TA1.1.2 - Cadastrar um usuário sem informar todos os campos obrigatórios (Cadastro não deve ser efetuado)‏

Plano de Teste de Aceitação TA1.2 – Editar Usuário TA1.2.1 – Editar um usuário com todos os seus dados corretos (Edição Efetuada com Sucesso)‏ TA1.2.2 - Editar um usuário sem informar todos os campos obrigatórios (Edição não deve ser efetuada)‏

Plano de Teste de Aceitação TA1.3 – Consultar Usuário TA1.3.1 – Consulta a partir de um usuário existente (Consulta Efetuada com Sucesso)‏ TA1.3.2 – Consulta a partir de um usuário inexistente (Retornar mensagem de erro)‏

Plano de Teste de Aceitação TA1.4 – Excluir Usuário TA1.4.1 – Remover todos os dados do usuário com sucesso Estimativa inicial: 2horas  

Plano de Teste de Aceitação RF02 – Administrar de Viaturas TA2.1 – Criar Viatura TA2.1.1 – Cadastrar uma viatura com todos os seus dados corretos (Cadastro Efetuado com Sucesso)‏ TA2.1.2 - Cadastrar uma viatura sem informar todos os campos obrigatórios (Cadastro não deve ser efetuado)‏  

Plano de Teste de Aceitação TA2.2 – Editar Viatura TA2.2.1 – Editar uma viatura com todos os seus dados corretos (Edição Efetuada com Sucesso)‏ TA2.2.2 - Editar uma viatura sem informar todos os campos obrigatórios (Edição não deve ser efetuada)‏

Plano de Teste de Aceitação TA2.2 – Editar Viatura TA2.2.1 – Editar uma viatura com todos os seus dados corretos (Edição Efetuada com Sucesso)‏ TA2.2.2 - Editar uma viatura sem informar todos os campos obrigatórios (Edição não deve ser efetuada)‏

Plano de Teste de Aceitação TA2.4 – Excluir Viatura TA2.4.1 – Remover todos os dados da viatura com sucesso Estimativa inicial: 2horas

Plano de Teste de Aceitação RF03 – Gerar relatório de rotas percorridas pelo veículo por período TA3.1 – Exibir lista de rotas percorridas pelo veículo dentro do período especificado Estimativa inicial: 1hora

Plano de Teste de Aceitação RF04 - Visualizar localização da viatura em tempo real utilizando mapas TA 4.1 - Exibir localização correta da viatura desejada Estimativa inicial: 1 hora

Plano de Teste de Aceitação RF05 - Visualizar a rota da viatura a partir da saída da área de atuação TA 5.1 - Imprimir relatório com as coordenadas, o horário e os logradouros percorridos por uma viatura que saiu da sua área de cobertura Estimativa inicial: 2 horas

Plano de Teste de Aceitação RF06 - Enviar informações sobre localização atual através de um dispositivo GPS TA 6.1 - Servidor receber corretamente as informações sobre a localização da viatura onde o dispositivo está instalado Estimativa inicial: 2 horas

Plano de Teste de Aceitação RF07 – Administrar setores TA7.1 – Criar setor TA7.1.1 – Cadastrar um setor com todos os seus dados corretos (Cadastro Efetuado com Sucesso)‏ TA7.1.2 – Cadastrar um setor sem informar todos os campos obrigatórios (Cadastro não deve ser efetuado)‏

Plano de Teste de Aceitação TA7.2 – Editar setor TA7.2.1 – Editar um setor com todos os seus dados corretos (Edição Efetuada com Sucesso)‏ TA7.2.2 – Editar um setor sem informar todos os campos obrigatórios (Edição não deve ser efetuada)‏

Plano de Teste de Aceitação TA7.3 – Consultar setor TA7.3.1 – Consulta a partir de um setor existente (Consulta Efetuada com Sucesso)‏ TA7.3.2 – Consulta a partir de um setor inexistente (Retornar mensagem de erro)‏

Plano de Teste de Aceitação TA7.4 – Excluir setor TA7.4.1 – Remover todos os dados do setor com sucesso Estimativa inicial: 2horas

Plano de Teste de Aceitação RF08 – Autenticação de usuários TA8.1 – Autenticação a partir de login e senha válido(Autenticação Efetuada com Sucesso)‏ TA8.2 – Autenticação a partir de login e/ou senha inválido(Retornar mensagem de erro)‏ Estimativa inicial: 1hora

Plano de Teste de Aceitação RF09 – Definir a viatura mais próxima da ocorrência TA9.1 – Mostrar a viatura mais próxima da ocorrência Estimativa inicial: 1hora

Referências Termo de Abertura do Projeto; 2009 YP - easYProcess http://www.dsc.ufcg.edu.br/~yp/DocResumo/03_0 2_UserStoriesETestesDeAceitacao.html