TERMO DE ABERTURA DO PROJETO TAP Identificação do Projeto Projeto Gerenciamento e Controle da Cozinha dos Bolsistas Unidade demandante Lara Popov Zambiasi Bazzi Oberderfer Gestor do projeto Beatriz Carla Koch 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 Todos Início do termo de abertura e projeto de visão 1.1 02/03 Beatriz e Mariana Cronograma 1.2 02/03 Beatriz Gerenciamento de riscos 1.3 16/03 Todos Diagrama de casos de uso e cenários 1.4 23/03 Todos Diagrama de sequência 1.5 30/03 Todos Diagrama de estados 1.6 06/04 Todos Preparação para seminário 1.7 13/04 Beatriz, Fernanda e Mariana Pré-apresentação 1.8 04/05 Todos Modelo Entidade-Relacionamento 1.9 11/05 Beatriz Diagrama de classes 2.0 11/05 Todos Dicionário de dados 2.3 18/05 Todos Telas do sistema 2.4 15/06 Fernanda, Mariana e Lucas Telas do sistema 2.5 15/06 Beatriz Revisão do projeto escrito 2.6 22/06 Todos Revisão dos projetos
1 JUSTIFICATIVA A finalidade deste documento é coletar, analisar e definir as necessidades e características de nível superior do Gerenciamento e Controle da Cozinha dos Bolsistas. Ele se concentra nos recursos (requisitos funcionais) necessários aos envolvidos e aos usuários-alvo. Os detalhes de como o Gerenciamento e Controle da Cozinha dos Bolsistas atende a essas necessidades estão descritos nas especificações de caso de uso. 2 PROBLEMA O problema Atualmente, a cozinha dos bolsistas possui um micro-ondas e pode ser utilizada por todos os alunos do Campus para esquentarem seus alimentos. Devido a falta de controle de acesso, muitos a utilizam e a deixam suja, muitas vezes impossibilitando o uso para o usuário subsequente. Afeta Os principais afetados são os próprios estudantes que tem que gozar de uma sala suja e muitas vezes sem higiene, com a solução estes seriam os beneficiários. Cujo impacto é Impossibilidade de uso pelos usuários subsequentes, devido a sujeira, bagunça e falta de higiene da sala. Uma boa solução seria Organizar o acesso dos estudantes a sala, bem como estabelecer usuários para limpar e realizar um sistema de denúncias. Esta solução proporcionaria mais comodidade aos usuários da sala e também aos vigilantes, pois os mesmos não sabem quem pode ou não ter acesso a sala.
3 OBJETIVOS 3.1 Objetivo geral Desenvolver um software para gerenciamento e controle da cozinha dos bolsistas. 3.2 Objetivos Específicos Criar um software na plataforma Web utilizando conceitos de HTML 5 e CSS 3; 4 STAKEHOLDERS Lara Popov Zambiasi Bazzi Oberderfer Cliente. 5 EQUIPE Beatriz Carla Koch - Gerente de projeto; Mariana Rafaela Picinin Web Designer; Lucas Dall' Rosa - Analista de Sistemas; Fernanda dos Santos Programadora. 5.1 Responsabilidades dos Envolvidos Função Descrição Responsabilidades Gerente do Projeto É responsável pelas orientações no projeto, bem como gerenciar banco de dados e realizar correções. Além de organizar o projeto. - Gerenciar banco de dados, bem como manutenção do mesmo - Realizar testes no sistema Web Designer É responsável pela parte gráfica do sistema. - Controlar e alterar o cronograma - Monitorar e controlar riscos - Auxiliar no desenvolvimento do sistema - Ajudar nas dúvidas - Gerenciar custos - Desenvolver a parte gráfica do programa utilizando as
Programadora É responsável pelo sucesso do projeto, pois desenvolve a parte lógica e de programação do sistema. linguagens determinadas - Criar layouts para o programa - Desenvolver código fonte em plataforma WEB Analista de Sistemas É responsável pela modelagem de dados e para encontrar o melhor caminho para desenvolvimento do programa. - Desenvolver diagramas de modelagem de dados. - Analisar os erros que o sistema pode ter. 6 PREMISSAS Para o sucesso completo desse projeto, é fundamental que as condições abaixo sejam atendidas: Pontualidade; Comprimento das funções determinadas; Respeito; Encontros para verificar o andamento do projeto. 7 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. 8 RESTRIÇÕES As restrições que envolvem o projeto são as seguintes: Componentes de hardware devidamente em funcionamento; Conexão a internet.
9 RISCOS eles: Os principais riscos identificados até o momento serão monitorados pelo Gerente. São Risco Tipo de Risco Descrição Falta de ligação do sistema com matrícula Erro de planejamento Complexidade de utilização Falta de wifi Problemas financeiros A probabilidade destes riscos são: Projeto e produto Projeto e produto Produto Produto Projeto e produto Caso os vigilantes não tenham um tablet, computador ou smartfone, o produto não Indisponibilidade de hardware Produto poderá ser utilizado Cronograma Projeto e produto Os prazos podem não ser cumpridos Caso sinta-se a necessidade de troca de Mudança de requisitos Projeto plataforma ou alteração de requisitos Erro de conexão com Banco de Dados Falta do profissional mais capacitado para a tarefa Falta de comprometimento dos integrantes Projeto e produto Projeto e produto Projeto e produto Não efetiva ligação do software com o portal do aluno em relação a matrícula Possíveis erros de logística das atividades pretendidas de serem executadas Complexidade na utilização do software por parte dos vigilantes Caso não tenha wifi disponível no dia, o sistema ficará inutilizado Orçamento baixo para implementação do projeta Pode acontecer do sistema não conectar no Banco de Dados, devido a problemas na conexão com a Internet e do programa com o servidor. O profissional mais capacitado para a realização desta tarefa pode faltar aula, ter consultas médicas, desistir do curso ou reprovar. Caso os integrantes não estejam comprometidos com o projeto, pode acarretar problemas
Risco Probabilidade Efeitos Falta de ligação do sistema com matrícula Alta Toleráveis Erro de planejamento Alta Toleráveis Complexidade de utilização Média Insignificantes Falta de wifi Alta Sérios Problemas financeiros Baixo Insignificantes Indisponibilidade de hardware Alta Sérios Cronograma Alta Catastróficos Mudança de requisitos Média Toleráveis Erro de conexão com Banco de Dados Baixa Catastróficos Falta do profissional mais capacitado para a tarefa Média Sérios Falta de comprometimento dos integrantes Alta Catastróficos 10 REQUISITOS 10.1 Requisitos Funcionais Os requisitos funcionais do nosso projeto são: [RF001]Interface fácil; [RF002]Acesso ao número de matrícula; [RF003]Banco de dados atualizado; [RF004]Login no sistema. Requisitos Funcionais Nº. Nome Descrição 1 Interface O sistema deve apresentar uma interface de fácil entendimento e uso por parte dos usuários. 2 Número de matrícula O sistema deve ter acesso aos números de matriculas dos alunos, pois, só assim, o sistema pode ter o controle dos cadastros e assim evitar possíveis fraldes por parte dos usuários. 3 Banco de Dados Para a real satisfação dos usuários e também para o bom funcionamento do sistema o software deve ter o seu banco de dados sempre atualizado. 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.
10.2 Requisitos Não-Funcionais Os requisitos não funcionais do Sistema de Controle de Acesso para o Instituto Federal de Santa Catarina, campus Chapecó são: [RNF001]Facilidade em utilizar; [RNF002]Restrição e confiabilidade do sistema; [RNF003]Preparação dos usuários para manusear o software; [RNF004]Banco de dados em MySQL; [RNF005]Programa em HTML e CSS; [RNF006]Sincronização de dados da instituição; [RNF007]Desenvolvimento para Dispositivos Móveis. Requisitos Não Funcionais Nº. Nome Descrição 1 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. 2 Restrição e O sistema deve garantir sua confiabilidade, confiabilidade do sistema restringindo a utilização do sistema apenas para usuários autorizados. Além de permitir denúncias anônimas. 3 Preparação dos usuários Os usuários que utilizarão o sistema precisam de para manusear o um treinamento, em especial os vigilantes e o software Grêmio Estudantil. 4 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. 5 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. 6 Sincronização de dados da instituição O sistema deve sincronizar dados já presentes no sistema interno da instituição, como dados de
7 Desenvolvimento para Dispositivos Móveis matrícula dos alunos a serem checados posteriormente na utilização da sala. O programa terá de se adaptar para dispositivos móveis, porque será utilizado em trânsito pelos vigilantes e alunos. 11 DIAGRAMAS E MODELOS 11.1 Modelo Entidade-Relacionamento
11.2 Diagrama de Casos de Uso 11.3 Cenários 1. Solicitação da chave 1. O aluno solicita a chave ao vigilante 2. Se a chave estiver disponível, O sistema verifica se o aluno está com pendências Caso negativo, empréstimo será realizado Caso afirmativo, o aluno procura o Grêmio e verifica se está banido do uso 3. Se chave estiver em uso, aluno utiliza a sala. 4. O responsável legal da chave é quem está de posse da mesma registrado junto aos vigilantes. 2. Devolução da Chave 1. O aluno efetua a devolução ao vigilante 2. O vigilante valida a devolução 3. Disponibilidade da chave para retirada
3. Reclamação 1. O aluno efetua reclamação pela janela denúncia, optando por anonimato. 2. O vigilante verifica se a reclamação é válida. Caso sim, denúncia é validada, repasse ao Grêmio Estudantil que efetua pena. Caso não, denúncia é rejeitada. 4. Pena 1. O Grêmio estipula a pena ao denunciado, especificando se é limpeza ou reparo de materiais. 2. O aluno é banido da sala até cumprir a tarefa, num prazo de 1 dia útil. 3. Grêmio fiscaliza a ação. Caso seja feito, o Grêmio dá um visto e permite que usuário retorne a usar a sala. Caso contrário, o grêmio solicita a limpeza pelas serventes e o pagamento da multa de R$ 20,00, este sobre resguardo do mesmo para futuras compras e reparações para a cozinha dos bolsistas. 4. Após o pagamento da multa, o usuário retorna a utilizar a sala. Caso contrário, será banido do uso por 6 meses. 11.4 Diagrama de Sequência
11.5 Diagrama de Estados 11.6 Diagrama de Classes
11.7 Prioridade de tarefas MoSCoW M Must have Cadastro de usuários (alunos, vigilantes e Grêmio Estudantil) e retirada e devolução da chave. S - Should have Restrições de cadastramento, Denúncias, Pena; C Could have Login, logout e Nível de permissão para usuários; W Would have - Manual do software. 11.8 Telas do Sistema Imagem 1: Cadastro do aluno.
Imagem 2: Cadastro dos membros do grêmio estudantil. Imagem 3: Cadastro dos vigilantes.
Imagem 4: Denúncias. Imagem 5: Histórico.
Imagem 6: Locação da chave, locador. Imagem 7: Locação da chave, locatário.
Imagem 8: Multas, aluno suspenso.
11.9 Dicionário de Dados
12 CRONOGRAMA OBSERVAÇÃO: As tarefas foram desenvolvidas em conjunto. O cronograma era apenas uma previsão. DURAÇÃO/DIA TAREFA RESPONSÁVEL DEPENDÊNCIAS ÚTIL 1 Modelo ER 5 Beatriz T20(M1) 2 Diagrama de fluxo de dados 2 Lucas 3 Diagrama de sequência 2 Lucas 4 Diagrama de atividades 2 Lucas 5 Use-case 2 Todos 6 Diagrama de classe 2 Mariana 7 Diagrama UML 2 Lucas 8 Banco de dados Todo o projeto Beatriz T1, T2, T3, T4, T5, T6, T7 (M2) 9 Controle dos usuários permitidos 15 Fernanda T8 10 Cadastro dos usuário e cadastro dos motivos de uso 15 Fernanda T9 (M3) 11 Monitoramento de uso diário 15 Fernanda T8, T9 12 Denúncias 20 Fernanda T8, T9 13 Desenvolvimento gráfico 15 Mariana T9, T10, T11, T12 (M4) 14 Levantamento dos requisitos Todo o projeto Fernanda 15 Criação de layouts de sites 30 Mariana T13 (M5) 16 Cronograma 5 Beatriz 17 Testes 10 Lucas T8, T9, T10, T11, T12, T13, T15 (M6) 18 Suporte aos clientes Todo o projeto Lucas 19 Auxílio aos funcionários Todo o projeto Beatriz 20 Levantamentos dos riscos 5 Beatriz 21 Termo de Abertura 4 Todos 22 Termo de Visão 5 Todos 23 Gestão do projeto Todo o projeto Beatriz 13 RECURSOS UTILIZADOS As ferramentas utilizadas para desenvolvimento do software são: DBDesigner: software para modelagem de dados, utilizado para fazer o Modelo ER do software; Astah: software para modelagem de dados, utilizado para fazer os demais diagramas do
software; Balsamiq: ferramenta utilizada para criação da interface/layout do programa; Notepad++: ferramenta 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; 14 CUSTOS Este projeto terá custo zero, porém, pode ser interessante que na implementação seja efetuada a compra de hardware para utilização do software. 15 INTERESSADOS Nome Descrição Responsabilidades Os membros fundadores deste projeto são os estudantes do sétimo módulo Beatriz Carla Koch, Fernanda dos Santos, Lucas Dall Rosa e Mariana Rafaela Picinin. Todos os alunos fundadores são responsáveis por este projeto. Verificar a viabilidade de instalação do software em questão. Desenvolver código fonte assim como gráficos do sistema. Vigilantes Controle da entrega da chave para os alunos. Manter o sistema. Treinar os usuários para um melhor aproveitamento do software. Controlar de dados e documentos referentes ao sistema, bem como desenvolver e planejar diagramas e estratégias de desenvolvimento. Controlar a retirada da chave da cozinha dos bolsistas da portaria atrvés do sistema implantado. Realizar a inicialização do sistema, assim como anotações. Alunos Usuários finais. Prestar denúncias quando necessário. Realizar a retirada de forma correta através dos
vigilantes. Retirar a chave de seu poder se não ficar sob sua guarda. Comprometer-se em devolver a chave, assim como a recebeu. Repassar a chave de nome caso saia da cozinha e usuários permaneçam em seu interior. 1.16 APROVAÇÃO DO TERMO DE ABERTURA 2. 3.Responsável 4.Data 5.Assinatura 6.[Nome da Parte Responsável] 7.[dd/mm/aaaa] 8.