Docstoc

CSS_PROJECT_Modules_Functionality

Document Sample
CSS_PROJECT_Modules_Functionality Powered By Docstoc
					                                                                                                                                                   1

CSS Project Zambia – Consolidating support
Authors:      Monique in het Veld (ICT Specialist, University of Nijmegen)
              Markus Pscheidt (ICT Specialist, Universidade Catholica Mozambique)
Date last modified: 04-07-2011

Overview of Requirements for the SIS at UNZA
new and extended functionality for the Opus Student Administration System

CONTENT

Assumptions & Remarks.................................................................................................................. 6
MILESTONE 3.1. ............................................................................................................................... 7
3.1.1. Additions to the OPUS College kernel ................................................................................... 7
   a. Study........................................................................................................................................ 7
   b. Subjects, Subjectblocks, Thesis .............................................................................................. 9
   c. Cardinal time-unit ................................................................................................................. 10
   d. Roles / user privileges .......................................................................................................... 14
   e. Students ................................................................................................................................ 14
   f. Studyplans ............................................................................................................................. 15
   h. Modularization ..................................................................................................................... 16
   i. Security................................................................................................................................... 17
3.1.2. New module for country specific settings Mozambique .................................................... 19
   b. Fast Input facility student ..................................................................................................... 19
   c. Test country-specific issue .................................................................................................... 19
3.1.3 - New module for country specific settings Zambia ............................................................. 20
   a. Implement country-specific study times ............................................................................. 20
   b. Implement country-specific study forms ............................................................................. 20
   d. Obligatory fields phone number and e-mail address .......................................................... 20
   e. Prevention of double registration of students .................................................................... 20
   f. Create graduation comment types ....................................................................................... 20
   g. Implement concept of parallel students .............................................................................. 22
3.1.4. Views by Privileges I ............................................................................................................ 23
   a. Student .................................................................................................................................. 23
   b. Teacher.................................................................................................................................. 23
   c. Head of Department ............................................................................................................. 24
   d. Dean / Asst. Dean ................................................................................................................. 24
                                                                                                                                                  2

   f. Academic Affairs Office ......................................................................................................... 25
   h. Registrar / Asst Registrar ...................................................................................................... 25
   g. Functional Administrator...................................................................................................... 26
3.1.5. Extensions to module Fees .................................................................................................. 27
   a. Add fee categories ................................................................................................................ 27
MILESTONE 3.2. ............................................................................................................................. 28
3.2.1. Additions to the OPUS College kernel ................................................................................. 28
   a. Staff-members ...................................................................................................................... 28
   b. Roles and privileges .............................................................................................................. 28
   c. Study, studygradetype, cardinaltimeunit ............................................................................ 29
   d. Subject, subjectblock, thesis, projectcourse........................................................................ 29
   e. Students ................................................................................................................................ 29
   f. Studyplans ............................................................................................................................. 30
   g. Results ................................................................................................................................... 30
   h. Refactoring ............................................................................................................................ 32
   i. Modularization....................................................................................................................... 33
3.2.2. Extensions to Mozambique Module.................................................................................... 34
   a. Exam-calculation grades / mappings ................................................................................... 34
   b. General conversion data opus 3.0 -> opus 3.2 .................................................................... 34
3.2.3. New module for university specific settings UNZA ............................................................. 35
   a. Generating university specific student number .................................................................. 35
   b. Fill copy-database with EWAN / SRS data ........................................................................... 35
   c. Conversion current data ....................................................................................................... 35
   d. Test Conversion .................................................................................................................... 35
   e. Extra attributes postgraduates: study permit ..................................................................... 35
   f. Interface for HRM system Accsys.......................................................................................... 36
   g. Interface for Accounting system SAGE ................................................................................. 36
   h. Student application for study-gradetype: 1 max................................................................. 36
3.2.4. New module for university specific settings CBU................................................................ 37
   a. Generating university specific student number .................................................................. 37
   b. Fill copy-database with STURECO data ................................................................................ 37
   c. Conversion current data ....................................................................................................... 37
                                                                                                                                                 3

   d. Test Conversion .................................................................................................................... 37
   e. Extra field application number at Admission ...................................................................... 37
   f. Interface (2-way) for Accounting system Dimensions ......................................................... 37
   g. Student application for study-gradetype: 2 max ................................................................. 38
3.2.5. New module DBConversion................................................................................................. 39
3.2.6. New module Admission....................................................................................................... 40
   a. Implement admission process .............................................................................................. 40
   b. Admission screens for Dean ................................................................................................. 43
   c. Limited admission period ..................................................................................................... 43
3.2.3. New module Continued Registration .................................................................................. 44
   a. Implement registration process ........................................................................................... 44
   b. Registration screens for dean .............................................................................................. 45
   c. Registration screens for student .......................................................................................... 45
   d. Limited registration period................................................................................................... 45
3.2.4. Extensions to Zambia module ............................................................................................. 47
   a. Implement country-specific user roles................................................................................. 47
   b. Extend subject-result calculations ....................................................................................... 47
   c. Subject / Graduation / Degree grade-point-percentage bindings ...................................... 48
   d. Graduation cardinal time-unit calculation........................................................................... 50
   e. Create degree comment types ............................................................................................. 51
   f. Degree calculation ................................................................................................................. 52
   g. Implement Admission Criteria Bachelor and cut-off point algorithm for the Admission
   Module ...................................................................................................................................... 52
   h. Implement Admission Criteria for Master for the Admission Module ............................... 55
   i. Scholarships: Criteria and subsidies not relevant ................................................................. 56
3.2.9. Apply new roles & privileges ............................................................................................... 57
   a. Bursar / Financial Officer ...................................................................................................... 57
   b. Librarian ................................................................................................................................ 57
   c. Internal Audit ........................................................................................................................ 58
   d. Dean of students................................................................................................................... 59
3.2.10. Extensions to Report module ............................................................................................ 61
   a. Reparations of current reports ............................................................................................. 61
   b. Student card.......................................................................................................................... 61
                                                                                                                                                 4

   c. Diplomas / Certificates of graduation .................................................................................. 61
   d. Fees reports for Bursar / Academic affairs office / Internal Audit ..................................... 61
   d. Admission slips ..................................................................................................................... 62
   h. Result slips ............................................................................................................................ 62
   i. Sponsor reports for Bursar / Academic affairs office / Internal Audit ................................ 62
   j. Student reports for Academic affairs office / Internal Audit ............................................... 63
   j. Student reports for Dean of Students ................................................................................... 63
3.2.12. Extensions to Scholarship module..................................................................................... 65
   a. Add sponsor types ................................................................................................................ 65
   b. Add sponsor categories ........................................................................................................ 65
   c. Business rules late payment sponsors ................................................................................. 65
   d. Flexible number of sponsors per student ............................................................................ 65
3.2.13. New module Accommodation / Housing .......................................................................... 67
3.2.14. New module Timetable / Roster ....................................................................................... 69
   a. Extensions kernel datamodel for timetable module ........................................................... 69
   b. Build of modules timetable / roster by new Giphouse Students ....................................... 69
MILESTONE 3.3. ............................................................................................................................. 70
3.3.1. Additions to the OPUS College kernel ................................................................................. 70
   a. Security.................................................................................................................................. 70
   b. Custom stylesheets / logo settings ...................................................................................... 71
   c. Backlog functionality / Audit trail ........................................................................................ 71
   c. Refactoring ............................................................................................................................ 71
3.3.2. Extensions for Zambia Module ............................................................................................ 72
   a. Implement Quota Allocation for the Continued Registration module ............................... 72
3.3.4. Extensions to UNZA module ................................................................................................ 74
   a. Backlog functionality / Audit trail ........................................................................................ 74
   b. Fees - New interface import Bank Information ................................................................... 74
3.3.5. Extensions to CBU module .................................................................................................. 75
   a. Backlog functionality / Audit trail ........................................................................................ 75
   b. Fees - New interface import Bank Information ................................................................... 75
3.3.6. Extensions to Fee module ................................................................................................... 76
   a. Bind fee payments to study-gradetype details (ctu) ........................................................... 76
                                                                                                                                                5

   b. New attribute tuition waiver for student ............................................................................ 76
   c. Extend student overview ...................................................................................................... 76
   d. New view fees-balance per study-gradetype ...................................................................... 76
   e. Break down fees ................................................................................................................... 77
   f. Bind Fee to study-gradetype in specific academic year ....................................................... 77
   g. Specify installments per Fee with deadline dates ............................................................... 77
   h. Implement option to pay all Fees at once for study-gradetype ......................................... 78
   i. Implement option for credit-balance for individual student ............................................... 78
   j. Implement option for refund for individual student............................................................ 78
   k. Implement e-mail reminders for outstanding fees............................................................. 78
   l. Implement automatic charge of outstanding fees in next cardinal time-unit .................... 78
   m. Affiliation fees for postgraduate students ......................................................................... 78
   n. Integrate penalties / fines within fees module ................................................................... 78
Appendices .................................................................................................................................... 80
1. Examples of curriculum and studyplan definitions at UNZA / CBU ........................................... 80
2. New modules and functionality not captured within the project ............................................. 83
   a. New module public homepage ............................................................................................ 83
   b. New module Alumni ............................................................................................................. 83
   c. View / role: PR / Communication ......................................................................................... 83
   d. View / role: Alumnus ............................................................................................................ 83
   e. New modules Publications and Research (for postgraduates) ........................................... 84
   f. Specific interfaces for CBU .................................................................................................... 84
   g. Extensions OPUS kernel ........................................................................................................ 84
                                                                                      6

Assumptions & Remarks
 1. existing e-mail smtp server at university
 2. reassessment procedure (after longer absence) is not included in the system
 3. A subject that is taught within several studies and / or several gradetypes will
    have the same value and content within one study-gradetype. For instance if
    statistics 2 is taught within Natural sciences second year first semester and
    within Humanitory sciences second year first semester and within Humanitory
    sciences as elective subject within the third year, the prerequisites for Natural
    sciences may differ from those within Humanitory sciences, but within
    Humanitory sciences the prerequisites for this subject will be the same,
    regardless if the subject is taken in the second or third year.
 4. The responsibility for the admission process lies with the Academic Office
 5. The responsibility for the (continued) registration process lies with the deans
    and assistant registrars of the schools.
 6. In Zambia the term „study-programme‟ is being used. In the OPUS system
    the term study- gradetype is used.
 7. In Zambia the term „course‟ is being used for parts of a certain study-
    programme (undergraduate / postgraduate), but since this means a whole
    study in Mozambique this can be confusing. Therefore in this document the
    word „subject‟ is used to define parts of a certain study-programme. In the
    application itself the desired terms can be used for the specific country and /
    or university by altering the language/country-specific configuration-files.

 Note: this document has a time-line in it. This means, that the following order in
 this document is also (more or less) the following order within the build process.
 The document has a link to a corresponding planning-excelsheet.
                                                                                        7




MILESTONE 3.1.


3.1.1. Additions to the OPUS College kernel

a. Study

    1. Implement start- and end-date for academic year
The start- and end-date for an academic year can run over 2 years, not necessarily
within one year. There may be variations within one university, e.g.: 2009 Medicine
can have a different start- and end-date than 2009 Natural Sciences.
Extend the database table with start-date and end-date.
Besides this extend the admin-function in the graphical interface with these new
fields.


   2. Define academic years per study and its underlying curriculum

Add or alter „valid from year‟ / „valid through year‟ -> one or more „current academic
years‟ on the following entities:
       Study-gradetype
       Subject-block (NOTE: studyyear will be replaced by the entity subject-block)
       subject
       subject_thesis
Note: the conversion of the current „valid from year‟ / „valid through year‟ is part of
this change.


   3. Create copy-functionality for study-curriculum

Any change in the curriculum of a study has to be done by copying the current
curriculum as a new version before making the changes. When a copy is made all
underlying entities are also copied. This concerns: study-gradetypes, subject blocks,
subjects, etc.
A new attribute academic year has to be specified for all entities within this copy.
After this the optionally necessary changes to the new version can be made.

In this way the history of the curriculum is saved and can be re-used for calculation
of results and keeping track of studyplans of students and so on.

Note: the level where the copy should be done is on grade type. In this way a
complete „deep‟ copy is made and only the academic year has to be altered.


   4. Implementation of subject-blocks
                                                                                      8


The concept of subject-blocks is already present in the OPUS College system. It only
has to be implemented on an object, on web and database-level.
Subject blocks can contain other subject blocks (tree structure). This is a necessary
recursion when defining combinations of compulsory and elective subjects.

Note: when subject-block is implemented the concept of study-year should be
withdrawn from the study-logic. This is then just a type of cardinal time-unit.


   5. Implementation of postgraduate study-gradetype

Implement attribute previous_study-gradetype with object study-gradetype. If
applicable, the obligatory previous study-gradetype can be filled in here.
Note: the system has to take into account that a student may have done his
previous study-gradetype at a different institution and therefore is not known to the
system. Therefore there has to be an option to manually override the checks on this
previous study-gradetype. (it is implemented and called: studygradetype-
prerequisite).
Also implement other extra attributes in order to make postgraduate (master) study-
gradetypes functioning in OPUS College. (See: subjects, new fields for „thesis‟).

Note: the choice of a studygradetype as next studyplan, while not the prerequisite
studygradetype is „ready‟ yet, should not be blocked. However, a message (blue ??)
should be shown.


   6. Implementation of major / minor subjectblocks

There is a distinction between subjectblocks that belong to the major study-
programme and subjectblocks that belong to the minor study-programme. The
concept of this is already present in the OPUS College system: subject-blocks can be
used to create subject-packages (e.g. „first year English minor‟).

The agreed scope of one subject-block would be that we define subject blocks per
cardinal time unit for majors and minors. This means that majors and minors cannot
be defined in OPUS as one big set of subjects that span over a period of several
years (a whole study-gradetype), but as a set of subjects within a sbjectblock that
are defined per semester.
Note: See the appendix for examples.

Note: this attribute cannot be required, since sometimes a subjectblock can contain
both subjects for the major and minor programme.

   7. Implementation of compulsory / elective subjects and subjectblocks

There are compulsory and elective subjects and subjectblocks.
The elective subjects can be chosen out of a range of subjects within a certain
studygradetype AND/OR within a certain cardinal time-unit within this
studygradetype.
To define how many elective subjects there should be within both a studygradeypte
and a cardinal time unit: new attribute in studygradetype:
numberofelectivesubjectstochoose PLUS new attribute in
cardinaltimeunitStudyGradeType (see: implementation cardinaltimeunit)
                                                                                         9

An elective subjectblock can be chosen out of a range of subjectblocks that are
elective within a certain studygradetype OR within a cardinaltimeunitnumber in a
studygradetype.
Note: there was also a wish for filler subjects (e.g. subjects to fill up a gap in subject
availability or to fill-in for a subject a student has exemption for), but that concept
can be easily put into the „elective subject‟ concept.
Note: use the existing table 'rigidity' for compulsory / optional -> elective


   8.    Implementation of study-gradetypes with foreign subjects and
        subjectblocks

For a number of studygradetypes there are one or more subjects and / or
subjectblocks that are taught in a different school / faculty. The OPUS College
system already takes this into account through the attribute freechoiceoption.
However, there are some issues related to authorization that should be covered:
 if the freechoiceoption attribute is „Y‟ a further choice has to be made to which
    studygradetypes / cardinaltimunitnumber combinations this subject or
    subjectblock is applicable. This is stored in subjectStudyGradeType and / or
    subjectBlockStudyGradetype. In the studyplan view then only freechoiceoption
    subjects / subjectblocks for that studygradetype of a foreign study(gradetype)
    are visible to select from
 the dean / asst. dean / asst. registrar of the school that organizes the study-
    gradetype gets read / write access to the entire studyplan of the student
    (including editing results), including the „foreign‟ subject of the other school.
 the dean / asst. dean / asst. registrar / lecturer of the subject from the school
    that organizes the subject that is selected within the foreign studygradetype gets
    read / write access to the actual subject within the studyplan of the student
    (including editing results). Other subjects within this studyplan are visible, but
    not writable.



b. Subjects, Subjectblocks, Thesis

   1. Add prerequisites to Subject

A subject can have one or more prerequisites. If this is the case, they are saved with
the subject on a study-gradetype level (coupling of extra table with id in
subjectstudy-gradetype), because a subject can be taught within different study-
gradetypes. And within each study-gradetype the prerequisites might differ.

Note: the mechanism of passing or not passing a cardinal time-unit is not part of this
logic. This is elaborated underneath its own description.

Note: the choice of a subject within a studyplan, in which not the prerequisites are
„ready‟ yet, should not be blocked. However, a message (blue ??) should be shown.

   2. Add prerequisites to Subjectblock
Note: the above goes for subjectblock too. Implement the same features for
subjectblock.


   3. Add prerequisites to StudyGradeType
                                                                                   10

Note: the above goes for studygradetype too. Implement the same features for
studygradetype.


    4. New entity thesis

For postgraduate studies the object subject has to be extended with extra fields. This
can be done in a separate sub-object „thesis‟ or within the object „subject‟ itself.

   thesis-title
   abstract
   keywords
   researcher(s)
   supervisor(s)
   publication(s)
   board of examiners (reading committee)
   defense committee
   status of clearness (concerning ethics committee)
   thesis status (e.g. „proposal cleared‟, „thesis accepted‟) and status-date
   year(s) of research
   affiliation fees
   research
   published works

Note: the thesis status have to be added as lookup values.
Note: The subject edit screen also has to be extended with these attributes.




c. Cardinal time-unit

The Cardinal time-unit is a new concept underneath both studyplan and study-
gradetype.

A cardinal time-unit may be a semester, a trimester, a study-year or any other time-
unit. It consists of a number of studyplan details (subject blocks and / or a number
of obligatory and / or elective subjects), chosen by a specific student for his/her
studyplan.


    1. Implement concept of cardinal time-unit for study curriculum



Entity Diagram Curriculum Study
                                                                                      11




Study-gradetype:
The cardinal time-unit is the time-unit that is measured within a study-programme
for various purposes: calculation of total grade for this time-unit, decision on passing
/ not passing cardinal time-unit, blocks of obligatory subjects and / or elective
subjects, and so on. The cardinal time-unit is saved at the level of study-gradetype
(e.g. bachelor programme of natural sciences uses semesters).

A study-gradetype needs the following new attributes:
    Current academic year
    Measured cardinal time-unit (semester, study-year, …)
    Number of cardinal time-units for study-gradetype (e.g. this was number of
    study-years)
    Max. number of cardinal time-units for study-gradetype (e.g. this is the max.
    number of time a student can use to finish this study-gradetype). Note: Only the
    actively registered cardinal time-units for a student within a study-plan count for
    this max.
    the number of subjects per cardinal time-unit
    max. number of subjects overload
    the rules for passing a cardinal time-unit for each student-type (e.g. fulltime
    student – clear pass -> no subjects failed, fulltime student – proceed and repeat
    -> for example: 1 or 2 subjects failed with minimum D+, part-time student. (See
    exact calculations on this elsewhere in this document)

Example of a study-gradetype: full time bachelor based on a cardinal time-unit by
semester, with at least 6 cardinal time-units to complete the study-gradetype.
                                                                                   12

Note: the concept of „half course‟ at CBU can be put in this cardinal time-unit
principle.
Note: the concept of „diploma student‟ (3 years study-gradetype) at CBU can also be
put in this cardinal time-unit principle.

Other adjustments:
       Add/edit study: StudyGradetype: number of years -> number of cardinal
       time-units. Max. number of years should be higher than it is now.
       Add /edit study: tab Study-years -> Cardinal time-unit
       Add / edit study-year (e.g. cardinal time-unit): year number -> cardinal time-
       unit number
       Add / edit study-year (e.g. cardinal time-unit): variation can be empty (name
       build up out of study / grade type and cardinal time-unit
       Study form: replace with studytime (daytime, evening, …)
       Add new entity cardinaltimeunitstudygradetype inbetween studygradetype
       and subjectblocks / subjects / projectcourse

Note: The current study-year will be replaced by this cardinal time-unit. Once
implemented, convert the current study-years to a type of subject block that can
inherit other subject-blocks.


   2. Implement concept of cardinal time-unit for studyplan

Entity diagram Studyplan
                                                                                      13

Studyplan:
Implement studyPlanCardinalTimeUnit and cardinal time unit Endgrade as extra
entities (list) within study plan.

A cardinal-time-unit Endgrade has the following attributes:
   current academic year
   measured cardinal time-unit
   cardinal time-unit number (in the range of number of cardinal time-units for
   study-gradetype) – NOTE: this might be optional
   end-grade cardinal time-unit
   comment end-grade cardinal time-unit
   0 – n study plan details

A studyPlanCardinalTimeUnit has the following attributes:
    Cardinal time unit number
    current academic year
    study plan progress status


Note: See the appendix for examples.

Note: these conversions should be made generic, so that the Mozambican
universities can execute an sql-script.


   3. Attribute max. number of subjects per cardinal time-unit

Make a distinction between different types of student, e.g. fulltime / part-time
student.
Note: This is done at the studygradetypelevel automatically.


   4. Overload concept for max. number of subjects per cardinal time-unit

The maximum number of subjects per cardinal time-unit per student-type can be
manually overloaded for a specific student. This is done on a studyplan level by the
student himself: He can increase the number of subjects, but a warning message will
appear that the maximum number of subjects is exceeded. This overload can only be
approved by an authorized person (role dean / asst. dean).


   5. Functionality for transition to the next cardinal time-unit


When a student has or has not succeeded his cardinal time-unit within a studyplan
there have to be several options for progress (see graduate cardinal time unit
calculations for the exact progress options).

This functionality is based on the rules for passing / not passing a cardinal time-unit
(see elsewhere in this document).
When the endgrade for a cardinal time unit in a studyplan is set to „passed‟ by the
(automatic) calculations the student is eligible for this transition. He or she can then
be assigned to the subjectblocks and subjects for the next cardinal time unit in this
studygradetype.
                                                                                      14

Note: this concerns only the basics (manual transition). The continued registration is
elaborated in deep in milestone 3.2.


   6. Functionality for repetition of the current cardinal time-unit

This functionality is based on the rules for passing / not passing a cardinal time-unit
(see elsewhere in this document). When the endgrade for a cardinal time unit in a
studyplan is set to „NOT passed‟ by the (automatic) calculations, the student has to
redo (a part of) current cardinal time unit:
     When a student goes „to part-time‟, he has to repeat the failed subjects, but
       cannot advance to the next cardinal time-unit.
     When a student „repeats and succeeds‟, he advances to the next cardinal
       time-unit, but has to redo the failed subjects in addition to the subjects in the
       new cardinal time-unit.

Note: A student never has to redo subjects that he has passed successfully.
Note: this concerns only the basics (manual transition). The continued registration is
elaborated in deep in milestone 3.2.



d. Roles / user privileges

   1. allow multiple roles per user

At UCM there is a wish to allow multiple roles per user, to avoid having one person
logging in with different usernames.

   2. Make editable fields option depending on role

Configure if fields can or can not be edited by a specific role. Use the html-id of the
fields for this configuration. This should be done through configuration in the
database:

E.g. Allow students to edit a configurable number of fields themselves.

New table with following attributes:
    Field id (e.g. „student.surname‟, …)
    Visible
    Editable

Note: the mentioned field id‟s should have the corresponding unique id within the
html on the lowest DOM tree level (e.g. „student.surname‟, …).



e. Students

     1. Distinguish student statuses from study-plan statuses and cardinal
     time unit statuses
                                                                                     15

The study-plan has to get an extra attribute status. The student statuses that are
actually study-plan statuses should be converted to these study-plan statuses.
Furthermore some statuses belong more to a level of the cardinal time unit that is
active. These statuses concern the continued registration

Student statuses are:
    Excluded
    Suspended
    Expelled
    Deceased

Study-plan statuses – admission process:
    Start initial admission
    Waiting for payment initial admission
    Approved initial
    Rejected initial admission

Study-plan statuses – general:
    Temporary inactive
    Graduated
    Withdrawn

Cardinal Time Unit statuses – continued registration process:
- start continued registration
- waiting for approval of registration
- rejected registration
- approved registration (waiting for payment)
- actively registered

Note: these changes will mean a conversion for the participating Mozambican
universities. That conversion is part of this task.


   3. Elaborate Student statuses

Use refactored statuses and add new statuses for new modules admission /
registration


   4. New attribute domestic / foreign

Distinguish between domestic / foreign student.




f. Studyplans

   1. Elaborate studyplan statuses and bind them to studyplan

   Use refactored statuses (split-up of student-statuses and studyplan-statuses) on
   the level of study-plan and add new statuses for studyplans (drop-out, etc. )
   Bind the studyplan status to studyplan itself and studyplan-detail (check if
   necessary to also bind to cardinal time-unit)
                                                                                      16



   2. Implement postgraduate study-plan for students

Some extra fields concerning thesis are necessary for postgraduates. For detailed
description of these extra Thesis-fields, see subjects.


   3. Create possibilities for exemptions

Exemptions can be put into the system by manually giving a (fixed) grade for the
subject the student has exemption for. The role to fill in this grade manually is dean
/ asst. dean.
Note: No concrete action, only check if this manual override functionality works.


   4. Make variation name of studyplan non-obligatory


   5. Overview screen student: subjects that are distributed to other
      studies

If a subject is choosable for other studygradetypes (socalled alien subject), it
currently has an extra (number of) row(s) in the table „subjectstudygradetype‟ for
each study-gradetype it is choosable for.
Note: in the select screen for a student for his / her next cardinal time-unit in a
study-plan only the subjects will have to be visible that are applicable for the
studygradetype the study-plan is concerned with.
Note: this is arranged for with the new privileges-setup. No extra action necessary
here.


   6. Flexible number of studyprogrammes to choose for student in a
      studyplan


Minimum only 1 choice for study-gradetypes (possible major / minor combination) at
admission / registration. There should also be a maximum set to the number of
study-gradetypes that can be chosen at admission. (assuming a maximum of 2).



h. Modularization

   1. Structure for country- and university specific parts of the system


   2. Flexible extension points concept


   3. Implement concept of language-country specific settings

Terms can be different for countries within the same language. Therefore the
language-files must be specified deeper.
                                                                                      17

For instance we have a file: messages_en.properties, which is the default for all
English language texts in OPUS. Zambia-specific variations shall be defined in
messages_en_zm.properties, by overriding the English default texts.. It should be
messages_en_zm.properties.

Overview/Examples of internationalized messages file structure:

Filename                            Content
messages.properties                 Messages that are the same in most languages –
                                    or default language messages
messages_en.properties              English language text defaults
messages_en_zm.properties           Zambian variations (only declare variations from
                                    English defaults, not all language texts again!)
messages_pt.properties              Portuguese messages defaults
messages_pt_mz.properties           Variations for Mozambique
messages_pt_br.properties           Variations for Brazil
messages_nl.properites              Dutch messages defaults
If a text is not found in a messages file, then the next higher level will be consulted,
e.g. for Zambia: if a text is not found in messages_en_zm, then
messages_en.properties will be searched in, if it is not found there, then
messages.properties will be consulted.



i. Security

Within the project the Radboud University / Giphouse Students Martijn Sprengers,
Benjamin Mäder and Adam Cornelissen will produce a document with
recommendations concerning security. A number of activities can be distillated from
this recommendations-document.

   1. Extend password protection

   Check old password at password-change. First fill in old password + re-enter,
   before changeable new password.
   Change the encryption from MD5 to SHA1, combined with salt-code. This is a
   piece of code that is extended to the string that should be encrypted. This string
   is configured on application-level.


   2. General security-improvements through Spring

Spring security encompasses all different areas, and can be configured in specific
XML files, in Java files (like the example above) and in JSP files. We can benefit
within OPUS from Spring security if we start with the basic implementation. Then, it
should make it easy in the future for developers to deal with most security aspects.
The Spring Security page has a lot of useful information:
http://static.springsource.org/spring-security/site/index.html
For an overview there is a good video of the original author of Spring security here:
 http://www.viddler.com/explore/oredev/videos/22/
A good site on the subject of application security, including web application security:
http://www.owasp.org/index.php/Main_Page
                                                                                      18

The basic way Spring Security works is by intercepting all web-traffic by a filter that
is activated just like any other Spring filter.
There are some basic things that are already quite useful, such as handling of
session timeouts. But a major challenge with regard to a more flexible security
structure for us is to allow several roles for one login, e. g. being a decentral admin
for two different organizational units.
What could be useful is Spring Security's expression language; See:
http://static.springsource.org/spring-security/site/docs/3.0.x/reference/el-
access.html:

@PreAuthorize("hasPermission(#contact, 'admin')")
  public void deletePermission(Contact contact, Sid recipient, Permission
permission);

Here, there is a check if the current user has admin permissions for the given
contact. Similarly, if we replace contact with "organizational unit" and admin with
e.g. "decentralized admin", we have an illustration how to check permissions.
                                                                                    19

3.1.2. New module for country specific settings
Mozambique

b. Fast Input facility student

The fast input facility for students is typical Mozambican. It should be moved to the
Mozambique module.



c. Test country-specific issue

To see if the structure of a country-specific module works, test two of the
Mozambican country-specific settings for Zambian needs. Suggestion is to test with
the specific Zambian student types and the generation of a specific student number,
see next chapter.
                                                                                      20


3.1.3 - New module for country specific
settings Zambia

a. Implement country-specific study times

    Adjust the database and graphical interface. Identified study times are:
     Daytime Students (D)
     Evening Students (E)

b. Implement country-specific study forms

    Adjust the database and graphical interface. Identified study forms are:
     Regular learning
     Parallel students
     Distant learning
     Various forms



d. Obligatory fields phone number and e-mail address

To be able to send e-mails concerning admission and registration process and/or
contact students by telephone the phone number and e-mail address will become
obligatory.



e. Prevention of double registration of students
To prevent double registration of students, the national registration number should
be taken into account with the uniqueness-check at initial admission.



f. Create graduation comment types

These are the comments that are shown automatically based on the end-grade for
one cardinal time-unit once the percentages are filled in (see above).

GRADES
Letter Grade                 Comment                       Description
A+                           Distinction
A                            Distinction
B+                           Meritorious
B                            Very Satisfactory
C+                           Clear Pass
C                            Bare Pass
S                            Satisfactory, Pass in a
                             Practical Course
P                            Pass in a Supplementary
                             Examination
                                                                                    21

AG                           Aegrotat Pass
D+                           Fail
D                            Definite Fail
F                            Fail in a Supplementary
                             Examination

Note: Aegrotat Pass is nowhere covered. Check if this is correct.

In a number of cases the letter grades can be overridden by letter grades that do
NOT go together with the percentage score. This score will be reset to 0:

GRADES THAT OVERRIDE PERCENTAGES (meaning 0 %)
Letter Grade         Comment                     Description
U                    Unsatisfactory, Fail in a
                     Practical Course
NE                   No Examination Taken
WD                   Withdrawn from the          Recorded when student
                     course with penalty for     has not completed
                     unsatisfactory academic     required level of course
                     progress                    work after a warning by
                                                 Dean. Dean withdrew
                                                 student from studies
                                                 before the examination.
LT                   Left the course during the
                     semester without
                     permission
DQ                   Disqualified in a course by
                     Senate Examination
DR                   Deregistered for failure to
                     pay fees
RS                   Re-sit course examination   Recorded when student
                     only                        was allowed by Senate to
                                                 re-sit the final semester
                                                 examination and to carry
                                                 over course work
                                                 assessment


In special cases the letter grades can be overridden by letter grades that go together
with the percentage score. This score will still be valid and counted:

GRADES THAT GO TOGETHER WITH PERCENTAGES
Letter Grade         Comment
WP                   Withdrawn from course
                     with permission
DC                   Deceased during course


In a number of cases the letter grades can be overridden by TEMPORARY letter
grades that do NOT go together with the percentage score. This score will be reset to
0:

TEMPORARY GRADES
                                                                                    22

Letter Grade                 Comment                       Description
IN                           Incomplete                    Recorded where a student
                                                           has not yet completed all
                                                           the requirements of a
                                                           course and has been given
                                                           extension with the formal
                                                           permission of the Head of
                                                           Department. Except for
                                                           courses which are done
                                                           during the long vacation,
                                                           this grade has to be
                                                           finalized into one of the
                                                           pass or fail grades before
                                                           the School‟s Board of
                                                           Examiners‟ meeting
DF                           Deferred Examination          Recorded where, for
                                                           health or other
                                                           compassionate reasons, a
                                                           student is to be allowed to
                                                           write the final examination
                                                           later, during the period
                                                           reserved for the deferred
                                                           examinations
SP                           Supplementary                 Recorded where a student
                             Examination                   is to be allowed to write a
                                                           supplementary
                                                           examination, during the
                                                           period reserved for
                                                           supplementary
                                                           examinations

Note: there has to be an option to overrule these generated comments with other
comments (role: dean / asst. dean).



g. Implement concept of parallel students

Parallel students are fulltime students, they only are not chosen through the cut-off
point principle, but have re-applied themselves and are approved manually by the
dean for registration. Parallel students have higher fees (self-sponsored).
They are distinguished on the level of their studyplan through the „studyform‟
attribute (parallel programme).
                                                                                       23


3.1.4. Views by Privileges I
Create specific views and screens depending on role & privileges. Depending on the
roles of users, they will have access to a different set of privileges and corresponding
menus, which make relevant functionality available.



a. Student

Views on:
   Student Personal data:
       Edit personal data (telephone email (See: Chapter 1 – Students – editable
       fields for student)
   Study plans:
       Register for cardinal time unit or loose subjects (next cardinal time-unit in
       own study-plan) (see: Chapter 7 – New module continued registration)
   Examinations & Results:
       Overview of all results within the study-plan(s) of the student (note: if not
       withheld due to outstanding fees or penalties)
       Print result slips (see: Chapter 9 – Reports)
   Fees:
       View outstanding fees
       Print payment receipts for all passed cardinal time-units in study-plan(s)
   Admission & Registration:
       Print admission slips (stages in admission process) (see: Chapter 9 –
       Reports)
       Print confirmation slip (see: Chapter 9 – Reports)
       Print examination slip (see: Chapter 9 – Reports)

Note: A student should only see the subjects that are applicable at the current stage
in the current study-plan. This is a complex calculation based on the end-grade of
the previous cardinal time-unit and the student-type (fulltime, part-time, and so on).
These calculations are taken care of in other tickets, here just show the results of
that.

Note: Show ctu-transition (like fast input students) with subjectblocks and/or
subjects for a 'passing' student to the following cardinal time-unit for a specific
study-gradetype. This ctu-transition is taken care of in another ticket, here just show
the results of that.

b. Teacher

Views on:
   Staff member Personal data:
       Editable teacher preferences (concerning teaching timeframe preferences and
       so on)
   Study curriculum:
       Subjects taught with timetable and student lists
   Examinations & Results:
       Examinations supervised with timetable and student lists
       Subject taught - results edit screen (with underlying examinations and tests)
                                                                                     24



c. Head of Department

Views on:
   Admission & Registration:
       Approval / rejection of continued registration – to status waiting for approval
       of dean (next cardinal time-unit in study-plans of registered students) (see
       Dean's homepage)
   Study plans:
       Add / edit / delete at department level student‟s study-plan data manually
       (adjust own continued registration of the student) (see Dean's homepage)
       Possibility to add subject overload at department level to a student‟s study-
       plan manually (see Dean's homepage)
       Full transcript at department level of student‟s study-plan and results so far
       (also in XLS) – already existing
   Examinations & Results:
       Print result slips at department level for examinations for various cardinal
       time-units and academic years. (see: Chapter 9 – Reports)



d. Dean / Asst. Dean

Views on:
   Admission & Registration:
       Approval / rejection of admission (see: Chapter 6 – New module Admission)
       Approval / rejection of continued registration – approve proposals of HOD‟s
       (next cardinal time-unit in study-plans of registered students) (see: Chapter
       7 – New module Continued registration)
   Study plans:
       Add / edit / delete student‟s study-plan data manually (adjust own continued
       registration of the student) (see: Chapter 7 – New module Continued
       registration)
       Possibility to add subject overload to a student‟s study-plan manually (see:
       Chapter 7 – New module Continued registration)
       Full transcript at school-level of student‟s study-plan and results so far (also
       in XLS)
   Study curriculum:
       Do proposals for Add / edit / delete study-gradetypes and subjects of own
       school (note: this is done as a request to the academic office – text message
       system)
   Reports:
       Senate Examinations Report of own school (see: Chapter 9 – Reports)
       Print result slips for examinations for various cardinal time-units and
       academic years. (see: Chapter 9 – Reports)
   Examinations & Results:
       View subject results for subjects that are from own school, but distributed to
       other schools in their study-gradetypes.
   Fees:
       View / print outstanding fees to the school
       Postgraduate students - Subjects taught at this school - results edit screen
       (with underlying examinations and tests) (see: Chapter 1 – Students)
                                                                                   25

N.B. The Dean needs a screen with student progress options to choose from and a
batch-wise select of students for the chosen student progress. See detailed
description of the identified progress-options underneath the country-chapters.
In this overview the dean needs to see in a separate column the students that have
chosen one or more elective subjects, because these selections have to be approved
in detail.
Note: Actions must be made batch-wise, like already existing mass assignment
(student-transfer from 1 studyyear to the next in the Mozambique module).




f. Academic Affairs Office

Views on:
   Admission & Registration:
       Approval / rejection of admission
       Configuration of registration period: Opening / closing registration period
       Print / Export Yearbook students at beginning of each cardinal time-unit
       Student reports (see chapter „Reports‟ for all student related reports for
       academic affairs office)
   Student personal data:
       Add / edit / delete student‟s personal data manually (adjust admission /
       registration student)
       Upload / edit / delete photographs of students
       Print student cards
   Study curriculum:
       Add / edit / delete study-gradetypes and subjects of all schools (note: dean of
       the school has sent a proposal for these changes through a text-message-
       system)
   Fees:
       Add / edit / delete student‟s fees related data manually
   Scholarships:
       Add / edit / delete student‟s sponsor related data manually
       Sponsor reports (see chapter „Reports‟ for all sponsorship reports for
       academic affairs office)
   Examinations & Results:
       Elaborate Senate Examinations Commission approval / rejection on student‟s
       study plan progression complaints. This approval / rejection itself is done
       outside the system. Note: Academic Office changes the results for that
       student, according to the decision of the Senate Examinations Commission,
       not the deans / asst. deans of the schools.
       Senate Examinations Report per school
       Print diplomas / certificates of graduation
   User accounts:
       Possibility to enable / disable system user privileges (limited period, limited
       privileges)

Note: The Academic Office is the authority where user privileges are maintained.
They are the central administrator for the university.



h. Registrar / Asst Registrar
                                                                                26

Views on:
   Examinations & Results:
       Print diplomas / certificates of graduation (see: Chapter 9 – Reports)
       Senate Examinations Report per school



g. Functional Administrator

Views on:
   Everything !
                                                                  27


3.1.5. Extensions to module Fees

a. Add fee categories

Identified categories are:
    Tuition (different per student type)
    Housing / Accommodation
    Examinations
    Medical
    Recreations
    Admission – Initial Application (First year students only)
    Registration (First year students only)
    Insurance / Caution (First year students only)

Specific for UNZA:
    Student Union
    Internet

Specific for CBU:
    Technological Fee
    Part-time Fee Per Course (Defined per school)
    Exemption Fee Per Course (Defined for whole university)
                                                                                     28




MILESTONE 3.2.


3.2.1. Additions to the OPUS College kernel

a. Staff-members

     1. New attributes concerning preferences staff-member

For timetable algorithm and other new functionality there are new attributes for a
staff-member:
     Working hours – start
     Working hours – end
     Preferred teaching day-part
     Preferred supervising day-part




b. Roles and privileges

   1. roles based on privileges that can be chosen

The current system works with hierarchical roles. The wish is to extend these roles
with privileges that can be chosen, so that the role itself becomes more flexible.
The privileges of a certain user then determines the set of available menus for this
user.
Example: A person with the correct authorization (probably the role dean) can alter
the contents of study-gradetypes, subject-blocks, subjects, underlying examinations
and tests.

See for the recognized roles per country: specific sections on country-settings.

Most common privileges:
View / Print
Add / Edit
Delete

Extra privileges:
View History
View Withheld ...


       2. set an end-date to privileges / actions
                                                                                       29

A set period for entering for instance exam-results or registration for a cardinal time-
unit: the specified privilege gets automatically deactivated when the period has
passed. In next time-unit this privilege has to be manually reactivated.




c. Study, studygradetype, cardinaltimeunit

1. integrate study and studygradetype into one screen

See: Requests_Terminology.doc for specifications.

2. max. number of subjects per ctu not fixed

- max. number of subjects per cardinal time unit: this differs per study, should not
be fixed for all authorizations. Can be overridden by higher authorizations.



d. Subject, subjectblock, thesis, projectcourse


   1. Thesis extensions

a.    distinction between principal supervisor and other supervisors necessary.
They can be internal and external (this means: not registered as staffmembers)
b.    beginning / end date
c.    new statuses failed and passed
d.    grade (without comment)
e.    only applicable for masters and phd‟s, not for bachelors (hide)

    2. Courses additions
- courses: credit amount value can be broken digits (1.5, etc.) and must not be
mandatory
- prerequisite courses: if student selects a course in studyplan that does not meet
the prerequisites than only dean of school and higher can override the block on this
(error for admin-D, student, lecturer, message for admin-B and higher - > submit
button shows or not)

e. Students

   1. Fine-tune attribute housingoncampus student / staffmember

Depending on student-type there may be different preferences.

Housingoncampus: Students that are part-time do not have the option for
accommodation on campus. Their (already existing) attribute
person.housingoncampus must be default set to „N‟. In general the attribute
person.housingoncampus is „Y‟ for fulltime students and parallel students. But it must
be possible to manually alter this trigger for certain roles (e.g. academic office and
dean of students).
                                                                                      30

Furthermore: show link to accommodation module next to this attribute, if the
module is loaded (just like with scholarships).

    3. Extra student fields for Dean of Students
Nieuw fields are:
- telephone number father
- telephone number mother
- multiple secondary schools (possibly more than one, so for the attributes
concerning secondary schools a 1 – n option)
- multiple activities / interests (for each activity a memo-field)
- multiple career preferences (memo-field, now: 1 – 3)
- multiple notes on interviews and counseling (memofield, 1 – n)
- multiple placement & follow-up (memofield, 1 – n)

Note: notes on interviews and counseling are confidential. They may only be seen by
the DOS, not by any other authority !!

E.g. also see the forms (paper) of the Dean of Student.



f. Studyplans

   1. Subjects within cardinal time-unit: subject-examination-access
   attribute

A student in principal has access to the approved subjects for a cardinal time-unit
within his / her studyplan. However, the dean can manually decide to exclude a
student from a subject-examination. The student can then not print examination
slips in the period that is set for that. The default-value for the subject-examination-
access attribute is true.
Note: this only counts for subject examinations. All continuous assessments
underneath this subject are not taken into account.

2. integrate studyplancardinaltimeunit / edit of 1 cardinaltimeunit into one
screen


See: Requests_Terminology.doc for specifications.



g. Results

1. Implement basic calculation for passing a cardinal time-unit

Implement simple generic form of calculating an end-grade for a cardinal time-unit,
based on the Mozambican system. Country-specific variations are described in detail
underneath the corresponding country-chapters.


1. Calculation of degree grade study-gradetype: flexible number of subjects
                                                                                      31

In Zambia at UNZA not all grades count for end-grade. Therefore the number of
subjects to count should be made flexible: Subjects to count from the last one down:
 In Mozambique: all subjects
 In Zambia (UNZA): last 16 subjects
 In Zambia (CBU): only senior subjects (3rd and 4th year (and 5th year))


2. Withhold results for students that are not eligible

When a student has not registered yet or has outstanding fees and/or penalties the
results for this student are not visible.


3. Specific period for retry of examinations and for deferred examinations

Examinations have (possibly) a retry-option. This retry-option is held within a fixed
period within the cardinal time-unit that the subject is taught. After this period there
is no possible retry.

Besides this a student may have a deferred examination, due to illness or other
causes that are the reason the student could not take the examination. This deferred
examination-option is held within a fixed period within the cardinal time-unit that the
subject is taught. After this period there is no possibility for a deferred examination.


4. On deletion of an examination result renumber other attempts

Bug: When there has been more than one attempt for an exam, and the (e.g.) first
one is deleted, the attempt numbers are not recalculated. So there will be more than
one attempt with attempt number 2 and further. This has to be refactored.


5. Overview screen dean / asst. dean / asst. registrar: subject results for
   subjects at other studies

If a subject is choosable for other study-gradetypes, it currently has an extra
(number of) row(s) in the table „subjectstudygradetype‟ for each study-gradetype it
is choosable for.
Note: in the select screen for a dean only the subject-results will be visible for the
subjects that belong to a study-gradetype that the school of the dean is concerned
with.

6. Create crosslinks between studyplan / results

Stepping between the views of the studyplan and the results of the student on the
corresponding levels.

7. Implement thesis-result

Create table and screen.
                                                                                       32

h. Refactoring

1. Refactoring of names (Zambian / English default)

Note: all words in the English version should start with a capital (academic English
rules)

Changes:
- study form = categories of study
- subject = course
- teacher = lecturer
- didactial forms = modes of delivery
- Weighing factor = weight
- subscription data = registration data
- bachelor = undergraduate
- master and phd = postgraduate
- study grade / study grade type = programme / study programme

-> see further: document Terminology_changes


2. Use of Annotated Controllers instead of Simple form controllers

Technical changes due to the progress to @Controllers.

3. Refactoring of Mass Assignment Students to the new structure

This part has to be done before the continued registration.
It‟s principle can be used as the start of this module.


4. Open source license structure

Choose a model and implement it in this phase.

5. Repair admin menu

Due to academic year and study year changes the admin menu is not working
anymore. Repair actions by Stelio.

6. Rename registration.view -> admission.view
Started with admission, but rename files used so far.

7. Small additions studyplan cardinal time unit
- Studyplanctu: if a progresstatuscode is given, the studyplanetails should not be
changeable anymore
- progresstatus: extra attribute „continuing‟ (which will be „isPassed‟); not passed are
only: exclude school, exclude studygradetype, others are all passed.

8. Staffmember appointment validator bug
staffmember: appointment start / end workday -> hours / minutes have no validator
If the value is not the right string, than the application breaks.
There should be a validator on hours/minutes.
                                                                                       33


9. Typify cardinal time unit / organizations

Typifying:
-      replace the word 'cardinal time unit' as much as possible with the typified
name (semester, trimester, etc.)
-      replace the word 'organizational unit' as much as possibile with the typified
name (department, school, ...)




i. Modularization

1. Countryspecific addresschecks (telephone, zipcode, ..) out of
OpusConstants (db)
Some addresschecks are country specific. They need to have their own
implementation in the specific country module.
This means that these values should be moved away from OpusConstants. So far
recognized:
- mobile phone
- telephone / faxnumber
- zipcode
                                                                                 34


3.2.2. Extensions to Mozambique Module

a. Exam-calculation grades / mappings

Identified grades and mappings to values are the current grades and values that go
with them, extended with the intermediate calculation of the new entity cardinal
time-unit (this calculation will be made by Monique, see: Chapter 3, Subject /
Graduation / Degree grade-point-percentage bindings).
The Mozambican markEvaluation filling is the whole alphabet.



b. General conversion data opus 3.0 -> opus 3.2
The data of opus version 3.0 must be converted to the new database structure. Best
is to do this the same as for the new zambian universities, who are making
conversion scripts through JAVA: one export script which is specific. One import
script (dbconversion module) that is generic for all parties.
                                                                                       35




3.2.3. New module for university specific
settings UNZA

a. Generating university specific student number

Note: The current student number is built up of 5 digits randomly + 2 digits for the
year.
CICT UNZA staff were interested in the following student number format, that is
currently used by UCM:
     1 digit university code
     2 digits faculty code
     2 digits year of admission
     4 digits running number, starting every year with 0001
Example: 706091234



b. Fill copy-database with EWAN / SRS data
UNZA will extract the data of the current online registration system and student
system into a PostgreSQL copy of their database.



c. Conversion current data

UNZA will extract the data of the current online registration system and student
system (or more likely, the copy in PostgreSQL) into the OPUS database.
This change concerns both the mapping of the data from EWAN / SRS to Opus and
writing the code to import this mapping into the opus database.

Note: This will be done by the CICT itself, under coaching of the kernel developers.

For the import-side into OPUS of this the DBConversion module can be used.



d. Test Conversion


e. Extra attributes postgraduates: study permit

Study permit - extra fields for postgraduates (mandatory),
       study permit number
       study permit date of issue
       study permit date of expiration
                                                                                     36

f. Interface for HRM system Accsys

At UNZA there is a wish for an interface that pushes information on staff-members
from their payroll system (Accsys) into OPUS.

Note: CICT-UNZA is assigned with this task, but it has least priority within this
project. This means that this interface may be built at the end of or after the current
project.



g. Interface for Accounting system SAGE

At UNZA there is a wish for an interface that pushes information from OPUS into
their Accounting system (SAGE).
At the moment it is already possibly to do the following from SAGE (quote Nabiana
N. Masiye): ON THE STUDENTS RECORDS,WE ARE ABLE TO POST TRANSACTIONS
TO THE GENERAL LEDGER WHICH IS MORE LIKE THE CASH BOOK BUT CANNOT
POST TO THE ACCOUNTS RECIEVABLE ACCOUNT.WE ARE ALSO ABLE TO DO
RECONCILATION.THIS IS SPECIFICALLY FOR OUR SECTION.

A wish of IA is to have access to SAGE (accounting system). At the moment there is
no relation between the online registration system and SAGE. Everything is
transferred through print outs. The Online Registration has an interface in which
information from the bank is imported, but that information is delivered only on print
to the SAGE system (owned by the bursary).
Ms. Katoyo (Chief Internal Auditor) claims that there is a module in SAGE to connect
/ interface with a student system, but this module is not effectuated yet. SAGE was
build by consultants from Zimbabwe and they would have to be involved if an
interface would be made.
Note: this concerns new information. We take notice of this, but cannot assure that
this can be done in this project.

Note: CICT-UNZA is assigned with this task, but it has least priority within this
project. This means that this interface may be built at the end of or after the current
project.



h. Student application for study-gradetype: 1 max

Flexible number of studies to apply for -> UNZA allows only 1 choice of study-
gradetype.
                                                                                       37


3.2.4. New module for university specific
settings CBU


a. Generating university specific student number

CBU wishes to have the same student number generation as UCM (Mozambique)
already has within OPUS. This means that the student number generator of the UCM
module has to be copied for CBU on that account.



b. Fill copy-database with STURECO data

CBU will extract the data of the current online registration system and student
system into a PostgreSQL copy of their database.



c. Conversion current data

UNZA will extract the data of the current online registration system and student
system (or more likely, the copy in PostgreSQL) into the OPUS database.
This change concerns both the mapping of the data from STURECO to Opus and
writing the code to import this mapping into the opus database.

Note: This will be done by the CICT itself, under coaching of the kernel developers.

For the import-side of this the DBConversion module can be used.



d. Test Conversion


e. Extra field application number at Admission

The application number given at the time the applicant is buying the form: the five
numbers are just a series of the number of forms sold each year. the numbering is
continued where it was left the following year and so on and so forth.



f. Interface (2-way) for Accounting system
Dimensions

At CBU there is a wish for an interface that pushes information from OPUS into their
Accounting system (Access / Dimensions).
Also there is a wish to make information from the accounting system visible within
the OPUS system (read-access database).
                                                                                  38

Suggestion: CICT can build this interface during or after the current project.



g. Student application for study-gradetype: 2 max

Flexible number of studies to apply for -> CBU allows only 2 choices of study-
gradetype. Configure this in the university-specific settings.
Note: the implemented attribute secondarystudyid: is not part of student, a student
can simply have more than 1 studyplan (solve in admission module). Only at
admission a second study can be schosen.
                                                                            39


3.2.5. New module DBConversion
Implementation of the import-module for Opus data by the CBU
Development Team.

This module uses the java domain objects / ibatis scripts that are already in
the college-module.

Note: this task is assigned to Sylvester to keep track on it for the whole CBU-
team.
Note: this is a zero-budget task, but just write the hours so that we
can see how much time you have spent on it together.
                                                                                      40


3.2.6. New module Admission

a. Implement admission process

Note: see for the exact fields the student has to fill in during the admission process
the paper forms for admission as a bachelor and as a post-graduate from CBU as a
starter. The admission for bachelor and post-graduate have different required fields
!!

Flow diagram for admission – PHASE 1




PHASE 1 - Initial admission:
   Step 1: Account creation - Student fills in basic information and receives
   student-number, login and invoice per e-mail.
   Step 2: Account payment - student goes to bank and pays admission fee
   (approx. $30,-)
   Step 3: Payment confirmation - bank pushes information on payment by
   student to OPUS. Study-plan status: Initial Admission. If there is no automatic
   push mechanism, then the payment information is entered by hand by the
   bursar‟s office.
   Step 4: Initial admission - After payment by student is fulfilled (check
   automatically by the system!), student can login and apply for a specific study-
   gradetype by filling in his / her background, secondary school subjects, and so
                                                                                     41

   on (see forms concerning initial registration from UNZA and CBU). Study-plan
   Status: Waiting for approval of Admission.
       Note: in the case of Admittance Schools the student at admission signs up for
       a preparatory phase (typically one, sometimes two years). Towards the end
       of the preparatory phase the student chooses a study-gradetype of first,
       second and third choice. At the end of Admittance School the student gets
       transferred to one of these choices, based on his / her grades during the
       common study- gradetype (see quota allocation, elsewhere in this document).
       Note: the study- gradetype of first, second and third choice can be within a
       different school / faculty.
   Step 5: Cut-off point selection - The dean can adjust the value of the cut-off
   point algorithm in order to select more or less students automatically. Based on
   this cut-off point a bulk of students is automatically selected for the study- study-
   gradetype of their first choice. However, the dean still has to approve this bulk-
   selection manually, for security reasons. Note: if there is a numerus fixus on the
   selected study-gradetype and the student is above the cut-off point selection, the
   student is placed on a waiting list. Study-plan Status: Approved Admission /
   Rejected Admission.
   Step 6 (optional): Cut-off point selection second choice – The dean can use
   the cut-off point algorithm to select students that have chosen a study-gradetype
   within his/her school as first or second choice, and are above the cut-off point. A
   bulk of students is automatically selected for the study-gradetype of their first or
   second choice. However, the dean still has to approve this bulk-selection
   manually, for security reasons. Study-plan Status: Approved Admission /
   Rejected Admission.
   Step 7: Manual selection – The dean approves / rejects admission requests of
   students that have not been automatically approved in the previous steps: in
   both cases an automatic e-mail is sent to student. Note: students that are on the
   waiting list due to numerus fixus are placed on top of the screen as a separate
   section for the dean. When rejected, the dean can add rejection information to
   the rejection. Study-plan Status: Approved Admission / Rejected Admission.
   Step 8: CONTINUED REGISTRATION - Student has Study-plan Status
   Approved Admission: See continued registration process in the registration
   module (next chapter)


Flow diagram for admission – PHASE 2
                                                                                      42




PHASE 2 - Follow up Study-plan Status Rejected Admission:
   Step 1: Admission parallel student - Rejected student can apply again for a
   certain programme as parallel student (see step 4).
   Step 2: Manual selection parallel students - Dean of school approves / rejects
   admission requests of parallel students: in both cases an automatic e-mail is sent
   to student. Study-plan Status: Approved Registration / Rejected Registration.
   Step 3: CONTINUED REGISTRATION – Parallel student has Study-plan Status
   Approved admission: See continued registration process in the registration
   module (next chapter)

Question: does a parallel student have to pay again for admission? Assuming yes !

There are a number of statuses for this process. They are recorded with the newly
created studyplan (so called study-plan statuses – admission process, see elsewhere
in this document).


Note: if a student is above the cut-off point but cannot be placed after the whole
admission process (due to numerus fixus or other reasons) the Academic Office
should be able to place this student in a school that was not of his / her first or
second choice.

Note: as a counterpart of the registration there should also be an option within
admission to deselect a bulk of students for admission in one overview. This can be
done in the same way as the manual selection of students by the dean (checking
them in an overview).
                                                                                    43

b. Admission screens for Dean

Implement possibility for dean to manually admit students through this overview
screen. See: trusted homepage for a list of views.

Identified steps in admission are:
Initial admission / Admission approved / Admission Rejected). Also show elective
subjects per student in this overview



c. Limited admission period

   The setting of this period should be a privilege for a specific role– Academic
   Office.
   Activate link to admission online only during admission period

Student and other authorized roles can only print admission slip for a limited period,
period can be set by specific role (See chapter „Reports‟ for details)


Note: to avoid crashes in the registration server the admission process should be
guided and limited. One can think of:
   - On line registration through workstations at campus: control both bad
       internet connection and the load of number of workstations at the same time
   - Software check on the maximum number of concurrent connections
   - Storage of the registration in temporary tables, copy to production database
       not before all information on the registration is received
   - E-mail messaging to students with different periods for registration per
       gradetype / studyyear
   - Etc…
                                                                                   44


3.2.3. New module Continued Registration

a. Implement registration process

Flow diagram for continued registration




   Step 1: Approval confirmation – Approval of confirmation is based on either a
   positive admission in the admission process or based on the end-grade of the
   student‟s previous cardinal time-unit (clear pass, repeat & proceed, and so on.
   See calculation of end-grades of cardinal time-unit elsewhere in this document).
   In all cases student receives e-mail with approval for the start of the continued
   registration. He / she can now login to proceed registration. Study-plan status:
   Start Continued Registration.
       Note: in the case of admittance schools the student gets, at the end of a
       certain number of cardinal time-units that are common to more than one
       study-gradetype, based on the grades of the last of these common cardinal
       time-units, transferred to one of these chosen study-gradetypes, through the
       process of quota allocation (see elsewhere in this document).
   Step 2: Subjects selection - Student selects subjects belonging to a specific
   cardinal time-unit of a study-gradetype (for instance second cardinal time-unit of
   Biology). A selection of only the subjects that apply for this student is shown to
   choose from. After selection student gets Study-plan status: Waiting for Approval
   of Registration.
                                                                                        45

   Step 3: Manual approval - Dean manually approves or rejects registration of
   student. In both cases an automatic e-mail is sent to student. When rejected, the
   dean can add rejection information to the rejection. Study-plan status: Approved
   Registration / Rejected Registration. A comment can be given that describes the
   reason for rejection and suggestions for a different selection of subjects.
   Step 4: Registration confirmation - When student has status Approved
   registration, based on student‟s selection, type of student, study-programme,
   number of subjects, and so on, the registration fee is calculated and student gets
   invoice for this.
   Step 5: Registration payment - Student goes to bank and pays registration
   fee. (minimum payment of > 50 % of tuition fees + full payment of other fees)
   Step 6: Payment confirmation - bank pushes information on payment by
   student to OPUS. Student gets study-plan status: Actively Registered.
   Alternatively, payment info can be entered manually by the bursar.
   Step 7: Registration privileges - After payment by student is fulfilled (check
   automatically by the system!), student can login and print confirmation /
   registration slip, with which he / she can fetch a valid student card.

There are a number of statuses for this process. They are recorded with the updated
studyplan (so called study-plan statuses – continued registration process, see
elsewhere in this document).




b. Registration screens for dean

   See chapter „Views on privileges‟ for details.



c. Registration screens for student

   Limitations for registration possibilities for subjects. Choices in subjects for a
   student should be limited to the subjects he/she can possibly take (based on
   chosen programme and prerequisites for subjects)
   Student is obliged to select all compulsory subjects in a cardinal time-unit

See chapter „Trusted Homepages‟ for details



d. Limited registration period

   Start- and end-date. Registration period can differ between Schools. (privilege
   for specific role – Academic Office)
   Activate link to registration online only during registration period (Monique)
   Student can print own registration slip and examination slip (Monique)

Student and other authorized roles can only print registration slip for a limited
period, period can be set by specific role (See chapter „Reports‟ for details).

Note: to avoid crashes in the registration server the admission process should be
guided and limited. See admission module for details.
46
                                                                                       47


 3.2.4. Extensions to Zambia module


a. Implement country-specific user roles

   Identified roles for Zambia are:

Existing Roles – suggested Mapping:
Admin = <system administrator> = Functional Admin / Registrar
Admin-C = academic affairs office
Admin-B = (Asst.) Dean / Asst. Registrar
Admin-D = Head of Department
Teacher = Lecturer
Student = Student (may edit own data partially, but not from others)

Identified new roles:
Financial officer = Bursar / Assistant Bursar
Viewing admin = Vice-Chancellor / Deputy Vice-Chancellor
Librarian
Internal Audit
Dean of Students

Newly identiefied, but not implemented roles:
Medical Office
University Computer Centre
PR / Communication
Alumni-student



b. Extend subject-result calculations

For each subject within a cardinal time-unit there is one subject-result, based on
grades for the underlying 4 possible types of „tests‟ that make up the result of one
subject:

1. Continuous assessment
These are one or more tests that each count for a certain weight for the end-result of
the subject. Attributes are:
     max. mark
     mark student
     weight of each test

2. Sessional examinations
Final examination for a subject. This can be a single examination, but can be also
combined with continuous assessment. If combined with continuous assessment, the
sessional result counts for 50 % (Diploma, Masters) or 60 % (Degree) and the
continuous assessments tests together count for the rest.
Note: if a student fails the continuous assessment for a subject, he may not take the
sessional examination.
                                                                                     48

3. Project results
Project results deal with a subject that has the shape of a project. This project
counts for 100 %.

4. Attachment results
Attachment results deal with an internship the student has taken. There is no
numeric mark, only a pass / fail option.
GRADES
Letter Grade                 Description
S                            Satisfactory
F                            Fail

FAIL GRADES
Letter Grade                  Description
NE                            Not examined
INC                           Incomplete

Based on the percentage that this calculation delivers, studygradetype and student-
type of the student, the grade is made up (see paragraph „Subject / Graduation /
Degree calculation‟ for the correct matrix.

In order to make these calculations possible there is change necessary to the OPUS
examination calculations: the minimum/maximum mark should be optionally set not
only on a study level, but also on all levels underneath: gradetype, studygradetype,
subjectblock, subject.

Note: see also: document from Ben J. Mazyopa (CBU) - „Result Algorithms‟.



c. Subject / Graduation / Degree grade-point-
percentage bindings

Calculation of the hierarchical grades (one subject, one cardinal time-unit
graduation, complete degree graduation) is different depending on study-gradetype
(bachelor / master) and student type.

These bindings should be made flexible. Each gradetype should be able to have it‟s
own grade point / percentage-range depending on the university. -> university
configuration.

Note: in OPUS College we will do the calculations based on only percentages. Based
on these the corresponding grade points, endgrades and endgradecomments will be
shown.
The users will fill in the percentages and in the table endGrade the corresponding
grade point, endgrade and comment is stored.
The table endGrade will be filled with all these values for all gradeTypes (Bachelor,
Master, etc.). There is an extra attribute „endGradeTypeCode‟ needed in this table,
which will be empty for Mozambique.

Examples for the different gradetypes (from UNZA):

BACHELOR
                                                                                   49

Letter Grade                 Grade Point                   Percentage
A+                           2.5                           86 – 100
A                            2                             75 – 85.5
B+                           1.5                           66 – 74.5
B                            1                             56 – 65.5
C+                           0.5                           46 – 55.5
C                            0                             40 – 45.5
D+                           0                             35 – 39.5
D                            0                             0 - 34.5


MASTER
Letter Grade                 Grade Point                   Percentage
A+                           6                             86 – 100
A                            5                             75 – 85
B+                           4                             70 – 74
B                            3                             65 – 69
C+                           2                             55 – 64
C                            1                             50 – 54
F                            0                             0 - 49


DIPLOMA other than MATHS AND SCIENCE / DEGREE PROGRAMME (Distant
Education)
Letter Grade           Grade Point           Percentage
A+                     5                     86 – 100
A                      4                     76 – 85
B+                     3                     68 - 75
B                      2                     62 - 67
C+                     1                     56 - 61
C                      0                     50 - 55
D+                     0                     40 - 49
D                      0                     0 - 39


DIPLOMA MATHS AND SCIENCE (Distant Education)
Letter Grade         Grade Point              Percentage
A+                   5                        90 – 100
A                    4                        85 - 89
B+                   3                        80 - 84
B                    2                        70 - 79
C+                   1                        60 - 69
C                    0                        50 - 59
D+                   0                        40 - 49
D                    0                        0 - 39

Also there is a distinction between full course and half course
Note: can this be calculated using the credits per subject, no need to define a
separate „half course‟.

Note: for UNZA the percentages per school can differ ! Check if the above covers all
varieties.
                                                                                   50



d. Graduation cardinal time-unit calculation

The exam-calculations should be extended with an end-grade (= graduation) for all
subject-results within one cardinal time-unit with following parameters:
    study-gradetype
    student-type
    cardinal time-unit

To be able to do this there are generic rules concerning passing / not passing a
cardinal time-unit. The number of subjects within a cardinal time can vary depending
on the measured cardinal time-unit and the study-gradetype. Therefore has to be an
attribute „maxnumberoffailedsubjects per cardinaltimeunit‟ on the level of
studygradetype. These statuses are called „progressStatus‟, a new domain table:

      Progression / Clear pass: If all subjects within the cardinal time-unit are
       succeeded. Student is automatically forwarded to the next cardinal time-unit
       of the current study-gradetype.
      Compensatory pass (P) / Proceed and repeat: If less than the maxnumber of
       failed subjects within the cardinal time-unit for full-time are not succeeded
       (depending on student-type) and the lowest grade of the other subjects
       within the cardinal time-unit is not lower than D+ and the student meets the
       following:
           o has not failed more than less than the maxnumber of failed in a
               cardinal time-unit
           o has taken more than half of the number of subjects in this cardinal
               time-unit
           o has obtained an average grade of C+ or higher for the passed subjects
               in this cardinal time-unit
       Student is automatically forwarded to the next cardinal time-unit of the
       current study-gradetype, including the less than max. failed subjects. Note: a
       possible overload of the maxnumber of repeated subjects has to be manually
       approved by dean of the school.
      To Part-time: If only one more than the maxnumber of failed subjects within
       the cardinal time-unit are not succeeded and the lowest grade is not lower
       than D+ or if a full-time student fails one or more repeat subjects. Student
       takes the failed subjects automatically in the next cardinal time-unit.
      At Part-time: If not all (repeated) subjects within the cardinal time-unit at
       part-time are succeeded and the lowest grade is not lower than D+. Student
       takes the failed subjects again automatically in the next cardinal time-unit in
       part-time.
      To Full-time: if all (repeated) subjects within the cardinal time-unit at part-
       time are succeeded and the student wishes to continue to full-time. Student is
       automatically forwarded to the next cardinal time-unit of the current study-
       gradetype for full-time.
      Repeat: If only one more than the maxnumber of failed subjects within the
       cardinal time-unit are not succeeded and the lowest grade is not lower than
       D+ and the student is in the final cardinal time-unit of his study-gradetype.
       Student is automatically forwarded to the current cardinal time-unit of the
       current study- gradetype for only the failed subject(s).
      Exclude study-gradetype: If only one more than the maxnumber of failed
       subjects within the cardinal time-unit are not succeeded and the lowest grade
                                                                                      51

       is lower than D. Student is blocked only from the study-gradetype of this
       school. Other study-gradetypes of this school and other schools may still be
       an option.
      Exclude school: If more than one of the maxnumber of failed subjects within
       the cardinal time-unit are not succeeded and the lowest grade is lower than
       D. Student is blocked from all study- gradetypes of this school.
      Withdrawn with permission
      Graduate: if all subjects from the study- gradetype are succeeded. An end-
       grade for the study- gradetype will be calculated.

Note: when a student fails in the last cardinal time-unit of a study-gradetype on a
level that allows Repeat or Proceed and repeat, he / she is transferred to the next
(non-existing) time-unit for this study-gradetype as part-time student to redo the
failed subjects.

Based on the graduation comment that this calculation delivers the graduation grade
is made up. (See paragraph „Subject / Graduation / Degree calculation‟ for the
correct matrix)

Note: The number of allowed failed subjects per cardinal time-unit should be
configurable per study-gradetype, since the cardinal time-unit can differ amongst
study-gradetypes, universities and countries.

Note: the decision to give a student a certain graduation comment / grade for a
cardinal time-unit must have the option to be manually overridden by a specific role
(Academic Office / Dean / Asst. Dean).

Note: the prerequisites for access to a certain subject are not part of this logic.

Note: see also: document from the CBU-calendar - „Rules of progression‟.



e. Create degree comment types

These are the comments that are shown automatically based on the total end-grade
for a study-programme (e.g. „bachelor biology‟. This total end-grade is calculated
upon a number of subjects counted from the last one taken backwards (e.g. In
Zambia the grades of the last 16 subjects are used, in Mozambique all subjects
within the programme are used). The number of subjects to calculate should be
flexible.

DEGREE POINTS
Comment                       Value (example)
Distinction                   28 points and above
Merit                         20 – 27.5 points
Credit                        12 - 19.5 points
Pass                          0 – 11.5 points

The value of these degree points should be flexible, they differ amongst schools /
faculties, study-programmes, universities and countries.
                                                                                     52

f. Degree calculation

The degree calculation is different for countries and universities. E.g. for the
participating universities in Zambia the following applies:
 UNZA: last 16 subjects
 CBU: only senior subjects (3rd and 4th year (and 5th year))



g. Implement Admission Criteria Bachelor and cut-off
point algorithm for the Admission Module

The Admission module must be extended for Zambia with the underneath criteria.

A student enters subjects and grades for 5 subjects from secondary school on
admission. Which grades he has to enter depends on the study-gradetype of first
(and / or second) choice. These grades are converted to points that count for the
total secondary-school point for this student. As an example 2 of the schools from
CBU are written out here.

   School of Business
      Compulsory O-level pass in:
          Mathematics
          English Language
      O-level pass in 1 or 2 subjects from:
          Additional Mathematics
          Economics
          Principles of Accounts
          Commerce
          Geography OR History
          Physics OR Chemistry
          Metal Work OR Wood Work (for Production Mgt)
          Geometrical & Mechanical Drawing (for Production Mgt)
          Science
      O-level pass in 1 or 2 subjects from:
          Agriculture Science
          Biology
          Engineering Science
          Human and Social Biology
          Food and Nutrition
          Science
          Literature in English
          A religious subject
          Computer Science

   School of Built Environment
      Undergraduate Degree Programmes except Bachelor of Science in Civil
      Engineering
          Compulsory O-level pass in:
           Mathematics
           English Language
          O-level pass in 1 subject from:
           Science
           Physical Science
                                                                                        53

           Physics
           Chemistry
          O-level pass in 2 subjects from:
           Additional Mathematics
           Biology
           Economics / Principles of Accounts / Commerce
           History
           Literature in English
           Art
           Geometrical and Mechanical Drawing
           Geometrical and Building Drawing
           Language other than English
           Computer Science
           Geography
           Religious Knowledge / Bible Knowledge
           Wood Work
       Undergraduate Degree Programme Bachelor of Science in Civil Engineering
          Compulsory O-level pass in:
           Mathematics
           English Language
          O-level pass in 1 or 2 subjects from:
           Science OR Physical Science
           Physics OR Chemistry
          O-level pass in 1 or 2 subjects from:
           Additional Mathematics
           Biology
           Commerce
           History
           Literature in English
           Geometrical and Mechanical Drawing OR Geometrical and Building
             Drawing
           Computer Science
           Geography
           Wood Work
           Human and Social Biology
           Zambian Language
           Principal of Accounts
           Religious Subject
           Agricultural Science

Alternative qualifications:
     Diploma holders from other institutions
     Degree Holders (e.g. B.Sc, BA applicants)

The student should be able to see in a list which 5 of his subjects he should give at
admission (these 5 subjects are depending on the desired study-gradetype), based
on a fixed list of secondary school subjects. He can then add these 5 subjects with
their grades. With these 5 subjects and their grades the total grade-calculation for
admission for this student is made.

The dean of school decides on the initial level of the cut-off point. Students below
this cut-off point are automatically selected for the study-gradetype they applied for
as their first choice. The number of selected students is visible for the dean. The
dean then can alter the cut-off point until the desired number of students is reached.
                                                                                      54

Then the dean can press submit to effectuate the automatic admission of the
selected students.
Optionally (for universities where students have a second choice for a study-
gradetype at admission): The whole process is repeated for the students below the
cut-off point for the study-gradetype of their second choice.
Note: all the above takes place within the same process, so the outcome of the
whole calculation is one list with students from both first and second choice !!

There can be more than one cut-off point algorithm for a university. Recognized cut-
off point selections are:
             Admission study-gradetype of first choice or second choice
             Progress to final semester post-graduate students (not implemented
               within the project)

Note: The cut-off point level should be adjustable by specific authorized roles.

Note: in this cut-off point there has to be a separation in steps between students
chosen from study of first choice and students chosen from study of second choice
(see diagram below). After both steps there is an automatic selection made, but this
selection has to be manually approved by the (assistant) dean.

There can be   more than one cut-off point algorithm for a university. Distinctions are:
              Admission study-programme of first choice
              Admission study-programme of second choice
              Progress to final semester post-graduate students

Note: the cut-off point is bottom-up: the lower the point, the better the grades and
level of the student.

Note: At the Business School at CBU tuition waivers get an extra cut-off point
advantage of 3 points.

Question – is this extra cut-off point advantage general for whole Zambia?

Approved ‘O’ and ’A’ level subjects with their codes
Code                       Description
001                        English Language
002                        Literature in English
101                        Mathematics
102                        Additional Mathematics
201                        Chemistry
202                        Physics
203                        Physical Science
204                        Engineering science
205                        Agricultural science
207                        Biology
211                        Science
301                        General Science
304                        Commerce
307                        Food and nutrition
308                        History
311                        Geography
312                        Metal work
314                        Geometrical and mechanical drawing
                                                                                  55

315                         Geometrical and building drawing
320                         Bible Knowledge / Religious Education
321                         Principles of Accounts
410                         Language other than English
415                         Other subjects
418                         Computer science
419                         Combined science
420                         Human and social biology
421                         Wood Work
422                         Art
423                         Zambian language
424                         Economics
425                         Botany


Note: see also: document from CBU - „Admission Criteria for 2010‟.



h. Implement Admission Criteria for Master for the
Admission Module

For Postgraduates (Masters) there is no cut-off point based on grades in Zambia. But
there are admission criteria involved.

      Master of Arts – Human Resource Mgt
          o First degree with credit and above in one of the following:
                   Human Resource Mgt
                   Education
                   Sociology
                   Anthropology
                   Law
                   Public Administration
                   Personnel Mgt
                   Political science
                   Economics
          o First degree with credit and above in other bachelor (only if 3 years of
              practical experience)
          o Practicing HRMs with postgraduate Diploma from recognized institution
      Master of Business Administration General
          o 2 years of practical experience and First degree with credit and above
              in one of the following:
                   Business Administration
                   Commerce
                   Accountancy
                   Economics
          o First degree with credit and above in other bachelor (only if 3 years of
              practical experience)
      Master of Business Administration Financial
          o 2 years of practical experience and First degree with credit and above
              in one of the following:
                   Business Administration
                   Commerce
                   Accountancy
                                                                                     56

                   Economics
          o   First degree with credit and above in other bachelor (only if 3 years of
              practical experience)
          o Holders of professional accounting qualifications (ACCA, CIMA)
      Master of Science in Project Mgt
          o 2 years of practical experience and First degree in any bachelor
          o 3 years of practical experience and Post-graduate diploma in various
              disciplines
          o Holders of professional qualifications (CIOB, RICS, RIBA)

The Admission module must be extended for Zambia with these criteria.




i. Scholarships: Criteria and subsidies not relevant

Criteria and subsidies are not relevant for Zambia. Hide these through the country
module.
                                                                                     57


3.2.9. Apply new roles & privileges

a. Bursar / Financial Officer

Views on:
   Financial Interface:
       Export-screen for export of student-data to financial / accounting system (see
       also: interface to financial / accounting system)
   Fees:
       Student / fees reports (see chapter „Reports‟ for all fee reports for financial
       officers)
       Add / edit / delete student‟s fees related data manually (payments)
       Print payment receipts
   Study plans:
       View student‟s study-plan
   Examinations & Results:
       View examination subscriptions of student
       View student‟s results so far (also in XLS) (see: Chapter 9 – Reports)
       View Senate Examinations Report per school (see: Chapter 9 – Reports)
   Scholarships:
       Add / edit / delete student‟s sponsor related data manually
       Sponsor reports (see chapter „Reports‟ for all sponsorship reports for financial
       officers)



b. Librarian

Views on:
   Personal data student:
       Summary of student information, including photograph
       Print student cards
   Fees:
       Add / edit / delete penalties for students concerning library / books

The UNZA library wishes to have a view on the SIS for the basic student information
and would like to have the ability to set the penalty themselves on the student. Once
the student has paid, the library can remove the penalty themselves then.
If this is not possible then the Request For Change (RFC) principle should apply: the
library writes an RFC directly into the system for this student. The Academic Office
and / or School effectuates this request through the penalty and after the student
has paid a new RFC is made by the library.
Note: The librarian has expressed his wish for a separate fee for use of the library.
This is however now not the case, so this should be arranged within the UNZA
organization, not through the OPUS system.

Input for the student information of the CBU library system is the student card with
the barcode. This card is generated by the Dean Of Students office. Furthermore the
library receives copies of the student photographs from the office of the Dean of
Students.
                                                                                     58

Problem is that there is no connection to Stureco, so that changes in student status
etc. are not known by the library administration. Lists of these changes are now
supplied in writing by the Academic office to the library. The Library wishes to see
mainly the status of the student and some basic information. Furthermore they
would like a list of recent changes in student information (daily, this could be
configured in the audit trail).

Ideally the library wants an interface between Opus and Liberty. Agreed upon is that
this is not possible yet, but we can create a view for the library on the student
information and the possibility to create lists with the information on the students
that is now manually filled in by the student (registration form) and a request for
change option for the penalties workflow.
For the penalties the CBU Library writes a request to the Academic Office. The
Academic Office withholds the results of the student. Also the access to the library is
then temporarily restricted for that student. The student pays the penalty directly at
the library‟s administration office and gets a receipt. With this receipt he goes to
Academic Office which releases the results again.
The concept of Request For Change for Opus by the Library sounds like a perfect
solution for this paper workflow on penalties to the librarian.



c. Internal Audit

Views on:
   Fees:
       Student‟s payment information
       Payment receipts per school and study-gradetype

The Internal Audit of UNZA would like to have summaries on a variety of data:
    - student per semester, year, programme
    - history trail of changes in sensitive information:
            o student information
            o student results
            o fees
            o scholarships
Also the IA needs to have archive information on this same sensitive data (see: audit
trail).
Furthermore the IA would like to have views on the fees module:
- the banking / accounting information
- the billing:
    - reports per student, per study programme, per semester, etc.
    - reports on the installments a student has done for the tuition fees
    - reports on sponsor information

A wish of IA is to have access to SAGE (accounting system). At the moment there is
no relation between the online registration system and SAGE. Everything is
transferred through print outs. The Online Registration has an interface in which
information from the bank is imported, but that information is delivered only on print
to the SAGE system (owned by the bursary).
Ms. Katoyo claims that there is a module in SAGE to connect / interface with a
student system, but this module is not effectuated yet. SAGE was build by
consultants from Zimbabwe and they would have to be involved if an interface would
be made.
                                                                                        59

Note: this concerns new information. We take notice of this, but cannot assure that
this can be done in this project.

See for the requested reports from internal audit at CBU the reports for bursary /
financial officers. They include the wishes from UNZA.



d. Dean of students

Views on:
   Fees:
       Student‟s housing payment information
       Add / edit / delete penalties for students concerning housing /
       accommodation
   Housing / Accommodation information

In OPUS the DOS of UNZA would like to have views on some basic student
information (studentid, name, year of study, city of origin, fulltime / parttime /
parallel / .. student, if it‟s a foreign student, if the student is expelled or suspended,
because then no accommodation is granted) and a view on all students that have
been granted accommodation.
Furthermore he wants to see part of the fees information for a student (did the
student do his payments on fees and penalties).
The DOS also would like to have the ability to set the penalty themselves on the
student. Once the student has paid, the DOS then can remove the penalty
themselves.
If this is not possible then the Request For Change (RFC) principle should apply: the
DOS writes a RFC directly into the system for this student. The Academic Office
effectuates this request through the penalty and after the student has paid (at the
DOS Office) a new RFC is made by the DOS.
In the new system the DOS would strongly want to have the same information on
Accommodation as he used to have. See Accommodation chapter for specifications.

The office of the Dean of Students of CBU stores extra information on students,
primarily on a social level (see sheet D.O.S.) for assistance at the counseling of
individual students. These extra fields should be stored with the student with the
view of the Dean Of Students. Note: this info is not required from the student
directly at admission, only after the registration is approved.

The DOS Office stores all secondary schools that a student attended (as background
information).
Sponsorships of students are renewed each academic year. Information on
scholarships is stored manually by the dean of students office.

Important information for the Dean of Students office would be:
   - information on changes in the study programme of a student
   - status changes of a student

The Dean of Students maintains the suspensions and expellations of a student. See
the list of offences in the DOS manual (page 27). A suspension is temporarily, an
expellation is on the level of a school or the whole university and is permanent.
However: after 3 years a student can re-apply to the same university / school.
                                                                                60

Furthermore the DOS office registers all Accommodation penalties. The workflow of
these penalties is as follows:
   - The DOS writes a letter to the Academic Office requesting the student‟s
       results to be withheld
   - The student pays directly at the bursary and receives a receipt
   - With the receipt the student goes to the DOS, who writes a clearance.
   - With this clearance the student goes to the academic office which releases the
       results of the student.

The DOS wishes a view on / list from all the changes in student information.
Furthermore a view on the penalties that are imposed on a student by other
authorities (like librarian, etc.).
And a list with all students per study programme and year of study, graduated
students, excluded and new moved-to-part-time students, so that the DOS can make
a schema for the accommodation. (see also: reports)

See for accommodation specifications for CBU the specs for Accommodation.
                                                                                      61


3.2.10. Extensions to Report module
Note: These reports will be built by CICT‟s of UNZA and CBU under coaching of
Markus.



a. Reparations of current reports
Due to all changes some of the current reports do not function anymore. Markus will
repair them in this phase.



b. Student card
The authorization to print the student cards is held by specific roles: Librarian /
Academic Affairs Office.



c. Diplomas / Certificates of graduation
The authorization to print the diplomas / certificates of graduation is held by specific
roles: Dean / Asst. Dean / Asst. Registrar / Academic Affairs Office.



d. Fees reports for Bursar / Academic affairs office /
Internal Audit

Several reports required by the bursar:
    billing students: create / adjust invoices per individual student and in bulk
    summary statement: a filtered group of students within a certain time period
    student statement of account/ individual student balance: collection of all
      payments and outstanding fees for one student
    past dues report: all student balances that have outstanding fees
    receipts list report: to enable generation of the cash book instead of relying
      on the bank statements
    debtor‟s age analysis report: to help management make decisions on writing
      off bad debts
    unregistered students reports: overview of students who have accessed the
      system, but not completed the registration process
    total fees received per cardinal time-unit per school
    reports on all postings : backlog

Note: all reports should be viewable and editable for the financial officers. The
underlined reports should also be viewable for the academic affairs office.

Required filters:
    student-number
    person.housingoncampus (Y / N)
    student category
    study programme
    sponsors (divided by sponsor-type or self-sponsored)
    An important feature is to be able to make reports for a certain time period
       (e.g. from year-month-date A to year-month-date B).
                                                                                       62


Note: all reports have to be made available also in XLS.

Important issues to know / view from Opus for Internal Audit of CBU are:
   - right numbers and lists of students from the system
   - correct data on each student
   - complete list of registrations
   - fees information on each student: the current system does not provide
      accurate information on the student fees / payments. Wish for track on
      payments of all tuition fees installments and other fee payments
   - information on the social environment of a student (regarding scholarships)
   - information on the results of students and on the grades of secondary school
      (admission information)
   - authorization and audit trail on changes and amendments of fees etc.
   - view on the roles of users in Opus and the changes in roles
   - information on scholarships



d. Admission slips

Print of the following stages in the admission process:
    account creation
    waiting for approval (after filling in background details)
    approved / rejected by dean (before choosing exact study-gradetype for next
    cardinal time-unit)

The possibility to print these admission slips is within a limited period during the
admission process.

Note: the authorization for this print-option should be with the individual student on
his own trusted homepage and with the academic office role and assistant dean role
within the system.



h. Result slips

See: printed results slip CBU for example.

Print of passed examinations of students.

Note: the authorization for this print-option should be with the individual student on
his own trusted homepage and with the dean / asst. dean role within the system.



i. Sponsor reports for Bursar / Academic affairs office
/ Internal Audit

Several reports required by the financial officers and the academic affairs office:
    Sponsor per school
    Sponsor per gender
                                                                                 63

j. Student reports for Academic affairs office /
Internal Audit

Several reports required by the academic affairs office:
    Registered students by school, gender and year of study
    Origin of students indicating secondary school, town, province and nationality
    Graduating students per school, study-gradetype and gender
    Final comment per school, study-gradetype and gender
    Sponsor per gender
    Age distribution of students per school, study-gradetype and gender
    Senate Examinations Report per school
    Staff / student ratio per academic year
    Attrition per school and grand totals (attrition = number of dropouts between
      beginning and end of cardinal time-unit)
    All students and studyplans by studyplan-status
    All students by student-status



j. Student reports for Dean of Students

The DOS wishes a view on / list from all the changes in student information.
Furthermore a view on the penalties that are imposed on a student by other
authorities (like librarian, etc.).
And a list with all students per study programme and year of study, graduated
students, excluded and new moved-to-part-time students, so that the DOS can make
a schema for the accommodation.
64
                                                                                      65




3.2.12. Extensions to Scholarship module
Note: These extensions will be built by CICT‟s of UNZA and CBU under coaching of
Markus.

a. Add sponsor types

Identified types are:
 Ministry of health (external)
 bursary committee (government)
 internal – tuition waiver (staff)
 internal – staff development fellowship (SDF, retired staff)
 internal – book transfer

Note: the „staff development fellowship‟ is a special sponsorship: „tuition fees‟ and
„other fees‟ are paid from this sponsorship. But the money itself for this is extracted
from the retired staff‟s own retirement benefit.
Note: the „book transfer‟ is a special sponsorship: it is for retirees / spouses /
children and other dependants of staff-members of the university.



b. Add sponsor categories

Identified categories are:
 100 %
 75 %
 50 %
 25 %
 otherwise: self-sponsored



c. Business rules late payment sponsors

If a sponsor pays late, student will / will not be withheld from registration. Set
default value: student will not be withheld from registration unless specifically
withheld by registration process or manually.
The table sch_scholarshipapplicatin must be extended with 3 attributes:
 Payment due date
 Payment received date (empty until payment is received)
 Late_payment (Y/N)




d. Flexible number of sponsors per student
                                                                                66

A student can (depending on university) have more than one sponsorship. And it can
be both internal or external. This should be configured in a module-specific
configuration file (init parameter in web.XML).
                                                                                    67




3.2.13. New module Accommodation / Housing
Specifications for UNZA Accommodation:

    - accommodated y/n
    - exact location (block, floor, apartment, bed)
    - appartment type (new, old) -> fees depend on it
Information on appartment type:
    - new / old / ??? (The newer apartments have a higher fee than the older
      apartments
    - fee per cardinal time unit
Appartments typically sleep 2 students.

Note: Opus should indicate a necessary removal of students from assigned
appartments after graduating (students that go on to next degree have to apply
again for housing).

CBU: Accommodation is now a paper system. The student applies through a letter
for Accommodation. Each year there are 1056 bed spaces and 1000 filled bed spaces
by continued registered students. The number of applications is between 3000 –
4000, so the DOS has to make choices:
    - new admissions have priority
    - continued registration students who are referred to parttime or have failed
       their semester / studyyear have NO longer a right for accommodation and are
       removed
    - continued registration students who are fulltime and who are in the final year
       of study have a right on accommodation
    - when a fulltime student is once accommodated he continues to be so as long
       as he stays in fulltime. However: each year all students have to reactivate
       their accommodation.
    - The fee for a room / bed stays fixed for a student if he stays in the same
       room / bed. On change the fee might be altered.
    - The fees for a room differ between old and new hostels. At concrete
       placement in a location (and acceptance of this location) the correct fee is set
       for the admitted student.
    - There is a deadline for the acceptance of the location of accommodation or
       the reactivation of the already accommodated student. After this deadline the
       student is removed and the bed is reallocated to someone else. For all
       students that have accepted or reactivated a list is generated by the DOS and
       sent to the bursary: the correct fees are posed on the students by invoice.
    - The second deadline is in the payment of the accommodation fee. If the
       student pays too late, the student is removed and the bed is reallocated to
       someone else.


Note: Necessary fees for accommodation should be pushed into the fees module
directly. Also the payments for this by the student should be visible in the fees
module.
                                                                                  68

Note: this module has more priority than alumni. The UNZA Dean Of Students has as
a part of the SRS / Student system details on the accommodation of students and
will lose this information in OPUS.

Note: Ben Mazyopa (CBU) will be in charge of the design and development of this
module.

Note: the inventory of the accommodation can also be stored, but this is not done in
this version yet. If all‟s as expected, then this can be an extension made by the
developers themselves.

Documents concerning the design of this module will be stored by Ben in the
Admission Project in the Opus Repository.
                                                                                    69


3.2.14. New module Timetable / Roster

a. Extensions kernel datamodel for timetable module

Extend existing tables with extra attributes concerning timetabling.

Subjectstudygradetype:
    subjectdifficultycode (varchar, new corresponding lookuptable:
       subjectdifficulty, current values: difficult / easy)
    hoursperweek (int)

TODO – Giphouse students will describe all extra entity-attributes before end of june.



b. Build of modules timetable / roster by new
Giphouse Students

Possibly within the project the modules timetable and roster will be built by new
Giphouse Students, based on the design the OUM Giphouse Students Martijn
Sprengers, Adam Cornelissen and Benjamin Mäder made.
                                                                                     70


MILESTONE 3.3.


3.3.1. Additions to the OPUS College kernel

a. Security

Within the project the Radboud University / Giphouse Students Martijn Sprengers,
Benjamin Mäder and Adam Cornelissen will produce a document with
recommendations concerning security. A number of activities can be distillated from
this recommendations-document.

   1. Prevent cross-site scripting

   The Giphouse students have made a proposition for a filter for all input fields,
   based on a blacklist. This filter can be plugged into the OPUS system and
   addressed on all insert / update actions. (see security-document Giphouse)
   Extend validation with all fields to prevent invalid input. Currently only the
   obligatory fields are checked on validation. All fields should be checked, including
   using the blacklist filter.

   1. Configure debug-logging log4j

Now when log is set to debug in log4j (eSURA.log), the user / pw can be found in
plain text in log. The password is anyway transmitted in plain text, which is insecure.
This should be altered.
See also: http://www.informit.com/articles/article.aspx?p=24253&seqNum=5


   2. Protect login with HTTPS

Goal is to set up an HTTPS connection (secure passwords etc.): login on HTTPS, and
all subsequent traffic (other than password related screens like changing passwords)
on HTTP.
To distinguish between them the login has to be put in a separate directory that is
only reachable through https.
Note: HTTPS (which is basically HTTP using SSL Certificates) is not entirely secure: A
man-in-the-middle can fake a certificate and still get the data (see e.g.
http://samsclass.info/123/proj2/p25c_MITM-Cain_ch12.doc) but this is quite a bit
harder. In this case, as always, efficiency and security have to be balanced.


   3. Code-check with OpenFortify

Fortify is a company that is specialized in checking code for security-issues. For open
source projects they have the option of OpenFortify, which is free.
A consultation of Fortify may be part of the project.
                                                                                    71

b. Custom stylesheets / logo settings

Stylesheets should be customized per participating university. Stylesheet and logo‟s
should be addressed through http on the webserver. There can be a number of
stylesheets and logo‟s to choose from.
This can be done by supplying a change-style functionality under the admin
functions.



c. Backlog functionality / Audit trail

   1. Setup general principle of backlog

The general principle of backlog should be implemented in OPUS. Besides that there
are some specific backlogs required.

   1. Archive table for examinations results that were overridden

Save history of this for at least 5 cardinal time-units in the past.

3. Keep track of student-status history

The history of the statuses of a student should be kept.


4. Keep track of studyplan-status history

The history of the statuses of a studyplan should be kept.


5. Backlog functionality for free transactions

Save history of this for at least 1 cardinal time-unit in the past.

6. Backlog functionality for scholarships

Save history of this for at least 1 cardinal time-unit in the past.

7. Report for the backlog– setup of principle

Some standard iReports should be written for the backlog.



c. Refactoring

1. Branch as a separate entity in the institution model

The branch should not be hierarchically placed between institution and organizational
unit. But on a different level with connections to organizational units, which can then
belong to several branches (solving of the UP problem).
                                                                                      72




3.3.2. Extensions for Zambia Module
a. Implement Quota Allocation for the Continued
Registration module

Implement „transfer of students‟ functionality (to study-gradetypes of 1st, 2nd or 3rd
choice) at the end of a certain period (one / two years). This period should be
flexible.
This principle is valid for all so called Admittance Schools. In these schools a
combined first and / or second year is organized after which the students split up to
specific study-gradetypes.

Note: this functionality can be implemented as a type of studygradetype (e.g.
programme of study). The end of this studygradetype is however not a grade or
diploma, but is not rewarded.

Note: This will be an extension to the „transfer students‟ option that is already in the
system. This quota allocation is a specific part of the new module „Registration‟.

Flow diagram Quota Allocation




   Steps in quota allocation process, in hierarchical order of clear pass ranking:
      Step 1: End-grade cardinal time-unit – Graduation grade calculation for
      the last cardinal time-unit of the admittance school is done automatically.
                                                                                    73

      Step 2-a: Manual approval / rejection – All students without clear pass
      have to be manually approved / rejected and transferred by the dean.
      Step 2-b: 1st choice programme - All students with clear pass are proposed
      to be transferred to the next cardinal time-unit of their first-choice study-
      gradetype until there is no room anymore (numerus fixus). The actual
      transfer has to be done manually.
      Step 3: 2nd choice programme - All remaining students with clear pass are
      proposed to be transferred to the next cardinal time-unit of their second-
      choice study- gradetype until there is no room anymore (numerus fixus). The
      actual transfer has to be done manually.
      Step 4: 3rd choice programme - All remaining students with clear pass are
      proposed to be transferred to the next cardinal time-unit of their third-choice
      study- gradetype until there is no room anymore (numerus fixus). The actual
      transfer has to be done manually.
      Step 5: Manually chosen programme - All remaining students with clear
      pass are manually put into a study-gradetype which was not in the student‟s
      first, second or third choice by the dean.

Question – what happens with students that have qualification repeat & proceed at
the end of admittance school / quota allocation?
                                                                                      74


3.3.4. Extensions to UNZA module

a. Backlog functionality / Audit trail

1. Storage of database versions for archive reasons Internal Audit

A monthly backup of the db and storage of these backups must be supplied for
archive reasons (trail for Internal Audit)

2. Reports on the archived database versions

Some standard iReports should be written for the archived database versions, with
which the Internal Audit can directly view these archive databases.

b. Fees - New interface import Bank Information

Implement possibility for a Bank to sent payment files directly to the system. This
file has to be read into the Opus database.

Note: for UNZA this is : Zanako.

Important: breakdown info from the file into 3 types of students:
      self-sponsored students
      parallel students
      government sponsored students

Note: if a sponsor pays, this is done in lumpsum.

Important: breakdown info from the file into 2 gradetypes:
      undergraduate / bachelor
      postgraduate / master & phd

Question – how is this information currently pushed into your student system? Is this
manually put in or automatically read into the system through a file ?
                                                                                      75


3.3.5. Extensions to CBU module

a. Backlog functionality / Audit trail

1. Storage of database versions for archive reasons Internal Audit

A monthly backup of the db and storage of these backups must be supplied for
archive reasons (trail for Internal Audit)



b. Fees - New interface import Bank Information

Implement possibility for a Bank to sent payment files directly to the system. This
file has to be read into the Opus database.

Note: for CBU this is: Zanako.

Important: breakdown info from the file into 3 types of students:
      self-sponsored students
      parallel students
      government sponsored students

Note: if a sponsor pays, this is done in lumpsum.

Important: breakdown info from the file into 2 gradetypes:
      undergraduate / bachelor
      postgraduate / master & phd

Question – how is this information currently pushed into your student system? Is this
manually put in or automatically read into the system through a file ?
                                                                                      76


3.3.6. Extensions to Fee module

a. Bind fee payments to study-gradetype details (ctu)

A fee is now bound to subject-blocks and subjects within a certain study-gradetype.
However, in the new structure it cannot be bound to the subject or subject-block
itself, because it might have a different fee within different study-gradetypes.
Besides this a subject or subject-block differs in fee for a part-time and fulltime or
parallel student.

Changes table fee_fee:
    Delete attributes studyyearid, subjectblockid, subjectid
    Add attributes subjectblockstudygradetypeid, subjectstudygradetypeid
    Add studenttype-code

Changes table fee_payment:
    Delete attribute studyyearid, subjectblockid, subjectid
    Add attributes subjectblockstudygradetypeid, subjectstudygradetypeid
    Add studenttype-code


Most fees are bound to the used cardinal time unit in the studygradetype (semester,
studyyear, etc.) Some fees are however bound to the academic year (e.g.
accommodation, etc.). The difference must be stored.


Note: these changes will mean conversion for the participating universities in
Mozambique. That conversion is part of this task.



b. New attribute tuition waiver for student

For spouses, children and other dependants of staff-members the attribute tuition
waiver can be set in relation to discounted fees. Default this new attribute will be set
to „N‟.



c. Extend student overview

The view which shows the balance for one student concerning fees should be
extended. This view should have the following:
    Balance B/f
    Fees Due
    Fees Paid
    Outstanding Balance



d. New view fees-balance per study-gradetype
                                                                                       77

A new view is required with the balance for a study-gradetype concerning fees. This
view should have the following:
    Balance B/f
    Fees Due
    Fees Paid
    Outstanding Balance



e. Break down fees

Break down in different fee categories and per individual student
Fees are dependent on:
   Subject
   Student type
   Foreign / local + regional (SADC, southern Africa region)
   First year / continuous years
   Undergraduate / postgraduate (bachelor / master)
   Tuition waiver (Y/N): relatives of staff-members discount

Breakdown payments in fees are built up hierarchically from top to bottom according
to the following payment order:
    1. Balance (outstanding payments of student, including penalties)
    2. Other fees (a.o. IT access, accommodation, recreation, medical, caution,…)
    3. Tuition fees

Note: tuition fees are separate from other fees. Tuition fees are the only ones that
can be paid in installments

Note: the level of breakdown should be defined. Probably the financial system should
keep the details, in the SIS we should only keep the top-level breakdown (balance,
other fees, tuition fees).

Note: part-time students (and possibly other student-types, arranged when
identifying a student: housingoncampus = „N‟) do not have accommodation.



f. Bind Fee to study-gradetype in specific academic
year

The fees are redefined each year with the new instance of the study-gradetype.

Question – how long is it required for a history of the fees to be kept?



g. Specify installments per Fee with deadline dates

A flexible number of installments can be specified per fee. For each installment a
deadline can be set.
                                                                                       78

h. Implement option to pay all Fees at once for study-
gradetype

Complete payment and recalculation on increasements of already paid fees within a
specific study-gradetype.

Note: if fees are increased during this period, the student will receive an invoice for
the increasements.



i. Implement option for credit-balance for individual
student

If a student has paid too much (or has had a refund), the surplus payments will be
automatically saved for the next cardinal time-unit.



j. Implement option for refund for individual student

This is only possible on official withdrawal of student within a fixed time period after
registration (note: this has to be a configurable attribute „period of refund‟).
If this is a refund or a save of surplus payments depends on the status of the
studyplan of the student (withdrawn -> refund, other statuses -> surplus next
cardinal time-unit).



k. Implement e-mail reminders for outstanding fees


l. Implement automatic charge of outstanding fees in
next cardinal time-unit

If a student has outstanding fees, these are automatically added to the fees for the
next cardinal time-unit.



m. Affiliation fees for postgraduate students

Declaration of the fees that are related to postgraduate study. Besides postgraduate
study fees, which can be automatically handled byh the fees module, there have to
be additional fees for postgraduates: affiliation fees.



n. Integrate penalties / fines within fees module

Fines for several possible offenses and those responsible:
 Late cardinal time-unit registration (bursar)
 Late examination registration (bursar)
                                                                                   79

   Losing / destroying books (library)
   Losing keys (accommodation, dean of students)
   Breaking windows (accommodation, dean of students)

Note: part-time students do not have accommodation.

Make it possible to flexibly configure what the specific punishment for an outstanding
penalty is. For instance: Results of students are withheld until penalties are paid.
Configure this per university, at application level.

Note: a problem might be the late registration penalty of UNZA. This penalty is
increased each day. Elaboration on how to calculate this should be done: Can we
solve this problem ?
                                                                                      80


Appendices


1. Examples of curriculum and studyplan
definitions at UNZA / CBU
Example curriculum structure:

Student A studies Math major, Chemistry minor, for a bachelor program. The
program goes over 6 semesters (e.g. 6 cardinal time units). In the first year (the
first 2 semesters) there are only mandatory subjects; later there are some elective
subjects both within the majors and minors, as well as more general elective
subjects that are not tied to majors or minors. Could the following be a possible
curriculum definition?

Curriculum definition first semester:
    Study block “Math major (semester 1)”: 3 mandatory subjects
    Study block “Chem. minor (semester 1)”: 1 mandatory subjects

Curriculum definition second semester:
    Study block “Math major (semester 2)”: 2 mandatory subjects
    Study block “Chem. minor (semester 2)”: 2 mandatory subjects

Curriculum definition for the third semester:
    Study block “Math major (semester 3)”: 2 mand., 1 (out of 3) eligible subj.
    Study block “Chem. minor (semester 3)”: 1 mandatory subjects

Curriculum definition for the fourth semester:
    Study block “Math major (semester 4)”: 1 mand., 1 (out of 3) eligible subj.
    Study block “Chem. minor (semester 4)”: 1 mand., 1 (out of 3) eligible subj.

Curriculum definition for the fifth semester:
    Study block “Math major (semester 5)”: 1 mand., 1 (out of 3) eligible subj.
    Study block “Chem. minor (semester 5)”: 1 mandatory subjects
    Eligible subjects semester 5 : 1 (out of 10) eligible subjects

Curriculum definition for the sixth semester:
    Study block “Math major (semester 6)”: 1 mand. subj.
    Study block “Chem. minor (semester 6)”: 1 mand. Subj.
    Eligible subjects semester 6: 2 (out of 10) eligible subjects

In all semesters the number of subjects is 4.

Example cardinal time-unit progress for one semester in a study-plan:

If student A studies the “Major Math / Minor Chemistry (semester 3)” in the 1st
semester of 2010, then the cardinal time-unit will look like this:

Student A - Major Math / Minor Chemistry (semester 3, academic year 2010):
    Study block “Math major (semester 3)”:
       Mandatory subject X
                                                                                       81

         Mandatory subject Y
         1 subject out of the following elective subjects:
               Elective subject A
               Elective subject B
               Elective subject C
      Study block “Chem. minor (semester 3)”:
        Mandatory subject W

Case 1: The student passes this 3rd semester, and he will continue to the next
semester, possibly in the academic year 2010 or 2011. Let‟s assume it is 2011:

Student A - Major Math / Minor Chemistry (semester 4, academic year 2011):
    Study block “Math major (semester 4)”:
          Mandatory subject F
       1 subject out of the following elective subjects:
              Elective subject H
              Elective subject I
              Elective subject J
    Study block “Chem. minor (semester 4)”:
       Mandatory subject M
       1 subject out of the following elective subjects:
              Elective subject R
              Elective subject S
              Elective subject T

Case 2: The student does not pass this 3rd semester for 3 subjects (subject X en
subject B) with no lesser grade than D+, and he will go to Part-time, possibly in the
academic year 2010 or 2011. Let‟s assume it is 2011:

Student A - Major Math / Minor Chemistry (semester 3, academic year 2011):
    Study block “Math major (semester 3)”:
       Mandatory subject X
       Elective subject B
    Study block “Chem. minor (semester 3)”:
       Mandatory subject W

If the student passes for this retry at the end of the semester, he will return to full-
time for semester 4 at the end of this semester.



Case 3: The student does not pass this 3rd semester for 1 subject (e.g. subject X),
and he will continue with a Compensatory Pass, possibly in the academic year 2010
or 2011. Let‟s assume it is 2011:

Student A - Major Math / Minor Chemistry (semester 4, academic year 2011):
    Repeat: Mandatory subject X (“Math major (semester 3)
    Study block “Math major (semester 4)”:
          Mandatory subject F
       1 subject out of the following elective subjects:
              Elective subject H
              Elective subject I
              Elective subject J
    Study block “Chem. minor (semester 4)”:
                                                        82

   Mandatory subject M
   1 subject out of the following elective subjects:
        Elective subject R
        Elective subject S
        Elective subject T
                                                                                   83


2. New modules and functionality not captured
within the project

a. New module public homepage

Create specific view for guests of the public website
       i.  General information admission
      ii.  Possibility to create student-account
     iii.  Study guides of faculties / schools
     iv.   General regulations universities
E.g. For CBU http://www.opus-college.net/docs/CBU/cbu-general-rules/
      v.   General information on schools / faculties
     vi.   Public homepages students, teachers, …




b. New module Alumni
Implementation of the alumni module based on the specifications by Markus &
Monique during the october 2010 visit.

Note 1: this task is assigned to Sylvester to keep track on it for the whole CBU-team.

Note 2: this is a zero-budget-task, but the CBU-developers can just write the hours
so that we can keep track of how much time they have spent on it all together.




c. View / role: PR / Communication

Views on:
   Study curriculum:
       Study guide: Subjects and study-curriculum information for study guide
       creation
   Alumni:
       Overview / edit of alumni-students: a.o. alter student status (e.g. deceased)
       Overview / edit invitations for alumni events



d. View / role: Alumnus

Views on:
   Alumni:
       Edit personal data (telephone & email (See: Chapter 1 – Students – editable
       fields for student)
       Overview of eligible alumni events
                                                                                         84



e. New modules Publications and Research (for
postgraduates)


f. Specific interfaces for CBU

At CBU there are wishes for the following interfaces, that cannot be part of the
current project. These are all connections to existing systems, so it is possible that
there are duplicates with the OPUS system‟s modules:
     Library
     Housing / Accomodation
     Computer Centre
     Clinic



g. Extensions OPUS kernel

     1. Staff-member to student and vice-versa

A student can become a staff-member. A staff-member can become a student. And a
student can be a staff-member at the same time.
The two entities are already related through the person-id. There should be a copy-
function from student to staff-member and vice versa. In this copy-function the
student-number / staffmember-number should also be transferred, so that both are
the same.

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:6
posted:7/12/2011
language:English
pages:84