Management System For
Graduate Students
Projects Day Presentation – June 2011
Team
Advisors
• Dr. Yuval Elovici
• Chuchem Tamar
Members
• Tal Franko
• Tal Goldstein
• Tamir Zur
• Miriam Nir
http://www.cs.bgu.ac.il/~talgol/2ndDegManagment/Main
Background
 Today, Internet connection is available from
almost anywhere.
 The process of managing a Graduate studies,
should be computerized, and interactive.
 But that's not the way it works today in BGU.
The way it works today
• Currently, there are no similar systems, so everything is done
manually.
• For most forms – there is no other way to submit them,
without using paper forms, and the department’s secretaries.
• There are some university websites that offers information on
student’s status, but most of them give very targeted
information (lecturer’s Email, exam hours etc.)
The way it works today
For example:
• Graduate student submits their Thesis, mailing it to his academic
advisor.
• The academic advisor mails it to the graduate committee.
• The department’s secretary gets a list of recommended
examiners and e-mails each one, asking him to attend.
Advantages of using our system
• Our system will save great amount of paperwork and will give
easy and quick access to all graduate students and faculty
members - and therefore, would save countless man hours.
• The system will present the university as a modern place to
nominees.
• With an electronic system, forms will not be “lost”.
• Computerizing these processes would produce important
data, such as statistics about students.
Our Objective
• Main goal: To computerize the process of managing
a Graduate studies.
• Handle all of the graduate student’s needs through this
system, so that all of the student’s steps would be monitored:
from registration to thesis grade, with the option to manage
and save all the forms and requests from all those involved
(student, advisor, examiner, authorization committee etc.)
Our Objective
• Ease the way all users communicate with each other and in
particular candidates and students with the academic staff
(instructors, teaching committee, secretaries and external
examiners).
• To make the system modular, in a way that we could add
stations and states to it.
• To make the system general enough to fit all University’s
departments in the future.
System Features
• Enable thesis search: allows university users and external
users to search thesis by criteria (Subject, Author etc).
• Login: Candidates should be able to login with login
parameters generated for them upon registration.
BGU students and Faculty/administration members (with a
valid BGU account) will login to the system using their BGU
username and password.
System Features (con’t)
• Users should have the ability to send messages and requests
to each other and to fill in forms*. e.g. A student can fill in the
form “Thesis Instructor request” to a lecturer.
• All users should have the ability to upload files to the system
(with some restrictions such as file size, file type) such as
progress report, thesis draft etc.
Candidates could upload grades sheet and recommendations
during the registration process.
* based on the system’s user role.
System Features (con’t)
• Instructors should have the ability to initiate/react to its students’
requests and messages.
• Committee Members should be able to reject/accept/respond
candidates’ requests (e.g. “more documents are required”).
• Should support a view of current Statistics (based on the user role)
at any given moment.
• Admin will have an absolute control of the system.
• The system should also inform its users on new events that may
need their attention, via email.
Architechture
Our system uses the client/server model
Client
• users use the system through a web browser.
• perform actions through the Web GUI. Each of its requests is
transferred through HTTP protocol to the server.
• Holds relevant data in its session with the system, such as:
UserID, Department, Available stations.
Architechture
Server
• Handles requests from clients (could handle many clients
simultaneously)
•
Will use other services available such as the system’s
database, the server’s file system and even the university’s
mail server.
• Handles automatic routines, such as making mails
notifications (after some time elapsed).
Architechture
Candidate
DB Server
Student
Files Server
Instructor
GUI,
Application Layer
Model Layer,
Business Logic
Persistency
layer
Teaching
Committee
Examiner
Admin
Secretary
BGU Web-Services
StockHolders
• Students/Candidates user:
Student in their second and third degree.
• Advisor (lecturer) user:
Lecturer that guides the student through their thesis.
Will accept / reject academic material for the student.
Adding data to his reviews.
The academic guide also needs to be able to submit requests
to the Certified Committee (CC).
StockHolders (con’t)
• Certified Committee user:
Makes decisions like accepting / rejecting requests from
students, such as: applying for graduate studies, thesis
subject, etc.
• Examiner user:
external Lecturer, that was selected by the Advisor and the
Certified Committee.
the examiner would exam the student’s thesis, and could send
his remarks.
Will get temporary user name and password – with an
expiration time.
StockHolders (con’t)
• System Administrator user:
the administrator will be able to perform any action of the
system.
He could also get the system out from dangerous states like
dead ends or undefined situations.
• Sponsors:
The system’s sponsors are Ben-Gurion University.
Usage Scenarios
Usage Scenarios
Testing Our System
• Functional requirements
• performance: speed & response, system availability.
• capacity : number of users and data to upload.
• safety & security : attacks (SQL injection etc)
• Usability : GUI , system transactions
• Compatibility : Browsers (all common browsers), compatibility and
OS support.
The End . . .