Marks and Grades

The grade aggregator tool consumes marks and grades from other tools in order to calculate final grades for students. Its original development was done at a point in time when the only suitable data sources were the coursework and exam tools, however the use of a defined common interface (as opposed to developing against the tool implementations) has allowed data sources to expand to support a number of other tools.

These later tools primarily were the quiz tool and a WebCT grade importer. A number of incomplete prototypes have also been developed but never completed, including a Moo- dle grade importer and a spreadsheet-based data source for holding data imported from arbitrary sources.

The grade aggregator itself then implements a further interface for exposing its calculated grades. This interface is specifically designed to feed grades from modules, rather than components of a module, and is consumed by the institution plugin. As with the intra- module grade source interface, this was developed as part of future planning, although unlike that interface it has to date seen only one implementation.

In comparison to similar mark APIs in Learn or Moodle, MMS’ interface is richer, pro- viding better support for scripting of the data processing. For example the final grade calculation scripts can examine component marks as well as the overall mark for course- work, in order to make decisions. This enables modelling of complex behaviour such as bonus marks awarded for consistency of quality of work.

5.13.2

Attendance

Attendance data is relevant to use cases such as monitoring students for early indications of problems with their academic engagement. With two tools providing this data (the lecture and tutorial tools), a common interface means consuming tools do not require to understand the tool details. This also adds scope for integration with external systems, such as aca- demic timetabling systems which could use this information to revise room requirements based on actual attendance.

5.13.3

Student Contact

The last interface slices across a number of different use cases. As part of changes to the requirements for institution Highly Trusted Sponsor status for tier 4 visas (adult students) in 2011, UKBA requires higher education institutions to record and report on student con- tact with the institution. Contact in this scenario is well defined, and covers a number of events in the normal student’s academic lifecycle including matriculation at the start of term, submission of coursework, and attendance at lectures and/or tutorials.

Matriculation is not currently managed by MMS, however coursework submission and attendance are, and accordingly the relevant tools can provide this data for reporting to central records, and onwards to the UKBA.

While the attendance tool could in theory provide this data directly, the provision of a generic interface allows for future extensions to the reported event types. For example if quiz completion was counted then the quiz tool could implement this interface and would automatically be included in reported data. See also discussion of the journal tool in the Future Work chapter, under section 12.5.6.

5.13.4

Coursework Submission

As part of the LAVA project (discussed in detail in chapter 10) tools were developed which produced assessed work as a result of student input (the collaborative form). A generic interface for tools which could accept coursework submission (the coursework tool is the only current implementation of this interface) was developed to allow the collaborative

form to submit to an assignment, ready for marking by staff.

5.14

Conclusion

MMS’ architecture is designed to provide a robust yet simple to use support framework for its hosted tools. The use of a layered approach to security, based on the organisational structure underpinning the authorisation model, moves much of the responsibility for se- curity away from the the tools and into shared framework elements, reducing the scope for errors in design or implementation. Further, the hosted tools are not required to understand the complexities of the authorisation model, further simplifying the development process. The architecture uses a fail-fast approach to error handling, and ensures that any errors are reported quickly and clearly to support staff. This, in combination with a version controlled data model, ensures that any issues are resolved quickly with a minimum of long-term impact on the overall system.

These factors combine to enable and encourage rapid development in response to changing requirements, while effectively managing the risks inherent in such an approach. The iso- lation of developers from low-level concerns allows them to focus their effort on end-user functionality, and enables development of tools which may be impractical otherwise.

Chapter 6

Integrations

In reducing administrative overheads one of the most obvious routes is to eliminate du- plicated effort. Any occurrence of manual entry of data which is already known to the institution is an opportunity to eliminate such effort. To this end, we consider the follow- ing:

• What data does MMS use for which there are existing data sources, and what further data could MMS used from these data sources?

• What form do these existing data sources take and how can we adapt them where needed?

• What data within MMS can be re-used by other external systems?

Further, we will consider how data within MMS can be used to drive processes in external systems.

MMS collates a substantial quantity of data from a variety of sources. Exposing this data for wider use increases the data’s utility, and provides additional motivation for time spent improving data quality within MMS. In contrast to a conventional data warehouse, MMS acts as an intelligent interface to the data, providing an authorisation layer, difference gen- eration, and other supporting tools to simplify integration with external systems.

These integrations embody the design principles of acquiring data as close to the original source as possible, of exposing data as widely as possible, and of course of integrating with

external systems. They are enabled by the design principle of modelling the institution, which ensures the model within MMS is generally compatible with other systems.

6.1

Data Sources

Configuration of MMS requires significant quantities of data which have existing sources including student and staff identities, details of modules running, lists of students enrolled on modules and student grades. Student grades include both assessment outwith MMS, and final module grades after any adjustments made after grades are reported from MMS (i.e. by the relevant Dean).

It is useful for MMS to also collate and present data from external systems, in a similar model to a web portal such as uPortal, and specifically reading lists. Lastly, as learning and teaching tools have been added to MMS it is desirable to be able to import pre-packaged content from external sources.

6.1.1

SITS:Vision

Early versions of MMS used the central data warehouse as the standard source for student records such as student details, course choices, degree intentions, etc. However the data warehouse is an interpretation of data from SITS:Vision, refreshed daily. As a result the data suffers from lack of detail, potential issues in interpretation, and during periods of high rate of change can be significantly out of date.

Direct integration of a data feed from SITS was added to resolve these issues. Data is read in via SQL, wrapped within the institutional abstraction layer. Recently SITS has introduced web service support (StuTalk) for integration with other, and the code is cur- rently being updated to use these officially supported interfaces. This data includes student identities, modules being run, and enrolments on modules.

SITS maintains a highly detailed model of the institution, and mapping this to a conven- tional web application may require re-interpretation (as was done by the data warehouse). In the case of MMS however its use of a model which closely reflects the institution limited this requirement, although some translation was still required, such as filtering records to

eliminate those not of relevance to MMS (i.e. students who have not yet started).

6.1.2

WebCT

St Andrews initially chose WebCT as its official VLE in 2001 (later replaced by Moodle in 2010). Although MMS had some limited VLE-like functionality, in contrast WebCT was intended as a VLE and included more powerful content and discussion tools, as well as a quiz tool that was popular in a number of schools (including Geography, International Relations, Modern Languages and Physics), both for assessed work and self-assessment. Where WebCT assessments formed part of a student’s final grade for a module, there was a need to aggregate the assessment results with other assessments (coursework, exam, lab works, etc.). The final grade tool (see 7.5) was rapidly becoming the preferred method for performing this data aggregation, however this meant the data needed to be copied from WebCT to MMS.

The introduction of a WebCT grade import tool automated this process, reducing risk of mistakes while ensuring the shown data in MMS reflected the latest data from WebCT at all times. This tool was exposed to the final grade tool via the genericised interface (see section 5.13.1), enabling it to treat it as any other data source.