Sistema gerenciador de grupos (SGG)

Descrição geral do sistema

O SGG deve ser um sistema que auxilie no gerenciamento dos grupos da rede acadêmica do DCC, incluindo criação e remoção de grupos por parte dos administradores e gerenciamento dos membros dos grupos pelos professores que os coordenam. O sistema deverá ser web, com interface amigável, para estimular o uso por parte dos professores ou alunos responsáveis pelos grupos.

Comentário: talvez usar outro nome e ser uma interface web genérica para o LDAP seja mais adequado. O caso dos grupos ficaria como uma parte do sistema. uniGroups

Estórias de usuário

As estórias estão classificadas em prioridades -- A (alta), M (média), B (baixa). Uma possível interpretação para essas prioridades é a seguinte:

• alta: é fundamental que o sistema possua essa funcionalidade
• média: se for possível, seria importante ter essa funcionalidade
• baixa: seria legal ter essa funcionalidade, mas se não der tudo bem.

Título	Prioridade	Descrição
Administrador pode criar grupo	alta	O administrador do sistema pode criar novo grupo. Cada grupo criado deve ter um nome e ao menos um coordenador (professor ou aluno).
Administrador pode alterar grupo existente	alta	O administrador do sistema pode alterar grupo existente: modificar nome, inserir coordenador(es), remover coordenador(es) do grupo. O grupo alterado deve ter ao menos um coordenador.
Coordenador de grupo pode alterar informações do grupo	media	Coordenador de grupo pode alterar descrição e outras informações do grupo*. O nome do grupo não pode ser alterado.
Coordenador do grupo pode incluir ou remover membros no grupo	alta	O coordenador do grupo pode incluir ou remover membros. Para inclusão, deve indicar se o novo membro tem status de Coordenador. A notificação sobre inclusão/remoção deve ser feita por email para outros coordenadores (se aplicável) e para usuários inseridos ou removidos do grupo.
Coordenador do grupo pode designar coordenador adicional	baixa	O coordenador do grupo pode tornar um membro comum Coordenador. A notificação sobre mudança de status deve ser feita por email para outros coordenadores (se aplicável), inclusive para o membro que se tornou coordenador.
Coordenador do grupo pode incluir ou remover membros no grupo em massa	alta	O coordenador do grupo pode incluir ou remover membros a partir de uma lista de emails. A notificação sobre inclusão/remoção deve ser feita por email para outros coordenadores (se aplicável) e para usuários inseridos ou removidos do grupo.
Coordenador pode gerar documento de autorização de acesso à sala do grupo	baixa	Um documento de acesso à sala do grupo é gerado, mostrando o nome do grupo, o nome do(s) Coordenador(es) do grupo, nomes dos membros do grupo (uma lista), data da geração do documento, e espaço para assinatura(s) do(s) Coordenador(es). O formato do documento pode ser editável (por exemplo, .odt, .doc) ou .pdf
Membro pode pedir para sair de grupo	baixa	Usuário que é membro de um grupo pode solicitar sua remoção de um grupo. Se o usuário for o único Coordenador do grupo, ele deve designar outro membro do grupo como Coordenador antes.
Usuários podem consultar informações de outros usuários	alta	Usuários podem consultar informações de outros usuarios no LDAP* (falta detalhar quais, não serão todas), incluindo email externo e nome completo, departamento ou curso, telefone (caso o usuário autorize), tipo do usuário (professor, aluno, convidado), se faz pesquisa, grupos aos quais pertence, dentre outros.
Usuário pode alterar suas informações no LDAP	media	Usuário pode editar suas informações pessoais, incluindo nome completo, email externo e telefone (pode escolher se deve ser público ou não).
O Sistema deve permitir busca por nome ou email externo	media	O coordenador pode não saber o login do aluno e pesquisar a partir do nome ou email externo no LDAP*. Os resultados retornados devem ser apresentados mostrando login, nome completo, email externo; o nome do usuário deve ser um link para página de detalhes do usuário.
Usuário pode buscar por grupos	baixa	O Usuário pode listar todos os grupos ou utilizar algum critério para realizar a busca, como um termo no nome ou na descrição do grupo. Os resultados retornados devem ser apresentados mostrando o nome do grupo; o nome do grupo deve ser um link para sua página de detalhes.
Usuário pode ver página de detalhes do grupo	baixa	Usuário interessado em determinado grupo pode ver detalhes do grupo. Os resultados retornados devem ser apresentados mostrando nome do grupo, coordenador(es), descrição e uma lista de membros.
Usuário vê informações de seu(s) grupo(s) ao ser identificado no Sistema	alta	Após sua identificação no Sistema, o usuário vê os nomes do grupos dos quais ele é membro, com uma indicação de quais grupos ele é coordenador. Os grupos dos quais ele é coordenador devem ter prioridade na listagem e os outros devem ser em ordem alfabética.

Informações

• Sobre Grupo: nome, nome completo, descrição, website, email, coordenadores, membros
• Sobre Membro (ver LDAP do DCC)

Motivações:

As principais motivações são:

• Os grupos de pesquisa do DCC possuem ferramentas disponíveis para os membros, porém o controle dos membros no sistema (syncgroups2/LDAP) é feito de maneira arcaica (através de membresia em listas de discussão e atualizado a partir de scripts).
• O syncgroups2 tem suporte ao conceito de grupos e isto é utilizado no controle das ferramentas, de acordo com o ldap.
• Mesmo os alunos que fazem pesquisa sem participar de grupos reconhecidos no CNPQ possuem serviços adicionais, que são controlados a partir de atributos (mas que são sincronizados da mesma forma arcaica).
• Depois da desativação do drupal do DCC não há nenhuma interface amigável para alteração das informações dos usuarios (ele não pode trocar o nome completo, se estiver errado ou trocar o nome de caixa alta para somente iniciais maiúsculas, nem trocar email externo ou telefone).
• Com uma interface amigável, mesmo os professores sem grupos no CNPQ poderiam ter "grupos virtuais" no sistema e toda a infra-estrutura de suporte se basearia nas informações presentes no sistema.

As principais mudanças seriam:

• alterar a membresia de uma pessoa teria efeito imediato no sistema (em vez de atualizar diariamente).
• os alunos que fazem iniciação científica ou fazem parte dos grupos de pesquisa do DCC seriam cadastrados pelos próprios responsáveis (sem atrasos e o aluno cobraria diretamente a ele)
• a membresia nos grupos ficaria mais fácil de estar correta (os membros antigos dos grupos podem continuar nas listas e os atuais podem usar o email externo e ainda assim os antigos não estariam com privilégios e os atuais teriam, o que é o oposto do que ocorre hoje com membros antigos e pessoas que se inscrevem com o email externo nas listas, já que somente emails do DCC são utilizados para sincronizar os grupos).
• as listas de acesso às salas seriam alteradas mais facilmente (incluindo o LInC?).

Como o syncgroups2 é feito em Ruby, o sistema em Rails, e as disciplinas possuem "grupos unix" no syncgroups2 (incluindo PF1 e PF2), o sistema abriria caminhos para o desenvolvimento de novas funcionalidades: como automatizar o cadastro de alunos e professores no Sistema de Submissões de Projeto Final (SSPF), controlar quotas de arquivos e impressão, possibilitar o acesso às salas a partir de um sistema web (em vez de listas e assinaturas).

---

• Links sobre LDAP + Ruby:
  • http://www.activeldap.com/
• Estórias de usuário - http://www.agilemodeling.com/artifacts/userStory.htm
• sgg.tar.gz: código-fonte com primeira estória (criação de grupos) implementada
  • ver também: vídeo da aula #3

• LabEngenharia(Estorias).dia: Arquivo com as estorias do SGG. Precisa ver as correlações

• LabEngenharia(Estorias)-020609.dia: Aula de 2 de junho.

• LabEngenharia(Estorias)-020609.dia: Aula de 2 de junho.

Cronograma do projeto

objetivos da aula de hoje:

• verificar o que foi feito até agora/tirar dúvidas
• definir uma versão única para trabalharmos a partir daqui
• dividir 1 ou 2 estórias pra cada equipe para a próxima iteração

cronograma ======

30/06:

   trazer feitas 2 estorias para todas as equipes (incluir membro/login)
   anexar código no wiki até o dia 29/06 23:59
      sgg-${fulano}-${sicrana}.tar.gz (tarball)
      ou
      sgg-${fulano}-${sicrana}.diff.gz (patch em relação ao svn)
   apresentar rodando (5 minutos/equipe)
   escolher uma versão definitiva
   dividir o restante das estorias

07/07:

   aula - projeto de interface; utilizando o propria projeto como estudo de caso

14/07:

   até 13/07 23:59, tem que estar no svn as 2 estorias por equipe feitas
   cada equipe apresenta as suas estorias

21/07:

   resultado final

Primeira versão de cada equipe

anexe aqui!!!

• sgg-fernanda-fernando.tar.gz: sgg Fernanda Fonseca e Fernando Barbosa

• IsaqueMauricio.tar.gz: Última Versão do Trabalho