| Oracle® Student Learning Implementation Guide Release 3.1.3 Part Number E21072-04 |
|
|
PDF · Mobi · ePub |
| Oracle® Student Learning Implementation Guide Release 3.1.3 Part Number E21072-04 |
|
|
PDF · Mobi · ePub |
Before students, teacher, and parents can start using the LT, all of the reference data must be loaded and preferences must be set appropriately. Note that:
The majority of these tasks occur at initialization.
Some/all of the tasks must be revisited periodically, typically at the start of each new school year.
User data (roles and relationships, and class enrolments) are the only elements of reference data that need to be regularly updated.
Regardless of the extent to which automated processes are used, the sequence of the tasks must be properly thought out and planned. In Figure 7-1, all of the functional setup and maintenance tasks are laid out in a flowchart to indicate the interdependencies between them.
The instructions on how to perform each of the setup tasks using the LTAdmin are described in the Oracle Student Learning Learning Tool Admin User's Guide Release.
This section outlines the steps that need to be followed, post installation and configuration of OSL, to get the first school users accessing the LT.
When OSL is first installed, it is seeded with the root Department (Institution) and some (technical) users to enable the underlying technical processes (data loading, content integrations, and so on).
The name of the root Department is set by the initialization script that is run as part of the installation of OSL and is exposed to Department Administrators only (in the LTAdmin UI). The Department Administrator cannot change the name of the root Department through the LTAdmin UI as required.
The only other question regarding seeded data is whether it is intended to manually set Preferences, create Schools, Curriculum Frameworks and Calendars before loading any production users. If this is the case, then an initial Department Administrator user must be loaded through DLS before the integration with the source system.
The sequence in which these objects are created or loaded is of no consequence. The objects may even be created after loading the schools and people. However, these objects must be created so they can be "adopted" by schools (and it is usually simpler to adopt calendars, curricula, and grade sets at the instantiation of the school).
These data objects are essentially "fixed". Curriculum Frameworks typically have a life span of several years.
The OSL Learning Tool Admin User's Guide describes how to create a Curriculum Framework. This includes some sections that describe the management of "Contexts" (specifically sections: 5.3.8 Managing Department and School Contexts; 6.2.3 Adopting Contexts for a Framework Item; and 6.2.4 Removing Contexts for a Framework Item).
Curriculum Contexts are legacy items that will not be supported in the future and, therefore, should not be implemented in any new deployments of OSL.
Institutions (schools) may be created manually using the LTAdmin UI but, in practical terms, this is really only an option for pilots or very small implementations.
As is the case with People, there are certain legacy attributes that will be discontinued in the future, as listed in Table 7-1 below.
Table 7-1 LT Institution Attributes
| Institution Attribute | Description |
|---|---|
|
Institution Name |
Required |
|
Institution Type |
Required - LOV: OSL_ INSTITUTION_TYPE (such as Primary) |
|
Parent Institution |
Required |
|
External Identifier |
Optional - used to match Institution to source system entity |
|
External System Identifier |
Optional - specifies the source system |
|
List Of Phone Numbers |
Legacy - Compound Object |
|
List Of Addresses |
Legacy - Compound Object |
|
List Of Email Addresses |
Legacy - Compound Object |
The Curriculum Frameworks (created in Section 7.1.2, "Create Calendars, Curriculum Frameworks and Grade Sets") must be made available to schools (so that they can be later adopted). Making curricula available is actually part of the Curriculum Framework creation process; that is whenever a school is created, the curriculum frameworks must be modified so that the new school can be added. This is typically a process that would be automated as part of on-boarding a new school or curriculum (which would normally happen after a school year in preparation for the following year).
Institution groups are used to streamline the process of availing Curriculum Frameworks to schools. For example, a "Special Developmental" Curriculum Framework would be made available to a "Special Developmental School" Institution Group.
Whenever a new "Special Developmental" school is created, it only needs to be assigned to the group. Conversely, if a new "Special Developmental" Curriculum Framework is created, it only needs to have the group assigned to it (rather than all of the Special Developmental schools).
The "adoption" of calendars, curricula, and grade sets by schools may be performed manually in the LTAdmin UI by a School Curriculum Administrator, but this places an administrative burden on schools. It is therefore recommended that the process is automated as part of the instantiation of a school (that is part of create school workflow). This is typically a process that would be automated as part of an annual "roll-over" process – that is after each school year.
After the Institutions have been loaded, it is then possible to assign people to them. It is this assignment (relationship) that determines the person's roleFoot 1 (as outlined in Section 3.2, "User Roles"). In OSL, relationships are never (and cannot be) deleted. Changing relationships are managed through start-dates and end-dates.
It is not technically necessary to create the people-institution (and people-people) relationships as part of the same process by which users are loaded (provisioned). Therefore, it is possible to load people without any relationships (or role assignments) much earlier in the process and add the relationships later. It is also possible to manually assign the relationships in the LTAdmin UI. Notwithstanding this, it is expected that relationships would typically be loaded as part of the user provisioning process.
Loading people and their roles and relationships is an ongoing process. Typically, in a production system, we would expect this to occur through a publish-subscribe or routine batch process, so that updates occur in near real time or with a maximum latency of 24 hours.
While it is possible for schools to create their own Grade Sets, it is more typical (and recommended) that schools adopt Grade Sets from the Department. School Grade Sets can be created at any time (even in production).
School Courses can only be created after the school has been created and must be created before the school Offering. The definition of a Course is very simple, it includes a (unique to school) Name (50 Char) and Code (15 Char).
School Courses may only be deleted where there is no dependent data (that is Offerings) but are more typically end-dated when they are no longer active. School courses only need to be created once, as they are then re-offered from one year to the next. Typically, there would be a review of courses after each year, where a few minor changes might be made (a new course created, an old course retired or a course renamed).
Tags should be applied to courses so that the classes (which ultimately hang off the courses) can be navigated in the LT, as illustrated in Figure 7-2.
Offerings can only be created after the school Courses have been created and the school has adopted both the Curriculum and Calendar (since an Offering is tied to a Course, Curriculum, and Calendar).
Offerings must be created before Classes can be created. The definition of an Offering is very simple, it includes a (unique to school calendar) Name (50 Char) and Code (15 Char).
School Offerings may only be deleted where there is no dependent data (that is Classes). Offering start-date and end-dated must fall within the associated school calendar.
The creation of school offerings typically occurs after each year (or semester) in preparation for the following year.
The ultimate object for creation is the School Class. A School Class is tied to an Offering. The definition of a Class is very simple, it includes a (unique to Offering) Title (80 Char).
School Classes may only be deleted where there is no dependent data (that is Enrolments or Learning Items that have been added by the teacher in the LT). Class start-date and end-dated must fall within the associated offering's start and end dates.
The creation of school classes typically occurs after each semester in preparation for the following semester. However, there are often last minute changes that are made to classes (new classes added, classes merged, or removed and so on) that can occur even after the new semester has begun.
Students and Teachers are enrolled into classes with a specified start-date and end-date, to cater for instances where a student (or teacher) may arrive or leave mid semester. Changes to class enrolments occur quite frequently during the normal course of a semester.
Occasionally, a user is mistakenly enrolled in a class, in which case the user's enrolment can be deleted, but only if there are no Learning Items that have been added to the class by an assigned teachers. After this point, Student and Teacher enrolments in the class may only be end-dated.
Preferences can be set at any stage (even in production), and preferences may even be loaded through DLS (as may be the case for the student workspace). But, it is expected that most preferences will be set manually in the LTAdmin UI by a Department Administrator. It should be performed before UAT.
The previous section outlines the sequence through which the functional setup tasks need to occur to ready an OSL environment for use by students, teacher, and parents. The following table summarizes all of these tasks including their dependencies and expected frequencies.
| Data Object | Dependencies | Frequency | Comment | Method |
|---|---|---|---|---|
|
Calendar |
Department |
initial, annual |
Set calendars at setup. Simple task performed manually in the UI. Possible to create calendars many years in advance, but likely to create calendars for upcoming years as required. |
Dept Curric Admin DLS |
|
Curriculum Framework |
Department |
initial as required |
Curriculum Frameworks are “fixed”. New Frameworks might be defined every few years. |
Dept Curric Admin DLS |
|
Grade Set |
Department |
initial as required |
Grade Sets are “fixed”. New Grade Sets might be defined once or twice per decade. |
Dept Curric Admin DLS |
|
School (Institution) |
Parent Institution (Department) |
initial as required |
Schools are “fixed”. On-boarding a new school (or closing an old one) would be planned ahead of time (i.e. not ad-hoc). |
DLS Dept Admin SIF 2.2 |
|
People |
NULL |
initial ad-hoc |
After the initial load of people, new people are provisioned (and un-provisioned) on a daily basis. |
DLS SIF 2.2 |
|
Teacher/ Student Relationship |
SchoolPerson |
initial ad-hoc |
Teachers and students are provisioned (and un-provisioned) on a daily basis. |
DLS Dept Admin School Admin SIF 2.2 |
|
Parent Relationship |
Person |
initial ad-hoc |
Parents are provisioned (and un-provisioned) on a daily basis. |
DLS Dept Admin School Admin SIF 2.2 |
|
School Admin Role |
SchoolPerson |
ad-hoc |
Assignment (and un-assignment) of school admin roles should be delegated to the schools. |
School Admin Dept Admin DLS SIF 2.2 |
|
Dept Admin Role |
DepartmentPerson |
initial ad-hoc (infrequent) |
There would only ever be a handful of Department Administrators. |
Dept Admin DLS SIF 2.2 |
|
Institution Group |
NULL |
initial as required |
Should only be created to support assignment of Curriculum Frameworks to schools. |
Dept Admin DLS |
|
School Calendar |
SchoolCalendar |
initial annual |
Adopt Calendar - Ideally part of school on-boarding and annual rollover process. |
DLS Dept Curric Admin School Curric Admin |
|
School Curriculum |
School CalendarCurric Fwk |
initial annual |
Adopt Curriculum - Ideally part of school on-boarding and annual rollover process. |
DLS Dept Curric Admin School Curric Admin |
|
School Grade Sets (Adopt) |
SchoolGrade Sets |
initial as required |
Adopt Grade Set - Ideally part of school on-boarding and Grade Set creation. |
DLS Dept Curric Admin School Curric Admin |
|
School Grade Sets (Create) |
School |
as required |
Not recommended. Manual process if required. |
School Curric Admin DLS |
|
School Courses |
School |
initial ad-hoc (infrequent) |
Reviewed by schools after each year with minor changes. Ideally there would be minimal latency between changes made in schools and flow on to the LT in an automated process. |
DLS School Curric Admin |
|
School Offerings |
School CalendarSchool Courses |
initial ad-hoc (infrequent) |
Created by schools after each year and/or semester. Ideally there would be minimal latency in flow on to the LT. |
DLS School Curric Admin |
|
School Classes |
School Offerings |
initial ad-hoc |
Created by schools after each year and/or semester. Expect frequent changes even in to early part of semester. Ideally there would be minimal latency in flow on to the LT. |
DLS School Curric Admin |
|
Class Enrolments |
School Classes |
initial ad-hoc |
Created by schools after each year and/or semester. Expect frequent changes throughout semester. Ideally there would be minimal latency in flow on to the LT. |
DLS School Curric Admin |
|
Preferences |
NULL |
initial as required |
Only preference that is subject to ad-hoc change is Student Workspace. |
Dept Admin School Admin DLS |
Footnote Legend
Footnote 1: In the case of Parents, this is a person-person relationship (that is Parent to Child)
|
 Copyright © 2009, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
