GestaoReunioes: mudanças entre as edições

De Wiki Cursos IFPR Foz
Ir para navegaçãoIr para pesquisar
Linha 125: Linha 125:


==Modelo Entidade e Relacionamento(MER)==
==Modelo Entidade e Relacionamento(MER)==
[[Arquivo:MerGestaoReuniao.jpg]]
[[Arquivo:MerReuniao.jpg]]

Edição das 13h42min de 20 de setembro de 2018

Gerenciador de Reuniões

Objetivo Geral

Desenvolver um sistema web capaz de gerenciar reuniões dentro do Instituto Federal do Paraná, visando um maior aproveitamento do tempo utilizado em reuniões acadêmicas e visando agilizar todo o processo de reuniões em geral.

Equipe

Professores orientadores
  • Alcione Benacchio
  • Wellington Oliveira
Alunos
  • Pablo Lima Flores
  • Tiago Marins de Queiroz

Escopo do projeto

O sistema de gerenciamento de reuniões tem o foco de facilitar e agilizar todo o processo que envolve reuniões, visando também padronizá-las em um formato que melhor atenda às necessidades dos envolvidos. Para que isso se realize, o sistema contará com uma série de mecanismos que possibilitarão organizar e acompanhar uma reunião desde o planejamento inicial até a sua finalização e possível marcação de reuniões futuras, ligadas ao tema já discutido ou não. O sistema seguirá um padrão para melhor atender as necessidades, que foram levantadas em pesquisas. O sistema contará com cadastro de usuários, que serão divididos em dois perfis, o perfil administrador, com acesso global às funcionalidades do sistema, responsável pela sua manutenção e o perfil usuário, que é o usuário padrão, que possuirá restrições às telas administrativas(cadastros, por exemplo). Este também será responsável pela manutenção das reuniões, em todo o seu “ciclo de vida”, desde o agendamento, definição da pauta, a execução da reunião, finalizando com a geração da ata. Em termos teóricos, uma reunião, poderá ter diferentes tipos de participantes, sendo estes: um facilitador (conduz a discussão, assegurando-se de que todos os lados da questão são levantados), um anotador (anota as ideias e decisões principais e distribui anotações), um controlador (que ajuda na evolução da discussão de modo eficiente), um colaborador (necessário para manter o foco e a discussão ativa) e um especialista (compartilha conhecimento sobre o assunto a ser tratado). Dependendo do tipo de reunião definida, alguns destes tipos podem não ser necessários ou uma mesma pessoa pode exercer as funções de mais de um tipo. Em relação ao agendamento, o sistema disponibilizará opções que incluem algumas particularidades a serem seguidas, tais como:

  • Título
  • Data
  • Local
  • Hora início
  • Hora término
  • Objetivo
  • Tipo
  • Possui pré-requisito? Qual?
  • Solicitante
  • Mediador
  • Secretário
  • Integrantes

Por padrão, será estipulado o tempo máximo de uma hora. Caso necessário, a partir de uma justificativa, pode-se aumentar esse período. O objetivo é uma descrição breve do que se pretende ser alcançar com a reunião. Em relação ao tipo, o sistema possibilitará cadastro de novos registros, mas possuirá alguns tipos primários como base, sendo estes:

  • Brainstorm: Onde cada pessoa sugere alternativas para cada fase, ou etapa, do problema definido, sem que haja discriminações ou críticas por parte dos outros envolvidos.
  • Consultiva: Deve apresentar tema relativo à decisão em outras instâncias e que afetam direta ou indiretamente os envolvidos.
  • Deliberativa: Deve apresentar o tema de consulta aos integrantes, devendo considerar tempo extra para debates, para que todos os integrantes possam ter o mesmo tempo para se pronunciar.
  • Trabalho: Deve ser focado na realização de uma atividade ou demanda em tempo determinado, idealmente duas horas.
  • Mista: situação a qual a tipificação será dada por cada tópico.

Caso seja marcada a obrigatoriedade de pré-requisito, pode-se especificá-lo, como por exemplo, ter participado de uma reunião anterior, ou ter um conhecimento sobre um assunto específico. Nos casos em que o participante é permitido o comparecimento, mesmo sem cumprir o pré-requisito, este não terá “voz ativa”, ou seja, só estará lá para ouvir e ficar ciente do assunto, mas não poderá debater, opinar ou votar em nada relacionado à reunião). As atribuições entre os participantes, no sistema, podem ser:

  • Solicitante: que é a pessoa responsável por agendar e informar todos os dados necessários para marcar a reunião.
  • Mediador: é quem conduzirá a reunião (poderá ser a mesma pessoa que solicitou a reunião ou não). Engloba a funções de facilitador e colaborador.
  • Secretário: possui a função de anotador e é responsável por registrar sobre o andamento da reunião e fazer a ata de reunião.
  • Integrantes que serão as demais pessoas que irão compor a reunião e discutir sobre a mesma.

Após a reunião ser agendada com sucesso, haverá um prazo para o usuário que a cadastrou submeta a pauta(por exemplo até 24h antes do horário previsto). A pauta será dividida por tópicos. Cada tópico será composto por:

  • Peso ou ordem de discussão/importância.
  • Responsável pelo tópico.
  • Descrição do que será abordado.
  • Tipo (caso o tipo da reunião for definido como Misto). Segue a mesma tipificação da reunião.
  • Tempo que deverá ser acompanhado pelo sistema para evitar problemas de excesso de tempo de um tema e falta de outros.
  • E se é aberto a debates pois dependendo do tipo de reunião debates não são necessários.

O sistema deverá avisar os participantes que foram convocados para a reunião através de um e-mail e também deverá marcar no google agenda (calendar) o dia e horário que ocorrerá. Ao decorrer da reunião, serão exibidos todos os tópicos. Haverá área específica para registro de anotações por tópico. Ao término será permitido a criação da ata de reunião, onde serão descritas as informações tratadas, como a ordem dos tópicos, seu responsável, o tempo executado, o que foi discutido e definido, por tópico. Haverá a possibilidade de se registrar, apenas a nível informativo, as ações a serem tomadas, com os respectivos responsáveis. Ao final de cada reunião, deverá ser possível disponibilizar a ata em formato PDF, para que todos os participantes tenham acesso ao que foi decidido em reunião e ficarem cientes das escolhas. Também ao término da reunião, deverá ser possível fazer um agendamento para as próximas reuniões, com periodicidade a ser escolhida pelo mediador da reunião.

Requisitos

Código
Requisito Funcional
RF 1 O sistema deve manter usuários.
RF 2 O sistema deve permitir tipificar os usuários em: administrador e usuário.
RF 3 O sistema deve manter pessoas.
RF 4 O sistema deve manter integrantes.
RF 5 O sistema deve manter reuniões.
RF 6 O sistema deve permitir o agendamento de reunião.
RF 7 O sistema deve manter tipos de reunião.
RF 8 Cada tipo de reunião deve ter um tempo de execução padrão.
RF 9 O sistema deve manter tópicos.
RF 10 O sistema deve manter pautas de reunião.
RF 11 O sistema deve manter atas de reunião.
Código
Requisito Não Funcional Tecnológico
RNFT 1 O sistema deve ser executado em ambiente web.
RNFT 2 O sistema deve ser desenvolvido utilizando a linguagem Java.
RNFT 3 O sistema deve utilizar as ferramentas do “ecossistema” Spring, como o Spring Security e o Spring Data.
RNFT 4 O sistema deve ser construído utilizando o thymeleaf e o bootstrap como ferramentas de desenvolvimento front-end
RNFT 5 O sistema utilizará o sistema de banco de dados relacional PostgreSQL.
RNFT 6 O sistema utilizará o framework Hibernate para acesso e persistência dos dados.
RNFT 7 O sistema deverá utilizar a API do google calendar(Agenda).
Código
RF
Regras de Negócio
RN1 RF2 Usuário do tipo 'usuario' não terão permissão de acesso às rotinas administrativas.
RN 2 RF6 No agendamento, deve-se preencher as seguintes informações: título, data, local, hora inicio, hora fim, objetivo, tipo, pré-requisito, solicitante, mediador, secretario e integrantes.
RN 3 RF8 Caso a reunião necessitar possuir um período maior do que o estipulado pelo seu tipo, deve-se adicionar uma justificativa.
RN 4 RF9 A reunião deve, obrigatoriamente, possuir pelo menos um tópico associado.

Diagrama de Classes

Modelo Entidade e Relacionamento(MER)