Embed Size (px)
Citation preview
TERMO DE ABERTURA DO PROJETO – TAP
Identificação do Projeto
ProjetoSistema de controle de acessos ao campus
Unidade demandanteLara Popov Zambiasi Bazzi Oberderfer
Gestor do projetoDaniela Reck
PatrocinadorInstituto Federal de Educação, Ciência e Tecnologia de Santa Catarina – Campus Chapecó
Histórico de registro
Versão Data Autor Descrição
1.0 23/02 Daniela, Edson, Júlia e Levi Início do termo de abertura e projetode visão
1.1 02/03 Daniela e Levi Cronograma
1.2 02/03 Júlia e Edson Gerenciamento de riscos
1.3 16/03 Daniela e Júlia Diagrama de casos de uso ecenários
1.4 23/03 Daniela e Júlia Diagrama de sequência
1.5 30/03 Daniela Diagrama de estados
1.6 06/04 Daniela, Edson, Júlia e Levi Preparação para seminários eadequação/atualização dosdiagramas
1.7 13/04 Daniela, Edson, Júlia e Levi Pré-apresentação: parte 1
1.8 04/05 Daniela, Edson, Júlia e Levi Modelo Entidade-Relacionamento
1.9 11/05 Daniela Diagrama de classes
2.0 11/05 Júlia e Edson Dicionário de dados
2.3 18/05 Daniela, Edson, Júlia e Levi Telas do sistema
2.4 15/06 Daniela, Edson, Júlia e Levi Pré-apresentação: parte 2
2.5 29/06 Daniela, Edson, Júlia e Levi Apresentação dos projetos
2.6 06/07 Daniela, Edson, Júlia e Levi Revisão dos projetos
1 JUSTIFICATIVA
A finalidade deste documento é coletar, analisar e definir as necessidades e
características de nível superior do Sistema de Controle de Acesso. Ele se concentra nos
recursos (requisitos funcionais) necessários aos envolvidos e aos usuários-alvo. Os
detalhes de como o Sistema de Controle de Acesso atende a essas necessidades estão
descritos nas especificações de caso de uso.
2 OBETIVOS
2.1Objetivo geral
Desenvolver um software para gerenciamento de as entradas e saídas dos alunos
no Instituto Federal de Santa Catarina – Campus Chapecó.
2.2 Objetivos Específicos
• Criar um software na plataforma Web utilizando conceitos de HTML 5 e CSS 3;
3 STAKEHOLDERS
Lara Popov Zambiasi Bazzi Oberderfer – Cliente.
4 EQUIPE
• Daniela Reck Rostirola - Gerente de projeto e Programadora;
• Levi Macedo de Carvalho – Web Designer e Programador;
• Edson Stapassola - Analista de Sistemas;
• Júlia Pinho Mallmann – Web Designer e Programadora.
5 PREMISSAS
• A principal premissa, ou seja, algo fundamental para o funcionamento do software
são usuários, tais como, alunos e servidores previamente cadastrados. Também
faz-se importante a presença ativa e capacitada de um porteiro.
• Faz-se necessária a presença de um hardware compatível com na função a ser
exercida, tendo acesso à energia elétrica.
6 GRUPO DE ENTREGAS
Entre os grupos de entrega encontram-se: os cadastros (porteiro, aluno, servidor e
visitante), características que possam ser utilizadas pelo sistema em prol do controle de
informações e identificação de cada usuário, os logins. Funcionará como um diferenciador
de tarefas devido a diferentes funções de cada usuário.
7 RESTRIÇÕES
As restrições que envolvem o projeto são as seguintes:
• Na falta de equipamentos necessários a produção do projeto será
interrompida/atrasada até que o problema seja sanado;
• Na falta de funcionários capacitados haverá atraso na entrega do projeto;
• Em caso de quebra de contrato as atividades serão interrompidas e haverá
uma taxa de 30% em cima do valor final do produto;
• Cada usuário terá somente um cadastro, em caso de desistência ou
formação, no caso do usuário tipo aluno, a sua conta será automaticamente excluída. O
mesmo vale para usuários tipo servidor;
• O servidor do software não fará registros após o período de término das
aulas.
8 RISCOS
Os principais riscos identificados até o momento serão monitorados pelo Gerente.
São eles:
• Problemas com o financiador do projeto;
• Alterações na Legislação vigente no país;
• Alteração no mercado quanto às suas necessidades ou capacidade de compra;
• Equipamentos defeituosos;
• Equipe desfalcada ou com problemas de relacionamento;
• Gastos excessivos;
• Estouro do prazo devido a falhas de desenvolvimento e/ou a erros no
gerenciamento;
• A complexidade do sistema, não devidamente percebida nas etapas iniciais.
9 REQUISITOS
9.1 Requisitos Funcionais
Os requisitos funcionais do Sistema de Controle de Acesso para o Instituto Federal
de Santa Catarina, campus Chapecó são:
[RF001]Consultar cadastro no sistema;
[RF002]Confirmar entrada;
[RF003]Confirmar saída;
[RF004]Login no sistema;
[RF005]Gerar relatório.
Requisitos Funcionais
Nº. Nome Descrição
1 Consultar cadastro no
sistema
O sistema deve permitir que o usuário consulte a
presença ou a ausência de seu cadastro para que
possa confirmar sua entrada no IFSC campus
Chapecó.
2 Confirmar entrada O sistema deve possibilitar a confirmação da
entrada de um usuário previamente cadastrado pelo
registro acadêmico da instituição.
3 Confirmar saída O sistema deve possibilitar a confirmação da saída
de um usuário previamente inserido na instituição
tanto pelo sistema como fisicamente.
4 Login no sistema O sistema deve, acima de tudo, permitir login e
logon do usuário do sistema de forma fácil em uma
interface amigável.
5 Gerar relatório O deve possibilitar a geração de relatórios a partir do
uso diário, mensal ou anula do Sistema de Controle
de Acessos aos IFSC campus Chapecó, para que os
setores administrativos da instituição tenham ciência
e possam gerenciar de maneira mais direta os
problemas relacionados à entrada e a saída do
campus.
9.2 Requisitos Não-Funcioncionais
Os requisitos não funcionais do Sistema de Controle de Acesso para o Instituto
Federal de Santa Catarina, campus Chapecó são:
[RNF001]Confidencialidade dos dados;
[RNF002]Facilidade em utilizar;
[RNF003]Confiabilidade de dados e operações;
[RNF004]Atualização fácil e rápida;
[RNF005]Banco de dados em MySQL;
[RNF006]Programa em HTML e CSS;
[RNF007]Sincronização de dados da instituição.
Requisitos Não Funcionais
Nº. Nome Descrição
1 Confidencialidade de
dados
O sistema deve garantir a confidencialidade
dos dados através de uma política de
privacidade com login e senha, em que cada
usuário poderá confirmar sua entrada e/ou
saída física e virtualmente.
2 Facilidade em utilizar O sistema deve ser fácil ao uso e acesso de
funcionalidades. O recurso "ajuda" deve
auxiliar o usuário a manusear de maneira mais
precisa o sistema, descrevendo suas
funcionalidades e localização de botões.
3 Confiabilidade de
dados e operações
O sistema deve garantir sua confiabilidade,
para que também os dados e operações sejam
seguros. Haverá confirmação de operações e
inserção de dados ao usuário em janelas de
mensagem.
4 Atualização fácil e
rápida
O sistema deve permitir fácil e rápida
atualização, disponível ao usuário assim que
concluída pelos desenvolvedores. Pode
ocorrer tanto por necessidade do usuário
quanto por análise e julgamento dos
desenvolvedores.
5 Banco de dados em
MySQL
O banco de dados do sistema deve ser feito
em MySQL, por ser uma ferramenta
atualizada, gratuita e de fácil utilização.
6 Programa em HTML e
CSS
O sistema deve ser desenvolvido em HTML5,
e seu design e interface em CSS3, utilizando a
ferramenta Notepad++, por ser gratuita e de
fácil acesso.
7 Sincronização de
dados da instituição
O sistema deve sincronizar dados já presentes
no sistema interno da instituição, como dados
dos alunos e servidores a serem checados
posteriormente na entrada e saída do IFSC
campus Chapecó.
10 DIAGRAMAS E MODELOS
10.1 Modelo Entidade-Relacionamento
10.2 Diagrama de Casos de Uso
10.3 Cenários
1 Consultar usuário
Caso de uso Consultar Usuário
Pré-requisito: Estar cadastrado no sistema
1 – O usuário informa código de cadastro
2 – O porteiro confirma a inserção de dados
3 – O sistema verifica a validade dos dados informados
4 – O sistema retorna os dados do usuário
2 Registrar saída
Caso de uso Registrar saída
Pré-requisito: Estar cadastrado no sistema
1 – O usuário informa código de cadastro
2 – O sistema verifica a validade dos dados informados
3 – O porteiro confirma a inserção de dados
4 – O sistema retorna saída de usuário efetuada com sucesso
3 Registrar entrada
Caso de uso Registrar entrada
Pré-requisito: Estar cadastrado no sistema
1 – O usuário informa código de cadastro
2 – O sistema verifica a validade dos dados informados
3 – O porteiro confirma a inserção de dados
4 – O sistema retorna entrada de usuário efetuada com sucesso
4 Cadastrar usuário
Caso de uso Cadastrar usuário
Pré-requisito: Portar documento oficial com foto
1 – O futuro usuário informa seus dados
Visitante: Nome, contato, foto e motivo da visita;
Aluno: Nome, matrícula, RG, CPF, turma, contato, curso e foto;
Servidor: Nome, RG, CPF, matrícula/SIAPE, contato, foto;
2 – O sistema verifica a validade dos dados informados
3 – O porteiro confirma a inserção de dados
4 – O sistema retorna cadastro de usuário efetuado com sucesso
5 Alterar usuário
Caso de uso Alterar usuário
Pré-requisito: Estar cadastrado no sistema
1 – O usuário informa a matrícula
2 – O sistema verifica a validade do dado informado
3 – O sistema abre o cadastro do usuário para alterações
4 – O usuário informa os dados a serem alterados
3 – O porteiro confirma a inserção de dados
4 – O sistema retorna alteração de dados efetuada com sucesso
6 Excluir usuário
Caso de uso Excluir usuário
Pré-requisito: Estar cadastrado no sistema
1 – O usuário/porteiro informa a matrícula
2 – O sistema verifica a validade do dado informado
3 – O sistema confirma a exclusão de dados, solicitando a senha do administrador
4 – O porteiro confirma a inserção de dados
5 – O sistema retorna exclusão de dados efetuada com sucesso
10.4 Diagrama de Sequência
10.5 Diagrama de Estados
10.6 Diagrama de Classes
10.7 Prioridade de tarefas – MoSCoW
M – Must have – Cadastro de usuários (alunos, servidores e visitantes) e saída de
usuários;
S - Should have – Consulta de usuário, restrições de cadastramento, Cadastro de
usuários;
C – Could have – Login, logout e Nível de permissão para usuários;
W – Would have - Manual do software.
11 CRONOGRAMA
12 TELAS DO SISTEMA
12.1 Tela inicial
12.2 Manual de ajuda
12.3 Perguntas frequentes
12.4 Registro do usuário - Funcionários
12.5 Registro de usuário - Alunos
12.6 Registro de usuário - Visitante
12.7 Alteração de usuário
12.8 Exclusão de usuário
12.9 Alteração de funcionário
12.9 Exclusão de funcionário
13 DICIONÁRIO DE DADOS
Entidade: ServidorAtributo Tipo Descrição
Nome_ser texto nome do servidorCPF_ser inteiro cpf do servidorRG_ser inteiro rg do sevidor
Siape_ser inteiro siape do servidorDpto_ser texto departamento do servidor
Telefone_ser texto telefone do servidorFoto_ser blob foto do servidor
Entidade: VisitanteAtributo Tipo Descrição
Nome_vis texto nome do visitanteCPF_vis inteiro cpf do visitante
Motivo_vis texto motivo de visitaTelefone_vis texto telefone do visitante
Foto_vis blob foto do visitante
14 RECURSOS UTILIZADOS
As ferramentas utilizadas para desenvolvimento do software são:
• DBDesigner: software para modelagem de dados, utilizado para fazer Modelo ER do
software;
• Astah: software para modelagem de dados, utilizado para fazer os demais diagramas do
software;
• Balsamiq: ferramenta utilizada para modelagem da interface do programa;
• Notepad++: ferramenta própria para a edição de texto e código fonte, utilizada para a
edição em HTML 5 e CSS 3;
• MySQL: sistema de gerenciamento de Banco de Dados;
15 CUSTOS
O Projeto terá custo zero.
16 GERENTE DO PROJETO
Nome Daniela Reck Rostirola
Cargo Gerente de Projeto
Endereço Eletrônico [email protected]
17 APROVAÇÃO DO TERMO DE ABERTURA
Entidade: AlunoAtributo Tipo Descrição
Nome_alu texto nome do alunoCPF_alu inteiro cpf do alunoRG_alu inteiro rg do aluno
Matrícula_alu inteiro matrícula do alunoMódulo_alu texto módulo doaluno
Telefone_alu texto telefone do alunoFoto_alu blob foto do aluno
Entidade: PorteiroAtributo Tipo Descrição
Nome_admin texto nome do administradorCPF_admin inteiro cpf do administradorRG_admin inteiro rg do administrador
Telefone_admin texto telefone do administradorFoto_admin blob foto do administrador
Unidade Demandante Data Assinatura
Lara Popov Zambiasi Bazzi Oberderfer 25/05/2015
Unidades Envolvidas Data Assinatura
Daniela Reck Rostirola 25/05/2015
Edson Stapassola 25/05/2015
Júlia Pinho Mallmann 25/05/2015
Levi Macedo de Carvalho 25/05/2015
Secretário-Geral/Diretor-Geral Data Assinatura
