How should Student Management evolve?

1
How should Student Management evolve? A personal
view
2
Original UTS vision Enrolment 100 student self
managed via web Students should get plan on
admission, enrol year by year in the
subjects they needed then automatically graduate
without the need for them to speak to anyone in
administration and without anyone in
administration having to lift a finger. If the
students or the Facultys circumstances changed
the students plan would be changed following
consultation with the student. Students free to
expand and choose. All control via plan and
requisites
3
(No Transcript)
4
What performance criteria should be used to
evaluate a student self-managed enrolment system
?
Convenient for students
Low admin overheads
High integrity
5
Structure of the presentation
Part 1 Evolution to improve performance Stude
nt convenience Staff administrative
overheads Part 2 Evolution to get a better
return on investment Better resource
utilisation Better integration
6
Part 1 Evolution to improve performance Stude
nt convenience Staff administrative
overheads Part 2 Evolution to get a better
return on investment Better resource
utilisation Better integration
7
I am a student about to on-line enrol..
I need all the information necessary to make the
decision The information needs to be organised
for me I need to be able to do what-ifs I want
the system to respond quickly I want an undo
button I dont want to go down blind alleys I
want to be able to put the process on hold and
resume
8
Log-on
Play
Save
Log-out
Log-on
Un-do
Play
Commit
Log-out
9
I am a student about to on-line enrol..
I need all the information necessary to make the
decision The information needs to be organised
for me I need to be able to do what-ifs I want
the system to respond quickly I want an undo
button I dont want to go down blind alleys I
want to be able to put the process on hold and
resume
10
Course structure What the student must do in
order to qualify for graduation (applies to all
students)
Course Program The year and semester that it is
assumed the student will enrol in each component
of the course
Student imprint The choices that student has
made and the subjects passed to date
11
Getting the information the student needs to the
student
Course Structure
The display student sees when web enrolling
Course Program
Student imprint
12
Student imprint
Course structure
Course Program
13
Where SM is at present Course structure can have
course program information added but only
one There is no limit to the number of course
templates No validation between structure and
template Program information ephemeral Study
Plan, Enrollable subjects, option choices in
three different places
Where SM needs to be Course structure simply
defines completion rules no program
information Course template generator that
forces consistency with structure Integrated
graphic display
14
Vision
Student action
Structure
Covers display at each level of expansion
Validated Program Template for Cohort
Foundation Study Plan Web display for cohort
Study Plan as seen by student
15
What is meant by a study package template
creation tool (to ensure validity of template)
16
Year 1 Autumn
Year 1 Spring
Year 2 Autumn
Course program (Autumn commencing full time)
Course structure
17
Year 1 Autumn
Year 1 Spring
Year 2 Autumn
Course program (Autumn commencing full time)
Course structure
18
Year 1 Autumn
Year 1 Spring
Year 2 Autumn
Subjects can only be pasted into spots where
requisites met
Course program (Autumn commencing full time)
Course structure
19
Year 1 Spring
Year 2 Autumn
Year 2 Spring
Course program (Spring commencing full time)
Course structure
20
Year 1 Spring
Year 2 Autumn
49307
Year 2 Spring
49265
49262
49263
Recommendation (Spring commencing full time)
Course structure
21
Combining the course completion rules and the
course program in a single graphical display
22
Assume course with no choice, four equal
load subjects a semester for full time students
over four years (This is just a starting example
more realistic courses will be addressed later)
The course could be displayed as an 8x4 array.
Each row giving the subjects recommended for
that semester ie they are offered, they will not
clash, they are free of requisite impediments and
they open subjects that will be recommended in
following semesters.
Example for FT students commencing in Autumn
23
Example for PT students commencing in Autumn
Year 1 Autumn
Year 1 Spring
Year 2 Autumn
Year 2 Spring
These diagrams give information about the course
structure and program but not the students
imprint
24
What about student imprint? Suppose the course
involves a choice of major and has some optional
subjects where any subject in a specified list is
acceptable Over time the display should evolve
to capture choices made (this already happens in
e-student what is new is that course program
Information is preserved) Example student
doing program full time commencing in Autumn
semester
25
Stage 1 major not yet chosen
Science major
Law major
Architecture major
Economics major
Stage 2 major chosen but not expanded
Year 1 Autumn
48001 Legal Aspects
48002 IT support
Science major chosen
Expand
Choose alternative
Year 1 Spring
48005 Modelling
26
Stage 3 major expanded but option not chosen
(recommended option is displayed)
Option in MAJ03946
Stage 4 major expanded and option chosen
Option in MAJ03946
27
So far we have covered the choice capture
component in the web display seen by students of
student imprint What about progression? Suppose
expansion has taken place. Student is give a
different display for each semester of
enrolment In this presentation colour coding is
used to convey status of each subject in practice
it would need to conform with useability
standards. Red have not met requisite Grey
Not offered that semester Yellow Available for
choosing Black Subject has been passed or
exempted
28
35001 Mathematics 1
68032 Physics 1
48102 Electronics 1
48001 Communication 1
AUTUMN ENROLMENT
48002 Informatics 1
35002 Mathematics 2
68933 Physics 2
48103 Electronics 2
48003 Statistics
48200 Electromagnetics 1
48210 Materials 1
48220 Electronics 3
48004 Economics
48240 Electromagnetics 2
48250 Materials 2
48260 Electronics 4
48221 Systems 1
48011 Optics 1
48201 Power 1
48005 Management
48261 Systems 2
48251 Instrumentation
48241 Power 2
48006 Accounting
48320 Systems 3
48310 Antennas
48300 Control 1
48007 Entrepreneurship
48350 Systems 4
48340 Signal Processing
48008 Project
29
Mouse hover gives extra information
30
AUTUMN ENROLMENT
31
AUTUMN ENROLMENT
Needs 68032 Physics 1
32
AUTUMN ENROLMENT
33
AUTUMN ENROLMENT
34
AUTUMN ENROLMENT
35
M
Tu
W
Th
F
36
M
Tu
W
Th
F
37
M
Tu
W
Th
F
38
M
Tu
W
Th
F
39
M
Tu
W
Th
F
40
M
Tu
W
Th
F
41
M
Tu
W
Th
F
42
35001 Tut
48001 Lec
48210 Tut
35001 Lec
48001 Lab
68032 Lec
68032 Lab
48210 Lec
43
SPRING ENROLMENT
44
SPRING ENROLMENT
45
Part 1 Evolution to improve performance Stude
nt convenience Staff administrative
overheads Part 2 Evolution to get a better
return on investment Better resource
utilisation Better integration
46
Types of maintenance overheads
Housekeeping maintaining data integrity Waiver
requests Study Plan changes Beginning
(admission) and End (graduation) processes
47
Why do study plans need to change? a
taxonomy Faculty induced change Faculty
permission required (eg major choice) New
version of subject Add or delete subject from
options list Structure change eg core subject
substitution Version phased out customised
transition needed Student induced
change Choice change or transfer Change of
status eg new RPL Substitution or additional
option choice
48
Why do study plans need to change? a
taxonomy Faculty induced change Faculty
permission required (eg major choice)
(Design) New version of subject (Tool) Add
or delete subject from options list
(ok) Structure change eg core subject
substitution (Tool) Version phased out
customised transition needed (Problem) Student
induced change Choice change or transfer
(Problem) Change of status eg new RPL
(Tool) Substitution or additional option
choice (Integrity issue)
49
OLD STRUCTURE
50
24
24
24
OLD STRUCTURE
NEW STRUCTURE
51
24
24
24
52
24
24
24
53
24
24
24
substitute
off plan
54
OLD PLAN
NEW PLAN
24
24
24
off plan
55
Why do study plans need to change? a
taxonomy Faculty induced change Faculty
permission required (eg major choice)
(Design) New version of subject (Tool) Add
or delete subject from options list
(ok) Structure change eg core subject
substitution (Tool) Version phased out
customised transition needed (Problem) Student
induced change Choice change or transfer
(Problem) Change of status eg new RPL
(Tool) Substitution or additional option
choice (Integrity issue)
56
Allowing manual change to study plan
destroys integrity. Can no longer assume plan is
consistent with structure
57
What is needed Study Plan stage and versioning
Draft v1 Not yet approved. May not have
sufficient credit points Active v1 Plan
conforms with structure or is a certified
variation. If inconsistent with structure
approver explanation recorded on the plan Plan
remains locked until graduation. If change is
required a new version of the plan must be
created initially in draft until
approved. Active v2
58
Part 1 Evolution to improve performance Stude
nt convenience Staff administrative
overheads Part 2 Evolution to get a better
return on investment Better resource
utilisation Better integration
59
Claim The information contained in study plans
is a valuable resource for planning
Example Forecasting subject enrolments
60
(No Transcript)
61
Number of planned instances on study plans
62
What makes a subject attractive?
Infrequently offered, but offered in semester in
question
Bottom of a long requisite train
Many subjects are released once passed
What the Faculty has recommended in its published
program?
63
What makes an attractive subject feasible?
68032 20
35002 18
48210 18
48011 16
48001 10
48002 8
48003 6
68032 20
35002 18


48441 10
48730 8

Score
Clash check
64
(No Transcript)
65
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Cohort 1. Semester 1
Cohort 2 Semester 1
Cohort 3 Semester 1
Cohort 1 Semester 3
Cohort 2 Semester 3
Cohort 3 Semester 3
Cohort 4 Semester

66
Timetable
Forecast subject enrolments
Requ- isites
67
Part 1 Evolution to improve performance Stude
nt convenience Staff administrative
overheads Part 2 Evolution to get a better
return on investment Better resource
utilisation Better integration
68
Student self management demands tight integration
between systems
69
(No Transcript)
70
Student web Interface and workflow
71
SPlus
OCAP (In-house)
CIS (In-house)
Allocate
E-Request (in-house)
72
SPlus
OCAP (In-house)
Student System
CIS (In-house)
Allocate
E-Request (in-house)
73
SPlus
OCAP (In-house)
Student System
CIS (In-house)
Allocate
E-Request (in-house)
74
SPlus
OCAP (In-house)
Student System
CIS (In-house)
Allocate
E-Request (in-house)
75
SPlus
OCAP (In-house)
Student System
CIS (In-house)
Allocate
E-Request (in-house)
76
SPlus
OCAP (In-house)
Student System
CIS (In-house)
Allocate
E-Request (in-house)
77
SPlus
OCAP (In-house)
Student System
CIS (In-house)
Allocate
E-Request (in-house)
78
Student system Official record of students and curriculum Integrity
New course approval system Supports approval process Complex workflow
Publications system Produces any publication that uses official data Publication layout and editing
Timetabling system Determines the timetable Efficient room scheduling
Class allocation system Allocates students to classes Efficient student scheduling
Exception handling system Supports exception handling process Work flow
Core functionality
79
Each system augments the SS data with data of its
own
80
Additional data that needs to be stored
(timetabling
Availability pattern in future years How a
student experiences the subject (eg 1 hr lecture,
2 hr tutorial) Week patterns for each activity
type Resource constraint (maximum class
sizes) If more than one activity type, how
sequenced If multiple classes, how
distributed Room and equipment
requirements Staff pool capable of teaching
81
Institutional difference customisation at edges
Innovate at edges
volatile, operational data remains local
SS should develop capacity to store all data
needed
82
Only when SS has functionality better than
dedicated system Should dedicated system be
Abandonned. In the meantime need good interfaces
83
(No Transcript)
84
Conclusions Current system is an excellent
foundation for development Much could be done
with student interface Much scope for user
friendly management tools Flexibility needed to
enable full exploitation of specialist function
peripheral systems Taking on additional
specialist functions low priority Active user
group needed