Summary

The final term project is to implement an on-line admissions and graduation clearance system for graduate students applying to the Computer Science department. The final “product” is described in the project details document, based on which you provided a design of your database in Phase 1.

In Phase 2, each team will be assigned a specific module to be designed and implemented. In Phase 3 of the project, the different modules will be integrated to provide a system (CS-STARRS) that meets the Banner++ specifications. As part of the team based design, integration, and testing we are essentially mimicking the design of a product by integrating different modules designed by different design teams.

In Phase 2, there are three modules/subsystems to be designed:

Application Systems (APS): The APS component provides an online application and admission review system for students seeking admission to the Masters program.

A graduate applicant goes to a website and enters their information (needed to apply for admission) into the database. Applicants can check their application status online – the status is one of three (i) application incomplete (ii) application complete and under review and (iii) decision (admit or reject).
The graduate admissions committee reviews applications and makes a decision -- Admit, Admit with Aid, or Reject. We want this review process to be automated, wherein the faculty reviewer can enter their scores into a review form.

Registration System (RES) : The RES component provides a course registration system.

Admitted students enroll at GWU (i.e., matriculate) and are now considered Graduate students. Once the student joins GWU, they will use an online registration system to register for courses and their transcript is recorded in the database (courses and grades). The RES must support course registration by students, grade entry by instructors and Grad Secretary (GS), and both students and GS can search for transcripts.

Advising System (ADS) : The ADS provides functions that help with advising and graduation requirements.

· Each student fills out an online Form 1 which lists the courses they will take to meet graduation requirements.

· When the student applies for graduation, the system must check to see if all graduation requirements are met (i.e., the student has taken the courses listed on the Form 1 and met GPA and course requirements). Once they are met, and the student is cleared to graduate they are then added to an alumni list.

Each module, or component, implements specific functionalities and must meet the specifications provided for it. Since you have the final project description available to you, you can use this knowledge to provide a design that will make it easier to integrate. However, you are NOT allowed to collaborate or discuss your design with the other teams. (Some part of the grade will be based on relative performance of the three teams.) Details on the type of data (and the forms used for review) are provided in the phase 1 project description document.

You will implement your system on the SEASCF machines using MySQL and PhP. Remember that you will need to integrate your application with other modules in Phase 3 – so be careful about what other software you use.

User Interface Design: For the final project we will examine and evaluate your user interface. In Phase 2 the emphasis is on correctness but we will expect good user interface design methods applied to your project.

Description of the three components

A description of the required/specified workflow for the three modules (APS, RES, ADS) is provided below. For more details, on the data required and what other functionality you may need to support in Phase 3, you can refer to the project description.

Application System (APS):

The APS component provides an online application and admissions review system. The application review process requires (potentially) multiple users to enter data and to reach a decision. It changes the status of an applicant to a final status of admit or reject. The final decision (of admit, admit with aid or reject) is made by a user (the GS or CAC) and not by the system – although the final decision must be stored in the system.A prospective graduate student, henceforth referred to as a ‘graduate applicant’, visits the URL for the admissions/applications. They are presented with an online application form which they proceed to fill out if they are applying to the graduate program. Once the application is complete their application is evaluated by a faculty committee and a final decision is made.

APS workflow:
You must implement the workflow described below. For specific data needed for this application, refer to the Project description document.

A graduate applicant visits a specific URL and enters a form to fill in their application for admission. When they have completed filling in all the information they submit their application.

as specified in Phase 1, the system must create an account/password for them so they can log back into the system to check their status.
They fill out their personal information and their academic information.

The transcript is mailed (US mail) by the applicant, and its receipt is noted in the database by the GS.
In phase 2, assume that letters are also mailed (US mail) by the letter writers. (The online recommendation letters submission will need to be done in Phase 3).

Note that because of the above two requirements (transcript and letters), the student’s application can be incomplete even though the student has entered all their information.

The application is considered to be complete when all required information has been entered by the applicant, and the transcripts and recommendation letters have been received.

The GS (graduate secretary) updates the status of their transcripts and letters. When these are received the GS logs into the system and enters that they have been received.

An applicant can check on the status. The status is updated by the admissions process.
Once an application is complete, it is ready for review for admission. The application is reviewed by a faculty admissions committee. Typically, the committee consists of 4-5 faculty.
The faculty committee will be given a list of completed (but decision pending) applications. This can be in the form of a list of student numbers. While this process seems okay, note that this again requires manual intervention.

You should think of automating this process – for example, when a reviewer logs in they can be presented with a list of pending applications which have not been reviewed (for fairness you can sort them by date received; for simplicity you can sort them by student number or name). They can click on an entry in the list to bring up the review form for that applicant.

Typically a number of reviewers can evaluate an applicant; for simplicity in Phase 2 assume that each application is reviewed by a single reviewer. The review process starts when the reviewer brings up a student’s review form. To add bells and whistles to your system you can consider multiple reviewers (and thus earn more points for the project) in Phase 3.

Given a student number, the system must generate the Review form – the data for the form is taken from the database based on what the applicant has entered. In practice, the reviewer also looks at the student folder at the detailed transcript, letters, etc. – in this project you can assume that they only look at the online review form!

A reviewer completes his review by filling out the various fields in the review form, and making a recommendation. The recommendation can be one of four options and represents a ranking: (1) reject, (2) borderline (to mean they are not certain), (3) admit without aid, and (4) admit with aid. The four numbers 1 through 4 in a sense correspond to a ranking of the applicant. If a number of reviewers were to review this applicant, one can calculate an average ranking. The reviewer can also add their comments (to make it simple assume that they can write about 40 characters in their comments) and recommend an advisor (again, you can simplify by assuming that this has to be one of the faculty in the department). When the review is complete the application is said to have been “reviewed” – but a final decision has NOT been made.
To get an idea of the review process and data see the sample review forms and sample (fictitious) reviews.
A final decision (of admit with aid, admit, or reject) is made by the committee as a whole – but in practice only the Chair of the admissions committee (the CAC) enters this decision into the system (which should only display admit or reject – the admit with aid is an internal note and is not actually entered into the banner system) with the help of the Grad Secretary (GS). When a final decision has been made, the status of the applicant is updated and the application review process is now complete. You can assume that the CAC or the GS can enter the final decision into the system.

Registration System (RES):

The RES component provides an online course registration system that allows students to register (add/drop) for courses, check for their transcripts, and allows faculty instructors to enter grades, and grad secretary (GS) the search for transcripts and enter/change grades.

RES workflow: You must implement the workflow below.

A graduate student, once formally admitted and registered in the system as a graduate student, can enroll for graduate courses using a web registration system.
The web registration system enables students to enroll for courses, and faculty (or the GS) to assign grades. A student will be able to use the online registration system to register for courses, and a faculty (or the GS) can use the system only to enter the final grades. The valid final grades are (A, A-, B+, B, B-, C+, C, F).

In Phase 3 you will need to integrate the modules and build in advising forms which will need to be approved by advisor before they can register.

At any time the GS, a faculty member, or the student can query the system for the current transcript of the student. Courses currently in progress show up with a grade of IP (in progress).
The registration system must store information on the courses, the faculty teaching the course, the grades (if assigned), the schedule (time and day). The course registration application must check for schedule conflicts.

To simplify the registration system you can assume the following. Each course has a title, a course number (dept followed by course number) that can be treated as a unique course number, a section number, the semester it is offered in, and the number of course credits (assume maximum credits is 3). Assume that each course only has one section.
To simplify the registration system you MUST implement the list of courses provided -- with the specific titles listed in the document. You can choose to populate it with additional courses if you choose. The course list also specifies the course pre-requisites, and also specifies a time schedule that you should use for your registration system.
The enrollment/registration information must store the course, the semester, the class time, day, the student identification, the instructor information, and the grade. Note that a course offering is unique when one considers the course number and the semester&year that it was offered in. For simplicity you should assume that courses are scheduled on M, T, W, R, each course meets once a week (like most of our grad courses), and the valid time slots are 3-6pm and 6-9pm only (i.e., only two time slots). Assume that the same schedule is applied every semester (i.e., the schedule shown in the list is assumed to be in place every semester). Your system MUST allow students to take courses in the 3-6pm and 6-9pm time slot on the same day (i.e., the time gap between consecutive classes is 0 minutes).
You should implement at least the adding of a course. i.e., you should also try to implement a "drop" application.
Faculty users (or the GS) should be able to enter the grade for courses they are teaching.

Advising System (ADS):

The ADS component provides some advising functions (for the student and advisor). Graduate Student database applications process goes all the way from application being received in the department to the student’s graduation clearance.
ADS workflow: You must the implement the workflow specified below for the ADS system.

A student must specify their entire program of study by filling out a Form 1. This lists the courses that they will take to meet the Degree requirements (this is somewhat similar to the curriculum sheets that undergraduates must follow to meet their degree requirements.). A sample of a Form 1 is provided here.
After completing the requirements for the degree to which they are admitted, the student formally applies for graduation by visiting a URL, “Apply for Graduation”, and entering their student number and selecting the degree to which they are applying. For simplicity, assume they are applying for the MS degree.

Since you will need to look up their transcript, assume that they have taken courses only from the list provided in phase 1 course list.

Assume that the valid final grades are (A, A-, B+, B, B-, C+, C, F).Courses currently in progress show up with a grade of IP (in progress).

Once a student has applied for graduation, the system performs an ‘audit’. Specifically the system checks to see if the student has satisfied all the degree program requirements.

This requires that the system check the courses the student has taken and compare them with the program requirements (both course requirements and GPA requirements) and compares them with the courses the student listed on their Form 1. (For example, if they have taken a different set of courses than listed on their Form 1 then they will not be cleared for graduation). You could simplify the process by checking for program requirements when they submit their Form 1 -- i.e., check if the courses listed on their Form 1 meet the course requirements of the MS program; thus, the application for graduation will only test if they have filed a Form 1 and if they satisfy the GPA rule.
To simplify the project, assume that only M.S. degree students are considered for this application (i.e., only MS students will apply for graduation).The program requirements for an MS degree are posted on the graduate academics section of the CS-GWU department website: http://www.cs.gwu.edu

The set of requirements that you should use (at a minimum) are: student must take 10 courses (each is 3 credits), must complete at least 30 credit hours, and must take the three core courses CS210, CS211, CS212, and must have at most 2 grades below B-, and must have a minimum GPA of 3.0.
In general, program requirements for the degree (in your project, only the MS degree) are stored in the system. This will allow changes to the program requirements to be made if necessary.

If a student has met the program requirements, they are “cleared” for graduation. Else, they are “not cleared” for graduation. If they are not cleared, then ideally the system must inform them why they have not met graduation requirements.

Once a student is cleared for graduation, the GS formally process their application and they “graduate”. (Note that, similar to the admission review process, a student can be cleared for graduation but they do not actually graduate until the GS, or another authorized user, enters this information into the system and formally clears them.)

The process of graduation must be automated; i.e., the GS need only check the “cleared for graduation” students and approve their graduation by clicking on some selection. (In practice the GS actually looks through their folder and transcript.)

When a student “graduates” they are removed from the Graduate student table and their information must be entered into an Alumni table. Note that only a summary of their academic information should be kept in the Alumni table.

In a real system, the enrollment information for a student is not removed since they may re-enroll at GWU for another degree. Thus, a graduation process would only require that their data be tagged to indicate that they have graduated with a degree while keeping all their information intact.

An alumni can only edit their personal information (such as email, address) by logging on to a URL using their student number (again, in practice it is better to give them a unique password rather than create privacy problems by using their student number).

Note on Phase 3 requirements: In addition to integrating the three modules in Phase 3, you will also need to implement a number of queries/reports (as specified in the project details document). Keep this in mind when doing your table designs.