メインコンテンツまでスキップ
pdf?stylesheet=default
Blackboard Help

管理モデルの構成

ドメイン使用の最も重要な部分は、教育機関の組織・グループのニーズに一致する管理モデルを開発することです。このトピックでは、教育機関の管理上のニーズを考えるプロセスを説明していきます。各段階には質問と簡単な例が含まれています。

これは管理モデルを考え始めるにあたっての役立つツールであることに留意してください。ドメインの柔軟性、および無制限のシステム担当により、各教育機関に合う一意なソリューションを作成できます。

ドメイン管理が必要なキャンパスでのグループ化とは

権限委譲可能な管理モデルをセットアップする最初の手順は、そのドメインに制限された権限のある権限委譲可能な管理者によってサポートされる教育機関でのグループを定義することです。ドメインには、ユーザ、コース、組織・グループ、タブ、およびモジュールの任意の組み合わせを含めることができるので、異なるドメイン構造を無限に作成できます。たとえば、学生、教職員、卒業生、およびスタッフ間でユーザの管理を分けるためにドメインの使用を選択した教育機関が、アカデミック部門間でのコース管理を分けるためにドメインを使用することができます。また、同じ教育機関が両方のモデルを適用して、アカデミック部門のドメイン管理者に、それぞれの部門のユーザを制御させることもできます。さらに、各部門は異なるドメインに分割することができます。1つのドメインはタブとモジュールコンテンツの管理に使用し、別のドメインはコースの管理に使用し、別のドメインではユーザを扱うことができます。

ドメインの柔軟性には、ドメインを作成し、管理権限を割り当てる前に、明確な目標と組織・グループが必要になります。そうしないと、ドメインが必要に応じて作成され、定義および監視の難しいシステムになってしまう可能性があります。ドメインが必要なキャンパスにグループを定義するときには、以下の質問を検討してください。

  • 教育機関はどのように構成され、管理されているか。各機能グループにドメインを作成する必要があるか。アカデミック部門の域を超えてこの質問を検討し、ラーニングミッションをサポートするキャンパスのグループについて考えてください。
  • Blackboard Learn内のユーザの定義に、教育機関での担当がどのように使用されているか。たとえば、ユーザは専攻、場所、学年、または他の変数で構成されているか。
  • 教育機関での個人はどのように管理されているか。異なるユーザグループが、異なる機能グループで管理されているか。たとえば、卒業生の関係を専門に扱うオフィスがあるか。承認部門が受講予定者の管理を担当しているか。
  • タブおよびモジュールに表示されるコンテンツの責任者は誰か。コンテンツを表示できるユーザの定義に、どの教育機関での担当を使用しているか。
  • Blackboard Learnでのデータ共有管理を異なる情報システムで行っているか。

キャンパスでのグループ化には、やはり権限委譲可能な管理が必要なサブグループ化を伴うことがよくあります。サブグループはドメイン内のドメインとしてネストすることはできませんが、これはドメインの階層構造の作成の障害にはなりません。ドメインは、コレクション、およびコースまたはユーザなどの単位で構成されているので、複数のコレクション内で表示可能です。他のドメインのサブグループから成るドメインは容易に定義できます。適切な組織・グループを維持するには、大きなドメインを組み込むドメインのための命名規則を作成します。たとえば、リベラルアーツスクールには、アカデミック部門用に複数のサブドメインがあることがよくあります。

ドメインは次の命名規則に従うことができます。

SLA – リベラルアーツスクール

SLA_HISTORY – 歴史部門、リベラルアーツスクール

SLA_ANTHRO – 人類学部門、リベラルアーツスクール

SLA_LANGUAGES – 言語部門、リベラルアーツスクール

SLA_LANGUAGES_FRENCH – フランス語コース、言語部門、リベラルアーツスクール

各ドメインはどのように定義されているか

各ドメインは、ユーザ、コース、組織・グループ、タブ、およびモジュールのセットを作成するために、基準を割り当てることで定義されます。各セットはコレクションと呼ばれます。ドメインには1つまたは複数のコレクションを含めることができます。ドメイン構造が定義されると、ユーザやコースなどの項目がドメイン内のコレクションにグループ化されます。コレクションの追加は、含める必要があるすべての項目を含めるためのコレクション定義の1プロセスです。ユーザまたはコースなどの新規項目がシステムに追加されると、それらは自動的にコレクションの基準を満たす任意のドメインの一部となります。このため、コレクションに分類される項目を決めるための基準およびルールを使用するためにコレクションを定義するときには、新規項目は作成時にコレクションに追加するようにすることが重要になります。また、項目を個々に追加するオプションもあります。項目を個々に追加できる機能は、制限があり固定されているドメインの定義に役立ちます。この機能により、他の項目がそのドメインの一部になるのを防げます。

まず、教育機関での担当のためのモデル、およびコースと組織・グループカテゴリのためのモデルをセットアップしてから、ドメインを定義するほうが簡単です。これらの変数は、完全にカスタマイズ可能で、ドメイン内コレクションを定義する最も柔軟で正確な方法として使用できます。Blackboardデータベースに他のシステムからのデータを格納するためにスナップショットを使用する教育機関では、データソースキーを使用してコレクションを定義することもできます。

最後に、ドメイン内のユーザと、コースおよび組織・グループの間に関係はありません。つまり、コースに登録されたユーザは、ドメインに自動的に含まれないということです。ドメイン内では、登録はコースによって制御されます。そのため、ユーザを変更する権限があるドメイン管理者は、コース内でユーザの登録を編集しないことがあります。ただし、コース登録を編集する権限があるドメイン管理者が、コースからユーザを含めたり、除外したりすることがあります。

コレクションを定義するときには、以下の点を検討してください。

コースおよび組織・グループ

  • このドメイン内のコースおよび組織・グループの定義にどのカテゴリを使用できるか。
  • カテゴリの代わり、またはカテゴリに加えて、このドメイン内のコースおよび組織・グループの定義にどのデータソースキーを使用できるか。
  • ドメインに利用不可なコースおよび組織・グループを含めるべきか。ドメインに無効なコースおよび組織・グループを含めるべきか。利用不可および無効ステータスは、完了およびアーカイブにスケジュールされたコースや組織・グループをマークするのによく使用されるので、これは重要な考慮点です。
  • ドメイン内のコースおよび組織・グループを登録オプションで限定するべきか。たとえば、学生自身が登録することのできるコース。
  • コースおよび組織・グループカテゴリは、個々に追加する必要があります。そのカテゴリが、ドメインにすべてに含まれているカテゴリにネストされているとしても同じです。

ユーザー

  • このドメイン内のユーザの定義にどの教育機関での担当を使用できるか。
  • 教育機関での担当の代わり、または教育機関での担当に加えて、このドメイン内のユーザの定義にどのデータソースキーを使用できるか。
  • ユーザはシステム担当によって定義することもできますが、カスタマイズされたシステム担当は権限を基にしている場合が多いため、通常はドメイン内のユーザ定義の良いモデルではありません。システム担当は、ゲストまたはオブザーバー担当を使用するときの属性として、最も役に立ちます。
  • ドメインに利用不可なユーザを含めるべきか。ドメインに無効なユーザを含めるべきか。利用不可および無効ステータスは、アーカイブまたは削除のユーザレコードをマークするためによく使用されるので、これは重要な考慮点です。
  • ドメイン内のユーザをプライバシーオプションで制限するべきか。[ユーザ検索ツール]への掲載をオプトアウトしているユーザは、ドメインから除外できます。

タブおよびモジュール

  • ドメインに利用不可なタブおよびモジュールを含めるべきか。これは、ユーザにタブおよびモジュールの作成を許可し、それらが発行されたら編集を認めないための方法です。代わりに、ドメインには利用可能な教材のみ含めることができます。この場合、製品内の利用不可な教材をドメイン管理者が編集することはできません。
  • タブおよびモジュールは、個々に選択してドメインに含めることができます。

たとえば、部門内で提供されているすべてのコースを含むコースおよびユーザのコレクション、およびその部門で働くすべてのユーザ、または彼らの専攻の言語リストと共にSLA_LANGUAGESドメインを作成する場合を考えてみます。この場合、コースコレクションは以下のように定義できます。

カテゴリ : LANG、LANG_FR、LANG_DE、LANG_ES、LANG_JP、LANG_NL

利用可否の設定 : 無視

有効:有効のみ

ユーザコレクションは、以下のように定義できます。

教育機関での担当 : DEPT_LANG、MAJOR_LANG

利用可否の設定 : 利用可能のみ

有効:有効のみ

ドメイン管理者に必要な管理者タスクは何か。

コレクションを定義した後は、確実に適切な権限をシステム担当に割り当てられるようになります。ドメイン管理者には、そのドメインにのみ適用されるシステム担当を基にした権限が与えられます。基本的に、システム担当によって定義された権限のあるドメインのための権限委譲可能な管理者を作成するためにユーザおよびシステム担当が組み合わされます。そのユーザとシステム担当の組み合わせは、そのドメインにのみ適用されます。

システム担当は各ドメインに対して作成できますが、各ドメインの管理者に適用できる権限を基にシステム担当を作成する方がより効率的です。システム担当はドメイン内で加法性があるので、完全にタスクを基にしたシステム担当モデルを作成し、次にそれらのタスクの組み合わせを使用して、個別の権限を特定の権限委譲可能な管理者に与えることができます。

システム担当を作成するときには、以下の点を検討してください。

  • ドメイン管理者によって使用される管理タスクはどのようなものか。
  • それらのタスクを達成するのに必要な権限は何か。
  • 各権限のセットの目標を達成するために、それらの権限をどのようにグループ化できるか。セットに常に適用可能でない権限があるか。
  • システム担当の命名はどのようにすべきか。命名規則は容易に認識できるものであり、権限のセットを定義する必要があります。

たとえば、USER_MANAGERという名のシステム担当は、マネージャユーザアカウントに対する完全な権限付きで作成されます。このシステム担当は各ドメインで使用して、ドメイン管理者にドメイン内のすべてのユーザアカウントを管理する能力を与えることができます。他のシステム担当、USER_PASSWORDをドメイン管理者に与えることもできます。この場合、ドメイン管理者は、ユーザにユーザパスワードの変更を認め、ユーザレコードの他の詳細の編集は認めないようにできます。

SLA_LANGUAGEドメインでは、部門長にUSER_MANAGER担当を与え、アシスタントにはドメイン内のUSER_PASSWORDシステム担当を与えて、紛失パスワードの置換リクエストに応答できます。

システム担当には加法性があることを忘れないでください。USER_PASSWORDのシステム担当があるユーザに、ユーザアカウントの他の側面を編集できる能力を含む別のシステム担当が与えられた場合、両方のシステム担当が適用されます。つまり、そのユーザには割り当てられたすべてのシステム担当のすべての権限があるということです。さらに、ユーザに初期設定ドメインに割り当てられた管理権限のあるシステム担当がある場合、それらの権限はシステム内のすべてのドメインとデータに適用されます。

ドメインの管理をするために割り当てられたユーザは誰か。

ドメインは、1つのシステム担当を持つ1人の管理者に制限されてはいません。むしろ、各ドメインはシステム担当数の制限のない無制限な管理者を持つことができます。ドメインでは、異なる管理者に異なる責任とタスクが割り当てられます。

ドメイン管理者としてユーザを割り当てるときには、以下の点を検討してください。

  • ドメインのどのような点において、ドメイン管理者が必要か。
  • 追加の不必要な権限、または潜在的にリスクのある権限を取り込むことなく、それらのタスクを達成するための権限を与えられる特定のシステム担当があるか。そのような担当がない場合、例外ケースをカバーするためのシステム担当の構成の修正、または新規システム担当の作成を検討してください。
  • 必要なタスクによりドメイン管理者の責任はどのように形成されるか。他の管理者がコースを割り当てている間に、ユーザ管理のために管理者が1人必要か。
  • 異なるドメイン管理者ポジションに、誰を割り当てるべきか。

ドメイン管理者として機能する個人、および適切な権限を与えるシステム担当を特定したら、最後の手順として、その情報をドメイン内でひとまとめにします。たとえば、

ドメイン:SLA_LANGUAGE

ユーザー:部門長

システム担当 : USER_MANAGER、COURSE_MANAGER、MODULE_CREATE、MODULE_MODIFY