GPPP – Gerenciamento de Presídios P.P.

Equipe:Arthur Freitas RamosDavi Duarte PinheiroDavid Barros HulakHugo Neiva de MeloTullio José de Souza Lucena

Tópicos

• Motivação e problema identificado• Escopo• Planejamento• Requisitos• Casos de uso• Arquitetura• Testes• Apresentação do sistema

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.

Escopo

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

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.

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.

Planejamento

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.

Recursos HumanosMembro 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 osistema e auxiliar na coordenação de testes.

Arthur Ramos Desenvolvedor Pleno, Subgerente e Arquiteto de software

Codificar, auxiliarna coordenação da equipe, no controle de riscos e planejar a arquitetura do sistema.

Cronograma

Principais riscos

• Falta de treinamento em JDBC.

• Tempo estimado.

• Mudança de requisitos.

• Recursos computacionais indisponíveis.

• Sobrecarga de integrantes.

Requisitos

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.

Requisitos funcionais

Casos de uso

Diagrama de casos de uso

Casos de uso exemplo: consulta

Diagrama de classe exemplo: consulta

Diagrama de seqüência exemplo: consulta

Casos de uso exemplo: login

Diagrama de classe exemplo: login

Diagrama de seqüência exemplo: login

Diagrama de classes

Diagrama de classes

Arquitetura

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.

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

Diagrama de Pacotes

Distribuição de classes no pacote

Testes

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.

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árioVerificar se as informações dispostas na interface correspondem às funcionalidades e

analisar a disposição de objetos na tela.

• Teste de PerformanceVerificar 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 AcessoVerificar se todos os mecanismos de proteção de acesso estão funcionando

satisfatoriamente.

• Teste de Falha/RecuperaçãoForçar o software a falhar de diversas maneiras para verificar seu comportamento.

• Teste de EstresseVerificar a funcionalidade do sistema em situações limite.

Exemplo de tipo de teste

Exemplo de tipo de teste

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

Exemplo de caso de teste

Exemplo de caso de teste

Apresentação do sistema

Apresentação do sistema