Natanael (njsj) Thiago (tan2) Rodrigo (rml2) Projeto Sonata Natanael (njsj) Thiago (tan2) Rodrigo (rml2)

Introdução: O Projeto Sonata tem o objetivo de desenvolver um software de gerenciamento de controle educacional, para auxiliar na gestão financeira e pedagógica da escola de música Sonata.

Sistema antigo x Sistema Informatizado Gastos com papel Espaço físico para arquivo Manutenção de arquivo a longo prazo Organização Diminui o trabalho de vários professores Maior agilidade no atendimento ao cliente

Cronograma

Cronograma 1ª Fase: Concepção Período: 31/05/2007 à 14/06/2007 Marco Principal: 14/06/2007 – Entrega do documento final de requisitos. Milestones: 09/06/2007 – Reunião para elaborar a primeira parte dos requisitos; 12/06/2007 – Reunião para validar os requisitos. (Adaptações, MSN) 2ª Fase: Elaboração Período: 10/06/2007 à 03/07/2007 Marco Principal: 03/07/2007 – Entrega do documento de análise. (dificuldades em prever estrutura do acesso ao banco) Milestones: 11/06/2007 – Início da elaboração da arquitetura; 14/06/2007 – Atualização da arquitetura; 19/06/2007 – Finalização da arquitetura; 02/07/2007 – Finalização do modelo de análise e de projeto 3ª Fase: Construção ( hibernate e mudanças de IDE ) Período: 20/06/2007 à 07/08/2007 Marco Principal: 07/08/2007 – Apresentação do projeto. Milestones: 20/06/2007 – Início da implementação; 10/07/2007 – Início da integração das implementações; 15/07/2007 – Início da fase de testes; 19/07/2007 – Entrega do documento de testes; 30/07/2007 – Finalização da implementação e integração; 01/08/2007 – Criação dos slides da apresentação; 06/08/2007 – Finalização da fase de testes. 4ª Fase: Transição ( Implantação programada com folga ) Período: 09/08/2007 à 10/08/2007 Marco Principal: 10/08/2007 – Teste do software final pelo usuário.

Riscos mais decisivos no processo Pessoal reduzido. Pouca experiência na tecnologia de acesso ao banco de dados ( Hibernate ) e na programação de GUI(Swing). Rápido entendimento dos requisitos. Cliente sempre a disposição para tirar dúvidas.

Escopo Controle de Alunos - dados pessoais, e relatórios de aulas e exercícios de casa. Cadastro de professores – dados individuais, de alunos e financeiros. Controle de usuários do sistema - um administrador Controle financeiro da escola.

Diagrama de Casos de Uso

Requisitos não funcionais O sistema deve ser implementado em uma linguagem independente de sistema operacional, caso ocorra uma futura troca de sistema. - Java O SGBD utilizado deve ser gratuito –MySQL O sistema deve ter uma interface auto explicativa que não tenha a necessidade de manuais ou treinamento prévio.

Os (nossos) erros clássicos “Escritórios barulhentos” (Grads) “Síndrome da bala de prata”/ Estimativas equivocadas em relação a resultados de ferramentas / Mudanças de ferramentas (3 versões da GUI) Falta de controle do código ( SVN fez muita falta )

Casos de uso implementados Logar Deslogar Adicionar Professor Remover Professor Editar Professor Consultar Extrato Consultar Alunos

Visão Geral da arquitetura

Diagrama de classes do caso de uso Efetuar Login

Diagrama de seqüência do caso de uso Efetuar Login

Visão Geral dos Testes Executados Testes de integridade de dados (consultas, remoções, modificações, e inserções no BD). Testes de segurança de acesso(Ex: professor não acessar parte do administrador). Testes de unidade( Ex: datas da tela de extrato).

Detalhamento do teste de Efetuar Login Criamos um JUnitTestCase com o método testarLogin(Usuario), onde o Usuario passado no parâmetro já está inserido no BD Em testarLogin é chamado o método login(Usuario) da classe UsuarioServiceImpl, que retorna o usuario que está armazenado no BD e que possui o mesmo login e senha do usuário passado como parâmetro Fez-se um assertEquals() entre os logins e senhas do Usuario do parâmetro e do Usuario que está armazenado no BD