Attendees: Jack Southard, University of Miami DARS representative; Roy Hermer, ACT; John McCleary, ACT; Holly Cartwright, ACT; Nancy Groves, Chair; Mike Kane, Thurgood Marshall; Myra Webb, Registrars; Lea Mizumoto, Warren; Sarah Spear, Eleanor Roosevelt; Ann Porter, Thurgood Marshall; Mary Quisenberry, Political Science; Todd Clopine, Five Colleges; Nieves Rankin, Biology; Brigitte Benoist, ECE; Kathy Pugh, Graduate Studies; Mae Brown, Admissions; Sherry Laver, Muir; Catherine Joseph, Warren; Helen Gunn, Revelle

Disclaimer: A great deal of information was covered, some of it more technical than the rest. Please feel free to contact me if any of the following is confusing or incorrect. I'll be more than happy to either research the question or direct you to a more knowledgeable person. A detailed description of the DARS system can be found on the web at: http://www.dars.muohio.edu/DARS_Handout.html

Synopsis: Jack Southard from the University of Miami, Ohio gave a demonstration of Miami's Degree Audit Reporting System (DARS). DARS was first written in 1983 and has been continuously upgraded ever since. Today, approximately 130 schools are using the DARS system including two UC's (Berkeley and Irvine), and SDSU.

Jack described the various components of the DARS system, detailing what DARS provided and what would be required of the customer. The "engine" of DARS - the primary programming that runs the system - is always maintained by the University of Miami - not by the customer. DARS is table-driven and the tables are maintained by the customer. This table setup allows each department, college, school to define their own requirements.

Other DARS Capabilities:

• Various portions of a student's Degree Audit can be run separately. Example: For an undergraduate student, the general education requirements only can be processed, or perhaps only the requirements for the major.
• "What Ifs" are allowed on the DARS system. If a student is considering a change of major, a degree audit could be run on the new major code to display how far along the student would be in that major.
• "What Ifs" can also apply to future classes, potential grades for work in progress, or grade changes. None of the information from these "What Ifs" is saved unless it is designated to be saved.
• Using the data from our newly created approximation tables, DARS can equate past, current or future transfer work to UC courses, and display them under the appropriate requirements.
• Exceptions to the various requirements are maintained in a separate table. Therefore, those exceptions do not disappear when future degree audits are run.
• Ninety-six (96) switches can be set to encode exceptions so they will display under the correct requirement. Even Mike Kane from Thurgood Marshall has grudgingly admitted this should keep him happy through 1998 - probably.

Components of the DARS System:

The following is a very simplistic breakdown of the various components of the DARS system.

• In the center of the DARS programs is the "engine" - the primary programs that run the system. These programs are maintained by University of Miami, Ohio - not by the customer.
• Surrounding the engine is the driver program that massages data from the tables to be fed into the engine
• Various tables are defined to store information about students, courses, requirements, approximations, and general requirement policies. These tables are maintained by the various colleges, departments, schools and administration at universities. They can be broken into two primary categories: Student Tables and DARS Tables.
• The web is the final component as it is the interface between users and the rest of the system.

As noted above, the tables are separated into two categories:

Student Tables

• Basic Student Information: Name, PID, major, entering catelogue are examples of student information stored in this table.
• Academic History: All courses (and even potential future courses) taken at the client-university would be maintained here.
• Transfer Courses: Courses taken at outside institutions and transferred are stored in this table. Once processed by the system, these courses can reflect as university approximations.
• Exceptions: Almost all exceptions would be stored here. Examples: allowing a student to use a course with a 'D' when normally a 'C' grade is required. Swapping courses would permit a student to use one course in lieu of another required course, etc.

'DARS' Tables

• Definition of University Requirements: How gpa is defined and computed is an example of this type of requirement. These requirements are usually fields the institution only has to define once.
• UC Course Conversion: When departments re-number classes but the content remains the same, this table equates old and new course numbers. It can also determined if a transferred course should be considered as duplicate credit to an in-house course.
• Repeat Tables: Limits can be set on the number of times a course can be taken. An example of this is the number of times a student is allowed to take Gospel Choir for a grade.
• String Table: Determines eligibility if a requirement is not met unless two or more sequenced courses are taken, or if a foundation course is necessary before the requirement is met.
• Other Requirements: Major requirements, general education requirements, SubjectA, and AH&I are examples of requirements that would be defined in this table.
• Restraint Limits: Definitions in these tables can include themaximum number of 199s allowed, maximum number of courses that can be taken P/NP, and the number of graded units required to receive college honors would be defined here.

Students' Use of the DARS System:

The students would also have secured and limited access to their own records on DARS. The following are a few examples:

• Students currently have access to their own records (StudentLink) and will eventually be able to produce degree audits for themselves.
• An audit can be programmed to list deficiences, and then to list possible options for meeting those deficiences.
• From the same location where the degree audit is produced, the audit can be emailed to advisors, professors, etc.
• Students interested in transferring from outside institutions will be able to produce an audit of their current work to see how they are progressing toward their transfer. Approximations tables would be used by the system to produce university equivalencies for the transfer work.

If the DARS system is decided upon by UCSD and a consensus can be reached quickly, ACT still hopes to maintain their target date of December 1997 to go on-line with UCSD's version of the Degree Audit System.

Please contact Helen Gunn (x41575) if you have any questions or corrections to these minutes.

Return to Act's Degree Audit Home Page