The Second Time's a Charm and on the Web for Degree Audit at Maryland
Tripti Sinha, Senior Systems Analyst, University of Maryland, Academic Data Systems, [email protected]
Jeff Lemich, Assistant Director, University of Maryland, Academic Data Systems, [email protected]
--As the title suggests, this is Maryland's second attempt at building a degree audit system. Although some of our colleges successfully used the old system, it just wasn't built with sufficient flexibility to accommodate all the complexities needed to fully audit all students. This paper will describe the approach we took to building the new system, and more importantly some of the problems we encountered along the way.
The Web-based degree audit system was developed in-house and released into production in February 1998. The proposal to build such a system arose from the need for innovative and automated advising and degree audit tools. The existing system had become cumbersome and outdated. With the advent of the Internet it became imperative to provide better tools at the desktop not just for academic advisors but for students as well.
When we first embarked on this project, we surveyed a number of institutions to see what they were doing in this area in the hopes of finding a product that both worked and had a nice, yet simple, interface. At the conclusion of our search, our campus decided to go ahead and try to develop its own product internally.
Why develop it in-house?
Objectives
When we kicked off the project we kept three objectives in mind. First, was that the system be independent of the database on which our student information system resided. At the time we had no real-time Web access to mainframe data. However, there was an advising data warehouse to which we had access. Also there are plans to possibly change our production database software. By taking this approach of source data independence, we achieved a lot of flexibility.
The second objective was that the core of the system be independent of the user interface. At the time when the system was being designed, the Web was not as mature as it is now. Many potential users only had access to character based interfaces. And we knew we wanted the output printed as well as online. By separating the main logic from its presentation future interfaces could be easily added.
The third objective was that the logic be written to be as generic as possible, with no hard coding of policies and exceptions. The system would be designed to be rule-based in order to minimize the amount of internal maintenance, thus making it more attractive for distribution to other Maryland institutions.
The major strength of this system has indeed been its three-tiered architecture, separating the data access layer, the business logic layer, and the presentation layer. This architecture has allowed this system to develop without major reconstruction during a time when technology was moving very quickly. Additionally it provides the system with a robust foundation. When this project was conceived the Web was in its infancy. Today, when the Web is certainly a universal standard and as additional capabilities become commonplace, the Audit System will be able to utilize them without much revamping.
End-user Participation
The University of Maryland is a large campus with thirteen colleges and 33,000 students. Gaining user input for this system was imperative. We established a small user group that represented the colleges and embraced their participation. Initially the shortcomings of the first degree audit system were examined in depth. In this system the language used to represent requirements was difficult and not rich enough to describe all requirements. Additionally, the language was difficult and somewhat cryptic. To make matters worse the colleges were expected to build their major requirements themselves using this cryptic language. At our user meetings we concurred that building of requirements for the new degree audit system should be centralized and managed by a single authority. Another limitation of the old system was that it was not available to students. The new system had to be designed such that it would be an outreach tool for students to use. It would allow auditing of a student’s major as well as "shopping around" for other majors, and enabling students to audit themselves for other possible majors of interest.
At our institution departments and colleges frequently customize some major requirements for individual students such that they deviate from the standard set of requirements. Advisors who have the right authority level do such customizations. These exceptions, as they are called, are stored on paper. The user group requested that the process of customization be automated. This lead to the creation of the Advisor/Advisee system, which handles relationships between advisors and advisees and corresponding security and authorization, levels.
The users also informed us that they wanted the new system to take advantage of the new capabilities that were emerging with graphical user interfaces. The old degree-audit system had a character based client front end. It was decided that the new system make available a presentation layer that was graphical. With the Web becoming increasingly mature, this layer is now the Web.
Specifications
How would we tackle specifying and auditing major requirements?
--One of the primary challenges of the project have been in developing a language flexible enough to describe the myriad of degree requirements for the more than 130 majors on the campus. Major requirements come in a variety of shapes and forms. Some requirements are a simple list of courses in which all courses in the list must be taken. In other requirements there are sets of courses available in which the student may choose a particular set only. Sometimes there are minimum grade or GPA requirements for the whole major or for part of the major. Often there are complex choices between courses. It was evident that the language should be able to handle such types of specifications. Upon examining the major requirements, a language syntax was developed.
--In addition to a language it is important to develop a method of processing it. The method chosen was to utilize a binary tree structure. A binary tree describes a set of nodes where each node may be connected to only one parent node and no more than two child nodes. This structure allowed for our definition of operators and expressions to represent nodes. Operators enable the representation of functions. These functions are standard Boolean operators such as "and", "or", "not", and other self-defined functions like "sets" and "groups". Expressions enable the representations of course names, sections, minimum/maximum credits, etc. The binary tree methodology allows for any level of complexity to be represented. Also it helps to facilitate optimization of the audit process.
Discussion of Audit System
--The system consists of six components: major requirements builder, audit engine, contract builder, advisor/advisee system, batch system, and client front-end. The major requirements builder is used to specify requirements and uses a language that generates a binary tree representation of requirements. It consists of operators and expressions that enable the construction of Boolean-like expressions. The audit engine traverses the binary tree of requirements, matches them with the student's records and produces a result. Degree auditing is essentially a very intelligent human process with a high degree of computation. This process is what is built into the audit engine. Some major requirements are customizable in that students may choose their own set of courses. An interactive contract builder handles such requirements where students specify courses that they would like to use towards requirements. These selections are then approved by the advisor/college. --
Major Requirements Builder
--The major requirements builder module was written in PowerBuilder and resides on a Novell Server. The requirements builder gives the user an easy tool for building major requirements. It's drag and drop feature eliminates the need to memorize the syntax of the language. Another important aspect is the management of the versions of specific requirements as they change over time. When storing requirements the language is checked for possible syntax errors. The requirements builder is also responsible for converting the language to the internal binary tree format. This is done with the combination of both expressions and operators to which the requirements builder applies precedence rules to build the binary trees. These trees are then stored in a database.
Audit Engine
--The audit engine essentially handles the auditing of requirements. The engine has two primary inputs: major requirements and the student's course history. Other inputs allow for the preprocessing of course data to resolve interdependencies such as cross lists and equivalencies. Other existing systems handle transfer course articulations. The engine begins its work by first preprocessing the student's course data. At the University of Maryland courses have several interdependencies, i.e. some courses have one-to-many and many-to-one relationships with each other. For example two different departments under two different names offer some courses, though they are essentially the same course. Such courses are referred to as "cross-listed courses". Additionally, our university has a large pool of incoming transfer students who transfer in courses from other institutions. These courses are evaluated to be equivalent to courses on this campus. Relationships between courses of this nature our first established by the audit engine. Following this the engine extracts all needed requirements from the database. Auditing begins with a traversal of the tree. During tree traversal nodes are visited. According to the type of node visited (i.e. operators vs. expressions) certain tasks are performed. During the traversal of the tree a number of optimization tasks are performed. For example if an 'OR' condition is satisfied further processing for that sub-tree is terminated. In other cases courses may be reused to satisfy more than one set of requirements within the major. At the end of traversal an audit result is computed. The engine then sends its results and corresponding data to a flat file. This output is stored in a "raw" format.
Advisor / Advisee System
The Advisor / Advisee System is used for two purposes in the Audit System. First it establishes a relationship between students and the faculty or staff members authorized to advise them and second it specifies the authority the advisor has within that relationship. At the University of Maryland each college establishes how they wish its students to be advised. Some colleges take the traditional approach and assign students to individual faculty advisors. Other colleges assign groups of students to teams of professional advisors. While still others will use a mix of both techniques. It is also common for a student to have more that one advisor. Students taking double majors may have an advisor for each, and students in special programs like athletics, pre-professional, and honors may also have special advisors. In addition to assigned advisors, departments and colleges always have a number of administrators who may advise any student within their unit. Knowing who may advise each student is very useful but not enough for auditing purposes. Advisors do more than just recommend courses. They may also clear registration blocks; plan with the student educational and career options, and makes special exceptions to degree requirements. It is imperative that the specific capability of an advisor be established for any given relationship with a student. The Advisor / Advisee system allows this security to be defined in a number of ways. An advisor's basic security is established for each track within a major. This basic security then may be restricted further with a number of attributes. For example some advisors may be restricted from viewing advising records to only students directly assigned to them, while others may be able to access any student in a track but only make exceptions to assigned advisees. Some advisors may be allowed to make exceptions to major requirements but may be restricted from making changes to core requirements. Further advisors may be allowed to make only particular types of changes within a track, such as course to course substitutions, minimum grade requirements, or changing the number of courses or credits needed for a requirement.
Contract System
This system is driven by the data in the Advisor/Advisee system. It allows in some cases for students to customize their major requirements. Advisors using the advisor privileges stored in the Advisor/Advisee system may then approve or reject these customizations. The Contract System allows tremendous flexibility in terms of exceptions that need to be made for some students. These exceptions are made frequently. Currently this process is done on paper.
--
Presentation Layer
--One of the strengths of the Audit System has been its three-tiered architecture. The presentation layer is separate from the business logic. Using the raw data produced by the engine the presentation layer is generated. When the project was started the Web was in its infancy. At that time the presentation layer generated was for a simple ASCII output. Today this layer has evolved to present on the Web as well. And there is yet another presentation for a paper batch process.
The client presentation layer of the system essentially provides an interface for the end-user to be able to invoke the audit engine for a major audit, display the results, customize a requirement and approve (in the case of advisors) customizations. This layer controls all security and authorization levels embedded in the system. It will query the student data repository with appropriate calls to extract course data that is fed into the audit engine. It checks authorization levels of advisors and so forth. Essentially the presentation layer acts as a "glue" and integrates all the different components of the Audit System.
Batch Process
--A batch process is also available which is currently under refinement. This process allows a list of students to be audited in batch against a selected major. The list of students is generated with an academic advising warehouse. This has been particularly helpful for mass audit of students required by college offices.
Conclusion
The development life cycle of this system has come with its fair share of problems and there are several things that we have learned from this undertaking. One is that implementing an academic degree audit system is not an easy task to do -- both from the technical as well as the administrative perspectives. Another -- which is a corollary to the first -- is that it is probably impossible to implement an academic degree audit system, whether built or bought, that satisfies the wide scope of expectations of a large and diverse advising community.
Some of the daunting challenges of the system have been in its inherent complexity. The audit engine attempts to perform a fairly intelligent task normally conducted by humans. Thus, this system resembles an artificial intelligence system. Furthermore it was realized that the task of building major requirements required sophisticated end-users with a fine technical understanding of Boolean logic. This was something foreign to most of the other transaction processing systems built at our institution where the end-user did not need to be technically sound but simply required a fine understanding of their business rules and needs in order to run a system. Another problem has been the lack of a full-time user project manager. A system as complex and big as the Degree Audit System requires an aggressive full-time individual who can successfully direct and market the product, and achieve end user buy-in.
Rather than viewing a degree audit system as a tool that satisfies 100% of the advising function, it is best to view it as a tool that does X % automatically very well, and provides good tools to do the remaining manual functions more efficiently. This would reduce the advisor’s work proportionately.
We have learned that it is very important to initially take the time to create a "destination" that clearly defines the services and functionality that such a system will be expected to deliver. This "destination" should emerge from a formal and systematic process that integrates input from the user and technical community, bringing technical, staffing, and budget realities into the mix. This should reduce the possibility of the "growing scope/expectations" syndrome. Additionally, the importance of a full-time user project leader, as well as full-time administrative support for the building and maintenance of academic requirements cannot be over-emphasized.
The system has been a moving target and we expect its growth to continue in this manner. But since its Web release this past February, the feedback and response that we have received from students has been overwhelmingly positive.
--You may try out the Audit System and other University of Maryland Web applications at http://www.testudo.umd.edu. Instructions are available on this site for using a test ID that will allow access to most secured applications.