GradAdmissionsSystemDesign < CF

CF Web>CSCFSoftwareNotes>ClientProjects>GradOfficeWebApplication>GradAdmissionsSystemDesign (2013-02-22, DrewPilcher) (raw view)
EditAttach
---+ Design Document for On-line Graduate Student Admissions System (OGSAS)

This document describes some details regarding the design and functionality of the On-line Grad Student Admissions System.  The design is centered around the application itself, the different states it assumes at various stages of the process, and the roles the system's users play in driving the process.

#SystemRoles
---++ Roles

All users in the system will have one of more roles in the process.  Roles are used to define views as well as access controls to the information in the database.  Users will be identified by their !UWUserid, and authenticate using !UWDir credentials.  All authorization will be handled by a uwuserid-role relation.

#RoleDirector
---+++ Director
In this case, =Director= refers to _Director of Admissions_.  It is expected than no more than two faculty members (Dir. and Associate Dir. of Graduate Studies) will have this role at any one time.  The Director drives the process, and in most cases the one who authorizes a state change for an application.

#RoleFaculty
---+++ Faculty
Faculty will have read-only access to all applications and applications will be presented to faculty categorized by research interest.  Faculty will be able review all applications in circulation, and be able to make comments, express interest, or not, for any given application. 

#RoleGradOffice
---+++ Coordinator
The staff Admissions Coordinator in the school will have full access to all applications, in order to add scanned documentation to an application, and to correct any applicant information as needed.

---+++ UW Officers
There may be a need for UW Staff and Administrators not directly involved in this process (perhaps even outside the School) to be able to view certain aspects of applications.

#RoleReferee
---+++ Referee
Referees will be able to access a web page to complete an on-line reference form which gets automatically stored to the database upon completion.  Referee will need to print out a generated pdf file to sign and mail to the School.

#RoleApplicant 
---+++ Applicant
Students should be able to see what state their application is in.  The states *Acceptance Pending*, and *Rejected*, should be displayed as *Decision Pending*.

---++ States
Every application will have a state in the system to indicate an application's stage in the admissions process.  The state of the application should be viewable by all users of the system.  The states are:

   * New - The application is new to the system, and the record may not be complete.
   * Hold - The application is missing some information/documentation, preventing it from being reviewed or circulated.
   * Initial Review - The application is ready for initial review, is being initially reviewed, by the Director of Admissions.
   * Circulate - The application is being reviewed by faculty.
   * Acceptance Pending - At least one faculty member has expressed interest.
   * Initial Offer - An electronic tentative offer has been sent, waiting to see if the student's interested.
   * Declined - An initial offer was made, but the student declined.
   * Acceptance Recommended - Details are finalized, student is interested, committed to make an official offer.
   * Rejected - No faculty have expressed interest and/or minimum requirements were not met

---+++ Sub-states

When an application is the the *Circulate* state, it will have a sub-state which is essentially a relation between any given faculty member and an application.  The possible sub-states are:

   * Unseen - Initial state.
   * Undecided - The faculty member has viewed the application, but has not completed his/her review.
   * No interest - The faculty member has decided not to accept the application.
   * Accept - The faculty member wishes to accept the applicant.

The sub-state is mainly for the benefit of the Director of Admissions, to track the status of applications in circulation.  See the Workflow section for further details on how the sub-state is used.


---++ Workflow

---+++ Before OGSAS

The on-line application starts with =applicants= visiting a web site at http://horizon.ouac.on.ca/uw/grad.  Note that this is run by OUAC, not directly by UW, although the appearance and questions are UW-customized.  This site allows =applicants= to create an account and fill out numerous fields that become the electronic part of the application.

The OUAC application includes:

   * Chosen program
   * Name, DOB, etc.
   * Citizenship, language, etc.
   * Addresses
   * Academic Background
   * Test Scores
   * Professional Background
   * Referees

When the =applicant= has submitted the application and paid the fee, the application is forwarded to the UW GSO and gets an account created on UW's "Applicant Quest" system.  Note that !UWDir credentials are used with this system.

---+++ OGSAS Process

Data extracts (8 different files) from "Applicant Quest" are sent to a staff member's e-mail address where a procmail filter extracts them and stores them in a holding area where they are checked-in to a revision control system.  From there, transformation scripts are used to transform the data into a normalized form appropriate for uploading to the OGSAS database.

The admissions process using OGSAS starts when either:

   * a new application appears in the database.
   * the =Applicant= logs into the system to input his/her research interests and supplementary information.

at which point the application is in state *New*.  E-mail gets automatically sent to all =referees= pointing them to a unique URL where they can complete an on-line reference form and e-mail gets sent the =coordinator= alerting him/her of the new application.  The system changes the state of the application to *Hold* and the =coordinator= scans and uploads supporting documentation, such as official transcripts.

The application is changed to state *Initial Review* after all on-line reference forms have been completed and the =coordinator= has ensured the record is complete with all supplementary information is present.

When an application is set to state *Initial review*, the =Director= is alerted by e-mail and will:
   * Ensure application meets minimum requirements
   * Ensure expressed research interests are appropriate
   * Determine and input what remedial course(s) is/are required (if applicable)
   * Verify all the required documentation is present
   * Comment if necessary

Once the =Director= has completed his/her review, the =Director= will change the application state to one of:
   * *Circulate* - ready for faculty to review
   * *Rejected* - did not meet minimum requirements
   * *Hold* - missing some documentation (this should rarely occur)

When an application is in state *Rejected*, a letter is generated to mail to the applicant.

When an application is in state *Circulate*, the =faculty= members in the applicant's research area(s) of interest will review it.  Faculty will be able to annotate the application for all peers to view.  When a =faculty= member wishes to accept an applicant, he/she will define the parameters of the acceptance by:
   * Specifying !MMath or !PhD
   * Supervise and fund vs. recommendation for additional scholarship funding

The system will then change the state of the application to *Acceptance Pending*, generate e-mail to all other =Faculty= in the =applicant's= areas of interest, copied to the =Director= soliciting any further interest in the =Applicant=.  A form summarizing the parameters of acceptance will be printed for the =Faculty= to sign-off.

The =Director= will review the application in the state *Acceptance Pending*, finalize details such as funding arrangements, and co-advisors.  When the =Director= has finalized these details, he/she will communicate these to the =Coordinator=.  The =Coordinator= generates the appropriate letters and uploads them to the system.  The system then sends e-mail to the applicant with the appropriate attachments, including a URL where the applicant can accept or decline the offer and changes the state to *Initial Offer*.

The =applicant= then logs in to the system, and expresses interest (or not).  An expression of interest by the =applicant= changes the state to *Acceptance Recommended*, and the following documents get generated to be sent to the Math Grad Office and the UW Graduate Studies Office:

   * Recommendation for Acceptance
   * Copies of offer documents previously sent to the =Applicant=

The state change to *Acceptance Recommended* also results in data being exported to the Grad Student Database.

The application will change to state *Declined*, if the applicant explicitly does so, or if after *N weeks* in the state *Initial Offer* (may prompt for a human to intervene instead?????).

The =Director= will review the applications that have been in circulation for some time and will decide to change the state to *Rejected* if he/she feels it is clear that there is no interest in admitting the =Applicant=.

---++++ Purging of Records

In accordance with University policy:

At the beginning of each term, the system will purge all applications where the term applied for was one year or more in the past.  For those applications that were accepted, it is expected that all relevant data be kept on paper, or in another system while the student is registered.  Such records need to be disposed of 2 years after the final term of registration.

-- Main.JasonTestart - 28 May 2007

---+++ Workflow State Diagram

<img src="%ATTACHURLPATH%/ogsas.png"/>

-- Main.IlguizLatypov's rendition of Main.JasonTestart's whiteboard - 08 May 2007
Attachments
Topic attachments
I	Attachment	History	Action	Size	Date	Who	Comment
dot	ogsas.dot	r3 r2 r1	manage	1.0 K	2007-05-17 - 11:36	IlguizLatypov	The state machine as a directed graph.
png	ogsas.png	r3 r2 r1	manage	85.8 K	2007-05-17 - 11:36	IlguizLatypov	unflatten \| dot -Tsvg -Gdpi=120
Topic revision: r16 - 2013-02-22 - DrewPilcher
Information in this area is meant for use by CSCF staff and is not official documentation, but anybody who is interested is welcome to use it if they find it useful.
Other Webs
My links
- People
- CERAS
- WatForm
- Tetherless lab
- Ubuntu Main.HowTo
- eDocs
- RGG NE notes
- RGG
- CS infrastructure
- Grad images
Edit