Professional Documents
Culture Documents
CourseScheduling SRS
CourseScheduling SRS
for
(v)9/30/2011 3:07 PM
Table of Contents
Business Review ...................................................................................................................................... 3
Background: ..................................................................................................................................... 3
Scope: ............................................................................................................................................... 3
Business Need: ................................................................................................................................. 3
Business Impact: .............................................................................................................................. 4
Infrastructure Integration: ................................................................................................................ 4
Administrative Integration: .............................................................................................................. 4
Risks/Mitigations: ............................................................................................................................ 5
Design Considerations: .................................................................................................................... 6
Existing system workflow: .............................................................................................................. 6
Design Team and Meetings ..................................................................................................................... 9
System Architecture Diagram: ............................................................................................................... 11
System Workflow Diagram: .......................................................................................................... 13
Functional Requirements ....................................................................................................................... 14
System Management: ..................................................................................................................... 14
1) Setup .................................................................................................................................... 14
2) Update Visiting Faculty List................................................................................................ 25
3) Manage Course Offerings .................................................................................................... 25
4) Produce Preliminary Offerings (modified August 2011) .................................................... 31
5) Publish Schedule.................................................................................................................. 32
6) Manage Textpack/Syllabus.................................................................................................. 33
7) Publish syllabus, text packs, course material ...................................................................... 34
8) Course Scheduling ............................................................................................................... 34
9) Check Banner for CRNs ...................................................................................................... 35
10) Updated CRNs Email notification ....................................................................................... 35
11) Publish CRNs on schedule .................................................................................................. 35
12) Update Enrollments ............................................................................................................. 35
Public Access Website ................................................................................................................... 36
Create Bookmark feature ............................................................................................................... 42
Published Curriculum .................................................................................................................... 43
Published Curriculum (Overview) Example .................................................................................. 44
Published Curriculum (Specific Area of Concentration) Example................................................ 45
Protected Access Website .............................................................................................................. 46
Existing Web Pages ....................................................................................................................... 50
Independent/Group Study (added Sept 2011) ................................................................................ 54
Implementation Planning (Oct 2011)............................................................................................. 55
Page 2
System Overview
This document is the design specification for the Graduate School of Management Course Schedule
system. Its purpose is to provide detailed system concepts and define specific required application
components to guide software development.
The goal of this Course Scheduling system is to provide a mechanism for the GSM to develop and
publish course offerings/schedules that will assist both prospective and current students in identifying
courses of interest.
Business Review
Background:
The GSM MBA program is a self-supporting operation that relies solely on student fees and
donations. The school does not receive any state or federal funding for this program. As such, it
must provide premium tools in order to maintain its national ranking as a top 50 Business School.
The Graduate School of Management provides course schedules on the web. These include MBA
course schedules offered at Davis, Sacramento and Bay Area locations. These course schedules
include information that may or may not be identified in the Campus Student Information System
(i.e., Banner).
Currently, the GSM course schedule web pages are driven by various sources, including MS
Access and MS SQL databases, in addition to content manually entered and formatted in a
content management system (CMS) and Active Server Page (ASP) files. The existing databases
and web publishing abilities are severely inadequate and convoluted, and results in extensive
manual interaction and redundant data entry.
Scope:
The primary scope of the project is to develop a Java based application that will interface with a
robust Oracle database structure to provide a streamlined data entry process and flexible data
extraction for web publications. The system will be designed to provide web content to MBA
students and prospective MBA students.
The scope of this project does not include non-MBA courses, such as Technology Minor
undergraduate courses, and executive education seminars/conferences. Undergraduate courses
information can be found in Banner, Rosters via the web.
Business Need:
The main motivation for the project is to develop a robust and flexible system that will
accommodate future changes and eliminate the existing data entry duplication. The system will be
developed using current object oriented design techniques and integrate seamlessly into the larger
workflow of various processes at GSM, including Student Registration and Fee Payments.
Page 3
Business Impact:
This system development will result in the following benefits/improvements:
Authentication process needed for the “Build My Schedule” component, which is a tool available
only to existing MBA students, will integrate with the Campus Central Authentication System
(CAS).
The source for some data elements of this system, such as student enrollment numbers, and
Course Reference Numbers (CRN), will be extracted from the Campus SIS.
The GSM uses the Event Management System (EMS) by Dean Evens & Associates, Inc (DEA).
for managing classroom reservations. All room reservations resulting from course scheduling
must be entered into EMS. DEA has a product, “EMS Campus”, which provides interfacing
capability between various standard or custom SIS systems. DEA has indicated that this EMS
Campus product could be used to interface with this Course Management system for the purpose
of establishing room reservations (ref. Section 8 of the “Workflow Diagram”). For the purposes
of this system, it will be assumed that the EMS Campus system will be implemented and
available.
The GSM uses an application, “User Role Administration”, for managing user access to various
software applications. User access to the Course Management system will integrated with the
User Role Administration system. The following roles will be added for the Course Management
System:
System Manager
Project Resources Coordinator
Specific access/activities for each of these new roles are defined throughout this document.
The development of this system is targeted for Java platform. The application will be hosted on
the Campus Java Virtual Machine (JVM) system.
Administrative Integration:
N/A
Page 4
Risks/Mitigations:
Room reservations are anticipated to be scheduling through EMS Campus product. This product
is not yet deployed within the GSM, so its capabilities are not yet fully known. Several
teleconferences and web meetings have been held with DEA to discuss interfacing capabilities.
Based upon information provided by DEA, it is anticipated that interfacing with this Course
Management system will be possible. A product quote was provided by DEA on 9/10/10, which
includes exchange credit for the current EMS Enterprise product owned by the GSM.
Page 5
Design Considerations:
The design goal is to develop the application that can reuse existing database information to the
greatest extent possible, build reusable components and be loosely coupled enough to allow future
modifications without major code changes. Furthermore, the system will be based upon a
relational database model, so functional expansion can be easily incorporated through future
development.
Adequate security needs to be provided for the information contained in the ‘Build my Schedule’
component. Unauthorized access to this information could create security and liability risk.
The existing Oracle database system complies with CyberSafety standards, as will the
development of this system. All data processing between the web server and database is
accomplished with stored procedures on the database and calls to stored procedures use defined
parameters which cannot affect the query scope. Access to all non-application specific data stored
in the database will be restricted.
The deliverable is a preliminary planning sheet developed in Excel. The main purpose of the sheet
is to serve as a goal for getting a broad outline of courses being offered for a specific year keeping
in mind faculty preferences for specific days.
These include updates vis-à-vis previous term’s course schedule – for instance, addition of any
new courses that were not offered in the previous term and or removal courses to be dropped.
Page 6
2. Data Entry to Access
Based on the details compiled in the preliminary course schedule worksheet, the data mentioned
in the previous step is entered in MS-Access, within the following tables:
Terms
MBA Courses
Course Description
Instructor
Comments
Please note that the information entered in Access does not contain CRNs for the courses at this
point. Though the data related to class location is preliminary in nature, the mapping of instructors
and the courses they are planning to lead is pretty much finalized by this point.
The rooms are reserved using EMS. Conflicts in room reservations, if any, are identified and
addressed at this point.
4. Publish schedules
The data entered in the step 2 is published on the GSM Student.net website.
http://students.gsm.ucdavis.edu
The office of Registrar sends a notification when the window to update Banner for the course
schedule for the specified term opens up. This usually occurs about 7 months before the
beginning of the quarter.
Upon notification, the information in the SIS system is updated for the specific term. The data
entry or modification in this step includes:
Addition of new courses (or courses not existing) to the current term.
Removal of the courses that are being dropped in the current term.
The SIS system generates a CRN for each course. There is a window of time to make any changes
in SIS for the updated schedule. Any subsequent changes past this window must be sent via email
to the UCD Registrar’s Office via reservations@ucdavis.edu. Turn-around time for these changes
to be updated in Banner by the Registrar’s office is usually no longer than 30 minutes.
Page 7
7. Information Updates
The CRN received for each course for a particular term is entered in MS Access database. This
results in the CRN number being displayed on the website. Additional comments and changes that
are entered in MS Access are also reflected on the website.
Page 8
Design Team and Meetings
The following identifies contact information for individuals involved in this project:
Page 9
The following meetings were held in support of this project:
6/2/10, 2:30‐4:30pm: Current Workflow Review
Attendees: Amit Diwan, Mari Royer
8/24/10, 9:30‐10:30pm: Requirements Gathering
Attendees: Amit Diwan, Jeff Royer, Chip Mrizek, Mari Royer
8/25/10, 2:30‐3:30pm: Requirements Gathering
Attendees: Amit Diwan, Jeff Royer, Mari Royer, Chip Mrizek
9/7/10, 2:00‐3:30pm: Requirements Gathering
Attendees: Amit Diwan, Jeff Royer, Mari Royer, Chip Mrizek
9/9/10, 10:45‐12:00pm: Requirements Gathering
Attendees: Amit Diwan, Jeff Royer, Mari Royer, Chip Mrizek
9/29/10, 2:30‐4:30pm: Requirements Gathering
Attendees: Amit Diwan, Mari Royer, Chip Mrizek
10/1/10, 9‐11am: Requirements Review
Attendees: Amit Diwan, Mari Royer, Chip Mrizek, Jim Stevens, Mary McNally, Kathy Gleed,
Holly Bishop‐Green
12/15/10, 1‐3pm: Discussion on Ad Hoc Courses
Attendees: Amit Diwan, Jeff Royer, Mari Royer, Chip Mrizek
1/19/11, 10am‐12n: Requirements Review
Attendees: Amit Diwan, Mari Royer, Chip Mrizek, Mary McNally, Holly Bishop‐Green, Laura
Aghazadeh
3/9/11: New Requirement Added: Prerequisite and Suggested Coursework
Per Mari Royer phone call to Chip
4/21/11: System Review with Student Affairs
Attendees: James Stevens, Kathy Gleed, Marta Barajas, Chip Mrizek, Amit Diwan.
4/26/11: Student Affairs system requirements checklist resulting from review on 4/21
Email from James Stevens
8/11/11: System Review
Attendees: GSM All Staff
8/30/11: Variable Unit Courses (i.e., Independent/Group study)
Attendees: Mari Royer, Chip Mrizek
Page 10
9/13/11: Implementation Review with RaPS system group
Attendees: Holly Bishop‐Green, Chip Mrizek, Kathy Gleed
9/29/11: Implementation Review with RaPS system group
Attendees: Heather O’Leary, Holly Bishop‐Green, Chip Mrizek, Kathy Gleed, Amit Diwan, Jeff
Royer
10/18/11: Implementation Planning
Attendees: Holly Bishop‐Green, Chip Mrizek, Kathy Gleed, Amit Diwan, Jeff Royer, Mari Royer,
Christina Lozano, Andy Fleisher, James Stevens. Absent: Lindsay Hardy
EMS
Reservation
System
Email Client
Admin
Course
Web Server Scheduling
HTTP
Application
GSM Student
SIS
(Banner)
RDBMS
Page 11
Non‐GSM Student
(public view)
Page 12
System Workflow Diagram:
7
1 Publish syllabus, text packs,
course material
Setup
6
A Manage Course Type
Manage Textpack/Syllabus
B Manage Concentration
C
Faculty response to
Manage Course Catalog
Project Resources
D Manage
Academic Period
Send email to Faculty Send email to Faculty
E Manage Course
Associations
4 5
Produce Publish
F Manage Sub‐terms
Preliminary Offerings Schedule EMS
G Manage Program Codes
3
H Manage Subject Codes Manage Course
8
Offerings
Course
A B Scheduling
I Manage Curriculum Manage Preliminary Manage Finalized
Course Offerings Course Offerings
J Manage Visiting
Adjunct/Faculty
K Manage Session Types
9 10 11 12
Banner Check Updated CRNs Publish
Manage Terms Update
L Data Banner Email CRNs on
for CRNs Notification Schedule Enrollments
Entry
M Manage Cross Registration
Differential
Automated Process
2
External Process
Update
Visiting Faculty List PPS External System
User Input Process
Page 13
Functional Requirements
System Management:
The user designated as the “System Manager” will play a pivotal role in driving and managing the
application. This includes a heavy emphasis on roles and responsibilities in feeding all the
required information in a timely manner and making the schedule available online.
There will be many tools available for this very purpose in the form of user friendly interfaces
that will encompass all the processes involved in smooth running of the system. These processes
have been mentioned in the section ‘Workflow’ above. The functional requirements as captured
for each of these steps are mentioned below:
1) Setup
As a first step, the System Manager will be able to define core resource information that will be
used while developing course scheduling for a particular term. This information is defined in the
steps below. These steps do not have to be followed in any particular sequence.
a) Manage Course Types
i) Course types identify the reason a course does not need to be scheduled. They will be
displayed in the course details. Any course flagged with a course type will prevent the
System Manager from establishing a detailed course schedule (i.e., meeting dates/times).
ii) Course Type should not be used to identify “core” or “elective” categories. This
information is addressed separately. Currently, the only course type identified during
requirements definition is “Practicum” and “Independent Study” courses.
iii) This information is expected to rarely change, so a user interface will not be developed for
this step. Additions/Changes will be submitted to the system administrator which will
subsequently enter directly into the database.
iv) The course type/s added here will appear in drop lists in the other steps in Course
Scheduling.
v) Course types drop lists for other steps will be dynamically updated if any changes are made
in this step.
b) Manage Concentrations List
i) The Concentrations list will be used for:
a. identifying course concentrations (i.e. Marketing, Finance, Business
Statistics, etc.)
Page 14
b. id
dentifying thhe focus areea of a facuulty memberr (i.e., Markketing, Finan
nce,
Information SSystems, etc.)
c) Managee Course Catallog
i) For the purposees of this sysstem, catalog g is identifieed as a curreent base list of courses that
t
are likely to bee offered in upcoming terms.t The purpose of identifying a catalog iss to
provvide a mean ns for the S System Man nager and R Registrar to define
d core data attribu utes
assoociated with a course thhat generally y don’t channge over tim me and will be used wh hen
estaablishing thee list of courrses to be offfered in anyy given term m. This shoould reduce the
amoount of data entry
e requireed by the sysstem manageer when estab blishing courrses for a term
m.
Page
e 15
d. Descrription
e. Conceentration
f. Units
g. Publissh (Y/N)
iii) Usinng this form,, the Systemm Manager wiill be able to perform thee following aactions:
1) Add a new course with the other reelated fields. Note: Whille the System m Manager can
c
add/update any course with all attributes,
a y would noot identify the
thhey typically
concentratioons associateed with a co ourse. This action is geenerally the ffunction of the
Registrar rolle (see iv.1 bbelow).
2) Edit an existting row of ccourse catalo og.
3) Delete one oro more rowss from the co ourse catalogg table.
4) Determine which
w coursees are includeed in the pubblished catalo
og on the weeb.
vii) A ccourse code is i not unique in the cataalog list. Som me course numbers (e.g., 290) are “re- “
usedd” (i.e., appllied to variouus course deescriptions foor a single teerm, then useed for differrent
courrse descriptions in subseequent termss). As such, tthe system manager
m can enter the saame
courrse numberr on multipple records and associiate it with h different course nam mes,
desccriptions, cooncentrationss, and even units. This bbusiness praactice, althouugh considerred
Page
e 16
poor, is required
d due to thee length of tiime requiredd to properly
y establish a new approv
ved
courrse number through
t the C
Campus.
d) Managee Academic Pe
eriods
i) Acaademic perioods allow thee system mannager to estaablish a grou
up of terms. Groupings can
c
incllude the variious terms ffor a summeer session, teerms within an academiic year, or any
a
otheer grouping desired. Thhe descriptio
on of the accademic periiod can be eentered in free
f
flow
wing text.
Page
e 17
iii) The academic periods added here will appear in drop lists in other steps in Course
Scheduling.
iv) Academic period drop lists for other steps will be dynamically updated if any changes are
made in this step.
e) Manage Course Associations
i) The System must be able to define association between certain courses and other courses
(e.g. practicum courses, prerequisites, suggested advance course). The result of the
association defined here will result in a link to the associated course information when a
student clicks to view details for the specific course.
ii) Each practicum course should have a defined mandatory or optional association to its
elective course.
iii) If a student selects a course and a mandatory association to another course exists, then that
course will will also be selected for the student. If the association is optional, then the
student will simply be informed of the option. If the association is a prerequisite, then a
validation that the prerequisite course has been previously enrolled, completed, or waived,
will be performed before allowing the student to select the course. If the association is
suggested prior coursework, then a validation that the suggested course has been previously
enrolled, completed, or waived, will be performed. If the validation fails, then the student
will be warned of the condition.
v) For either of the associations (mandatory or optional), the association is not bi-directional.
So, a practicum course cannot be taken on its own, but rather must be taken with the
associated elective course. Contrary, an elective course can be taken without a practicum, if
the association is set as optional.
vi) Using this form, the System Manager will enter the following information:
a) Course Code of the Elective Course
b) Associated Course
c) Association Type (Mandatory, Optional, or Prerequisite)
vii) Further, the System Manager will be able to perform the following actions:
Page 18
a. Add a new aassociation between
b two courses.
b. Edit an existting associattion.
c. Delete one oor more associations.
Note:
1. The
T Elective Course Nam me and assoociated practticum coursee name will be
displayed
d ass well, but these will be automaatically deriived from the
curriculum.
c
O clicking ‘Edit’ against a particular row, only
2. On y Associationn Type will be
allowed
a to bee edited.
f) Managee Sub‐Terms
i) Reggular terms are
a automatically extractted from thee SIS system m. This meeets the need for
mosst sessions, except
e the suummer sessiion. The sum mmer session n is broken into three su
ub-
term
ms (two sum mmer and aan intersessiion). The S SIS system has h two sum mmer sessio ons
idenntified for each year, buut these term ms are not used by thee GSM, because the GS SM
courrses that aree offered durring the sum mmer are noot managed by b the officee that manag ges
summmer session ns for the resst of the Cam mpus. Hencee, the GSM does not usee the SIS terrms
estaablished for any summerr session and d instead willl use this seetup step to define all su
ub-
term
ms.
Note: Indication ns are that iintercessionss may soon no longer be b applicablle to the GS SM
proggram, but thiis functionaliity is being retained
r for ffuture flexibiility.
Page
e 19
iii) The sub-term/s added here will appear in drop lists in the other steps in Course Scheduling.
iv) The sub-terms in drop lists in other steps would be dynamically updated if any changes are
made by the System Manager in managing sub-term list.
g) Manage Subject Codes
i) A subject code (e.g., MGT, MGP, MGB) is one attribute used to uniquely identify a course
offering. A subject code generally associates the course offering to a specific program (i.e.,
majorcode). However, this has not historically been consistent. Since it takes considerable
time to get a new subject code approved for use through the Campus, a single subject codes
has been used for courses in multiple programs. Subject codes are used by the GSM
database to identify specific course information to be downloaded from the SIS, so it is
critical to maintain an accurate list.
iii) This information is expected to rarely change, so a user interface will not be developed for
this step. Additions/Changes will be submitted to the system administrator which will
subsequently enter directly into the database.
iv) The subject codes added here will appear in drop lists in other steps in course scheduling,
unless they are marked as inactive.
h) Manage Program Codes
i) A program code is synonymous with major code (i.e., SMBA, SMBB, SMBE) and is used
to identify a formally established GSM program of instruction. Major codes are used by
the GSM database to identify specific course information to be downloaded from the SIS,
so it is critical to maintain an accurate list.
ii) This information is expected to rarely change, so a user interface will not be developed for
this step. Additions/Changes will be submitted to the system administrator which will
subsequently enter directly into the database.
iii) Program codes are associated with a specific location. The location associated with a
program code is used to identify if a student must pay cross-registration fees for courses
enrolled at locations other than their individual program location.
Page 20
iv) Thee Program Codes
C addedd here will appear
a in drrop lists in the other stteps in Cou
urse
Schheduling.
vi) Thee program co odes added heere will appeear in drop liists in other steps
s in courrse schedulin
ng,
unleess they are marked
m as innactive.
i) Managee Curriculum
m
Managee Visiting Adjunct/Faculty
i) Facuulty records are typicallly establisheed in the GS SM core dattabase system m, based uppon
assiignments in the
t Campus Personnel Paayroll System m (PPS). However,
H the GSM database
retriieves inform
mation from tthe PPS system when a person’s po osition is maarked as actiive.
For the purpo ose of courrse schedulling, a neeed exists to o associate courses withw
visitting/adjunct faculty or leecturers long
g prior to beeing active in
n the PPS syystem. Hen nce,
this course scheduling syystem must contain a method of o temporariily identifying
visitting/adjunct or lectures that will suppplement the faculty lisst extracted ffrom PPS. TheT
systtem managerr will be ablle to managee this suppleemental list of “temporaary instructorrs”.
Page
e 21
All drop lists asssociated witth faculty wiill combine the faculty list
l extractedd from PPS and
a
the supplementaal “temporaryy instructors” list.
ii) Theere should bee no duplicaation of a peerson betweeen the list ex xtracted fromm PPS and the
suppplemental lisst. For this reason, theree will be a bbackground validation
v prrocess that will
w
rem
move an instrructor’s entrry from the supplementaal list once that instructtor is added d to
maiin GSM dataabase from P PPS. This process
p mustt be able to match
m recordds between the
two list using consistent and unique attributes. Poteential attribu utes (i.e., nam
me, email, ettc.)
werre reviewed d, but nonee were con nsidered reliiable enoug gh. Howwever, oncee a
facuulty/lecturer is formally eestablished in n the SIS, a uunique PIDM
M is identifieed. The systtem
mannager will bee responsiblee for entering g this PIDMM once receivved for facullty identifiedd in
the supplementaal list. Whhen the systeem recognizzes that a PIIDM has been added fo or a
persson, it will ch
heck to see if there is alreeady a matchhing PIDM ini the GSM ddatabase. If so,
the person will be removedd from the su upplemental list and any y course refeerences will be
trannsferred to th
he faculty/leccturer identiffied in the GS
SM databasee.
iv) Thee system maanager will be able to have h access to the follo
owing operaations on taable
recoords of visitin
ng adjunct/faaculty:
a. Add an instructor reecord.
b. Edit an existing insttructor record.
c. Delete oone or more instructor reecords.
Page
e 22
v) On addition of an temporary instructor record, if the PIDM is not known, the system will
automatically generate a temporary PIDM in the saved record. As a convention, it will be a
randomly generated number prefixed with a ‘T’ for ‘Temporary’. Once available, the temp
PIDM will be replaced by the actual PIDM by editing the field.
vi) In cases where a temporary instructor may also have other affiliation with the school (i.e.,
student, alumni, staff, designated affiliate), the System Manager will not be allowed to
update a person’s name or email address. The System Manager will only be able to edit this
information if the person’s sole affiliation is as a temporary instructor.
vii) Most people in the GSM database system can have mulitiple email addresses, but only one
email address has been requested for temporary instructors. A UCD provided email is
always considered to be the designated email for official campus communications. As
such, if a person has a UCD email address, then only their UCD email address will be used
for this Course Scheduling system.
Manage Session Types
i) Session types identify the context of a session (i.e., lecture, discussion, exam, independent
study, etc.)
ii) This information is expected to rarely change, so a user interface will not be developed for
this step. Additions/Changes will be submitted to the system administrator which will
subsequently enter directly into the database.
iii) The session types added will appear in drop lists in other steps in course scheduling.
Manage Terms
i) Using this feature, the Registrar can manage terms. The intended use of this option is to
replace management of Term information from Oracle Forms application in Course Fee
Payment system as is being done currently.
Page 23
Manage Cro
oss Registratio
on Differential
ii) Usinng this feature, the Regisstrar can man
nage terms. T
The intendedd use of this ooption is to
repllace managem ment of Crosss Registratioon Differential informatiion under Teerms from
Oraacle Forms ap pplication in the current Course
C Fee PPayment system.
Page
e 24
2) Update Vissiting Faculty List
a) This is the backgrou
und process that will lau
unch indepenndently of main
m course sscheduling web
w
applicattion. It will perform thee reconciliattion on facuulty/lecturer lists identifi
fied in step 1.7
above.
3) Manage Coourse Offerings
a) Thee system man nager buildss a preliminaary list of coourses being offered. The list is sentt to
the faculty for review.
r Thee system manager negotiiates schedu ules and otheer changes with
w
facuulty and will adjust the course offerings accorddingly. Thee result of thhis stage is the
abillity to producce a PDF filee representin
ng preliminarry course offferings for fuuture terms that
t
can be sent to faaculty.
b) Thee system man nager finalizees course offferings. Thiss includes deetailed schedduling activitties
(i.e.., setting session dates/tiimes). The result
r of thiss stage is thee ability to ppublish detailed
courrse offeringss for approacching or current terms.
The same uuser interfacee will be useed for both sttages of mannaging coursse offerings. However, it is
expected thhat different data
d will be eentered/updaated within eeach stage.
Page
e 25
Course offerings data can be entered, edited, and published within either stage until the end of the
term. When a term has ended, the ‘Term’ drop list will no longer display that term, and, therefore,
associated records will not be accessible. However, the course offerings for such a term can be
viewed in read-only mode through ‘View Course Offerings History’ accessible through main menu
view for the System Manager.
The system will have the ability to track course cancelations. In order to flag a course status, there
will be a drop list with the values, ‘Active’ and ‘Canceled’. A course will default to an ‘Active’
status. If the system manager cancels a course, they can enter a note as to the cancelation reason in
the “Status Notes” field.
CRNs will be populated as soon as they are available in the SIS. This will be automated and
without user intervention (refer to process step 9). Once the CRN is transferred from the SIS,
changes to a course might create a data inconsistency with Banner. As such, if the CRN exists for
a record, and the System Manager attempts to edit the record, a warning message will be displayed
indicating, “Warning: Changes to this course must be coordinated with Banner”.
One or more schedule patterns can be associated with each course offering. The schedule field for
each course will have an icon that identifies whether the course has been scheduled or not.
‐ A clock icon implies that the course needs to be scheduled.
‐ A calendar icon implies that the System Manager has already set the schedule for that
course.
‐ The text ‘n/a’ will display for the course that does not need to be scheduled (i.e., is an
independent study or practicum course).
Note: The number of units associated with a course might change based on a particular term.
Therefore, there might be duplicate entries of a course code in the dropdown with differing units
from the information fed in ‘Manage Course Catalog’ step. Based on the desired units in the
current term for a particular term, the System Manager will select the correct course code. Also,
the values in the ‘Units’ column will be read-only.
Page 26
aa) Manage Prelim
minary Course Offferings
i) Informmation entered dduring the ‘Setuup’ phase of the course manag minary
gement system iis utilized in buuilding the prelim
coursee offerings for a term. The folllowing informattion is expected to be entered/seelected by the Syystem Manager during
this prreliminary stagee:
a. Course Code ((selected from thhe catalog list)
b. Subject Code (selected from ssubject code list))
c. Section
d. Instructor Nam me (select from ffaculty list)
e. Course Name (automatically ppopulated based upon the coursee code selected fr from the catalog))
f. Major Code (sselected from maajor code list)
g. Sub-term (opttional)
h. Notes (if appliicable)
i. Status (i.e., acctive/cancelled)
j. Status Notes ((if applicable)
Note:
dule informationn, Schedule descrription and Seatss are entered by the System Mannager in the nextt step.
1) Sched
2) The other
o fields such as CRN, Seats L
Left, Waiting Lisst will be populaated automaticallly and are read oonly.
P
Page 27
ii) The system will provide capability to copy Course Offerings data from a previous term if
the currently selected term does not have any data. Course offerings for a particular term
often closely reflect course offerings offered in previous terms, so this ability to copy
records will reduce data entry.
(1) This ‘Copy from Previous Term’ function will cover terms over the last two years.
(3) In case a specific term already contains course offering records, then ‘Copy from
Previous Term’ feature will be disabled. One can only copy from previous terms into a
“blank” term. The feature of copying from previous term is enabled only once. Once
the data is copied over to the selected term, the feature is disabled. If the button for
copying over from previous term is disabled, in order to use this feature, all course
offerings for the term must be deleted. The ‘Select All’ and ‘Remove All’ functions
can be used to accomplish this.
b) Manage Finalized Course Offerings
i) In this phase, the system manager generally develops detailed schedules for each course.
ii) When the session date for a course is identified, the session type will be included (i.e.,
Lecture, Discussion, Exam).
iii) If a schedule has not been assigned for a particular course, clicking the clock icon will open
a dialog box with start and end date/time for that course.
Page 28
(1) When thhe System Manager
M seleects ‘Date’ as the optioon will openn a
calendarr in the durattion specifiedd. The calendar opened wwill include the
months wwithin which h the durationn falls.
(2) The Sysstem Manageer can selectt one or morre dates for the classes for
that courrse. The timmes for the seelected dates would be a default vaalue
that will be edited inn the next step containing
g summary lis
ist of schedulles,
that is, oonce the dates are set.
Page
e 29
(4) The scheedules in thee list can be edited to ch
hange the exxact time of the
classes ffrom their deefault value.
(5) Once a schedule is set for a coourse, the ico on in the ‘MManage Cou urse
Offeringgs’ changes from
f ‘clock’’ to ‘calendaar’. If a couurse schedulee is
removedd, it changes back to ‘clocck’.
(7) In the sstep 1 abov ve, if the S System Man nager clickss ‘Select Da
ays
(Pattern))’, an option
n to select oone or moree days of thee week will be
presented.
(8) On contiinuing, the syystem will ddetect the dates for the corresponding
days seleected within the start andd end dates and
a populate those valuess in
the summmary list of schedules.
s
Page
e 30
iv) If a schedule has
h been assiigned for a particular ccourse, clickiing the caleendar icon will
w
direectly take the System MManager to th he summary list of scheedules. Any editing for the
scheeduled coursses can be peerformed at th
hat point.
Page
e 31
(4) Some sessions include lunch/dinner breaks. It is not recommended that these breaks be
included in the preliminary schedule, but if truly desired, then again, the System
Manager will enter one record for each distinct session time.
(5) Once a session is entered, it cannot be modified. Instead, the undesireable entry must
be deleted and another entry added.
(6) The entered sessions will be displayed on the report as calendar appointments. The
appointment information will include:
5) Publish Schedule
a) When the schedule is finalized and ready to be published on the web, it will appear by
academic period in the list of schedules ready to be published.
b) The trigger for publishing schedule would be a ‘Publish’ button that will make the schedule
available on the web for the selected academic period. This publish action will make available
the course schedules for all related terms on the “Public Access” website.
Page 32
c) If two aacademic perriods containn the same term, then the courses relaated to that teerm will be
published when the system mannager publish hes the first pperiod.
6) Manage Teextpack/Sylllabus
a) This steep is aimed at
a facilitatingg managemen
nt of textpackk and syllabu
us informatioon by Projecct
Resourcces.
Page
e 33
c) If no URL is entered by Project Resources Coordinator for syllabus for a particular course, the
system will have the following text in the course details – ‘No Syllabus Available’. If the
information is entered, the Syllabus link will be active.
d) If no URL is entered by Project Resources Coordinator for bookstore for a particular course,
the System will have the following text in the course details – ‘No Textbook Required’. If the
information is entered, the bookstore link will be active and the following text will be
displayed:
1. Sacramento/Davis students:
‘Textbook Required: Please refer to the course syllabus for textbook information.
Textbooks may be purchased at the UCDMC Bookstore.’
e) If no URL is entered by Project Resources Coordinator for textpacks for a particular course,
the System will have the following text in the course details – ‘No Text Pack Required’. If the
information is entered, the following text will be displayed - ‘Text Pack Required’ and will be
link to the textpack URL entered by the coordinator.
f) Once the information entered is saved, it will appear in the course details section of the “Public
Access” website.
8) Course Scheduling
a) It is anticipated that room reservations will be performed through the EMS Campus system. It
is also anticipated that room reservation information will be returned to this Course
Management system by EMS Campus. This room reservation information will be displayed on
the “Public Access” website.
Page 34
9) Check Banner for CRNs
a) This is an automated step that will be scheduled as a background process. This process will
check SIS/Banner for the availability of CRNs for applicable course offerings on a daily basis.
If new CRNs are available, the process will automatically update the system.
b) For courses where CRN information is not available (in SIS), the field will contain a blank.
a) For a particular course, the number of seats left, maximum enrollment and waiting list
information will be updated on the web through an automated process.
Page 35
Pu
ublic Access Website
1) The public access webssite will displlay results off course scheeduling activ
vities. It willl be used by
y:
Currrent GSM sttudents to ideentify coursees of interest for a specifiic term
Thee public and/o or prospectivve students to o identify coourses, catego
orized by:
o Overall Curriculum
C ((refer to Pub
blished Curriculum sectio on below)
o Courses related to specific co oncentrationss (ref: Publlished Curriiculum sectiion
below)
o Courses offered during a specificc term
3) The displayyed results (llist of coursee schedules) can be saveed as a PDF document annd printed. The
T
document w will containn a date/timee stamp. An n option willl be providded to print a summary of
courses, or to include coourse detailss.
5) If a course has any nottes associateed with it, it will containn (*) next to it in the listting. The no
otes
will also apppear in toolttip for the coourse besidess getting dispplayed in cou
urse details.
Page
e 36
The following are screensh
hots of the prooposed Public Access weebsite interfaace.
This wiill be the deefault view w without any user input. The results will corresppond to all the
courses in all the prrograms offeered by GSMM. However, to see sched dules for couurses in speciific
terms w
with or without combinatiion of other filters, the apppropriate op
ptions can bee selected.
Page
e 37
2) When ‘Course’ tab is selecteed.
The results inn this case can be naarrowed by optionally selecting course c title, course co ode,
conncentration, status and seeats availabillity. The drop
p list for eacch of these fillters will conntain the valu
ues
thaat have alreaddy been popuulated by thee System Maanager.
Page
e 38
3) Filteer options when ‘Instructtor’ tab is selected.
The results in this case caan be narrow
wed by optio
onally selectiing instructo
or’s name ass well as gro
oup
oncentration)).
(co
Page
e 39
me’ tab is seelected.
4) Filteer options when ‘Day/Tim
Page
e 40
5) Filteer options av b is clicked.
vailable whenn ‘Units’ tab
Page
e 41
Crreate Bookm
mark featuree
3. The buutton will onlly be displayyed if one or more filter ooptions are selected.
4. move any filteers that were selected forr course scheedule search.
Clickinng ‘Reset filtter’ will rem
Page
e 42
Published Curriculum
Dynamic web pages that extract specific curriculum information from this course scheduling system
will be developed to provide marketing information for the public. URLs will be established for each
of these web pages, so they can be referenced in any publication or other marketing web page.
1. A web page that provides an overview of all courses offered by default. In order to view
courses offered by a particular program, the use will select the specific program from the drop
list.
Note:- The default view will be set to ‘All Programs’ as mentioned above.
Page 43
Pu
ublished Currriculum (O
Overview) Exxample
Page
e 44
Pu
ublished Currriculum (Sp
pecific Areaa of Concenttration) Exaample
Page
e 45
Protected Access Website
The protected access of the System will include a feature called ‘Build My Schedule’. Students can
pick all courses they intend to take for a specific term and develop a personalized course schedule.
They will be able to save this schedule for future access and/or print their personalized schedule.
1) Access to this function will be limited to current GSM MBA students. Authentication will
use the UC Davis Campus Authentication System (CAS) to check user credentials. Once
authenticated through CAS, the system will verify that the user is currently identified as a
student in the GSM database.
2) If a user is not currently logged into the system, a “Login” link will be provided on the
“Public Access” view.
3) If a student is logged into the system, the following links will be provided:
a) “Build New Schedule”
b) “Retrieve Saved Schedules”
c) “View Course Advisor” (link to the http://students.gsm.ucdavis.edu/courseAdvisor)
d) “View Exam Schedule”
Page 46
4) When a studentt selects the “View Exam m Schedule””, a web pag ge will be diisplayed wh
hich
willl provide thee exam scheedule for a selected
s term
m. The sch hedule will be grouped by
courrse location.. Only sessioons where th
he system addministrator has associaated the sessiion
withh a session ty
ype of “(E)xaam” will be displayed in this schedulle.
6) Onlly one perso onalized scheedule can ex xists for eachh term for a student. Iff a student has
h
prevviously saved a personallized schedulle and they aattempt to bu uild a new schedule for the
sam
me term, an error
e messagge will be displayed andd they will bee instructed to retrieve/eedit
the ppreviously saved scheduule for that teerm.
Page
e 47
7) When a studen nt adds one or more co ourses to a personalizeed schedule, the followiing
messsage will bee displayed: ““Courses thaat you have aadded to yourr schedule doo not guaran
ntee
seatt availability
y.” The sam me message will be inclluded when a student prroduces a PD DF
repoort. Studentts will be abble to add coourses to theeir personalizzed schedulee which do not
n
repoort current seeat availabiliity.
Page
e 48
8) A sttudent will be
b able to addd the schedu
ule to his perrsonalized caalendar. Thiis function will
w
not utilize any calendar synnc functionss, so will noot modify an ny appointmeents previou usly
saveed. Rather, it will simpply produce an “.ics” forrmatted file that can be applied by the
userr to their personal calenddar.
10) If a student add ds a course tto their perssonalized schhedule and that
t course iis subsequenntly
cancceled, the stuudent will seee it crossed out in their ssaved person
nalized scheddules. In such a
casee, the edit theeir personalized schedulee and removeed the canceled course.
Page
e 49
Ex
xisting Web Pages
There iss a significant number oof current GSSM web pagges that could d potentiallyy be affected
d or
modifieed to use in nformation ffrom this new
n system. Many of these web pages inclu ude
marketiing informaation, managed by Ex xternal Relaations & Development
D t, and stud dent
informaation, manag ged by Studeent Affairs. The decision whetherr/how to modify these web w
pages tto integratio on information from th he new sysstem will be b left to thheir respecttive
manageement units. However,
H thhe informatio h guide thoose decisions.
on below is pprovided to help
Curricuulum Overviiew
http://w
www.gsm.ucddavis.edu/ProospectiveStu
udents/index..aspx?id=5484
This weeb page cou
uld be replacced with info
formation proovided by th
he “Publisheed Curriculu
um”
section above.
1) By ddefault, the page will shhow curricu ulum overvieew containin ng a catalog of all courrses
spread oover differen
nt programs.. In such a case, there won’t be categ
gorization off courses under
a course types can vary depending
‘Core’ oor Elective as d onn a program..
Page
e 50
2) Alsoo, a user can
n select a prrogram to view a speciffic course listing and, inn this case, see
Corre/Elective co
ourses.
3) The page will also be accesssible by a ho otlink with pprogram nam me passed as a parameterr in
the U
URL. When a user goes directly to th he URL the Curriculum view for thaat program will w
be diisplayed with
h droplist forr Program prrepopulated ffor the progrram passed aas a parameteer.
Concen ntrations
There aare several ex
xisting web ppages for speecific concenntrations inclluding the foollowing:
http://studen
nts.gsm.ucdaavis.edu/Currriculum/businnessanalytics.htm
http://studen
nts.gsm.ucdaavis.edu/Currriculum/entreepreneurship p.htm
http://studen
nts.gsm.ucdaavis.edu/Currriculum/finannce_accountting.htm
http://studen
nts.gsm.ucdaavis.edu/Currriculum/geneeralmanagem ment.htm
http://studen
nts.gsm.ucdaavis.edu/Currriculum/markketing.htm
http://studen
nts.gsm.ucdaavis.edu/Currriculum/publlichealth.htm m
http://studen
nts.gsm.ucdaavis.edu/Currriculum/strattegy.htm
http://studen
nts.gsm.ucdaavis.edu/Currriculum/techm managementt.htm
Page
e 51
Each off these existin ng web pagees has extenssive informattion that is noot included nnor can be
derivedd from this neew course sccheduling sysstem. Howeever, each off these web ppages includees
a listingg of specific courses. Thhese course liists could be derived fromm this new syystem, sincee
each coourse can be associated
a w
with the approopriate conceentrations. However,
H subbstantial
formattiing changes of the existinng page wou uld need to bbe accepted and
a there currrently is no
methodd in the new system
s to cattegorize an individual coourse as “Sug
ggested” or ““Related” to a
specificc concentratio on as is curreently referen
nced (e.g.,
http://sttudents.gsm.u ucdavis.edu//Curriculum//marketing.hhtm). Likew wise, there is no method to
t
categoriize an indiviidual course into sub-cateegories (e.g.,, Methods, Technology,
T A
Applicationss)
(ref: htttp://students.gsm.ucdaviss.edu/Curricu ulum/businesssanalytics.hhtm)
Page
e 52
concenttration will be accessiible and thee concentraation droplisst on the ppage will be
prepopuulated with th
he concentraation value was
w passed ass a parameterr.
Finals S Schedule
There aare a few web b pages creatted that prov
vides the Finaal Exam scheedule for a sppecific term..
(e.g., htttp://studentss.gsm.ucdaviis.edu/bambaa/finals.asp). Items 3.d & 4 under thhe “Protected d
Access Website” seection of this specification n was designned to replacce these web pages. The
Page
e 53
significant difference is that the new system does not group the courses by Core, Breadth, or
Elective, and this information is only available through protected web pages, so only current
students can access.
Course Schedules
A set of web pages is created each year to display the course schedules by term for each
program. Examples of these pages include:
http://students.gsm.ucdavis.edu/samba/2010-2011/schedule.asp
http://students.gsm.ucdavis.edu/bamba/2010-2011/schedule.asp
http://students.gsm.ucdavis.edu/bamba/2011-2012/summer_schedule.asp
These web pages should no longer be needed as most of the functionality provided by these
pages has been included in this system design. There are some general comments/notes that
appear on these pages which will not be available in the new system. For example, the header
of existing web pages includes a note: “Courses with fewer than eight students enrolled may
be considered for cancellation before the start of the quarter”. A function to include such a
note in the current system is not available.
Independent/Group study courses introduce unique requirements not previously raised during
initial design of the Course Scheduling system. These courses are identified as “variable unit”
courses and the specific number of units is not identified until the student submits a proposal to
an instructor and the units are determined by the instructor. Only after this process is complete
is the student normally provided with the CRN number for registration purposes. When the
student registers for the course in Banner, they must select the appropriate number of units.
Since Banner defaults the units to a value of one (1), the student often does not make the
necessary changes and registers for the wrong number of units. The registrar must correct these
errors, which creates a burden. Dealing with variable unit courses was not included in the
initial course scheduling desing. In order to remedy this, the following design changes will be
implemented.
Page 54
a. The System Manager will be allowed to change the units value on independent/group
study courses.
b. A single course offering will be entered for each program for independent study. A
second course offering will be entered for each program for group study. The unit vale
for these courses will be set to zero and the “Publish to Web” attribute will be set to
‘Y’.
c. If a student adds an independent/group study course to their personal schedule, an
automated email will be sent to the student with a link to the independent/group study
proposal form.
d. The System Manager will create a course offering with the correct unit value and
instructor. This will instill a situation where multiple course offerings will have the
same CRN or subject/coursenumber/section within a single term, but this should not
create issues for the system.
e. The “Publish to Web” attribute for independent/group study courses will be
automatically set to ‘N’ for any course offering with a unit value greater than zero. The
system will prevent changes to publish flag for these course offerings.
f. The System Manager will be provided the ability to add specific independent/group
study courses to a students personal schedule. This action will be performed when the
instructor approves the student’s proposal. When this action occurs, the previous
independent/group study course with zero units will be automatically deleted. An
automated email will be sent to the student informing them of the addition to their
personal schedule and directing them to process a payment for the added course.
Discussed What, Where, Who, When information should be transitioned to existing websites
What Where Who When
All information Drupal CMS Development Group Starting now,
Page 55
available. Eliminate and to complete Drupal performed
duplication of effort, Student.Net CMS or contract incrementally, to be
data entry, content. programming effort completed by Feb, in
with Digital Design. time for Spring
registration
Student Affairs for
Student.Net
Computing available
as resource to identify
where information is
available and for
concepts on how to
use it.
‐ Personal schedule main menu page: Change “View Saved Schedules” to “View/Modify or (View
and Modify) Schedule”? Which works better?
‐ Build Schedule view has column header “Wait List1” need to remove the “1”
Page 56
‐ Text formatting in the filters being displayed is not styled like the public view
‐ Change the default listing of courses when building personal schedule to something other than
10? I heard all different values, but what should we actually use? 25? 50? 100?
‐ When student logs in and chooses term, get their home program and default the results to the
selected term + home program
‐ Remove “Select” from “Select Term:” and “Select Program:”
‐ After adding courses to personal schedule, the pdf that can be saved should:
o Add CRN
o Remove Day/Time
o Remove Room
o Remove Term
o In the pdf, change the header to the current term the student is working in
‐ Change the title of the pdf to “Proposed Schedule and Locations”
‐ Within personal scheduling, enforce rules for Max Units
‐ In the resulting view after adding course(s) to personal schedule:
o Add a header div above table to display “instructions” or “notes” of what to do after
they’ve created their schedules
‐ Change “SessionType” of “Exam” to “Final”
‐ Change personal schedule main menu to read “Finals Schedule” in place of “Exam Summary”
‐ Add a view to personal scheduling that displays ALL of the courses and their sessions that the
student has signed up for
‐ In the “View/Modify Schedule” table, add in button to navigate to add more courses
‐ Change courseOffering “Course Status” so that the column header does not display red asterisk
when the value is already set
‐ Populate CRN for variable unit courses as soon as course offerings have been created for them (so
that when students are assigned to these courses, they can see the CRN in their saved schedules).
Also, don’t send email to student unless CRN is available.
‐ Increase length of field for TextPack, TextBook, and Syllabus fields. Provide WYSIWYG editor for
Project Resources to mix text and URL links. Also provide checkbox to indicate when an item is
not applicable. When checkbox selected, disply “Not applicable” on web.
Page 57
o When the Send Email button is selected, invoke users email client to create new
message with:
From: gsmcourseschedules@gsm.ucdavis.edu
PDF Attachment (if possible) or content of report in body of text.
Page 58