GPPP – Gerenciamento de Presídios P.P.

Apresentação em tema: "GPPP – Gerenciamento de Presídios P.P."— Transcrição da apresentação:

1 GPPP – Gerenciamento de Presídios P.P.
Equipe: Arthur Freitas Ramos Davi Duarte Pinheiro David Barros Hulak Hugo Neiva de Melo Tullio José de Souza Lucena

2 Tópicos Motivação e problema identificado Escopo Planejamento
Requisitos Casos de uso Arquitetura Testes Apresentação do sistema

3 Motivação e problema identificado
Grande informação a ser manipulada pela administração de presídios. Necessidade de um sistema de gerenciamento para melhor organização interna.

4 Escopo

5 Nome do produto e de seus componentes principais
O nome do produto é GPPP: Gerenciamento de Presídios PP Ltda. • Principais componentes: o Gerenciar a entrada e saída de presos. o Gerenciar informações de funcionários e presidiários, bem como suas inter-relações. o Gerenciar a blocos e pavilhões, bem como suas interrelações. o Gerenciar a alocação de celas a prisioneiros. • Relatórios (consultas que podem ser feitas): Presos que estavam na penitenciária em uma determinada data; Listagem dos presos de uma determinada cela; Carcereiros presentes num determinado pavilhão e numa determinada data; Presos que cometeram determinado crime.

6 Missão do produto => Um presídio é geralmente formado por alas como, por exemplo, a médica, a alimentar, a carcerária, a de visitas e a administrativa. => Gerenciar as relações entre essas diversas subdivisões presidiárias seria altamente complexo. => Este projeto dedica-se essencialmente às relações entre a parte administrativa e a carcerária. => As cadeias brasileiras, por exemplo, estão geralmente superlotadas. => Deste modo, é importante manter uma estrutura organizacional para manter controle sobre tempo de sentença cumprido, quais presos estão em que cela de qual bloco especificamente ou quais carcereiros são responsáveis por que pavilhões, por exemplo. => Com a grande quantidade de informações necessárias para a administração de tal estrutura e sem uma organização eficiente de software gerencial, o acesso e a manutenção de dados seriam dificultados.

7 Limites do produto O sistema é o mais geral possível, de modo a contemplar a realidade da maioria dos presídios. Presidiários, celas e pavilhões são gerenciados. Podem-se fazer atualizações, remoções e inserções. Gerações de relatórios.

8 Planejamento

9 Recursos utilizados Java, através da IDE eclipse e da IDE Netbeans.
JUDE, para modelagem em UML. brModelo para modelagem E-R em ferramenta CASE. Windows Vista, 7 e XP como sistemas operacionais. Microsoft Office Word para geração de artefatos. Microsoft Paint para edição de imagens.

10 Recursos Humanos Membro Cargo Funções Hugo Melo
Gerente de projetos e desenvolvedor pleno. Coordenar a equipe e a estrutura organizacional, controlar riscos e codificar. Davi Pinheiro Gerente de Testes e desenvolvedor sênior. Elaborar o plano de testes, garantir sua execução, codificar e auxiliar na coordenação do desenvolvimento. Tullio Lucena Desenvolvedor pleno, analista de sistemas e designer de interface. Definir a arquitetura, projetar a análise do sistema, codificar e planejar uma interface simples e intuitiva. David Hulak Desenvolvedor Pleno, gerente para elaboração de artefatos e engenheiro de testes Codificar, garantir clareza e consistência nos documentos realizados, testar o sistema e auxiliar na coordenação de testes. Arthur Ramos Desenvolvedor Pleno, Subgerente e Arquiteto de software Codificar, auxiliar na coordenação da equipe, no controle de riscos e planejar a arquitetura do sistema.

11 Cronograma

12 Principais riscos Falta de treinamento em JDBC. Tempo estimado.
Mudança de requisitos. Recursos computacionais indisponíveis. Sobrecarga de integrantes.

13 Requisitos

14 Requisitos não-funcionais
Requisitos de produto - Segurança: [RNF 01] Restrição de acesso: o administrador pode cadastrar/remover/modificar/visualizar dados e gerar relatórios, enquanto demais funcionários só podem visualizar. - Manutenibilidade: [RNF 02] O sistema deverá ser implementado com uma arquitetura modular, com fraco acoplamento e forte coesão, a fim de facilitar futuras manutenções e adequar-se a possíveis novos requisitos. - Usabilidade: [RNF 07] A interface deverá ser o mais autoexplicativa e intuitiva possível, para facilitar a utilização do sistema. - Confiabilidade: [RNF 08] As informações contidas na base de dados deverão ser consistentes, i.e., atualizações de dados devem surtir efeito em todos os cenários aplicáveis. Requisitos de Processo [RNF 03] A linguagem de programação a ser utilizada deverá ser Java, devido a seu eficiente suporte à orientação a objetos. [RNF 06] O sistema deverá funcionar no SO Windows. Documentação [RNF 04] Deverá ser gerada uma documentação bem estruturada em linguagem de sistema. [RNF 05] Deverá ser gerada uma documentação bem estruturada em linguagem de usuário.

15 Requisitos funcionais

16 Casos de uso

17 Diagrama de casos de uso

18 Casos de uso exemplo: consulta

19 Diagrama de classe exemplo: consulta

20 Diagrama de seqüência exemplo: consulta

21 Casos de uso exemplo: login

22 Diagrama de classe exemplo: login

23 Diagrama de seqüência exemplo: login

24 Diagrama de classes

25 Diagrama de classes

26 Arquitetura

27 Arquitetura Elaboração das classes e dos pacotes do sistema.
Modelo em camadas. 3-tier: Divisão em três camadas, interface gráfica, camada de negócio e repositório de dados.

28 Arquitetura: camadas GUI: - Interação com o usuário. Negócios:
- Funcionalidades e restrições. - Comunicação da GUI com essa camada é feita através de uma fachada. Repositório de dados - Gerenciamento de entidades consistentes. Armazenamento, modificação e consulta de dados. Protegido a acesso direto: modificações controladas pela camada de negócio

29 Diagrama de Pacotes

30 Distribuição de classes no pacote

31 Testes

32 Testes • Enumerar as funcionalidades a serem testadas. • Planejar sistematicamente os testes. • Definir vários tipos de teste em relação aos diversos tipos de requisitos.

33 Tipos de teste Teste de Função
Verificar se todas as funcionalidades estão corretas, considerando-se condições válidas e inválidas. Teste da Interface do Usuário Verificar se as informações dispostas na interface correspondem às funcionalidades e analisar a disposição de objetos na tela. Teste de Performance Verificar o tempo de resposta e processamento para diferentes configurações, número de usuários e quantidade de informações armazenadas Teste de Segurança e Controle de Acesso Verificar se todos os mecanismos de proteção de acesso estão funcionando satisfatoriamente. Teste de Falha/Recuperação Forçar o software a falhar de diversas maneiras para verificar seu comportamento. Teste de Estresse Verificar a funcionalidade do sistema em situações limite.

34 Exemplo de tipo de teste

35 Exemplo de tipo de teste

36 Casos de teste A análise dos casos de teste é baseada em:
Requisitos funcionais; Casos de uso; Parâmetros de entrada e suas descrições; Pré-condições para o teste ser realizado; Resultados esperados (pós-condições e saídas).

37 Exemplo de caso de teste

38 Exemplo de caso de teste

39 Apresentação do sistema

40 Apresentação do sistema