Newsgroups: bit.listserv.cumrec-l
Date:         Tue, 8 Sep 1992 16:34:11 EDT
From:         Jack Southard <SOUTHARD@MIAMIU.BITNET>
Subject:      Re: Degree Audit Software

While I'll agree with Jeffrey Bell that as degree requirements become more
complex you have to be more sure that any packaged software you might acquire
will actually do what is needed.  However, I must take exception with the
statement that "you cannot realistically expect your degree programs to conform
to whatever predefined templates are available with a third-party package."
Although Jeff does point out that "you must find a package that fits YOUR
environment, or else develop your own," he does not seem to hold out to much
hope for the former prospect.

In 1983 when we started to develop the original Miami University degree audit
system - we didn't know where that would take us.  But 101 schools later (and
many many many enhancements) I believe we found that our original design model
did have enough flexibility for DARS to process some of the most complex
requirements found in the US or Canada.

My primary purpose in commenting is that I have been on record since my
AACRAO presentation in 1990 that a school which is considering developing its
own degree audit take a very close look at what is available from someone else
before they commit those resources at home to a task that is never ending.
We have encouraged that review by hosting a series of Computerized Degree
Audit Workships to address just the complexity Jeff aludes to.  The 14th one
those workshops will be held at Miami University on October 25-28.  Contact
me for additional information or if you have any degree audit related
questions.


Jack Southard
Assistant Director, Research and Special Projects
The Computing Center
Miami University
Oxford, OH  45056
(513) 529-5360.


On Fri, 4 Sep 1992 14:13:41 EDT Jeffrey R Kell said:
>They key issue between developing something in-house versus packaged software
>is (obviously, but often under-researched) how well it fits your requirements.
>You cannot realistically expect your degree programs to conform to whatever
>predefined templates are available with a third-party package, you must find
>a package that fits YOUR environment, or else develop your own.
>
>If your catalog requirements are simplistic and can be defined with simple list
>operations (eg, take a, b, c; select x courses from a, b, c...; etc) then you
>face a relatively simple task.  If, however, you have complex interactions
>between requirements, pre- and co-requisite structures, ill-defined elements
>within requirements (eg, select from "humanities"/"fine arts"/"natural science"
>etc., which are volatile sets of courses) and other complications you may have
>to develop your own system to insure it will fulfill your needs.
>
>We ended up developing our own system.  It is largely table driven, with data
>exceptions available by student or by degree, but it also has the capability
>for actual hard-coded exits by degree/catalog year at any point in the
>processing cycle.  This allows us the flexibility of coding any arbitrary (and
>believe me, some of them are QUITE arbitrary!) requirement that doesn't happen
>to fit into a neat, elegant table structure.
>
><Jeff>
>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
>| Jeffrey R Kell, Dir Tech Services | Admin Postmaster/Listserv co-ord. |
>| Admin Computing, 117 Hunter Hall  | Bitnet:  JEFF@UTCVM.BITNET        |
>| Univ of Tennessee at Chattanooga  | Internet: jeff@utcvm.utc.edu      |
>| Chattanooga, TN  37403-2598       |   or jeff_kell@admin.utc.edu      |
>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU