CompProj:440 : Teaching Software 2017 / 2018 - Final Report


This project involves eliciting all software requirements for taught courses 2017/2018, and acquiring, configuring, packaging and distributing the requested software for use across our DICE desktop environment (which includes teaching labs, the desktops of teaching staff, and shared-use compute and login servers).


Informatics Teaching


The primary deliverable is a list of software: some acquired automatically from upstream sources, some built from scratch. The changes required are largely recorded in changes to the dice_sl7_rat.rpms and research-and-teaching-packages.h LCFG source files; the packages whose release strings include X.inf can be assumed to be locally built or modified in some way.

The secondary deliverable is a review of documentation such that students and staff are given enough information to locate and operate the software.

Though it's not explicitly part of the project descriptor, this project overlaps with the DICE-based lab exam system; a tertiary deliverable is to ensure that software packaged or included as part of this project is made safe for use in exams, where we're notified that it will be used in this way.


The project took nn FTE of CO time, and approximately nn FTE of CSO time.

The project was undertaken largely in Aug-Sep (overrunning into the first teaching block) 2017 with a second small peak of activity in Dec 2017 for S2 requirements. There were also snagging issues relating to one or two of the major software requests, due to the fact that the software had not been acceptance tested subsequent to its installation.

There will be significant error in the figures as it's difficult to record where the effort in packaging software might also form part of: a research request, the exam environment, or where requested software is or becomes part of the managed platform for desktops or servers. This results in significant effort savings, since software need only be packaged once for use in any environment, but can result in under-reporting against this project (where software has already been configured, or where effort is allocated against another project) or over-reporting where packaging effort is tracked against this project when it should belong to ongoing operational platform maintenance effort.


late requests: Steps have been taken to improve latency in requirements reporting, so that we're not so squeezed for time / surprised by more complex requests, but this is still dependent on teaching allocations being made in a timely fashion. It's increasingly common that we will have late requests with genuine scheduling constraints (late duty (re)allocation where this is the exception; last-minute coursework changes due to student feedback; etc.) so it's all the more important that we continue to stress that the requirements which can be specified ahead of time are specified as soon as possible, and support ITO efforts to perform routine duty allocation as early as is reasonable.

Documentation updates: these were performed as usual, including significant improvements to the pages covering specific frameworks, such as Java and Python. These updates are usually driven from a trawl of the content list with specific 'FAQ' style updates written in response to support requests. A more structured approach should probably be considered.

Use outwith labs: Although we have a responsibility to pass on requests for teaching software to IS labs in an attempt to improve the usability of such machines for Informatics students, in practice allocations and therefore requests come too late for IS' change management process, and in any event we are better able to support the fallback position of encouraging students to use our resources remotely. I'd support improvements to capacity and resilience of our remote access systems - and support the use of remote access to tunnel onto vacant/unloaded lab desktops - as our remote access systems seem to be exceptionally popular.

Exams: One can normally expect that any piece of software we distribute should work normally without access to the Internet (assuming that's not its primary function, e.g. web browsers...) but it's becoming increasingly common for courses to rely on 'just in time' updates and plugins which must be loaded into users' home directories. This is clearly incompatible with lab exam usage (and, in the case of software such as Eclipse, extremely difficult to prepare on a per-machine basis). We should revise the teaching software request email to encourage staff to think about exam use - for such courses, perhaps we should request a list of plugins / packages that students need but which are not normally bundled.


The project was completed; most software was provided ahead of time, and the project by definition closed at the end of AY2017.

Future Work

See Observations, above. Work for the new AY continues in TeachingSoftware2018Report.

-- GrahamDutton

Topic revision: r4 - 23 Jan 2019 - 13:45:50 - GrahamDutton
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies