Student Systems
ISTIP
Project Control
Document
Degree Audit Replacement System
1. Introduction & Purpose
1.1. Purpose
The ISTIP Degree Audit Enhancement project has two initiatives:
1. Enhancements I and II to the current Degree Audit system (Current System)
2. Development of the replacement Degree Audit system (Replacement System)
This
Project Control Document is written to establish the scope, schedule and
assumptions for the Replacement System. The
Enhancements I work has already been specified and is scheduled to be completed
by
1.2. Audience
The audience for this document is the Degree Audit Stakeholder group:
· Administrative Information Systems
·
· Graduate Division
· Registrar’s Office
· Student Academic Services
· Undergraduate Admissions
Since the Replacement System is intended to meet campus needs, other campus representatives will be involved at the discretion of the Student Executive Group, the Student ISTIP Management Group, or the Degree Audit Stakeholder group.
1.3. Description and History of Project
In the winter of 1997 a functional
review was undertaken to determine exactly what the University needed in an
improved Degree Audit System. Robert Kilgore chaired a committee of individuals
from all major campus constituencies (College Honors, Graduate Division,
1.4. Summary of Work to Date
The Degree Audit Stakeholders analyzed commercially available audit
systems and determined that four of the five systems were unsuitable for use at
UCLA:
·
On
Course – not detachable from SCT’s integrated Banner system (a complete student
record system)
·
Degree
Navigator – extremely limited functionality with very small market share
·
·
PeopleSoft
– degree audit component under development will run as part of their integrated
student record system.
After careful consideration of the effort involved in developing an
entirely custom system, the system architect and key ISTIP stakeholders
concluded that a system combining the strengths of each approach – commercial
system and custom development - would serve the campus best. The most popular
audit system – DARS from
This architecture has the potential to substantially reduce long-term
programmer efforts, broaden the number of coding “experts”, and leverage
existing training resources. The Degree
Audit Stakeholders unanimously approved the combined approach, favoring over
both a full custom development and the full adoption of a commercially
available package.
DARS is currently available as both a mainframe-based system and a client
server based system but the user base – and support – is rapidly migrating to
the client/server system. The mainframe-based system had been evaluated and
rejected in 1997 as being functionally unusable. The Stakeholders recommend the
client/server version of DARS and all references in this Project Control
Document are to the client/server version.
The architecture for the system is diagramed on the following page.
1.5. Description of Approach to Managing Changes to Scope, Schedule, and Assumptions
The Degree Audit Stakeholders are responsible for identifying and managing changes to scope, schedule and assumptions. Changes will be logged in the Issues Tracking Database – http://istip.ais.ucla.edu/DA.htm. The Stakeholders are responsible for bringing changes to the attention of management: the monthly ISTIP Management Group or the quarterly Executive Committee. All approved scope changes will be reflected in the Project Control Documents and work plans.
2. Scope
2.1. Introduction/Description of Bounds of Project
The
Replacement System will be designed to produce certified degree audits for all
UCLA students: undergraduate, graduate
and professional (except Medical and Dental which maintain their own course
records). It will be used to articulate transfer credit for UCLA students,
providing information to the student record database and supporting enrollment
logic.
Through the application of technology, it is feasible that the way students plan their course work could be changed. Combining course information and degree requirements, it will be possible to produce a student ‘plan’ of courses leading to graduation, opening the potential of advance enrollment or reservation in courses, providing data to schools and college for advance course planning, and potentially improving our ‘quarters to graduation’ measure.
2.2. Project Objectives
The replacement system will be designed to enable the accurate auditing
of all students who utilize the central functions of the Office of the
Registrar. It will support distributed
application of the most common substitutions and exemptions and will automate a
significant part of the ongoing manual application of transfer course
articulation. Additionally, it will
provide the necessary resource to inform course planning at the school,
college, and department level. The
system will be developed so as to allow for the creation of the “Student Plan”
which if supported by central campus offices will significantly reduce the
“quarters to graduation” measure for undergraduates.
2.2.1
UCLA Student Web Access
· Students will be able to request and receive graphic representations of their progress towards their degree including university requirements, general college or school requirements, major requirements, minor requirements, concentration requirements, and/or specialization requirements, as appropriate
· Students will also be able to model alternative majors, minors, concentrations and/or specializations via the web
· Students will be able to request a list of classes which will optimize meeting unfilled requirements
· Students will be able to develop and “fine tune” a plan for enrolling in classes through graduation
·
Students
will be able to request information on how a non-UCLA course will transfer to
UCLA for schools where UCLA has established articulation agreements. We expect that this feature could also be
used for prospective students.
·
Students,
and prospective students, will be able to check for lower division major
preparation course requirement that are satisfied by non-UCLA courses where
UCLA has established articulation agreements.
2.2.2
UCLA Counselor Web Access
· Counselors will be able to request and receive graphic representations of their students progress towards degree including their university requirements, general college or school requirements, major requirements, minor requirements, concentration requirements, and/or specialization requirements as appropriate
· Counselors will be able to model their students into alternative majors, minors, concentrations and/or specializations via the web
· Counselors will be able to request a list of classes which will optimize their students remaining requirements
· Counselors will be able to approve or deny changes to their students plan for enrolling in classes through graduation
· Counselors will be able to use simplified web screens to grant standardized substitutions and exemptions for their students
2.2.3
UCLA Admissions Access
·
Staff will establish and maintain, via the web and the
·
Based on transfer articulation rules encoded and maintained by the
Undergraduate Admissions Office the majority of transfer credit will be able to
be systematically articulated into UCLA equivalencies or title credit for
non-UCLA courses at postsecondary institutions where UCLA has established
articulation agreements.
·
Transfer
credit will be applied based on standardized tests (AP, IB), combinations of
coursework from one or multiple schools, and the completion of standardized
sets of courses, e.g. IGETC, for satisfying UC requirements and UC reciprocity.
·
Staff in
the Undergraduate Admissions Office will review and update transfer credit
articulation agreements on a regular and ongoing cycle based on changes in
acceptable transfer credit courses approved by UC and postsecondary
institutions’ catalogues.
·
Staff in
the Undergraduate Admissions Office will enter individual transfer credit
courses for new, re-entering, and continuing students and certify that the
credit is appropriately entered and applied to UCLA courses and
requirements. Undergraduate Admissions
Evaluation staff will make manual adjustments to transfer credit as needed.
·
Both raw
source transcripts as well as articulated transfer work will be stored and be
available for ad-hoc analysis.
2.2.4
UCLA Degree Auditor Access
·
Degree
auditors will be able to request and receive graphic representations of degree candidates’
program completion status including their university requirements, general
college or school requirements, major requirements, concentration requirements,
minor requirements, and/or specialization requirements as appropriate
·
Degree
auditors and other interested parties will be able to query the degree audit
system to determine the program completion status of students with a selected
degree expected term, major, minor, specialization, etc.
·
Degree
auditors will be able to identify shortages on degree requirements and transmit
this information to students in a timely fashion
·
Degree
auditors will be able to monitor the completion of outstanding requirements
throughout a student’s expected term of graduation and, if necessary, in
subsequent terms
·
Degree
auditors will be able to use simplified web screens to input standardized
substitutions and exemptions for degree candidates
·
Degree
auditors will be able to certify students for graduation based upon the output
of the degree audit system, with minimal need for detailed review and/or
departmental approval
·
Degree
auditors will be able to award degrees and notify students of degree completion
in a more automated fashion
2.2.5
UCLA Administrative and Curriculum Planners in the Schools and College Access
·
All
course work and requirements would be available to support enrollment planning
and projections.
2.3. People and Processes Covered
2.3.1. People and Organizations
· AIS staff
· College staff
· Graduate Division staff
·
· Registrar’s staff
· Students
· Undergraduate Admissions staff
2.3.2. Processes - this section will be completed in the “Proof of Concept” phase
2.3.2.1.
Student
Access to and management of degree progress information
· Obtaining degree progress information.
· Organizing and viewing degree progress reports through various modalities
· Accessing information about transfer course articulations.
· Using degree progress information to construct course plan.
2.3.2.2.
Counselor
use of degree progress information as an advising tool
· Explaining degree progress information.
· Organizing and viewing degree progress information.
· Using degree progress information to detail enrollment options
· Controlling student enrollment options
· Approving/denying changes to student’s program
2.3.2.3.
Admissions
procedures for organizing, codifying and storing student data.
· Organizing, storing and accessing admissions data received from postsecondary institutions
· Entering student’s raw data received from postsecondary institutions with which UCLA has an articulation agreement
· Entering student’s raw data coursework received from postsecondary institutions with which UCLA does not have an articulation agreement
· Establishing UCLA equivalencies for standardized tests and coursework
· Maintaining (updating) existing articulation agreements
· Increasing the number of schools with which UCLA has articulation agreements
·
Storing and
obtaining access to raw source transcripts and articulated transfer work
2.3.2.4.
Degree
Audit procedures for evaluating student records
· Organizing and viewing degree progress information
· Assessing student progress to degree
· Monitoring completion of outstanding graduation requirements
· Awarding degrees and notifying students of degree completion
· Inputting standardized substitutions and exemptions for degree candidates
2.3.2.5.
Registrar’s
processes (other than Degree Audit)
· Processing transcript summary information/ transfer units; high school data
· Sharing student data between Admissions and Registrar’s Offices
· Allocating classroom resources (CASA)
· Generating reports
· Updating course inventories
· Updating Data Dictionary
2.3.2.6.
UCLA
Administrative and Curriculum Planners in the Schools and College Access
· Allocating classroom resources
· Scheduling faculty resources
· Planning curriculum
2.3.3. Technical Transition from Current System this section will be completed after the “Proof of Concept” phase has been completed
2.3.3.1.
·
·
·
·
·
2.3.4. Deployment of New System. this section will be completed after the “Proof of Concept” phase has been completed
·
·
·
·
·
2.4. Volumes of Data Covered
Current volume of data.
Major codes = 297
Minor codes = 51
Requirements = 1,780 sets (current and historical)
Course Usage Groups = 15,488 groups of course requirements
Course Usage List = 314,876 course entries
This volume would grow as the system supports
other schools.
Anticipated new volume of data:
Articulation Agreements
California State Universities = 23
UC Campuses = 8
Other Schools (4
year/out-of-state/international) = 300+
2.5. Impact to the Mainframe
Process
|
Changes |
Impact
|
|
TRCD screen |
Current:
Volume
of course entries transferred during the school year 98-99. Term Equivalencies Applied 98F 69,370
99W
3,680 99S 12,605 991
308 992
254 -------------
86,217 Replacement:
|
The
same number of users from Admissions and Registrar’s that uses the TRCD will
be using the new web screens to enter transfer courses from transcripts; however,
data will be sent to the mainframe only after it is finalized in DARS. The
number of CICS connections that is no longer used because TRCD will no longer
be used will be replaced by a still-to-be-determined connection to the
mainframe. The
design of the replacement system changes the way the function is
accomplished. Intensive logic and
articulation processes will be executed on the DAUD server. The
impact to the mainframe is neutral.
There will be no increase in demand for mainframe disk space. |
|
TCA agreements encoding |
Current:
N/A Replacement:
|
Encoded
TCA agreements will be saved on the DAUD server. The mainframe will not keep the data. This
is a new process and the mainframe is not touched. There is no impact to the mainframe. |
|
DAUD encoding |
Current:
Replacement:
|
The
same number of users from the college and schools will be using the new
system. This
function will completely run under the DAUD server. DARS will be the engine. The
impact is positive. Mainframe work is off-loaded to DAUD server. The demand for disk space will diminish. |
|
DPR Requests |
Current:
Replacement:
|
The
same number of users will be making the requests. The
student’s transfer information and UCLA coursework will be transferred from
the mainframe to the DAUD server. The
mainframe connection will be determined during the “proof of concept” phase. The
impact is positive. Most mainframe work is off-loaded to DAUD server. The demand for disk space will
decrease. |
2.6. Budget
The budget to be covered by ISTIP funding is detailed on the following page. In addition, all the participating units will devote significant staff resources - non-billable support - to the project. This expense will be reported in the monthly project reports as well as the billed expense so the total cost of the project can be monitored.
2.7. Exclusions
Project scope excludes
· Development of EDI/Speede/OCR for transfer credit processing
· CAS – DARS Course Applicability System
3. Schedule
3.1. Schedule
3.1.1.
Analysis
of Replacement Options:
3.1.2. Project Planning and System Design 7/15 - 11/30/2000
3.1.2.1.
“Proof of Concept”
3.1.2.1.1. Install system in test environment
3.1.2.1.2. Evaluate functionality vs. need
3.1.2.1.3. Complete specifications for development
3.1.2.1.4. Finalize costs and time frame for development
3.1.2.1.5. Obtain authorization and funding to proceed
3.1.3.
System
Development and Implementation:
3.2. Major milestones and deliverables
|
Major Milestones |
Major Activities |
Major Deliverables |
|
Install system in test environment |
·
Identify and acquire DARS server ·
Acquire DARS software ·
Recompile Cobol modules ·
Configure test/development server ·
Configure DARS system software ·
Configure Oracle database ·
Develop naming standards ·
Deploy client software ·
Test and fine tune the test environment ·
Get and send data between server and mainframe |
· Successful integration of the server into CIS infrastructure · Error free running of DARS · Successful interaction between Oracle, database client software, and mainframe |
|
Evaluate
functionality vs. needs |
·
Complete the coding for the College of
Letters & Science in the Master School Ref table according to the
parameters established by the PCD ·
Code 80% of the TCA rules for 2 California
Community Colleges ·
Code partial TCA rules for 1 postsecondary
institution (Cal State Northridge) ·
Enter transfer credit for several test
students (to evaluate TCA rules and application to degree audit) ·
Encode sample major (Psychology) ·
Encode GE 2002 ·
Encode University Requirements ·
Encode College Proficiency Requirements ·
Produce Degree audit report ·
Identify the strategy for connecting DARWIN TCA components to UCLA
course files for validating course information ·
Identify the strategy for connecting DARWIN TCA components to UCLA
student data for validating information ·
Determine whether there are any Ø
batch loading of the
school master reference table data, and source (non-UCLA) institution course
lists Ø
reports for verifying and
printing TCA agreements Ø
custom reporting tools ·
Design conversion strategy ·
Complete specifications for development: screens, reports,
interfaces, conversion Finalize costs and time
frame for development. |
· Functioning test major ·
Functioning test articulation rules for · Functioning test Master School Reference table · Functioning test degree audit · Specifications for screens, reports, interfaces, and conversion · Project Control Document for System Development |
|
Request
authorization and funding to proceed |
Present to ISTIP Executive
Committee and Management Group. |
· Approval and funding |
2.3.3.3.
Dependencies
Success depends on receiving an appropriate budget, the availability and performance of vendors and UCLA project personnel, and the functioning of equipment and software.
Data for the DAUD server, such as course and class tables may come from the SRDB database of the Registrar’s office which will depend on the successful implementation of Data Propagator and Datajoiner between AIS and Registrar’s office.
2.4.3.4.
Critical Staffing
The success of the project is jeopardized to the extent that any of the following critical resources are not available to support development of the system.
Development of Replacement System* |
||
|
Staff Member |
Availability |
Potential Disruptions to Availability |
|
AIS |
|
|
|
Francisco De Guzman and/or Farid Ibrahim |
0.5 FTE |
None anticipated |
|
L&S |
|
|
|
Eric Splaver |
0.25 FTE |
Production
responsibilities |
|
Robert Kilgore |
0.75 FTE |
Other projects |
|
Programmers - 2 |
|
Inability to hire/retain |
|
Encoders - 2 |
|
Inability to hire/retain |
|
Registrar’s Office |
|
|
|
Randy Cirilo and/or Larry Inks |
0.25 FTE |
Production responsibilities
and development including ISTIP SR0 Database Rationalization project |
|
Undergraduate Admissions |
|
|
|
Kathleen O’Kane and/or Daniel Fogg |
0.25 FTE |
Admissions Selection 12/1 –
5/1 (each year), production responsibilities, and participation in the ISTIP
Undergraduate Admissions Database Rationalization project |
|
Sharon Abramson and/or Judy Gorian |
0.25 FTE |
Meeting Admissions
Selection timelines (12/1 – 5/1 each
year) |
|
Articulation Analyst/Encoder |
1.00 FTE |
Equivalent FTE will be
hired to backfill trained staff to develop, code and test articulation rules |
*includes ISTIP billed and non-billed personnel
3.5. Contingencies
Continue with current degree audit system.
4. Assumptions
2.1.4.1.
Planning
Assume technical architecture - attached
2.2.4.2.
Roles and responsibilities
In general, College Information Services and AIS will be responsible for the technical success of the system. The Degree Audit partners will be responsible for confirming system requirements, and reviewing/approving functional specifications, testing, and authorizing moving the enhancements to production.
Alfonso Luna Administrative
Information Services
Anita Cotter Office
of the Registrar
Bonnie Allen Administrative
Information Services
Cathy Lindstrom-Jacobson Office of the Registrar
Daniel Fogg UARS
Eric Splaver College
of Letters & Science
Francisco de Guzman Administrative
Information Services
John Sandbrook College of
Letters & Science
Judy Gorian UARS
Kathleen O’Kane UARS
Larry Inks Office
of the Registrar
Penny Hein-Unruh College of
Letters & Science
Robert Kilgore College of
Letters & Science
Sharon Abramson UARS
4.3. Staffing – availability, skill relevance, etc.
All organizations will continue to provide the same resources to the project. Sharon Abramson, Randy Cirilo, Francisco de Guzman, Daniel Fogg, Judy Gorian, Robert Kilgore, and Eric Splaver are critical to the project.
2.4.4.4.
Third party commitments
DARS –
2.5.4.5.
User and transaction volumes
Students (37,000) and counselors (200) have online access to Degree Audit and can request audit reports through the web. Batch requests can be as much as 600 to 2000 UIDs per run.
4.6. Technologies – hardware and software
4.6.1. Degree Audit “back-office” Engine:
4.6.2.
Database:
Oracle 8i Release 3 (announced
4.6.3.
OS
Server: IBM AIX RS/6000
4.6.4.
Minimum
Client configuration recommandation:
IBM-compatible pc, minimum of 64Mb RAM
Running either Windows 95 or Windows NT
Recommended 400 Mhz speed
30Mb Hard disk free space
4.6.5. Minimum Server configuration recommendations:
30Mb Hard disk free space
If multiple daemons will be running, add 4.5Mb for each daemon
Minimum of 128Mb RAM
1 or more processors
4.6.6. Software:
Database client libraries, C compiler, Microfocus Cobol, Cobol/SQL pre-compiler for Oracle, GNU maker, Perl, Powerbuilder
4.6.7. Test Environment:
TSOASIS and all the attached data and communication services.
2.7.4.7.
Risks
· Attracting and retaining staff in the units involved
· Expanding the scope of work beyond that specified in this document
· Ability to effectively test this development work among the development partners
4.8. Funding - Covered in Section 2.6
2.9.4.9.
Contingencies
Assume we would continue to run and maintain the current degree audit system until the replacement system is ready.
5. Signature Block
____________________________________ ____________________
John Sandbrook Date
Assistant Provost,
____________________________________ ____________________
Eric Splaver Date
Project Architect,
____________________________________ ____________________
Robert Kilgore Date
Degree Audit,
____________________________________ ____________________
Anita Cotter Date
Associate Registrar, Office of the Registrar
____________________________________ ____________________
Larry Inks Date
Associate Registrar, Office of the Registrar
____________________________________ ____________________
Kathleen O’Kane Date
Student Systems Manager, Student Academic Services
____________________________________ ____________________
Francisco De Guzman Date
Project Lead, AIS
____________________________________ ____________________
Bonnie Allen Date
Project Manager, AIS
____________________________________ ____________________
Karen Melick Date
Systems, Network & Architecture Manager, AIS
____________________________________ ____________________
Jack Ewart Date