You are here

Course Software

Printer-friendly versionPrinter-friendly version

Teaching Software on DICE

It is very important that software is installed, tested and distributed as early as possible before the start of teaching, so as to avoid any compatibility problems with DICE. We preserve versions of key software, once finalized, throughout the session (and until after any laboratory examinations) to ensure that students keep a consistent environment.

Note that because of this lab desktop version freeze, staff desktops often have a more recent version of DICE. Hence it is imperative that any testing of course software you do includes testing on a lab desktop - don't assume that if it works on your own desktop that it will also work on a lab desktop just because they are both DICE.


Specific software needed on the DICE desktop for teaching courses is provided based on the following timetable, as agreed:

  1. Report by lecturer/TAs of software for existing (completed) course as taught (did everything work as required?) (by mid-December or end March)
  2. Assignment of Teaching Duties (end April)
  3. Assessment of course software needs for next academic year, including any new, additional, or changed software (to be based on end-of-semester assessment, as [1] above) (end May)
  4. Confirmation of any changes needed, or none (mid-June)
  5. Delivery of requested software by computing support (end July)
  6. Completion of second assessment by lecturer/TAs (does everything now work as required?) (mid-August)
  7. Tweaking/fixing (as/if required by [6]) (end August)
  8. Requirements sign-off (mid-September)

in IS Labs

Some courses have teaching software deployed on IS Lab machines as well. While we make some attempt to collate and track the requirements the actual process to have software installed on IS Lab machines is under a separate mechanism managed by IS. Packaging requests are on a standard schedule. The minimum length of time to complete a package is given as 4 weeks; obviously, more time than this is very much preferable, particularly for complex packages, and it does require engagement from the requestor in terms of initial entry of the request (sufficient information for a team who does not know the package to be able to install and run check the package) and prompt testing and feedback.

More information:

Last reviewed: 

System Status

Home dirs (AFS)
Other services
Scheduled downtime

Choose a topic