TERMO DE ABERTURA DO PROJETO TAP. Identificação do Projeto

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

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

•

4 STAKEHOLDERS

Lara Popov Zambiasi Bazzi Oberderfer – Cliente.

5 EQUIPE

•Beatriz Carla Koch - Gerente de projeto;

•Mariana Rafaela Picinin – Web Designer;

•Fernanda dos Santos – Programadora.

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áfica do 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 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

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 Produto

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

Risco Probabilidade Efeitos

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 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.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. 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.5 Diagrama de Estados

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 2: Cadastro dos membros do grêmio estudantil.

Imagem 4: Denúncias.

Imagem 6: Locação da chave, locador.

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

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

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 Lucas

19 – Auxílio aos funcionários

Todo o projeto Beatriz

5

Beatriz

21 – Termo de Abertura

4

Todos

22 – Termo de Visão

5

Todos

23 – 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

permitidos

10 – Cadastro dos usuário e

cadastro dos motivos de uso

11 – Monitoramento de uso

diário

14 – Levantamento dos

requisitos

15 – 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 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