Saltar al contenido principal
pdf?stylesheet=default
Blackboard Help

Estructuración del modelo de administración

La parte más importante de utilizar dominios es desarrollar un modelo de administración que concuerde con las necesidades organizativas de la institución. Este tema describe el proceso por el que pueden determinarse dichas necesidades organizativas de la institución. Aquí se incluyen las preguntas que hay que plantearse a cada paso, junto con un pequeño ejemplo.

Recuerde que esta herramienta le sirve para empezar a plantearse su modelo de administración. La flexibilidad de los dominios y un número ilimitado de roles de sistema abren la posibilidad de crear soluciones únicas acordes a cada institución.

¿Cuáles son las agrupaciones del campus que necesitan administración de dominios?

El primer paso para configurar un modelo de administración delegada es definir los grupos de la institución que pueden recibir asistencia de administradores delegados con privilegios limitados para ese dominio. Como los dominios pueden incluir cualquier combinación de usuarios, cursos, organizaciones, fichas y módulos, la estructura de los distintos dominios es ilimitada. Algunas instituciones pueden elegir usar dominios para diferenciar la administración de usuarios según sean alumnos, personal docente, licenciados y personal. Las mismas instituciones pueden utilizar dominios para diferenciar la administración de los cursos según los departamentos académicos. Las mismas instituciones pueden incluso aplicar ambos modelos, otorgando a los administradores de dominios de departamentos académicos control sobre usuarios de sus respectivos departamentos. Además, cada departamento podría dividirse en distintos dominios. Un dominio podría utilizarse para administrar el contenido del módulo y la ficha, mientras que otro podría administrar cursos y otro gestionar los usuarios.

La flexibilidad de los dominios exige que haya una organización y objetivos claros antes de crear los dominios y asignar privilegios administrativos. De lo contrario, es muy probable que los dominios se crearan según necesidad, lo que generaría un sistema difícil de definir y supervisar. Cuando vaya a definir los grupos del campus que necesitan dominios, tenga en cuenta las siguientes cuestiones:

  • ¿Cómo está organizada y administrada la institución? ¿Es lógico crear dominios para cada grupo funcional? Considere esta pregunta más allá de los departamentos académicos y piense en los grupos del campus que colaboran en la misión de la enseñanza.
  • ¿Cómo se utilizan los roles institucionales para definir usuarios en Blackboard Learn? Por ejemplo, ¿los usuarios se organizan por especialidad, ubicación, año de estudio o alguna otra variable?
  • ¿Cómo se administran los individuos de la institución? ¿Hay grupos funcionales distintos que se encarguen de la administración de cada conjunto de usuarios? Por ejemplo, ¿hay una oficina de ex-alumnos que gestione las relaciones con los antiguos alumnos? ¿Es el departamento de admisiones el responsable de los futuros alumnos?
  • ¿Quién está a cargo del contenido que aparece en las fichas y módulos? ¿Cómo se utilizan los roles institucionales para definir quién puede visualizar el contenido?
  • ¿Hay diferentes sistemas de información que sean responsables de los datos compartidos con Blackboard Learn?

Es muy probable que los grupos del campus tengan subgrupos que también necesiten de una administración delegada. Los subgrupos no pueden anidarse como dominios dentro de otro dominio, aunque esto no impide que se cree una estructura jerárquica de dominios. Como los dominios se componen de recopilaciones y una unidad, como un curso o un usuario, puede aparecer en múltiples recopilaciones, resulta fácil definir dominios que se componen de un subgrupo de otro dominio. Para mantener una organización adecuada, es importante desarrollar una convención de nombres de dominios que incluya a los dominios de mayor tamaño. Por ejemplo, la Facultad de Filosofía y Letras podría tener varios subdominios para cada departamento académico.

Los dominios podrían seguir esta convención de nomenclatura:

FFL – Facultad de Filosofía y Letras

FFL_HISTORIA – Departamento de Historia, Facultad de Filosofía y Letras

FFL_ANTROP – Departamento de Antropología, Facultad de Filosofía y Letras

FFL_FILOLOGÍA – Departamento de Filología, Facultad de Filosofía y Letras

FFL_FILOLOGÍA_FRANCÉS – Enseñanza de francés, Departamento de Filología, Facultad de Filosofía y Letras

¿Cómo se define cada dominio?

Cada dominio se define asignando criterios para crear conjuntos de usuarios, cursos, organizaciones, fichas y módulos. Cada conjunto se denomina recopilación. Un dominio puede incluir una o más recopilaciones. Una vez que se defina la estructura de dominio, los elementos como, por ejemplo, usuarios y cursos, se agrupan en colecciones dentro del dominio. El proceso de añadir recopilaciones se basa en definir la recopilación de forma que abarque todos los elementos que debería incluir. Cuando se añade un nuevo elemento al sistema, como un usuario o un curso, este se convierte automáticamente en parte de cualquier dominio cuyos criterios de recopilación cumpla. Por este motivo, es importante que cuando se defina una recopilación se utilicen criterios y reglas que determinen qué elementos pueden entrar en ella, así los nuevos elementos se añadirán a la recopilación a medida que se creen. También hay una opción para añadir los elementos de forma individual. La capacidad de añadir elementos individualmente resulta útil para definir dominios que son limitados y estáticos, asegurando que ningún otro elemento forme parte del dominio.

Resulta mucho más sencillo definir dominios tras haber configurado por primera vez un modelo de roles institucionales y otro modelo para las categorías de curso y organización. Estas variables son totalmente personalizables y constituyen la forma más flexible y precisa de definir las recopilaciones de un dominio. Las instituciones que utilizan Instantánea para rellenar la base de datos de Blackboard con datos de otros sistemas también pueden utilizar las claves de orígenes de datos para definir las colecciones.

Por último, no hay relación entre los usuarios de un dominio y los cursos y organizaciones. Es decir, los usuarios inscritos en un curso no se incluyen automáticamente en el dominio. Dentro de un dominio, las inscripciones se controlan mediante los cursos. Así, un administrador de dominios con privilegios para editar usuarios no podrá modificar las inscripciones de los usuarios en un curso. Sin embargo, un administrador de dominios con privilegios para editar inscripciones en un curso podrá incluir o excluir usuarios de un curso.

Cuando vaya a definir recopilaciones, tenga en cuenta lo siguiente:

Cursos y organizaciones

  • ¿Qué categorías pueden utilizarse para definir los cursos y organizaciones de este dominio?
  • Además de las categorías o paralelamente a ellas, ¿qué claves de orígenes de datos pueden utilizarse para definir los cursos y organizaciones de este dominio?
  • ¿Debe incluir el dominio cursos y organizaciones no disponibles? ¿Debe incluir el dominio cursos y organizaciones desactivados? Es importante tener en cuenta este punto puesto que el estado de no disponible y desactivado se suele usar para marcar cursos y organizaciones que están completos y programados para archivo.
  • ¿Deberían limitarse los cursos y organizaciones del dominio en función de las opciones de inscripción, por ejemplo, los cursos en los que los alumnos pueden inscribirse ellos mismos?
  • Las categorías de curso y organización deben añadirse individualmente, incluso si la categoría está anidada en una categoría que ya se ha incluido en el dominio.

Usuarios

  • ¿Qué roles institucionales pueden utilizarse para definir los usuarios de este dominio?
  • Además de los roles institucionales o paralelamente a ellos, ¿qué claves de orígenes de datos pueden utilizarse para definir los usuarios de este dominio?
  • Los usuarios también pueden definirse por rol del sistema. Sin embargo, es más probable que los roles del sistema personalizados se basen en privilegios, por lo que no suelen ser un buen modelo para definir a los usuarios de un dominio. El rol del sistema resulta más útil como atributo cuando se utiliza el rol de invitado o de observador.
  • ¿Debe incluir el dominio usuarios no disponibles? ¿Debe incluir el dominio a los usuarios desactivados? Esta cuestión es importante ya que el estado de no disponible y el de desactivado se utilizan a menudo para marcar los registros de usuarios que deben archivarse o eliminarse.
  • ¿Deben los usuarios del dominio estar limitados por las opciones de privacidad? Los usuarios que salgan del directorio de usuarios pueden excluirse de un dominio.

Fichas y módulos

  • ¿Debe incluir el dominio las fichas y módulos no disponibles? Es una forma de permitir a los usuarios crear fichas y módulos, pero no editarlos una vez que se han publicado. Además, un dominio puede incluir solo lo materiales disponibles. En este caso, los administradores de dominio no podrán editar el material no disponible que esté en producción.
  • Las fichas y módulos pueden seleccionarse individualmente para incluirlos en un dominio.

Por ejemplo, puede considerar incluir en el dominio FFL_FILOLOGIA una recopilación de cursos y usuarios que incluya todos los cursos ofrecidos por el departamento y todos los usuarios que trabajen en él, o bien enumerar los idiomas en función de su especialidad de estudio. En este caso, la recopilación de cursos podría definirse como:

Categorías: FILOL, FILOL_FR, FILOL_AL, FILOL_IN, FILOL_JP, FILOL_NL

Disponibilidad: Ignorar

Activado: Solo activado

La recopilación de usuarios podría definirse:

Roles institucionales: DEPT_FILOL, DIRECTOR_FILOL

Disponibilidad: Solo disponible

Activado: Solo activado

¿Qué tareas administrativas son necesarias para los administradores de dominio?

Después de definir las colecciones, se pueden asignar con seguridad los privilegios apropiados a cada rol del sistema. Los administradores de dominio reciben privilegios en función de un rol del sistema que se aplica únicamente a ese dominio. Básicamente, el usuario y el rol del sistema (o roles del sistema) se combinan para crear un administrador delegado para el dominio con los privilegios definidos por los roles del sistema. Esa combinación de usuario y roles del sistema solo se aplica en ese dominio.

Los roles del sistema pueden crearse para cada dominio, pero resulta más eficaz crear los roles del sistema en función de privilegios de iguales que puedan aplicarse a un administrador de cada dominio. Como los roles del sistema son acumulativos en un dominio, es posible crear un modelo de roles del sistema que se base completamente en tareas y utilizar a continuación una combinación de esas tareas para otorgar privilegios individualizados a administradores delegados específicos.

Durante la creación de roles del sistema, se debe tener en cuenta:

  • ¿Qué tareas administrativas usarán los administradores de dominio?
  • ¿Qué privilegios son necesarios para realizar estas tareas?
  • ¿Cómo pueden agruparse estos privilegios para que cada conjunto de privilegios cumpla uno o más objetivos? ¿Hay algún privilegio que no se aplicará siempre en el conjunto?
  • ¿Cómo deben denominarse los roles del sistema? La convención de nomenclatura debe reconocerse fácilmente y definir el conjunto de privilegios.

Por ejemplo, se crea un rol del sistema denominado USUARIO_ADMINISTRADOR con todos los privilegios para gestionar cuentas de usuarios. Este rol del sistema podrá utilizarse en cada dominio para otorgar a un administrador de dominios la capacidad de administrar todas las cuentas de usuario del dominio. Es posible otorgar otro rol del sistema, USUARIO_CONTRASEÑA, a un administrador de dominios para permitir a ese usuario cambiar la contraseña de los usuarios, pero no modificar otros detalles sobre el registro del usuario.

En el dominio FFL_FILOLOGIA, el director del departamento puede contar con el rol USUARIO_ADMINISTRADOR, mientras que su asistente recibiría el rol del sistema USUARIO_CONTRASEÑA en el dominio para responder a las solicitudes de cambio de contraseña perdida.

Recuerde que los roles del sistema son acumulativos. Si un usuario tiene el rol del sistema USUARIO_CONTRASEÑA, y recibe otro rol del sistema que incluya la posibilidad de modificar algún aspecto de las cuentas de usuario, se aplicarán ambos roles del sistema. Es decir, el usuario contará con la suma de todos los privilegios de todos los roles del sistema que se le han asignado. Además, si el usuario tiene roles del sistema con privilegios administrativos asignados en el dominio predeterminado, estos privilegios se aplicarán en todos los dominios y para todos los datos del sistema.

¿Quiénes son los usuarios asignados para administrar el dominio?

Los dominios no se limitan a un administrador con un rol del sistema. En vez de ello, cada dominio puede tener un número ilimitado de administradores con un número ilimitado de roles del sistema. En un dominio, los distintos administradores tienen asignadas distintas responsabilidades y tareas.

Cuando asigne usuarios como administradores de dominio, tenga en cuenta lo siguiente:

  • ¿Qué aspectos del dominio necesita un administrador de dominios?
  • ¿Hay roles del sistema específicos que otorguen privilegios para realizar estas tareas sin introducir privilegios innecesarios o potencialmente peligrosos? En caso negativo, considere la posibilidad de revisar la construcción de los roles del sistema o crear un nuevo rol del sistema para cubrir ese caso excepcional.
  • ¿Cómo forman las tareas necesarias las responsabilidades de los administradores de dominio? ¿Hay un administrador a cargo de la administración de usuarios, mientras que a otro se le han asignado los cursos?
  • ¿A quién deben asignarse las diferentes posiciones de administrador de dominio?

Una vez que se identifica a los individuos que trabajarán como administradores de dominio y los roles del sistema que otorgarán los privilegios adecuados, el último paso es reunir esa información en el dominio. Por ejemplo:

Dominio: FFL_FILOLOGIA

Usuario: Director de departamento

Roles del sistema: ADMINISTRADOR_USUARIOS, ADMINISTRADOR_CURSOS, CREAR_MODULOS, MODIFICAR_MODULOS