termo de abertura do projeto –...
TRANSCRIPT
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.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.
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.