TERMO DE ABERTURA DO PROJETO – TAP

Identificação do Projeto

ProjetoGerenciamento e Controle da Cozinha dos Bolsistas

Unidade demandanteLara Popov Zambiasi Bazzi Oberderfer

Gestor do projetoBeatriz Carla Koch

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 Todos Início do termo de abertura e projetode 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 ecená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

- Controlar e alterar o cronograma

- Monitorar e controlar riscos

- Auxiliar no desenvolvimento do sistema

- Ajudar nas dúvidas

- Gerenciar custos

Web Designer É responsável pela parte gráfica do sistema.

- Desenvolver a parte gráficado programa utilizando as

linguagens determinadas

- Criar layouts para o programa

Programadora É responsável pelo sucesso do projeto, pois desenvolve a parte lógica e de programação do sistema.

- Desenvolver código fonte em plataforma WEB

Analista de Sistemas É responsável pela modelagem de dados e paraencontrar 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

Os principais riscos identificados até o momento serão monitorados pelo Gerente. São

eles:

A probabilidade destes riscos são:

Risco Tipo de Risco Descrição

Projeto e produto

Erro de planejamento Projeto e produto

Complexidade de utilização Produto

Falta de wifi Produto

Problemas financeiros Projeto e produto

Indisponibilidade de hardware ProdutoCronograma Projeto e produto Os prazos podem não ser cumpridos

Mudança de requisitos Projeto

Projeto e produto

Projeto e produto

Projeto e produto

Falta de ligação do sistema com matrícula

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

Caso os vigilantes não tenham um tablet, computador ou smartfone, o produto não poderá ser utilizado

Caso sinta-se a necessidade de troca de plataforma ou alteração de requisitos

Erro de conexão com Banco de Dados

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.

Falta do profissional mais capacitado para a tarefa

O profissional mais capacitado para a realização desta tarefa pode faltar aula, ter consultas médicas, desistir do curso ou reprovar.

Falta de comprometimento dos integrantes

Caso os integrantes não estejam comprometidos com o projeto, pode acarretar problemas

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 obom funcionamento do sistema o software deve ter oseu 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.

Risco Probabilidade Efeitos

Alta ToleráveisErro de planejamento Alta ToleráveisComplexidade de utilização Média InsignificantesFalta de wifi Alta SériosProblemas financeiros Baixo InsignificantesIndisponibilidade de hardware Alta SériosCronograma Alta CatastróficosMudança de requisitos Média Toleráveis

Baixa Catastróficos

Média Sérios

Alta Catastróficos

Falta de ligação do sistema com matrícula

Erro de conexão com Banco de Dados

Falta do profissional mais capacitado para a tarefa

Falta de comprometimento dos integrantes

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

confiabilidade do sistema

O sistema deve garantir sua confiabilidade,

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

para manusear o

software

Os usuários que utilizarão o sistema precisam de

um treinamento, em especial os vigilantes e o

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

matrícula dos alunos a serem checados

posteriormente na utilização da sala.

7 Desenvolvimento para

Dispositivos Móveis

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 multade 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.

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

TAREFA RESPONSÁVEL DEPENDÊNCIAS

1 – Modelo ER 5 Beatriz T20(M1)

2 Lucas

3 – Diagrama de sequência 2 Lucas4 – Diagrama de atividades 2 Lucas5 – Use-case 2 Todos6 – Diagrama de classe 2 Mariana7 – Diagrama UML 2 Lucas

8 – Banco de dados Todo o projeto Beatriz

15 Fernanda T8

15 Fernanda T9 (M3)

15 Fernanda T8, T9

12 – Denúncias 20 Fernanda T8, T9

13 – Desenvolvimento gráfico 15 Mariana T9, T10, T11, T12 (M4)

Todo o projeto Fernanda

30 Mariana T13 (M5)

16 – Cronograma 5 Beatriz

17 – Testes 10 Lucas

18 – Suporte aos clientes Todo o projeto Lucas19 – Auxílio aos funcionários Todo o projeto Beatriz

5 Beatriz

21 – Termo de Abertura 4 Todos22 – Termo de Visão 5 Todos23 – Gestão do projeto Todo o projeto Beatriz

DURAÇÃO/DIA ÚTIL

2 – Diagrama de fluxo de dados

T1, T2, T3, T4, T5, T6, T7 (M2)

9 – Controle dos usuários permitidos10 – Cadastro dos usuário e cadastro dos motivos de uso11 – Monitoramento de uso diário

14 – Levantamento dos requisitos15 – Criação de layouts de sites

T8, T9, T10, T11, T12, T13, T15 (M6)

20 – Levantamentos dos riscos

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.

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.

Vigilantes Controle da entrega da chave para os alunos.

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 poderse 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.