TERMO DE ABERTURA DO PROJETO TAP Identificação do Projeto Projeto Sistema de controle de acessos ao campus Unidade demandante Lara Popov Zambiasi Bazzi Oberderfer Gestor do projeto Daniela Reck Patrocinador Instituto 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 projeto de 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 cená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 e adequação/atualização dos diagramas 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 de casos de uso e
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 O sistema deve permitir que o usuário consulte a sistema 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 1 Confidencialidade Descrição de O sistema deve garantir a confidencialidade dados 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 O sistema deve garantir sua confiabilidade, dados e operações 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 rápida e 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 O banco de dados do sistema deve ser feito MySQL em MySQL, por ser uma ferramenta atualizada, gratuita e de fácil utilização. 6 Programa em HTML e O sistema deve ser desenvolvido em HTML5, CSS e seu design e interface em CSS3, utilizando a ferramenta Notepad++, por ser gratuita e de fácil acesso. 7 Sincronização dados da instituição de 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: Atributo Nome_ser CPF_ser RG_ser Siape_ser Dpto_ser Telefone_ser Foto_ser Entidade: Atributo Nome_vis CPF_vis Motivo_vis Telefone_vis Foto_vis Servidor Tipo inteiro inteiro inteiro blob Visitante Tipo inteiro blob Descrição nome do servidor cpf do servidor rg do sevidor siape do servidor departamento do servidor telefone do servidor foto do servidor Descrição nome do visitante cpf do visitante motivo de visita telefone do visitante foto do visitante
Entidade: Atributo Nome_alu CPF_alu RG_alu Matrícula_alu Módulo_alu Telefone_alu Foto_alu Aluno Tipo inteiro inteiro inteiro blob Descrição nome do aluno cpf do aluno rg do aluno matrícula do aluno módulo doaluno telefone do aluno foto do aluno Entidade: Atributo Nome_admin CPF_admin RG_admin Telefone_admin Foto_admin Porteiro Tipo inteiro inteiro blob Descrição nome do administrador cpf do administrador rg do administrador telefone do administrador foto do administrador 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 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 daniela_reck@hotmail.com 17 APROVAÇÃO DO TERMO DE ABERTURA
Unidade Demandante Lara Popov Zambiasi Bazzi Oberderfer Unidades Envolvidas Data 25/05/2015 Data 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 Assinatura Data Assinatura Assinatura