Management System For Graduate Students

1. Management System For Graduate Students Projects Day Presentation – June 2011

2. 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

3. Background • Today, Internet connection is available from almost anywhere. • The process of managing a Graduatestudies, should be computerized, and interactive. • But that's not the way it works today in BGU.

4. 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.)

5. 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.

6. 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.

7. 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.)

8. 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.

9. 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.

10. 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.

11. 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.

12. 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.

13. 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).

14. Architechture Candidate DB Server Student Files Server Model Layer, Business Logic Instructor Persistency layer GUI, Application Layer Teaching Committee Examiner BGU Web-Services Admin Secretary

15. 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).

16. 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.

17. 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.

18. Usage Scenarios

19. Usage Scenarios

20. 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.

21. The End . . .