管理モデルの構成
Blackboardでは通常、ドメインの代わりに教育機関の階層の使用をお勧めします。教育機関の階層では他のLearnの機能をフルに活用でき、カスタムルールに基づいたロジックは必要ありません。
ドメイン使用の最も重要な部分は、教育機関の組織的ニーズに一致する管理モデルを開発することです。このトピックでは、教育機関の管理上のニーズを考えるプロセスを説明していきます。各段階には質問と簡単な例が含まれています。
これは管理モデルを考え始めるにあたっての役立つツールであることに留意してください。ドメインの柔軟性、および無制限のシステムロールにより、各教育機関に合う一意なソリューションを作成できます。
ドメイン管理が必要なキャンパスでのグループ化とは。
権限委譲可能な管理モデルをセットアップする最初の手順は、そのドメインに制限された権限のある権限委譲可能な管理者によってサポートされる教育機関でのグループを定義することです。ドメインには、ユーザ、コース、コミュニティ、タブ、およびモジュールの任意の組み合わせを含めることができるので、異なるドメイン構造を無限に作成できます。たとえば、学生、教職員、卒業生、およびスタッフ間でユーザの管理を分けるためにドメインの使用を選択した教育機関が、アカデミック部門間でのコース管理を分けるためにドメインを使用することができます。また、同じ教育機関が両方のモデルを適用して、アカデミック部門のドメイン管理者に、それぞれの部門のユーザを制御させることもできます。さらに、各部門は異なるドメインに分割することができます。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
