You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 51 Next »


UNIC Virtual campus is an information system intended for the exchange of data and the implementation of specific business processes within the university alliance (European university) UNIC, within which the University of Zagreb also operates.

University Computing Centre (Srce) as a component of the University of Zagreb, is in charge of building the UNIC virtual campus.

Basic definition and facts

What is it? 

UNIC Virtual Campus is an information system consisting of a central database (central register) and several web applications and application programming interfaces (APIs). 

What will it serve for?

Firstly, it will cover the mobility of students and virtual student cards. Later on, it will connect research activity information as well. 

Who is building it?

University of Zagreb, primarily University Computing Centre (SRCE). 

How is it funded?

Initial phase of development is funded through UNIC and UNIC4ER projects. 

Everyday maintenance, superadmin tasks and further development funding should be discussed. 

Where will it be stored and running?

On the servers of the University Computing Centre, University of Zagreb. There are two data centres with a shared virtualization platform for redundancy. 

How will users interact with the Virtual Campus?

Mostly through the web applications of the Virtual Campus, but some data could be imported or obtained through APIs. Web applications will cover all the functions of APIs, and more. 

Abbreviations

VC - Virtual Campus (UNIC Virtual Campus Information system)

SMS - Student Management System (a local information system containing data about students, courses, teachers, exams, etc.)

LMS - Learning Management System (a local information system containing data about courses, learning materials, exams, etc.)

IdP - Identity Provider (authorization and authentication infrastructure used for storing and verification of electronic identities of students and staff at the university)

Requirements

Here are some of the recognized prerequisites needed for functioning of VC.

  • IdP has to participate in eduGAIN.
  • Students have to have ESI (European Student Identifier).
  • GDPR consents have to be written in order to be built into applications, to ensure that all participants give their consent to use their data. 
  • VC uses ECTS grades (A-F). When communicating with VC, all local marks should be converted to ECTS marks and vice versa.
  • Data is owned by UNI of origin:
    • student data is owned by a student home UNI
    • course data is owned by UNI offering a course, as well as data about students taking part in the course and exams.

Process


Offering a course

Course enrollment

Course ending

Student Card Issue

Student Card Verification

Invalidating the UNIC Student Status


More about the possibilities of working in the system can be found on the following links:




Process

Offering a Course

Course offers can be updated each academic year.

Via API: 

  1. A course that will be offered to UNIC students needs to be described in local SMS 
  2. Local SMS pushes the course offering to VC via API. 

Manually:

  1. OrgUnit Admin edits a course offering in the Admin portal manually.

Course enrollment

This process is time-framed, based on when the course starts. All parts of the process should be over by the date when the course starts (CS_DATE). 

  1. A student browses through courses offered in the VC and chooses the one (or more) that she/he wants to enroll in (deadline: CS_DATE-35). Home OrgUnit Admin gets a message.
  2. Home OrgUnit Admin checks the prerequisites for the course (if needed consults with the students mentor / study program lead / …). Enters a decision in VC (deadline: CS_DATE-25):
    1. denied - the process ends here, student gets a message
    2. approved - the process continues; receiving OrgUnit Admin gets a message
  3. Receiving OrgUnit Admin checks the prerequisites (is the course already filled up etc.; if needed, she/he consults with the student, teacher, home OrgUnit Admin). Enters a decision in VC (deadline: CS_DATE-15):
    1. denied - the process ends here, student gets a message
    2. approved - the process continues
  4. Student is enrolled (deadline: CS_DATE-10):
    1. the data are copied in receiving SMS (and LMS) via API or
    2. the data are entered manually in receiving SMS (and LMS) by home OrgUnit Admin
  5. Course starts (at CS_DATE).

Course ending

  1. If the student drops off the course during the course, that information is entered in VC via API or receiving OrgUnit Admin;
    Otherwise, when a student finishes the course, the final grade is entered in VC via API or receiving OrgUnit Admin.
  2. If home OrgUnit is using API
    1. Upon the entry of the grade or drop-off info into VC, the grade or drop-off info is returned to home OrgUnit via API
  3. If home UNI is not using API:
    1. home OrgUnit Admin gets a message
    2. home OrgUnit Admin logs into VC, gets the data and enters it in home UNI SMS



  • No labels