This is a summary of a poster session presented at the 1993 CAUSE Annual Conference held in San Diego, California, December 7-10. It is the intellectual property of the author(s) and may not be published without permission. Disseminating the material otherwise is permitted, provided that the author(s) and the original presentation of the 
paper at CAUSE93 are acknowledged. 


A SUCCESS STORY OF IN-HOUSE DEVELOPMENT OF A STATE-OF-THE-
   ART STUDENT INFORMATION SYSTEM AT THE UNIVERSITY OF 
                   MARYLAND/COLLEGE PARK


INTRODUCTION

Buy or develop? That's the question. Many directors and 
administrators of University DP shops confront this question 
under dwindling resources and shrinking budgets. Five years 
ago, the University of Maryland at College Park decided to 
develop a in-house Student Information System. It comprised 
1,500 programs that were housed in the UNISYS 1191 and 
Hewlett Packard 3000/64 to  a new IBM 3090 mainframe. The 
Student Information System (SIS) serves seven  major user 
areas including undergraduate and graduate application,  
registration and grade processing, advising, degree 
clearance and transcripts, and course management and 
scheduling.  Rather than simply converting all  existing 
programs from one system to another, the campus used this 
opportunity to re-engineer and improve the way some offices 
did business with the student and academic community, as 
well as the way the system interacted with its  users. The 
office of Academic Data Systems (ADS) was charged with the  
development of the new SIS. A task force consisting of 
members from ADS and  the user community was formed to map 
the goals of the new system, create a migration methodology 
and establish resource requirements.

DEVELOPMENT REQUIREMENT

During development, the campus should not be disrupted in its  
educational mission and users should continue to function 
with no loss of service. While we were migrating, current 
systems and the developing systems needed to be synchronized. 
The migration was not a straight conversion of the systems 
'as is', but provided increased functionality whenever 
possible. Any additional function that were not possible 
during the basic migration occurred afterwards. The 
prioritization of how the various SIS systems were migrated 
was based on user needs. Additionally, the 15-year old 
Student Records system residing on the UNISYS was given 
priority because of the age of the system and a campus 
mandate. It was estimated that the basic migration would 
occur over a three year period. Long before the entire system 
completed, it was necessary for all SIS users to begin 
reaping the benefits of the new  system. As the first step in 
the migration, the decision was made to populate 
and maintain a full, up-to-date SIS database on the IBM.

OLD SIS PROBLEM

There were problems. System access was limited only to first-
line  users, such as admissions, records, registrations, etc.  
Advisors and administrators at colleges and departments had 
no direct access to the information other than via paper. The 
overall look and feel of all  the online programs was very 
inconsistent. This also caused problems with  training. It 
was often painful for a user to move from one online program  
to another, and search-type data such as student ID numbers 
had to be  re-entered each time. Control card parameters for 
nightly batch programs were entered by production control 
staff at the computer center via paper forms that were 
submitted by the user. Errors in the entry process often led 
to erroneous parameters being supplied, resulting in aborted 
jobs. Ad-hoc requests for information always required that a 
program be written; hence these requests require a 
programmer's time. Because security to access individual 
online programs was hardcoded, it also required programming 
effort whenever a user wished to limit or expand program 
access. Certain services  to students, such as enrollment 
verifications and requests for official  transcripts, though 
semi-computerized, were provided in a nightly batch mode  
and required much manual sorting and checking.

SIS DEVELOPMENT GOALS

The ADS staff met with the various users to determine what 
new  capabilities and functions they envisioned for their 
respective systems.  The programming staff, many of whom had 
worked very closely with the users  for years, provided much 
input to this process. As a result of this  interaction with 
the user community, the following goals and objectives  were 
incorporated into the re-engineering process:

1)Information should be made available to colleges and 
departments either via direct access on the mainframe where 
appropriate, or via regular data download to smaller, 
individual platforms. 

2)All online programs and reports should have a common look 
and feel across sub-systems, and navigation between online 
programs should be simple and should minimize re-entry of 
key information.

3)The security mechanism that allows entry to various online 
programs and sub- systems should be dynamically controlled 
by designated managers in user offices, thus eliminating the 
need for a programmer's involvement. 

4)Users should be able to process a high percentage of ad-
hoc requests themselves without the need for programming 
support. 

5)Control card parameters for nightly batch jobs should be 
entered directly by the user, rather than by a third party, 
with the benefit of immediate editing. 

6)To improve service to its clientele, user offices should 
be able to provide on-the-spot service whenever possible 
rather than overnight.

NEW SIS HIGHLIGHT

As a result of all this effort, the student services offices 
across campus have enhanced the way they do business, and in 
turn the quality of service they provide to students and 
faculty.  Below are some concrete examples:

1) A fully integrated online navigation system was developed 
that allows  users to go from screen to screen, program to 
program, and sub-system to sub-system with minimal effort. 
The system 'remembers' key information  between transition 
to minimize re-entry of data. Student information is 
available by ID number or name. All function keys are 
standardized. 

2) Online help is available and text can be entered by the 
user. The help can  be brief, or it can provide full 
documentation. 

3) The system allows a manager to dynamically set security 
for his or her system. Within seconds, access to any 
particular program or sub-system can be provided or denied 
by the office manager. In view of existing budget 
constraints, this capability has been particularly useful 
when user offices share personnel at various times during 
peak periods of activity.

4) 'Super selection' programs are available that allow the 
user offices to  satisfy ad-hoc requests for information in 
a query-by-example mode.

5) A walk-in information request system was implemented that 
allows students  to pick up, or have mailed to the desired 
destination, official transcripts and enrollment 
verifications. Under the old system, this task sometimes 
required as much as two weeks to complete.
 
BENEFITS OF IN-HOUSE SIS DEVELOPMENT

The major reward from all of this work and effort for the 
programming staff in ADS has been the satisfaction of seeing 
improvements that are tangible and visible on a daily basis.  
The new system has empowered users by placing more 
information at their fingertips, and by allowing them to 
take control with the service aspect of their operation. At 
the University of Maryland, every office is charged with the 
responsibility of improving service to students and faculty. 
By enhancing the way that various campus units deal its' 
clientele, ADS feels that it has contributed to that 
mission. The benefits of the in-house development are 
enhanced application  software, flexible application 
software maintenance, maximization of user input through 
frequent user testing, quick return of investment of 
programmer training, conversion of programmer's new 
technology into another system development, high programmer 
and user morale, and substantial cost saving.

WHY THIS EFFORT SUCCEEDED

Several distinctive factors contributed to making ADS 
developmental efforts a success. The first was timing. The 
approach of cost-effective in-house development  gained 
support from campus administrators during the budget 
constraint of 1991. It was necessary to develop, in house, a 
system that should accomodate the University's policy 
changes. If we had purchased a package, we would have had to 
pay exorbitant fees whenever policy changes were made. When 
creating SIS, the developmental goals had to satisfy the 
University's mission to provide flexible computing services  
to all levels of users. Second, frequent communication 
between users and programmers was a vital element to our 
success. No developmental effort can succeed without direct 
user involvement. Third, ADS was lucky to have able, 
dedicated programmers who were willing to learn and grow. 
From the Director to student programmers, one objective was 
to program efficently.  Finally, state-of-the-art computer 
technology has provided tools that fuifill developmental 
goals.    


Jacob Lee, Systems Analyst,  Email-jlee@deans.umd.edu
Barbara Riggs, Assistant Director Records and 
Registrations
Email-briggs@record1.umd.edu


Date Revised: 02/24/94 (bdz)