System Requirements Specification

for

Course Scheduling System

(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:

 Decrease duplicate data entry

 Improve data consistency
 Offer user friendly controls for filtering course schedule data on various criteria
 Be flexible to incorporate features that will integrate with other Course Registration and
Management systems
 Enhance and attract more students with an insight into course schedules of existing
programs
Infrastructure Integration:
This system will be integrated with an existing database system which currently contains
information for current GSM students, staff, and faculty. The website will be hosted on an
existing GSM web server and will interface with the GSM Oracle database system.

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.

Existing system workflow:

A brief description of the current workflow process involved in course scheduling is provided
below. It is imperative that the updated system takes into account all the steps and functionalities
therein so that the workflow of the newer system provides a seamless transition.

1. Development of preliminary Course Schedule Worksheet

According to the existing workflow, a preliminary course schedule is developed as a result of a

series of meetings between faculty and staff. These schedules could be for terms a couple of years
in advance.

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.

The preliminary course planning includes the following data elements:

 Quarter (term)
 Year
 Program Type (Major code)
 Day
 Time
 Location (Name of the room, Number, Seating Capacity)
 Course Number
 Instructor
Note: Each of the program types has its own display requirements

 
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.

3. Scheduling of rooms through EMS

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

5. Notification from Banner

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.

6. Data Entry to Banner

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.

Once registration begins, enrollment information is updated in the MS Access database by

procedures and jobs located on an MS SQL database. The start and ending dates for updating this
information is specified via the Terms table in the Access database. These updates are then
published from the Access database to the website.

 
Page 8

Design Team and Meetings

The following identifies contact information for individuals involved in this project:

Chip Mrizek, GSM, 2-8330, cjmrizek@ucdavis.edu

Mari Royer, GSM, 4-6265, mariroyer@ucdavis.edu

Amit Diwan, GSM, 2-5828, adiwan@ucdavis.edu

Jeff Royer, GSM, 2-6186, jlroyer@ucdavis.edu

Jim Stevens, GSM, 2-7661, jrstevens@ucdavis.edu 

Mary McNally, GSM, 2-7365, mmmcnally@ucdavis.edu 

Kathy Gleed, GSM, 4-5476, krgleed@ucdavis.edu 

Holly Bishop-Green, GSM, 2-7363, hbbishopgreen@ucdavis.edu 

 
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 

System Architecture Diagram:

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.)

ii) Usinng this form

m, the Systeem Managerr/Registrar wwill be able to perform
m the followiing
actioons:
c. Add
A a new cooncentration
d. Edit
E an existiing concentraation.
e. Remove
R one or more exissting concenttrations.

ppear in drop lists in the other stteps in Cou

iii) Thee concentratiions added here will ap urse
Schheduling.

iv) Conncentrations drop lists foor other step

ps will be dyynamically updated
u if anny changes are
madde in this step
p.

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.

ii) Thee following fields

fi would bbe entered by the System
m Manager/R
Registrar in thhis form:
a. Coursse Code
b. Coursse Name
c. Coursse Type (if appplicable)

 
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.

iv) Usinng the form above, the R

Registrar willl be able to pperform the following
f acttions:
(1) Identify the Concentratioon related to each coursee.

v) Onee course can have one or more concen

ntrations.

vi) Each course sho

ould have at lleast one con
ncentration.

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.

viii) Evven though initially

i addded, the ‘cattegory’ (i.e., core, or elective)
e collumn has beeen
rem
moved from the t table as this inform mation is tiedd to a speciffic program and term. For F
instaance, a core course for oone program may/may noot be a core course
c for annother progrram
in fuuture.

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.

ii) Oncce an academ mic period iss added, it will

w serve as a link to ad
dd one or moore terms to be
assoociated with the defined aacademic period.

 
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.

iv) Prerequisite associations will be considered mandatory.

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.

ii) Thiss information

n is expectedd to rarely chhange, so a uuser interfacee will not be developed fo
or
this step. Additions/Changees will be sub bmitted to thhe system adm ministrator wwhich will
subssequently en
nter directly iinto the datab
base.

 
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.

ii) The following subject codes will be initially setup:

Subject Code Description Active

MGT Davis MBA Y
MGB Bay Area WP Y
MGP Sac WP Y

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.

v) Thee following program

p codees will be iniitially setup:

Majjor Code Descriptionn Location Active

SMBBA MBA-Full--Time Davis Y
SMBBE MBA-Worrking Professsional Sacramento Y
SMBBL MBA-Worrking Professsional Sacramento N
SMBBB MBA-Worrking Professsional Bay Area Y

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

i) Usinng the Manag

ge Curriculuum, the Systeem Manager is able to maanage coursees based on
program
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.

iii) Thee data entry form

f to manaage this list will
w consist oof the following fields:

a. Namee of the instru

uctor (Last N
Name, First Name)
N
b. PIDM
M number, if available (opptional field))
c. Emaill (personal or
o UCD) (opttional field)
d. Conceentration
e. Recorrd Retention Date

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

Course offeerings for any

y specific terrm are manaaged in two sstages:

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.

(2) Only active courses will be copies, not cancelled courses.

(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.

(4) Information that will be copied will include:

(a) Course Code

(b) Subject Code
(c) Section
(d) Instructor of Record
(e) Course Name
(f) Program
(g) Status

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.

(3) On conttinuing, the System Maanager will see a summ

mary of all the
schedulees entered forr different coourses.

 
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’.

(6) On clickking the ‘Resset’ button, aall the sched

dules for all tthe courses (for
(
that term
m) will be rem
moved.

(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.

v) Thee values for the

t field ‘Sesssion type’ in
n the summaary list of sch
hedules will be availablee in
a drrop list and populated ffrom the values entered by the Systtem Manageer during Settup
phase (Manage Session Typees).

4) Produce Prreliminary Offerings

O (m
modified Aug
gust 2011)
 
a) The maain goal of thhis step is to aassist the System Managger and Sched
duler in negootiating with
Facultyy in establishiing course offerings.

b) Two repports will be developed tto assist in prreliminary coourse offerin

ngs schedulinng. Samples of
these reeports are pro
ovided in Atcch1.

i) Couurse Assignm Ladder” facuulty and courses

ments: This rreport will prrovide a list of “Senate/L
theyy are assigneed for an acaddemic period
d. A means oof identifyingg a category for faculty will
w
be rrequired to prroduce this rreport.

ii) Couurse Conflictts:

(1) This report will

w display a calendar off scheduled ccourses for each
e program
m.
(2) In order to support this rreport, the Sy
ystem Managger will inpuut a preliminaary schedule
information for each couurse. This infformation wiill include daay, time, andd Odd/Even
week identiffier, based uppon a single representativve week for which
w a courrse is being
considered.

(3) Some coursees are held att different tim

mes on each day (i.e., Friday 6-9pm, and Sat 9am m-
4pm). In such cases, thee System man nager will ennter one reco
ord for each ddistinct sessiion
time.

 
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:

(a) Subject Code – Course Number – Section

(b) Instructor Last Name
(c) “Core” (if applicable)
(d) Course Name
(7) The Scheduler will be able to move appointments on the calendar display and save
changes. This action will only allow changes to the day/time. Any other information
changes must be made by the System Manager through the Manage Course Offerings
interface.
(8) Only one version of the calendar can be saved at any give time. Multiple versions is
not supported. To review multiple scenarios, it is recommended that each scenario be
printed.
(9) The Scheduler will be provided an opportunity to lock the schedule. Once locked, no
further changes will be allowed, unless the System Manager unlocks the schedule
through the Manage Course Offerings interface.

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.

b) The couurse syllabuss or textpackk information

n will be filteered by term. A list of avvailable courrses
with theeir scheduless will be displayed. The Project Resource Coord dinator will hhave the optiion
of addinng/editing bo
ookstore, sylllabus and tex
xtpack URLs for each co ourse.

 
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.’

2. Bay area students:

‘Textbook Required: Students can order their textbooks online. Please use our online
textbook form.’

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.

7) Publish syllabus, text packs, course material

 
a) This is an automated step that will occur when the relevant details are entered by the Project
Resources. Once entered, these details are immediately available through 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.

10) Updated CRNs Email notification

 
a) Once CRNs are available for course offerings for a particular term and an update of Course
Offerings with the CRNs has been accomplished, an email will be automatically sent to the
System Manager.

11) Publish CRNs on schedule

 
a) Once available, CRN information will be published on the web. This information will be
displayed in the detailed course view (on clicking course link).

b) For courses where CRN information is not available (in SIS), the field will contain a blank.

12) Update Enrollments

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

2) The followiing set of filtters will be aavailable to aid

a in searching for a cou
urse or a set oof courses:
Proggram and Teerm Informattion, Academ mic Period, C
Course Inform
mation, Instrructor
Infoormation, Daay/Time, Uniits

As demonsstrated in thee interface sscreenshots below,

b somee of the filteers will conttain sub-filteers.
These can bbe used indiv
vidual or in ccombination of other filteers.

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.

4) The Coursee field will be

b displayed as a web lin nk. Clicking on this link
k will unfoldd course detaails.
Clicking baack will resto
ore it to origiinal view.

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.

1) Thee default view

w.

Thee ‘Program’ and

a ‘Term’ ffilters will alw ways remainn visible as a part of left hhand filter list.
On the right han
nd filter list, tthe ‘Academ
mic Period’ taab will selectted by defauult.
            

 
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.

At any ppoint, the cu

urrently activve filters willl be displayedd in another section of thhe screen.

 
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.

ote: The ‘Coore Courses’’ checkbox w

No will appear only if the uuser selects a specific pprogram in the
“P
Program” seaarch filter. Otherwise,
O it will be hiddeen.

 
 
 

 
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

The drop list fo

for each of th
hese filters w
will contain the
t values thhat have alreeady been poopulated by the
Sysstem Manager.

 
 
 
 

 
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
 

1. The syystem will dyynamically ddisplay data according

a to the selected filters. The ffilter view will
w
also bee displayed on
o the right sside of the top box.

2. When the user clicks ‘Create B Bookmark’ bu utton, a URL

L, somethingg like:
tp://courseSccheduler.gsm
“http m.ucdavis.eduu/filterId=85
509”
will bee presented that can bee saved and bookmarked. Note thatt this URL//bookmark will w
containn a link to th
he current reesults of thee course scheeduling information baseed on the fillter
options selected.

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.

These dynamic web pages include:

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.

2. A web page for each area of concentration

 
   

 
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.

5) When a student selects to “B

Build New Schedule”,
S thhen they mu
ust identify thhe term for this
t
perssonalized sch
hedule.

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.

9) Studdents will bee allowed to aadd courses with conflictting schedules.

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.

11) Perssonalized sch

hedules will not contain course fee innformation.

 
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.

MBA C Curriculum anda Concenttrations

https://sstudents.gsm
m.ucdavis.eduu/curriculum
m/new.htm#cooncentration ns
This weeb page appeears to focus on MBA req quirements rather than co ourse scheduuling
informaation and as such,
s is not ssomething th t new system.
hat can be repplaced with the

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)

1) By ddefault, the page

p will shhow a listing
g of all conccentrations an
nd courses aassociated with
w
each cooncentration as
a shown in the figure.

2) Also, a user can select

s a partiicular concen
ntration to viiew a courses associated with it.

3) The ppage will alsso be accessiible by a hotlink with conncentration name

n passedd as a parameeter
in the URL. Wheen a user ggoes directly y to the UR RL the Cou urses associiated with the

 
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.

dual Course Overviews

Individu O
There aare several exxisting web ppages that prrovide an oveerview of a specific
s course (e.g.,
http://w
www.gsm.ucd davis.edu/ProospectiveStu udents/index..aspx?id=656 6). This infformation
seems dduplicative of
o that providded in
http://w
www.gsm.ucd davis.edu/ProospectiveStu udents/index..aspx?id=5484, but why pages with
individuual courses are
a available has not been n determinedd and this fun
nctionality w
won’t be
replicatted unless a valid
v need is identified.

Individudual Course Details

D
There aare many exissting web paages that prov vide details oof a specific course (e.g.,,
http://sttudents.gsm.uucdavis.edu//samba/2010 0-2011/ss.aspp?crn=32177 7&termcode= =201101).
It is recommended thatt these weeb pages be eliminated
e inn favor of usiing the new system. Thee
new sysstem can be used
u to provvide this inforrmation by ccreating pre-ddefined bookkmarks (see
“Createe Bookmark Feature”
F secction above. A bookmarkk can be creaated that willl display the
details oof a single co
ourse.

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.

Course Schedule Notes

A web page is created each term to display notes associated with the course schedule. An
example is:
http://students.gsm.ucdavis.edu/CourseNotesWinter2011.htm
Continued publication of these notes has not been discussed. While some of the information is
duplicated within this new course scheduling system, the ability to replicate the format or
highlight specific scheduling components for a single web page is not available in this design.
A course notes page can be generated for each term which will include a section for each
program and the individual notes for associated program courses. However, the notes cannot
be categorized.

Independent/Group Study (added Sept 2011)

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.

Implementation Planning (Oct 2011)

Reviewed overall structure of web information available:

 Catalog (all courses available at GSM)
 Curriculum (program specific catalog)
 Course Offerings (sections offered within specific term)
o Public view (search utility and ability to create bookmarks for pre-defined
filters)
o Student view (login required)
 Concentrations (list of courses associated with each concentration)
 Course details
 Course Offerings details
Note: many of the pages above have two versions:
(1) Formatted to use same styling as new Drupal CMS.
(2) Formatted similar to existing Student.Net website

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.

Performed demo/review of process for:

 Student using new course search/selection utilities.
 Variable Unit registration process

 Implementation for students

o Pilot for Winter quarter (initiating on Nov 28, 2011)
 Who: select group of students in WP programs as designated by Student
affairs. Not Full-Time Day-Time program.
 There is no way for system to provide/restrict access to individual students,
so control is simply based upon instructions and information distribution.
o Full implementation in Spring quarter (iniating in Feb, 2012)
 Who: All WP students. Student Affairs will think about Full-Time Day-
Time students.
o Instructions
 To be developed/distributed by Student Affairs
 Communicated directly to students participating in Pilot program
 Published on Student.Net website for full implementation
o Support structure
 Students to contact Student Affairs as normal. Student Affairs issues
requiring Computing assistance to helpdesk
 Helpdesk will handle issues associated with pilot program as top priority
and resolve as quickly as possible to keep students on track.
 If issue is encountered that prevents student from registering and Computing
can’t fix quickly enough, then student can revert to old process.

Changes Requested during meeting:

‐ 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. 

Post Production Change Requests

4/3/12 – Requested by Mari/Hemant

 Instructor Schedule Report
o Add course location and append session type to meeting information

4/3/12 – Requested by Mari/Hemant

 Course Conflicts planning tool
o Allow user to select multiple programs and display the calendars for all selected
programs on a single web page.
o If possible, reduce height of each hourly timeslot to about 1/3 what it is now

4/3/12 – Requested by Mari/Hemant

 Instructor Schedule Report
o Add a button next to the “Save to PDF” button titled “Send Email”.

 
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.

4/5/12 – Requested by Mari/Hemant

 Manage Course Offerings:
i. Add ability to move course offering from one term to another to accommodate
frequent scheduling changes.
 Add Academic Period to available filters
 Eliminate requirement to select term. Requirement should be that either
an academic period or term must be selected. Copy Term should still not
be accessible unless a term is identified.
 Add Term field to beginning of displayed fields
 Remove Status Notes field, to make space for the term field being
added.
 When the user click “Edit” on a record and the edit screen appears, add a
button for “Change Term”. If this button is selected, prompt user to
pick new term and prompt for subterm. If selections are made, then:
a. Call insertCourseOffering to create new course offering using:
i. New term identified
ii. Same subject code, course number, sequence number,
course name, majorcodeID, instructorPIDM, units, notes,
maxEnrollment, status, statusNotes, publishToWeb,
CourseType, catalogID)
b. Call DeleteCourseOffering for old courseID.
c. Note: Mari recognizes that:
i. a student could have potentially added the course being
deleted to their shopping basket.
ii. When a course is deleted, it is automatically removed
from any shopping basket.
iii. No indication is provided the student as is the case with
canceled classes.

 
Page 58