Understanding Research

This section of the user manual provides an overview of the Research Subsystem.

In this Section:

See Also:

A Specialist User overview provides information about setting up the subsystem to ensure it functions correctly. A Special Topics section provides more detailed explanation of some aspects of the subsystem. Detailed explanations and instructions for the use of individual database forms can be accessed from the subsystem's Table of Contents or using the links provided throughout this overview.

An Introduction to the Research Subsystem

The Research subsystem is used to manage all processes relating to research students within an institution. These students are those who have applied for/enrolled in a research course and unit. The functioning of the subsystem involves interaction with other subsystems (Admissions, Enrolments, Assessments for example) and unique processes within the Research subsystem.

The functionality provided through the Research system can be used in varying ways, to best suit the needs of an institution. In addition to using the subsystem to manage research students, some functions may also be useful in assisting with student administration in other courses.

For example an Architecture course might require a student to complete a project each year (in units called Special Project 1, 2 and 3 - coursework units that use the standard method for EFTSU calculation). The recording of a student's proposed project, the tracking, monitoring and examination of the project could use Candidature and Thesis functionality from this subsystem. Any Student Course Attempt can have only one candidature, but this candidature can have multiple theses, so each year's project could become a new 'thesis'.

Admitting/Enrolling a Research Student

When a student makes an application for admission to a research course, the admissions process allows navigation to the Research Candidature Details form (RESF3211). This form is used to record specific information about this candidature.

Some details are mandatory before an offer of a place can be made, so should be recorded early in the Admissions process. These are: Research Topic, expected submission dates (which can be the system-calculated dates) and a Principal Supervisor (refer to Supervision). Where the candidate's Commencement Date is different from the default Course Start Date, this should also be entered. Note that Commencement Date cannot be backdated any earlier than the Course Start Date Alias instance. The teaching period chosen for the application/enrolment must be one which allows entry of the applicable commencement date. Other non-mandatory candidature and thesis details can be entered at this stage if known, or at any time over the candidature period. An Admission Course Application Instance record for this student now exists (along with the underlying Candidature details).

The student is pre-enrolled in the course when the mandatory Candidature details exist and an offer of a place is made by the institution. Where a 'PRE-ENROL' step is set for the Admission Process Category used, pre-enrolment occurs automatically when the application is processed through Admissions (using form ADMF3000). If the Student Course Attempt is entered directly through the Enrolments subsystem (using ENRF3000) pre-enrolment is done through the running of a batch job (ENRJ3100), scheduled by an Enrolment specialist.

All candidature (and thesis) details, including the commencement date, entered as part of the Admission Course Application, are brought forward to the Student Course Attempt. The SCA has the status of 'UNCONFIRM' (if the student has not confirmed their enrolment) or 'INACTIVE' (where the student has accepted the offer by confirming the Student Course Attempt via enrolments or admissions, but as yet has no enrolled units).

Enrolment or Admissions functionality could now be used to further process the Student Course Attempt. This would normally follow these steps:

The student is now enrolled in the selected research course and all units. From this point on, research functions could be accessed directly (rather than navigating to the research forms via ADMF3000 or ENRF3000).

If a student does not proceed with the application and confirm her/his enrolment, the Clean-Up Unconfirmed Student Course Attempts job (ADMJ3850) removes the link between the unconfirmed student course attempt and the candidature record, then deletes the student course attempt (created through pre-enrolment). This job would be scheduled by a specialist in Admissions.

Candidates who want to begin their research after the 31st August Census Date in one academic year or prior to the start of the standard first teaching period in the next, may be enrolled in the applicable research unit for a summer semester, if the institution has established calendars and teaching periods to allow this. Refer to the Specialist Overview for example configuration of these calendars. EFTSU for a Student Unit Attempt in a summer semester would be calculated using standard methods, where calendars are configured as described in the specialist overview.

 

Re-Enrolment

The process of re-enrolling a candidate in required units (for subsequent teaching calendar instances) and the course (for subsequent academic calendar instances) would be done by (or in consultation with) an enrolment specialist. The batch pre-enrolment process (ENRJ3100) can be used for this re-enrolment of students.

Unit Discontinuation & Withdrawal

Withdrawal of a student from his/her research unit is handled through the standard Unit Discontinuation process (using form ENRF3000). Administrative Unit Statuses applicable to research units can be configured to allow discontinuation without an assessment penalty. The establishing of these statuses, research grading schema and unit discontinuation data aliases is fully explained in the Specialist Overview.

Entry of Assessment Results for a Research Unit

Results entered against research units can use a specific grading schema established for use in this subsystem. Institutional policy and assessment specialists should be consulted for further explanation about assessment procedures. Setting up a grading schema for research units is explained in the Specialist Overview.

Course Transfer of a Research Candidate

The course transfer process (using ENRF4150), as it applies to transfer from one research course to another research course, allows the existing candidature record to be transferred to the new course. The transfer of a candidature record includes transferring a candidate's attendance history; all thesis records (except any deleted thesis records which exist in the current candidature); thesis exam and panel member details; supervisors; scholarship and milestone details. If a candidature does not exist in the current course, a course transfer cannot occur. If a candidature record exists already in the new course, the current candidature cannot be transferred.

If a transfer is done through Admissions, using the system Admission Process Type of 'TRANSFER', any associated candidature details are not transferred and must be reentered.

 

Capturing and Maintaining Candidature Details

The Research Candidature Details form (RESF3211) allows the capture, processing and control of all candidature details. It is the central form in this subsystem and all other functional forms can be accessed from it.

An enrolled research student's candidature record has at a minimum the mandatory candidature details (Research Topic, Principal Supervisor, Min and Max Submission Dates). A default Attendance % value (from CRSF1170) and system-calculated values for the effective full-time days used and total available (EFTD Used/Total) will also exist (refer to Special Topics for an explanation of these calculations).

Research staff can complete and update the candidature details using this form, at any time throughout the candidature. This may involve

The Research Candidature Details form also provides a summary view of the current status of any thesis associated with this candidate. A candidate can have multiple theses and an information lamp on the form notifies the user where multiple theses exist.

Additional data collection, monitoring and reporting can be done using the other forms accessed via the navigation buttons here. These additional forms are used to record/update data relating to theses, scholarships, milestones and supervision details.

Monitoring Days Used, Submission Dates & Attendance

The EFTD Used/Total, submission dates and attendance entries maintained in RESF3211 are important to monitoring a candidate's progress. The displayed number of effective full-time days available and current number used give a candidate and his/her supervisors a clear picture of the amount of time remaining for the research. Callista dynamically provides either the actual EFTD or an override EFTD value that has been entered manually. Note that a candidate with an attendance of less than 100% will 'consume' only a proportion of an EFTD each calendar day. Submission dates provide 'deadlines' (for the earliest and latest dates at which submission can be made) against which research progress can be evaluated, in reviews conducted with the candidate (see Milestones).

Variation in a candidate's attendance pattern is common over a candidature and these changes can be recorded by entering a new value in the Attendance variation overlay. At the same time, the event associated with the variation can be recorded.  Attendance variations can be recorded in advance. The Attendance Variation overlay provides a record of the candidate's attendance pattern, with each entry displaying a start and end date, applicable attendance % and type, and a description of the causal event. The attendance variation records can be altered. For example a candidate's attendance pattern may be updated as part of a review meeting. This may require changes to both the Attendance % field and changes to the history records. Institutional policy determines how frequently attendance updates are to be made for research candidates.

Supervision

Supervisors are those responsible for overseeing the progress of any research student. The Research Supervisors form (RESF3250) is used to record and maintain all information about a candidate's supervisors. Institutions determine policy regarding the qualifications and the number of supervisors required for a candidate. Callista requires that there be, at a minimum, one principal supervisor. This supervisor is recorded at the Admissions stage. Additional supervisors can also be recorded during the admissions process, if known. They can be added at any time during the candidature, when staff changes require this or when the need for additional supervisors makes this necessary. A supervisor whose supervision period cannot cover the whole of the candidate's research period, has their supervision period recorded by entering an End Date.

Note: Regardless of the circumstances (including intermission or re-admission) supervision records must be continuous (ie. the next supervisor record must start on the day after the last record ended).

Supervisors may be staff of the institution or external to the institution. Where a supervisor is from outside the institution, the person's details must be added to the database so he/she can be recorded as a supervisor. This can be done from the form. A candidate's supervision arrangements are the basis for the distribution of income (generated by this student) to the organisational units within institution. Payments to external supervisors cannot be handled by Callista and would be done by an organisational unit, using the institution's financial package. For this reason, supervisory and funding percentages may not be the same.

In the example, the table displays details for the 3 supervisors recorded for a candidate. Payment for the last supervisor K Harrison, who is not a staff member, is to be made by the organisational unit 001. The funding percentage given for the supervisory staff member from that unit (J. Smith) includes an appropriate proportion to cover payment to the external supervisor.

Supervisor Name

Member of Staff?

Organisational Unit

Supervision %

Funding %

J. Smith

Yes

001

60

80

L. Lim

Yes

002

20

20

K. Harrison

No

n/a

20

0

 

Scholarships

The current delivery set provides the facility to record scholarship details using the Record Scholarship Details form (RESF3500). A candidate can receive more than one scholarship and each can be entered. The dates of the scholarship, its monetary value, other benefits or conditions which apply, can be recorded for each scholarship.

The functionality is also available to:

Monitoring Candidature Progress Using Milestones.

Institutions usually have established phases a candidate proceeds through, in the preparation and submission of his/her thesis. These phases have points at which progress is reviewed by supervisors, other research staff and the candidate. Milestones provide the facility to nominate these phases and review points, and monitor progress against them.

Establishing Milestones.

Each research course may have different phases and review points. Because of this, Callista provides the facility for an institution to define a set of milestones for a course. The creation of these sets of course default milestones would be done by a specialist user in the form RESF3231.

Milestones for a particular candidate are established in the Maintain Candidature Milestones form (RESF3232). For most candidates, the Course Default Milestone set is appropriate and can be inserted for the candidate, using the button on the form. Milestones from the set that are not required can be deleted. Additional milestones which are not part of the course set, but are required for this candidate, can be added. A milestone can be nominated as a precedent for another milestone, where one must be achieved before another.

The milestones for a candidate can be viewed by accessing RESF3232 from either the Candidature or the Thesis form.

Updating Milestone Progress.

Each milestone has a due date by which it should be achieved. Typically, a review meeting between the candidate and her/his supervisors would be held at this time to assess progress against the milestone. Progress is recorded by changing the status of the milestone, at these review points. A milestone which is complete would be given the status of 'ACHIEVED'. Institutional policy determines the procedures for renegotiating milestones which have not been achieved. Institutional policy also determines penalties for failure to achieve milestones.

For example an institution may adopt the following policy relating to renegotiation. Where the supervisor agrees progress is being made but the candidate needs more time to achieve the milestone, the due date is changed and the status updated to 'RE-PLANNED'. Where progress has not been satisfactory, the status is changed to 'FAILED' and a second review meeting (for this milestone) arranged to reassess progress. At this second meeting, successful progress would mean the status is updated to 'ACHIEVED' or 'RE-PLANNED' as appropriate.

The comments field provides supervisors and administrative staff with the facility to enter notes relating to any review of a candidate's progress or milestones.

Note: Functionality to trigger notification about imminent or past (but not updated) milestones is to be delivered in a future delivery set.

Capturing and Maintaining Thesis Details.

The Maintain Thesis Details form (RESF3700) allows the capture and maintenance of all thesis data associated with a candidature. A thesis cannot exist without a candidature record. The context candidature record is displayed when the form is accessed from RESF3211. If accessed directly (from a menu for example), the required candidature record is retrieved through a query.

In general, institutional policy determines when various thesis information should be recorded. The system allows the entry of most details in the Thesis block at any time. The following data can only be entered when the described conditions are met.

A candidate can have entries for multiple theses and a single thesis can have multiple examinations recorded. A thesis record can be deleted, if the thesis has not been submitted. This is a 'logical' deletion; the record is not physically removed from the database, instead it is marked as a deleted thesis. This means it can still be displayed if required.

Examination of a Thesis.

Procedures for the examination of a thesis and creation of examining panels are well established in institutions which offer research studies. These subsystem functions are designed to be used with these established procedures. For example most institutions have a required notification of submission period for a thesis. When a candidate gives this notification, the Expected Submission date can be entered in RESF3700. The process of recording this examination and establishing the examining panel may, in some institutions, begin on nomination of an expected submission date. Other institutions may allow this process to begin before the submission date has been nominated.

Selecting a Thesis Exam Type and Thesis Panel Type is the first step in the examination process. These fields are mandatory when the actual submission date is entered. A tracking item and associated steps can be initiated for this thesis exam using the tracking item navigation button.

The creation of the examining panel can follow the entry of the exam and panel types. Note that an examining panel is not mandatory. In circumstances where an institution does not want to record details of an examining panel (for example where research functionality is being used to record the examination of a special project undertaken by an undergraduate student), the Thesis Exam block can be completed without any records for an underlying examining panel. However, if the Panel Type selected has a recommended size, creating a partial panel with less than this recommended number prevents the entering of a Thesis Result for this examination. (The Thesis Panel Types and their recommended size values can be viewed in RESF3181.)

Creating an examining panel follows the general steps outlined here:

The establishment of the examining panel is now complete. The institution's thesis examination processes would now be followed and the system can be used to track and update the steps in this process.

Enter the Recommended Result and Remarks from each confirmed panel members as they are received. When the examination process is complete, a Thesis Result is entered for that examination, in the Thesis Exam block. If an examining panel exists, entering a result which matches none of the Recommended Results entered for panel members triggers a warning.

The payment date for examiners is entered as required. This and the Examiner's Remarks are the only fields which can be altered after a Thesis Result has been entered against the thesis examination.

When there is to be no further examinations of this thesis and all existing examinations have a Thesis Result entered, the Final Result can be entered. The status of the thesis becomes 'EXAMINED'.

Using the Tracking Facility.

The examination of a thesis and the communication between an examining panel member and the institution both require the completion of an established set of processes and tracking the location/transfer of documents. Tracking items created for either the examination or a panel member assist in ensuring these occur as required.

The Tracking subsystem provides the facility to monitor the movement of documents or progress of defined processes. Two system tracking types have been defined for use in the Research subsystem. These are 'RES-TEX' and 'RES-TPM'. Each has an associated set of steps. These become the default steps when a tracking item is initiated for a Thesis Exam ('RES-TEX') or a Thesis Panel Member ('RES-TPM'). These steps are defined by a subsystem specialist, when setting up the system (see Specialist Overview).

A tracking item is created by using the Tracking button on RESF3700, against the Thesis Exam or Thesis Panel Member. Once the item has been created, it can be opened and updated when required, using the same button. Action dates for each step are calculated and completion dates entered when the step is finished. Notes can be added about any step. Steps that do not need to be completed can be by-passed. For example where a tracking item is created for each prospective panel member, a number of default steps can be by-passed for those who decline to join the panel.

It is not mandatory to create tracking items, but this facility may be a valuable tool in managing the thesis examination process.

(Refer to Tracking, for a general understanding of this subsystem.)

 

Last Modified on 25 September 2002