Download
1 / 40
430 likes | 565 Views
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. Tópicos. Motivação e problema identificado Escopo Planejamento Requisitos Casos de uso Arquitetura Testes
E N D
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
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.
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.
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.
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.
Principais riscos • Falta de treinamento em JDBC. • Tempo estimado. • Mudança de requisitos. • Recursos computacionais indisponíveis. • Sobrecarga de integrantes.
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.
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
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á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.
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).
