A Blackboard recomenda a utilização dos recursos da Hierarquia institucional em vez de Domínios na maioria dos casos. A Hierarquia institucional possibilita a utilização mais completa das outras funções do Learn e não precisa da lógica com base em regras personalizadas.

A parte mais importante do uso de domínios é o desenvolvimento de um modelo de administração que corresponda às necessidades organizacionais da Instituição. Este tópico descreve o processo de reflexão sobre as necessidades administrativas da Instituição. Ele mostra as perguntas que devem ser feitas em cada estágio e um breve exemplo.

Lembre-se de que isto é uma ferramenta para ajudar no início da reflexão sobre o modelo de administração. A flexibilidade dos domínios e as funções ilimitadas do sistema geram a oportunidade de se obter soluções exclusivas apropriadas a cada instituição.

Quais são os agrupamentos no campus que exigem gerenciamento de domínio?

A primeira etapa para configurar um modelo de administração delegada é definir os grupos da Instituição que podem ser suportados pelos administradores delegados, com privilégios limitados a este domínio. Uma vez que os domínios podem incluir qualquer combinação de usuários, cursos, comunidades, guias e módulos, a estrutura dos diferentes domínios é ilimitada. Algumas Instituições podem optar por usar domínios para separar o gerenciamento dos usuários entre alunos, corpo docente, ex-alunos e equipe. As mesmas Instituições podem usar domínios para separar o gerenciamento dos cursos entre departamentos acadêmicos. As mesmas Instituições podem até aplicar os dois modelos e permitir que os administradores do domínio do departamento acadêmico controlem os usuários nos respectivos departamentos. Além disso, cada departamento pode ser dividido em domínios separados. Um domínio pode ser usado para gerenciar o conteúdo da guia e do módulo, enquanto outro gerencia cursos e outro ainda gerencia os usuários manipulados pelo domínio.

A flexibilidade dos domínios exige metas claras e organização, antes que sejam criados domínios e atribuídos privilégios administrativos. Do contrário, é provável que os domínios sejam criados conforme a necessidade, resultando em um sistema difícil de definir e supervisionar. Considere as perguntas a seguir quando definir os grupos do campus que exigem domínios:

  • Como a Instituição é organizada e gerenciada? Faz sentido criar domínios para cada grupo funcional? Considere esta pergunta não somente para departamentos acadêmicos, e pense nos grupos do campus que suportam a missão do aprendizado.
  • Como as funções na instituição são usadas para definir os usuários dentro do Blackboard Learn? Por exemplo, os usuários são organizados por graduação, local, ano de estudo ou outras variáveis?
  • Como são gerenciados os indivíduos da Instituição? Os diferentes conjuntos de usuários são gerenciados por grupos funcionais diferentes? Por exemplo, existe um escritório de ex-alunos que trata das relações de ex-alunos? O departamento de admissões é responsável pelos alunos prospectivos?
  • Quem é responsável pelo conteúdo que aparece nas guias e módulos? Quais funções na instituição são usadas para definir quem pode exibir o conteúdo?
  • Existem diferentes sistemas de informações responsáveis pelos dados compartilhados com o Blackboard Learn?

É muito provável que os agrupamentos do campus terão subagrupamentos que também exigem a administração delegada. Os subagrupamentos não podem ser aninhados como domínios dentro de um domínio, mas isto não impede a criação de uma estrutura hierárquica de domínios. Uma vez que os domínios são compostos por coleções e, que uma unidade como um curso ou usuário pode aparecer em várias coleções, é fácil definir domínios que consistam em um subgrupo de outro domínio. Para manter a organização adequada, desenvolva uma convenção de nomeação para domínios que incorporem os domínios maiores. Por exemplo, a Escola de Artes Liberais terá vários subdomínios prováveis para os departamentos acadêmicos.

Os domínios podem seguir a convenção de nomeação a seguir:

SLA – Escola de Artes Liberais

SLA_HISTORY – Departamento de História da Escola de Artes Liberais

SLA_ANTHRO – Departamento de Antropologia da Escola de Artes Liberais

SLA_LANGUAGES – Departamento de Idiomas da Escola de Artes Liberais

SLA_LANGUAGES_FRENCH – Cursos de francês, Departamento de Idiomas da Escola de Artes Liberais

Como cada domínio é definido?

Cada domínio é definido atribuindo critérios para criar conjuntos de usuários, cursos, comunidades, guias e módulos. Cada conjunto é chamado de coleção. Um domínio pode incluir uma ou muitas coleções. Assim que a estrutura do domínio é definida, os itens como os usuários e cursos são agrupados em coleções dentro do domínio. Adicionar as coleções é um processo para definir a coleção, de maneira a englobar cada item que deve ser incluído. Quando novos itens, como um usuário ou um curso, são adicionados ao sistema, eles automaticamente se tornam parte de qualquer domínio cujos critérios de coleção eles cumprem. Por isso, ao definir uma coleção, é importante usar os critérios e as regras para determinar os itens que se encaixam na coleção, a fim de garantir que novos itens sejam adicionados à coleção quando forem criados. É possível adicionar itens individualmente. A capacidade de adicionar itens individualmente é útil para definir os domínios que são limitados e estáticos, garantindo que nenhum outro item se torne parte do domínio.

É muito mais fácil definir domínios depois de configurar um modelo para as funções na instituição e um modelo para as categorias de curso e comunidade. Essas variáveis são completamente personalizáveis e servem como a maneira mais flexível e exata para definir coleções dentro de um domínio. As instituições que usam Instantâneos para preencher o banco de dados do Blackboard com dados de outros sistemas também podem usar chaves de fonte de dados para definir as coleções.

Por fim, não existe nenhuma relação entre os usuários de um domínio e os cursos e comunidades. Isto é, usuários matriculados em um curso não são incluídos automaticamente no domínio. Dentro de um domínio, as matrículas são controladas por cursos. Assim, o administrador de um domínio com privilégios para editar usuários não pode alterar as matrículas dos usuários em um curso. No entanto, o administrador de um domínio com privilégios para editar as matrículas no curso pode incluir ou excluir os usuários de um curso.

Ao definir as coleções, considere o seguinte:

Cursos e organizações

  • Quais categorias podem ser usadas para definir os cursos e comunidades neste domínio?
  • Como alternativa a (ou além das) categorias, quais chaves de fonte de dados podem ser usadas para definir os cursos e comunidades neste domínio?
  • O domínio deve incluir cursos e comunidades não disponíveis? O domínio deve incluir cursos e comunidades desativados? Esta é uma consideração importante, pois o status de não disponível e desativado é frequentemente usado para marcar cursos e comunidades que estão concluídos e programados para arquivamento.
  • Os cursos e comunidades no domínio devem ser limitados pelas opções de matrícula, por exemplo, cursos nos quais os alunos podem se matricular sozinhos?
  • As categorias de curso e comunidade devem ser adicionadas individualmente, mesmo se a categoria for aninhada em uma categoria que já está incluída no domínio.

Usuários

  • Quais funções na instituição podem ser usadas para definir os usuários neste domínio?
  • Como alternativa a (ou além das) funções na instituição, quais chaves de fonte de dados podem ser usadas para definir os usuários neste domínio?
  • Usuários também podem ser definidos por função do usuário administrativo. No entanto, é provável que as funções personalizadas do sistema sejam baseadas em privilégios, portanto geralmente não são um bom modelo para definir os usuários em um domínio. A função do usuário administrativo é muito útil como um atributo ao usar a função de convidado ou observador.
  • O domínio deve incluir os usuários não disponíveis? O domínio deve incluir os usuários desativados? Esta é uma consideração importante, pois o status de não disponível e desativado é frequentemente usado para marcar os registros de usuário para o arquivamento ou a remoção.
  • Os usuários no domínio devem ser limitados pelas opções de privacidade? Os usuários que optarem por sair do Diretório de usuário podem ser excluídos de um domínio.

Guias e módulos

  • O domínio deve incluir guias e módulos não disponíveis? Esta é uma maneira de permitir que os usuários criem guias e módulos, mas não os editem depois de publicados. Ou então, um domínio pode incluir somente os materiais disponíveis. Neste caso, os materiais não disponíveis que estão em produção não podem ser editados pelos administradores do domínio.
  • Guias e módulos podem ser selecionados individualmente para a inclusão em um domínio.

Por exemplo, considere preencher o domínio SLA_LANGUAGES com uma coleção de cursos e usuários que inclua todos os cursos oferecidos no departamento, e todos os usuários que trabalham no departamento ou que listam Idiomas como sua graduação. Neste caso, a coleção de cursos pode ser definida como:

Categorias: LANG, LANG_FR, LANG_DE, LANG_ES, LANG_JP, LANG_NL

Disponibilidade: Ignorar

Ativado: Apenas ativado

A coleção do usuário pode ser definida como:

Funções na instituição: DEPT_LANG, MAJOR_LANG

Disponibilidade: Apenas disponível

Ativado: Apenas ativado

Quais tarefas de administrador são exigidas para administradores de domínio?

Depois que as coleções foram definidas, é possível atribuir privilégios apropriados às funções do sistema de uma maneira confiável. Os privilégios são concedidos aos administradores de domínio com base em uma função do usuário administrativo que é aplicada apenas a este domínio. Essencialmente, as funções do usuário e do sistema são combinadas para criar um administrador delegado para o domínio, com os privilégios definidos pelas funções do sistema. Essa combinação de funções do usuário e do sistema se aplica apenas a este domínio.

As funções do sistema podem ser criadas para cada domínio, porém é mais eficiente criar funções do sistema com base em privilégios semelhantes, que podem ser aplicados a um administrador em cada domínio. Uma vez que as funções do sistema são aditivas no domínio, é possível criar um modelo de função do usuário administrativo completamente baseado em tarefas, e em seguida usar uma combinação dessas tarefas para conceder privilégios individualizados aos administradores delegados específicos.

Ao criar as funções do sistema, considere o seguinte:

  • Quais tarefas administrativas serão usadas pelos administradores de domínio?
  • Quais privilégios são necessários para realizar essas tarefas?
  • Como esses privilégios podem ser agrupados de forma que cada conjunto de privilégios cumpra uma ou mais metas? Existem privilégios no conjunto que nem sempre são aplicáveis?
  • Como as funções do sistema devem ser nomeadas? A convenção de nomeação deve ser de fácil reconhecimento e deve definir o conjunto de privilégios.

Por exemplo, uma função do usuário administrativo nomeada USER_MANAGER é criada com privilégios completos para contas de usuários gerentes. Esta função do usuário administrativo pode ser usada em cada domínio para conceder ao administrador a capacidade de administrar todas as contas de usuário no domínio. Outra função do usuário administrativo, USER_PASSWORD, pode ser concedida ao administrador do domínio para permitir que esse usuário altere a senha, mas não edite nenhum outro detalhe do registro.

No domínio SLA_LANGUAGE, o chefe de departamento pode receber a função USER_MANAGER, enquanto um assistente é atribuído à função do usuário administrativo USER_PASSWORD no domínio, para responder a solicitações de substituição de uma senha perdida.

Lembre-se de que as funções do sistema são aditivas. Se um usuário tiver a função do usuário administrativo USER_PASSWORD, e receber outra função que inclua a capacidade de editar algum aspecto das contas de usuário, ambas as funções se aplicam. Isto é, o usuário tem a soma de todos os privilégios de todas as funções do sistema que lhe foram atribuídas. Além disso, se o usuário tem funções do sistema com privilégios administrativos atribuídos no domínio padrão, esses privilégios se aplicam em todos os domínios e para todos os dados no sistema.

Quem são os usuários atribuídos para administrar o domínio?

Os domínios não são limitados a um administrador com uma função do usuário administrativo. Na verdade, cada domínio pode ter um número ilimitado de administradores com um número ilimitado de funções do sistema. Em um domínio, os diferentes administradores são atribuídos a responsabilidades e tarefas diferentes.

Ao atribuir usuários como administradores de domínio, considere o seguinte:

  • Quais aspectos do domínio exigem um administrador?
  • Existem funções específicas do sistema que concedem privilégios para realizar essas tarefas, sem introduzir privilégios adicionais desnecessários ou potencialmente arriscados? Se não, pense em revisar a construção de funções do sistema ou em criar uma nova função para cobrir o caso excepcional.
  • Como as tarefas exigidas formam as responsabilidades para os administradores de domínio? É necessário que um administrador gerencie usuários, enquanto outro é atribuído aos cursos?
  • Quem deve ser atribuído às diferentes posições do administrador de domínio?

Depois de identificar os indivíduos que servirão como administradores de domínio e as funções do sistema que concederão privilégios apropriados, a última etapa é reunir essas informações dentro do domínio. Por exemplo:

Domínio: SLA_LANGUAGE

Usuário: Chefe de departamento

Funções do sistema: USER_MANAGER, COURSE_MANAGER, MODULE_CREATE, MODULE_MODIFY