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 arquivoManutenção de arquivo a longo prazoOrganizaçãoDiminui o trabalho de vários professoresMaior 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 DeslogarAdicionar ProfessorRemover ProfessorEditar ProfessorConsultar ExtratoConsultar Alunos

Visão Geral da arquitetura

Telas

controle

DAO

basicas

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