Two servers, one for live use and one for testing, have been installed in our data centre and are being remotely configured by Worktribe. Worktribe provide the virtual server to us as an OVA file that is then installed and hosted in our existing virtual server environment. Almost all of the support and maintenance will be done by Worktribe remotely, which is a different approach to most of our systems though should be straightforward. Active Directory integration, which will allow users to log on to APMS using their standard University username and password, is also being configured.

We are starting to see parts of the system coming together now, and have been able to do some end-to-end testing of selected processes.

The vast majority of fields and workflows for creating short courses, standalone credit and ‘normal’ programmes have been created. This is where testing has been focussed. Worktribe still have a little more to do with preventing changes to programmes once they have been validated, but it is encouraging to see some significant progress and to be able to run through from proposing a programme to getting it validated.

Here’s a sneak preview of what you currently see when first proposing a new programme. (There may, of course, be some change by the time the system goes live.)

The project team are all very pleased that another instance of the system has been set up to be used specifically for populating our existing programme and module data. The population exercise has begun, which in itself is a major undertaking, and towards the end of the project the data will be moved across to what will be the live system. Starting population with real information at this point brings an added benefit that bugs are identified early, along with any suggestions for tweaks.

In addition to the programme proposal and validation work mentioned earlier, Worktribe have also put in place the mechanism to ‘roll over’ programmes from one academic year to the next. This is needed so that Agresso Students can be populated with instances of programmes for each academic year, and will also form the basis of how modifications are made to programmes.

After a few discussions between ICT’s server specialists and Worktribe, an appropriate way of backing up the system has been agreed. Although we hope that the worst will never happen, it’s essential we have backups in case of a major failure that means we lose the server or its data. The APMS server will be backed up to another server via a share, and from there backed up to an off-site facility. The backup routines will run every day, with Monday to Thursday backups kept for a week and Friday backups kept for a month.

ICT’s Application Support Team attended a training course about DTC (Data Translation Centre) – a tool in Agresso Students used to import information to the system in a support manner. This will be the way that programme and module information is imported from APMS to Agresso Students, and our Application Support Team are now able to configure and support the technical implementation.

The main areas Worktribe is now tackling are

• how the marketing information about programmes is stored in the system and made available to be published on the Univerity’s website
• how the system will handle programme modifications
• how deletions/suspensions of programmes will be managed and the information archived
• how records will be ‘locked down’ once validated but certain fields are still made available for editing.

I have started thinking about how to get information about the system out to a wider audience when we get nearer its launch. A lot of people, especially academics, will need to know about and use it so it is important to strart thinking about how to get the message out. To that end I have started talking to the Internal Comms team, and we have started work on a simple communication strategy.

In order to allow Worktribe more time to concentrate on core functionality at the moment, access to the API will come later but will still definitely be made available as part of the project.  We’ve seen the first XCRI-CAP outputs from the system which Jamie has had a look and provided feedback to Worktribe. At this stage the XML is produced by manually selecting a programme and choosing an option to export the XML file, but later will be available via a URL. Worktribe is making some refinements, with the aid of the XCRI-CAP validator, and we should see the next iteration soon.

In my last post I gave an overview of the APMS project so far, and how the work with Worktribe is going.  This time I thought I would talk a bit more about some of the information that will be coming out of the system.

Diploma Supplements

One of the driving factors behind the project is diploma supplements.  In order to be able to automatically produce diploma supplements with meaningful information about the programme of study, rather than just a very basic outline, the system needs to store those details about the programme and combine it with student details to produce the document.

Since APMS will be the main source of programme information and approval processes, the  programme information needed for diploma supplements will naturally be stored in it.  Details about students and their results are stored in Agresso Students, so the technical gurus at Worktribe are working on routines to bring that data in to APMS and produce the diploma supplements in it.  The full details of exactly how all of this will work in practice are still being ironed out, but ultimately we will be able to produce diploma supplements en masse, and possibly give them to graduates at the same time as their certificates.

Key Information Set

The Key Information Set (KIS) is certainly causing a fair degree of consternation in the sector at the moment.  Despite HEFCE’s and HESA’s assertions that organisations should already know all of the information that the KIS summarises, and indeed some of it is already reported and those sources will be used for its production, the reality is that the information is not necessarily held in a way that means it can be returned electronically.  In fact, some of the technical detail about how the extra data will be returned have only just been released by HESA.  An article published by Guardian Professional talks about some of the issues facing institutions.

As you probably already know, a significant part of the KIS data set relates specifically to programmes (courses in KIS terminology).  Institutions must submit this data set to HESA in a defined XML format.  Since at Lincoln we will be collating programme information in the new system, and much of it until now has not been recorded in a way that lends itself easily to producing the submissions as required, it made sense from the outset to include recording the necessary information and outputting in an appropriate manner part of the system requirements.

Like Diploma Supplements, the full details of exactly how it will work have yet to be discussed in their full detail, but I will give updates as we go through the project.  Technical information about the KIS, for those interested, can be found here.

HEAR

The Higher Education Achievement Report (HEAR) is intended to be a method of reporting and making available information about student achievements during their time at the institution.  JISC’s description is that it is “intended to provide a single comprehensive record of a learner’s achievement at a higher education institution. It will be an electronic document, which will adhere to a common structure and be verified by the academic registrar or equivalent officer. Institutions may also choose to issue a paper document.”

From my perspective, the HEAR will take what is currently in Diploma Supplements and take it further in the following ways:

• It will be an electronic ‘document’
• It will provide more details about types and weightings of assessments
• It will also includes information on activities carried out by the student which do not carry credit towards their award, but which can be verified by the institution.

A HEAR document will be submitted by institutions for each student in XML format (specification version 1.0c is the current version at the time of writing).

The technical details of the HEAR, and exactly how it will be submitted and delivered, are still being developed at the moment; as a result we are understandably not actively working on this yet.  However, with the Academic  Programme Management System becoming source of our Diploma Supplements, and the HEAR being the next extension of those, it obviously makes sense for APMS to also deliver HEAR documents.  HEAR production was therefore included in the specification and will be delivered in due course.

XCRI-CAP

XCRI-CAP production is, of course, a vital piece of the JISC Course Data Stage 2 programme.  As part of APMS, Worktribe will produce an XCRI-CAP feed from the system.  It’s likely that we will cache this somewhere on our main University website rather than have to arrange for public http access to APMS, and of course the public facing website is designed to handle loads that APMS is not.

Worktribe is working on producing this feed which will replace the existing mechanism we have for producing our current XCRI-CAP feed provided at http://www.lincoln.ac.uk/xcri.

Programme and Module Specifications

At certain points we need to be able to produce programme and module specifications in document format, for example Word (.doc) or PDF (.pdf) files.  Occasions when these might be needed include:

• During validation panel meetings
• For auditors to review
• To include on the website with programme marketing information

In time we may be able to persuade people to view the information in APMS rather than in a document, and there might be some potential for including the full programme specification as another web page rather than as document downloadable from the marketing information page for a programme on our website.  In the meantime, however, Worktribe’s system give us the ability to produce these documents as needed.

Data for ON Course

In addition to the XCRI-CAP feed and KIS information, the ON Course project at Lincoln will make use of Wortribe’s APIs to extract programme and module information from APMS and do interesting things with it!  The APMS project is focussed on improvements to course data flows within the institution; ON Course seeks to find innovative ways of exposing that data publicly and, combined with other existing sources of open data, provide examples of how it can be used.

At the moment we’re accumulating test data, designing APIs and experimenting with tools and ideas.  We are still undecided about whether we will focus on an outward facing application for prospective students or develop an application that has greater benefits for curriculum design and business intelligence, but recent conversations and experiments have us leaning towards the latter.

The documentation about these APIs will be made available at http://data.lincoln.ac.uk.

I’ll try to keep this as much to the point as I can whilst giving you a good overview of the APMS project so far.

The University indicated that a project for an academic programme management system (which I’ll shorten to APMS) should begin. A Sponsor for the project, a senior University manager with a vested interest, was found (the University Registrar) and a Project Manager appointed (me!). Draft Business Case and Project Initiation Documents were written and a project board formed to steer the project.

I spent time with various parts of Registry to better understand and document the processes behind managing curricula and a team of us spent quite some time working out what was needed from a system and compiled a requirements specification. An Invitation to Tender (ITT) was written that included the requirements specification, and published so that potential suppliers could tender for the system.  The team reviewed the tenders received, but found that the costs exceeded the EU threshold for public sector procurement. This meant the Invitation to Tender must follow the EU tender process and be advertised through the Official Journal of the European Union (OJEU).

The ITT was revised and submitted through the OJEU, and the documentation is available to download at the bottom of this post.  Several companies submitted tenders, and an evaluation panel reviewed tenders, saw demonstrations and after scoring each solution made a recommendation to select a particular supplier, which was accepted by the project board. There was a gateway review by the SMT to give the final go-ahead. After a period of contract negotiation, the contracts were signed.

The contract has been awarded to Worktribe Ltd, and work on delivering the system started in earnest in January.

In the meantime, the University undertook the first stage of the JISC project about making the most of course information, and was successful in its bid for stage two. The work will build on what we are putting in place in the APMS project to create examples of how the data can be used in other ways, including generating feeds for using curriculum data elsewhere.

The first workshop with the University project team and Worktribe was held in January, and was the first chance for both sides to get stuck in to the work together. A small group of us then spent another day with Worktribe in early February, going through the progress they’ve made so far on the system and talking through some more of the detail. It’s encouraging being able to see the software in action so early, though we have to remember there is a long way to go yet and a lot of work to be done.

We had some debate, both internally and with Worktribe, over the best approach to take for collating all the information that needs to go into the system ahead of the system being finished. The main data/information stores currently are:

• The student management system, Agresso Students (formerly known as QLS), which holds programme and module structures at static (not related to year or session) and sessional level.
• Definitive programme and module specifications, held in PDF/Word documents.

The information from Agresso Students, although in a database structure, only contains a small proportion of what needs to go into the APMS. The definitive documents hold a lot more information (but not necessarily all that is in the student management) but are obviously not in a format that can be imported into a database.

We need to start compiling and preparing all the data ready to go into the APMS now because it will take quite some time to do, and there simply isn’t enough time to wait until the system is finished and then start populating it manually. One idea was building a spreadsheet and gradually populating it with everything needed. This approach presents a number of difficulties though:

• The data is more complex than a simple spreadsheet allows for.
• Some fields contain large quantities of text; this is not easy to view or manipulate in a spreadsheet.
• There would be a lot of columns and a lot of rows, making the spreadsheet difficult to manage.

Another option was to enter (type, copy/paste etc) the information directly into an unfinished implementation of the system.  The system could then be upgraded to eventually become the final version, or the information ported to a different version at the end. This approach means not having to worry about the format of the data or how to import it, and also gives valuable experience to those doing the work about how the system works (as well as potentially flagging any bugs early). It presents some challenges, though, too, including the need to make the system as ready as possible for real data; making sure it is not used as a test system, and real date being changed; how to cope with late changes in design once data has been input.

Ultimately, we all agreed that as soon as all the fields for information we think we need to capture are set up in the system, and the structure is reasonably stable, Worktribe will create an instance especially for us to start populating with real data. This will be carefully controlled to avoid being used as a test system! Although we all accept that we might need to make some more changes yet, and some extra information might be needed, it should be a reasonably final system in term of data.

Most recently, our small group met with Worktribe again late February to review the work that has been done for the first development round and prepare for the next. The progress so far is very positive. We have also been making ample use of the issue tracker, used to report bugs, ask questions or request changes to Worktribe.

We’re approaching some of the more challenging aspects at the moment – at least for Worktribe who have to develop it! In particular, the next phase includes:

• Working out how to create new versions of programmes and modules when making modifications, rolling over to a new academic year or revalidating.
• Making sure permissions are set so that people can access what they need to, but not change anything they shouldn’t. In parallel with this is making sure that throughout the approval and validation process for a programme (managed with a ‘workflow’ in the system), information can be changed at the appropriate time but also locked once certain stages.

Work is also taking place on the integration between Agresso Students and the Worktribe APMS. Following a day that Matt, Worktribe’s technical director, spent with us a couple of weeks ago, Worktribe are now working on how to extract the student, enrolment and assessment information from Agresso Students needed to generate diploma supplements.  Experimentation with a utility called Data Translation Centre (DTC) built into Agresso Students has also revealed a supported method of importing curriculum information into it.  DTC is a tool for importing data from third-party sources into Agresso Students without need to know the structures of the database and with checks in place to ensure the data is valid for the system and will not cause any problems.

Downloads:

• Invitation to Tender: ITT198-1
• Requirements: ITT198-1 Annex 1 to Appendix A – Requirements List
• Pricing and Questions: ITT198-1 Appendix B