User Support and Training

Managing requirements in terms of staff development and user support are further com- plicated when deploying software from within a single academic school, rather than from central support units, as resources that would normally be expected to be available for such tasks are typically limited to handling institution-wide projects with backing from senior management.

Accordingly, costs for activities such as staff training, writing of end-user documentation and user support are done using the same pool of researchers. These tasks then have a direct impact on research output, meaning that minimising the needs for these is a priority at the design and development stage.

Chapter 4

Design

A central theory behind MMS is that it is possible to substantially streamline institutional administrative efficiency by using a suite of software tools to improve visibility of both data and processes. Underpinning these tools needs to be a framework providing common functionality such as authentication and authorisation, integration with external systems, custom data types, etc.

This thesis primarily discusses this core framework and its own data management tools. The design of MMS was formed around the “pain points” of academics working in the School of Computer Science, based on discussions of their experiences of existing pro- cesses. This led to an analysis of where these processes are unduly time-consuming, com- plex or risky.

MMS’ framework provides support to researchers and developers working on tools for students and academics, with a focus on use cases involving module and/or tutorial-group centric authorisation models. The APIs it provides avoids cases of “re-inventing the wheel”, and enable rapid development of tools which make use of institutional data through pro- vision of abstracted functionality for common tasks. The core MMS tools build upon that framework and seek to minimise administrative overheads and risks through a set of com- plementary principles taken from experiences in developing TAGS, and refined from user feedback on MMS (both informal, and from surveys which are discussed further in chapter 11):

structure[6], in contrast to designing a model based on an abstraction of the institu- tion, and requiring users to translate roles into that model. This principle stems from experiences gained working with TAGS, and the limitations of its model.

• Acquiring data from as close to the original source as possible; for example course- work is submitted directly by students, grades by academics, attendance from tutors. Collecting data at source reduces the risk of errors during transcribing of data. This principle is self-evident when considering data flows within an institution.

• Version control stored data to reassure users both that processes have been followed correctly, and that any input mistakes can be easily caught and rectified. This prin- ciple was added after initial development of MMS, in response to user queries about the origin of data or changes to data, and the frustrations in being able to answer those questions.

• Provide detailed audit trails on data and configuration to allow users to understand how a dataset has been formed over time. This is a logical extension of version control of data.

• Exposing data as widely as practical, from the best source(s) available, while reflect- ing institution policy on data security and management. This principle is based on experiences of the INSIDE project, and informal user feedback about frustrations with duplicated effort in entering the same data in multiple places/systems.

• Exposing process details to end-users, to enable more meaningful analysis and feed- back, by using a “many eyeballs” approach as discussed in Raymond[111]. Typically end-users are also more knowledgeable on the processes being modelled than devel- opers, and enabling them to better understand how processes are modelled improves chances of them being able to identify issues. This principle is based on experiences supporting MMS, where staff queried models the most unambiguous description of the model was the actual code used.

• Providing tools for analysing data quality and auditing data changes. This principle originates from experiences from INSIDE, and iterative improvements to student enrolment management tools to ensure staff could answer questions arising in a self- service approach.

• Pro-actively raising issues early and clearly in order to ensure they are handled as early as possible, including identifying and flagging potential data issues for user attention. This is an extension of the common “fail fast” design in software error handling.

• Integrating with external systems such as VLEs, search appliances, web portals, mo- bile applications and survey tools to deliver high quality data to those systems. This follows logically from the earlier design principle of exposing data as widely as pos- sible.

Data is exposed to the users best placed to understand it, and so incorrect or out of date data can be readily identified and corrective action taken early. MMS is also pro-active in auditing data quality, intelligently correcting issues where it can do so and contacting relevant staff where it cannot.

Naturally data security is a primary concern in this environment, and to effectively both display data as widely as possible while ensuring data is not released inappropriately MMS requires a deep understanding of authorisation within a higher education institution, and modelling the roles, privileges, entities and relationships is a critical part of its design. This also allows MMS to display the most relevant data to a user at any point, for example indicating a student’s illness records next to tutorial absences.

4.1

Lessons Learnt from TAGS

MMS’ development started in mid-2002, targeting a release in time for the start of the academic year 2002/3, three months later. This initial release was intended as a proof of concept for the design, and would provide the core application framework along with a number of tools targeting the most popular uses of TAGS. These tools included:

• coursework submission, marking and feedback tool

• external link tool

• tutorial attendance tracking tool

These tools were chosen because they were the most popular uses of TAGS. While the ma- jority of these tools were administration-focused, this was not the reason for their selection. The administration theme did however direct later decisions in extending the platform’s functionality. These tools were supported by a basic framework covering:

• New core data model intended to reduce code duplication through homogenisation of entities (users, groups, modules, resources).

• A hierarchy of groups of users for authorization modelling.

• Administrative tools to manage modules, groups, users and the relationships between them.

• System administrator tools for auditing logged in users and logging users out if needed.

• Developer diagnostic tools for checking database record integrity (MySQL had been configured to use MyISAM instead of InnoDB for the database engine, and as a result it did not provide referential integrity constraints, and at the time it was not anticipated how risky this would be).