Newsgroups: bit.listserv.cumrec-l
Date:         Mon, 28 Sep 1992 09:18:36 GMT
From:         Roy Martin <CCSYS005@CCSUVM1.BITNET>
Subject:      On-line Registration Systems

In reply to:  "Mike Dieckmann (216)775-8795" <BMIKE@OCVAXC.CC.OBERLIN.EDU>
Subject:      On-line registration systems

Mike,

We've been using our online registration system at CCSU for about two
years now.  I have pretty much been the only programmer/analyst working
on the student information side of it.  (We have one other programmer
who has done the FINANCIAL AID, and much of the Billing System side.)
We average 4000 students a semester, so our size is similar to yours.
We decided to write our own system.  (IBM SQL/DS as the database, with
CSP as the language hitting against it.)  We're CONSTANTLY in development
mode - enhancing, refining, and adding new capabilities.

In answer to some of your questions:

1.  Did you go with phone-in registration via touch-tone telephone (which
    appears to be the latest fad) or with some other method?  How did you
    decide?

We originally designed the registration programs to be terminal driven.
We were actually forced into that by the fact that our phone system
couldn't handle the load that a telephone registration system would bring
on it.  Even if it could have handled the load, though, we probably would have
opted for starting with a terminal-based system, and phasing in a phone
system, (which is what we are in the process of doing now).  Being able to
talk with the terminal operators and WATCH the flow of students through the
system has been an immeasurable help in redesigning the system to make it flow
more naturally.  (Plus it's kind of fun being able to personally point out to
all the students who actually wait for regular registration and end up with a
bunch of closed classes that they *should* have taken advantage of EARLY
registration!)    Really, though, designing a phone system is a major task
of its own.  It's much easier to build into it, after having already designed
much of the rest of the system first with a terminal based system.

We will maintain our terminal registration system even when the phone system
is complete.

2.  What was the policy making body for deciding on how the system would
    function?  Merely the registrar?  Or others?

DON'T RELY ON JUST A COUPLE OF OFFICES!  I know that committees are no fun, but
if you design the system without giving every department at least SOME say
in the flow of the system you're asking for nothing but complaints and
resentment.  Remember, also, that since you've been doing it in batch mode
for so long, the tendency will be to reproduce in the new system, procedures
that were put in place merely because that's how you HAD to do them
in the batch mode.  Brainstorm with department heads a little bit.  Many of
them have probably had experience at some other school that had their
registration system on-line.

(Plus, they'll all buy off on the new system, bugs & all, if they helped
design it.)

3.  Do you have any metrics on how many units are needed to serve students?
    (For example, it takes a student 30 minutes to register, therefore with
    XX terminals our system can serve XX students per hour ....).

The average time at the computer for each student varies: between 2 & 4 min.
(But remember, your system will vary, depending upon the amount of streamlining
you do, and the size of your computer & software it's running.)

4.  What are the major lessons you learned in this effort?

Spread the load over time!  We use an appointment system at CCSU.  Each
student is assigned a time and day to register.  They may register any time
ON OR AFTER that time.  This time is printed on a label we afix to their
Class Scheduling Form that they pick up at the Registrar's.  The forms are
what the student writes their schedule on, and are available about one week
prior to the start of registration.  For EARLY registration student times
depend on how many hours they've completed toward their degree.  Those with the
most hours, (and thus closest to graduation), get the first time slots.
We will register about 75% of our students during early registration.

For REGULAR registration, we merely use a rotating alphabetical order.
The scheme isn't perfect, but most students say it's fair and none have
suggested a different method of assigning times.

HAVE THE COMPUTER ENFORCE THE TIME!  Don't make some poor terminal clerk have
to tell an irate student that they are too early.  It's so nice for the clerk
to be able to "blame it on the computer".  (We store each student's
appointment time in the computer and look it up prior to accepting that
student's PIN at the registration main menu.)

5.  How did you TEST your system?

We created a test semester and merely ran alot of operators into a room and
had them register bogus student records.  We also made sure that the first
semester we came on-line for real was one of our slower ones.  We did our
first registration during a summer semester which is traditionally slow.
Thus when the inevitable bugs turned up, we didn't inconvenience too many
students.

Good luck!  Remember, (especially when you start putting in overtime), that
the students are going to love you for the new system you'll write for them.
(Ours sure did.)


||-------------------------------|-----------------------------------||
||   Roy Martin                  |  CORPUS CHRISTI STATE UNIVERSITY  ||
||   Programmer/Analyst &        |  6300 OCEAN DRIVE                 ||
||     GOD (Guardian Of Data)    |  CORPUS CHRISTI, TX  78412-5599   ||
||                               |     PHONE: (512) 994-2693         ||
||   CCSYS005@CCSUVM1            |     FAX:   (512) 994-2366         ||
||-------------------------------|-----------------------------------||
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU