gppp – gerenciamento de presídios p.p. equipe: arthur freitas ramos davi duarte pinheiro david...
TRANSCRIPT
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