관리 모델 구조화

대부분의 경우 도메인 대신 교육기관 계층 기능을 사용하는 것이 좋습니다. 교육기관 계층 기능을 사용하면 다른 Learn 기능을 더 잘 활용할 수 있으며 사용자 지정 규칙을 기반으로 하는 로직이 필요하지 않습니다.

도메인을 사용할 때 가장 중요한 부분은 교육기관의 구조적 요구와 일치하는 관리 모델을 개발하는 것입니다. 이 주제에서는 교육기관의 관리 요구에 대해 생각해 보는 과정을 안내합니다. 단계별 질문과 함께 간략한 예제가 나와 있습니다.

이를 통해 관리 모델을 생각해 볼 수 있습니다. 도메인의 유연성과 무제한 시스템 역할을 통해 각 교육기관에 일치하는 고유한 솔루션을 구현할 수 있습니다.


도메인 관리가 필요한 캠퍼스의 그룹화

위임 관리 모델을 설정하는 첫 번째 단계는 교육기관에서 해당 도메인에 대해 제한된 권한이 있는 위임 관리자가 지원할 수 있는 그룹을 정의하는 것입니다. 도메인에서는 사용자, 코스, 조직, 탭 및 모듈의 모든 조합을 포함할 수 있으므로 다양한 도메인 구조에는 제한이 없습니다. 일부 교육기관에서는 도메인을 사용하여 학생, 교직원, 동문 및 스탭 간에 사용자 관리를 분리하도록 선택할 수 있습니다. 하나의 동일한 교육기관에서 도메인을 사용하여 학과 간에 코스 관리를 분리할 수 있습니다. 하나의 동일한 교육기관에서 두 모델을 모두 적용하는 것도 가능하며 학과 도메인 관리자는 각 부서의 사용자를 컨트롤할 수 있습니다. 또한 각 부서는 별도의 도메인으로 나눌 수 있습니다. 예를 들어 한 도메인은 탭 및 모듈 콘텐츠를 관리하는 데 사용할 수 있는 반면, 다른 도메인은 코스를 관리하고 사용자를 처리하는 데 계속해서 사용할 수 있습니다.

도메인은 유연성을 갖추고 있으므로 도메인을 생성하고 관리 권한을 할당하기 전에 명확한 교육목표 및 조직을 정의해야 합니다. 그렇지 않으면 도메인을 필요에 따라 생성하는 경우 결과적으로 시스템을 정의하고 감독하기 어려워질 수 있습니다. 도메인이 필요한 캠퍼스 그룹을 정의할 때 다음 질문을 고려하십시오.

  • 교육기관을 어떻게 구성 및 관리하고 있습니까? 기능 그룹마다 도메인을 생성하는 것이 적절합니까? 학과를 넘어서는 이 질문을 고려하여 학습 사명을 지원하는 캠퍼스 그룹에 대해 생각해 보십시오.
  • Blackboard Learn 내에서 사용자를 정의할 때 교육기관 역할은 어떻게 사용됩니까? 예를 들면 사용자를 전공, 위치, 학습 연도 또는 다른 변수에 따라 구성합니까?
  • 교육기관에서 개인은 어떻게 관리합니까? 다양한 사용자 세트는 각각의 기능 그룹에서 관리합니까? 예를 들면 동문 관계를 담당하는 동문 사무실이 있습니까? 예비 학생을 담당하는 입학 부서가 있습니까?
  • 탭 및 모듈에 표시되는 콘텐츠를 담당하는 책임자는 누구입니까? 콘텐츠를 볼 수 있는 사람을 정의하는 데 사용하는 교육기관 역할은 무엇입니까?
  • Blackboard Learn과의 공유 데이터를 담당하는 다른 정보 시스템이 있습니까?

캠퍼스 그룹에는 위임 관리가 필요한 하위 그룹이 있을 가능성이 높습니다. 하위 그룹은 도메인 안에 도메인으로 중첩될 수 없지만 이는 도메인의 계층 구조를 생성하는 데 있어 문제가 되지는 않습니다. 도메인은 컬렉션으로 구성되고 단위 조직(예: 코스 또는 사용자)은 여러 컬렉션에 나타날 수 있으므로 다른 도메인의 하위 그룹으로 구성되는 도메인을 쉽게 정의할 수 있습니다. 적절한 조직을 유지하려면 더 큰 도메인을 포함하는 도메인에 대한 명명 규칙을 개발해야 합니다. 예를 들면 인문대학에는 학과의 여러 하위 도메인이 있을 수 있습니다.

도메인은 다음 명명 규칙을 따를 수 있습니다.

SLA - 인문대학

SLA_HISTORY - 인문대학 역사학과

SLA_ANTHRO - 인문대학 인류학과

SLA_LANGUAGES - 인문대학 언어학과

SLA_LANGUAGES_FRENCH - 인문대학 언어학과 프랑스어 코스


각 도메인이 정의되는 방식

각 도메인은 사용자, 코스, 조직, 탭 및 모듈 세트를 생성하기 위한 기준을 할당하여 정의합니다. 각 세트를 컬렉션이라고 합니다. 한 도메인에서는 컬렉션 하나 또는 여러 개를 포함할 수 있습니다. 도메인 구조를 정의하고 나면 사용자 및 코스 같은 항목을 도메인 내 컬렉션으로 그룹화합니다. 컬렉션을 추가하는 것은 포함해야 하는 모든 항목을 망라하는 방법으로 컬렉션을 정의하는 과정에 해당합니다. 사용자 또는 코스 같은 새 항목을 시스템에 추가하면 자동으로 컬렉션 조건을 충족하는 모든 도메인에 속하게 됩니다. 이러한 이유로, 새 항목을 생성했을 때 이를 컬렉션에 추가하려면 컬렉션을 정의할 때 컬렉션에 속하는 항목을 결정하는 조건과 규칙을 사용해야 합니다. 항목을 각각 추가하는 옵션이 있습니다. 항목을 각각 추가하는 기능은 다른 항목이 도메인에 속하게 되지 않도록 하여, 제한적이고 정적인 도메인을 정의하는 데 유용합니다.

교육기관 역할에 해당하는 모델과 코스 및 조직 카테고리에 해당하는 모델을 먼저 설정한 후에 도메인을 정의하는 것이 훨씬 수월합니다. 이러한 변수는 완전히 사용자정의할 수 있으며 도메인 내 컬렉션을 정의할 수 있는 가장 유연하고 정확한 방법으로 사용합니다. 스냅샷을 사용하여 Blackboard 데이터베이스를 다른 시스템의 데이터로 채우는 교육기관에서는 데이터 소스 키로도 컬렉션을 정의할 수 있습니다.

최종적으로 도메인과 코스 및 조직의 사용자 간에는 아무런 관계도 없습니다. 다시 말해, 코스에 등록된 사용자는 자동으로 도메인에 포함되는 것이 아닙니다. 도메인 내에서 등록은 코스에서 컨트롤합니다. 그러므로 사용자를 수정할 수 있는 권한이 있는 도메인 관리자는 코스의 사용자 등록을 변경하지 못할 수 있습니다. 그러나 코스 등록을 수정할 수 있는 권한이 있는 도메인 관리자는 사용자를 코스에 포함하거나 코스에서 제외할 수 있습니다.

컬렉션을 정의할 때 고려해야 할 사항은 다음과 같습니다.

코스 및 조직

  • 이 도메인에서 코스 및 조직을 정의하는 데 사용할 수 있는 카테고리는 무엇입니까?
  • 아니면 또는 카테고리에 더해 이 도메인에서 코스 및 조직을 정의하는 데 어떤 데이터 소스 키를 사용할 수 있습니까?
  • 도메인에 사용 불가능한 코스 및 조직을 포함해야 합니까? 도메인에 비활성화된 코스 및 조직을 포함해야 합니까? 사용 불가능하고 비활성화된 상태는 주로 완료되고 아카이브를 위해 예약된 코스 및 조직을 표시하는 데 사용하기 때문에 이 항목은 중요한 고려 사항입니다.
  • 도메인의 코스 및 조직을 등록 옵션으로 제한해야 합니까(예: 학생이 스스로를 등록할 수 있는 코스)?
  • 도메인에 이미 포함되어 있는 카테고리에 카테고리를 중첩하는 경우에도 코스 및 조직 카테고리를 각각 추가해야 합니다.

사용자

  • 이 도메인에서 사용자를 정의하는 데 사용할 수 있는 교육기관 역할은 무엇입니까?
  • 아니면 또는 교육기관 역할에 더해 이 도메인에서 사용자를 정의하는 데 어떤 데이터 소스 키를 사용할 수 있습니까?
  • 사용자는 시스템 역할에 따라서도 정의할 수 있습니다. 그러나 사용자정의된 시스템 역할은 권한을 기반으로 할 가능성이 크기 때문에 대개는 모델 도메인에서 사용자를 정의하는 데 적합한 모델이 아닙니다. 시스템 역할은 게스트 또는 참관인 역할을 사용할 때 속성으로 가장 유용합니다.
  • 도메인에 사용 불가능한 사용자를 포함해야 합니까? 도메인에 비활성화된 사용자를 포함해야 합니까? 사용 불가능하고 비활성화된 상태는 주로 사용자 기록을 아카이브 또는 제거로 표시하는 데 사용하기 때문에 이 항목은 중요한 고려 사항입니다.
  • 도메인의 사용자를 개인 정보 보호 옵션으로 제한해야 합니까? 사용자 디렉토리에서 배제된 사용자는 도메인에서 제외할 수 있습니다.

탭 및 모듈

  • 도메인에 사용 불가능한 탭 및 모듈을 포함해야 합니까? 이는 사용자가 탭 및 모듈을 생성할 수 있지만 항목이 게시된 후에는 수정할 수 없도록 하는 방법입니다. 아니면, 도메인에 사용 가능한 자료만 포함할 수 있습니다. 이 경우 프로덕션에 있는 사용 불가능한 자료는 도메인 관리자가 수정할 수 없습니다.
  • 탭 및 모듈을 도메인에 포함하도록 각각 선택할 수 있습니다.

예를 들면 부서에서 제공하는 모든 코스 및 부서에서 작업하거나 학습 전공으로 언어를 표시한 모든 사용자를 포함하는 코스 및 사용자 컬렉션으로 SLA_LANGUAGES 도메인을 채운다고 가정합니다. 이 경우 코스 컬렉션은 다음과 같이 정의할 수 있습니다.

범주: LANG, LANG_FR, LANG_DE, LANG_ES, LANG_JP, LANG_NL

사용 가능성: Ignore

활성화됨: 활성화 전용

사용자 컬렉션은 다음과 같이 정의할 수 있습니다.

교육기관 내 역할: DEPT_LANG, MAJOR_LANG

사용 가능성: 사용 가능 전용

활성화됨: 활성화 전용


도메인 관리자에게 필요한 관리자 작업

컬렉션을 정의한 후에는 시스템 역할에 적절한 권한을 확실하게 할당할 수 있습니다. 도메인 관리자는 해당 도메인에만 적용되는 시스템 역할을 기반으로 권한을 부여받습니다. 기본적으로, 사용자 및 시스템 역할은 결합되어 시스템 역할에 따라 정의된 권한으로 도메인의 위임 관리자를 생성합니다. 이러한 사용자 및 시스템 역할의 조합은 해당 도메인에서만 적용합니다.

도메인마다 시스템 역할을 생성할 수 있지만 각 도메인의 관리자에게 적용할 수 있는 권한에 따라 시스템 역할을 생성하는 것이 더 효율적입니다. 시스템 역할은 도메인에 추가되므로 전적으로 작업에 따라 시스템 역할 모델을 생성한 다음 이러한 작업의 조합을 사용하여 개별화된 권한을 특정 위임 관리자에게 부여할 수 있습니다.

시스템 역할을 생성할 때 고려해야 할 사항은 다음과 같습니다.

  • 도메인 관리자가 사용할 관리 작업은 무엇입니까?
  • 이러한 작업을 수행하는 데 필요한 권한은 무엇입니까?
  • 각 권한 세트로 하나 이상의 교육목표를 달성하기 위해 해당 권한을 어떻게 그룹화할 수 있습니까? 세트에서 적용하지 못할 수도 있는 권한이 있습니까?
  • 시스템 역할의 이름은 어떻게 지정합니까? 명명 규칙은 쉽게 인식할 수 있고 권한 세트를 정의할 수 있는 것이어야 합니다.

예를 들면 USER_MANAGER라는 시스템 역할은 관리자 계정의 전체 권한으로 생성됩니다. 이렇게 하면 이 시스템 역할을 각 도메인에서 사용하여 도메인 관리자에게 도메인의 모든 사용자 계정을 관리할 수 있는 능력을 부여할 수 있습니다. 또 다른 시스템 역할인 USER_PASSWORD를 도메인 관리자에게 부여하여, 사용자가 사용자 비밀번호를 변경할 수는 있지만 사용자 기록에 대한 다른 세부 사항은 수정할 수 없도록 할 수 있습니다.

SLA_LANGUAGE 도메인에서는 부서 책임자에게 USER_MANAGER 역할을 부여할 수 있는 반면, 도메인의 보조자는 분실한 비밀번호 대체 요청에 응답할 수 있도록 USER_PASSWORD 시스템 역할을 할당할 수 있습니다.

시스템 역할은 추가 항목이라는 점에 유의하십시오. USER_PASSWORD 시스템 역할이 있는 사용자가 사용자 계정의 일부 특성을 수정할 수 있는 능력이 포함된 또 다른 시스템 역할을 부여받으면 두 시스템 역할이 모두 적용됩니다. 즉, 이 사용자는 사용자가 할당된 모든 시스템 역할의 권한을 모두 합친 권한을 갖습니다. 또한 사용자에게 기본 도메인에 할당한 관리 권한이 있는 시스템 역할이 있으면 이러한 권한은 모든 도메인과 시스템의 모든 데이터에 적용합니다.


도메인을 관리하도록 할당된 사용자

도메인은 하나의 시스템 역할을 가진 한 명의 관리자로 제한되지 않습니다. 정확히 말하면, 각 도메인에는 시스템 역할의 수에 제한이 없는 관리자가 무제한으로 있을 수 있습니다. 한 도메인에서 관리자마다 다양한 책임 및 작업을 할당할 수 있습니다.

사용자를 도메인 관리자로 할당할 때 고려해야 할 사항은 다음과 같습니다

  • 도메인 관리자를 필요로 하는 도메인의 특성은 무엇입니까?
  • 불필요하거나 잠재적으로 위험한 권한을 추가로 유발하지 않고 이러한 작업을 수행하기 위한 권한을 부여하는 특정 시스템 역할이 있습니까? 없다면 시스템 역할 구성을 변경하거나 예외적인 경우를 처리하도록 새 시스템 역할을 생성하십시오.
  • 필수 작업에 따라 도메인 관리자의 책임을 어떻게 구성해야 합니까? 관리자 하나는 사용자 관리에 필요하고 다른 관리자는 코스 할당에 필요합니까?
  • 서로 다른 도메인 관리자 위치에 누구를 할당해야 합니까?

도메인 관리자 역할의 개인과 적절한 권한을 부여할 시스템 역할을 식별한 후에는 마지막 단계로 이러한 정보를 모두 도메인 안에 넣어야 합니다. 예:

도메인: SLA_LANGUAGE

사용자: Department Head

시스템 역할: USER_MANAGER, COURSE_MANAGER, MODULE_CREATE, MODULE_MODIFY