jisc final report template - sussex...

Project Identifier: Version: Contact: Date:

of 18 Document title: University of Sussex Final Report Last updated : 8 March 2013

JISC Final Report

Project Information

Project Identifier To be completed by JISC

Project Title University of Sussex Course Data

Project Hashtag

Start Date 31st October 2011 End Date 31

st March 2013

Lead Institution University of Sussex

Project Director Carol Shergold

Project Manager Jane Major

Contact email [email protected]

Partner Institutions N/A

Project Web URL http://blogs.sussex.ac.uk/coursedata/

Programme Name Course Data – Making the most of course information

Programme Manager Ruth Drysdale

Document Information

Author(s) Carol Shergold, Jane Major

Project Role(s) Project Sponsor / Director, Project Manager

Date 8th March 2013 Filename Sussex University Course Data

Final Report.pdf

URL N/A

Access

Document History

Version Date Comments

mailto:[email protected]

Project Identifier: University of Sussex Course Data project Version: Final Contact: [email protected] Date: 8 March 2013

Document title: JISC Final Report – University of Sussex Course Data Project Template last updated : Feb 2011 – v11.0

of 18

Table of Contents NB: This table of contents ‘auto-populates’ - to update the table of contents – place cursor in the table of contents, right-click your mouse, click ’update field’, select appropriate option

............................................................................................................................................ 1

1 ACKNOWLEDGEMENTS ............................................................................................................................ 3

2 PROJECT SUMMARY ................................................................................................................................. 3

3 MAIN BODY OF REPORT ........................................................................................................................... 4

3.1 PROJECT OUTPUTS AND OUTCOMES ................................................................................................................ 4 3.2 HOW DID YOU GO ABOUT ACHIEVING YOUR OUTPUTS / OUTCOMES? ...................................................................... 6

3.2.1 Overall project management and governance ............................................................................... 6 3.2.2 Changes to our aims and objectives ............................................................................................... 7 3.2.3 The project stories ........................................................................................................................... 8

3.3 WHAT DID YOU LEARN? .............................................................................................................................. 13 3.3.1 Overall project management and governance ............................................................................. 13 3.3.2 A better understanding of our Course Data .................................................................................. 14 3.3.3 XCRI-CAP ....................................................................................................................................... 14

3.4 IMMEDIATE AND FUTURE IMPACT .................................................................................................................. 15

4 CONCLUSIONS AND RECOMMENDATIONS ............................................................................................. 16

4.1 GENERAL CONCLUSIONS .................................................................................................................................... 16 4.1.1 Conclusions relevant to the wider community and to JISC............................................................ 17

5 IMPLICATIONS FOR THE FUTURE ............................................................................................................ 17

6 REFERENCES ........................................................................................................................................... 18



of 18

1 Acknowledgements

This project was funded by the E-Learning Programme: JISC Course Data, Making the Most of Course Information. We extend our thanks to the JISC team for their support and also within the institution to Student Systems; Student and Academic Services, ITS Client Services, Communications (Publications and Branding/Web Team), the Office of Governance and Secretariat (Planning) and, finally, ITS Corporate Information Systems. A special thanks to Rob Brownsell for his contribution on reaching new technical boundaries and David Guest for his work in visualising our technical focus and outcomes for the XCRI-CAP feed. Data Synchronisation/Migration The business lead on this project was Colin Clark, the University’s Assistant Registrar for Student Progress and Assessment. Team members: Colin Clark – Business Lead Katie Damen – Client Manager in IT Services Jane Monaghan – Business Analyst in IT Services Gary Wilkinson – Oracle forms developer in IT Services Key Information Sets Dominic Hull – Business Lead Katie Damen – Client Manager, IT Services Gary Wilkinson – Oracle forms developer in IT Services Martin Scolding – XML production, validation and transfer XCRI-CAP Team members: Carol Shergold – Project Sponsor Jane Major – Project Manager in IT Services Michele Saliman – Business Analyst in IT Services Rob Brownsell – Lead developer Tim May – Head of Student Systems Office key data owner Finally, we would like to thank our Programme Manager, Ruth Drysdale, and all her team for their hard work in running this programme.

2 Project Summary In September 2011, JISC offered funding for institutions under the title "Course Data: Making the Most of Course Information". At this point, the University of Sussex was undertaking a complete overhaul of its courses and modules for all courses commencing in academic year 2012/13. In this review, learning outcomes were to be aligned for courses, modules and assessments; the credit structure was to be drastically simplified; and the structure of the academic year was changed so that our three term structure was replaced by two teaching terms.



of 18

A further driver during this time was the need to provide clear, consistent data to prospective and existing students. Like all HEIs, we were aware that we needed to produce a data feed for the Key Information Sets for August 2012. We also wanted to ensure that we were ready to take part in any national initiatives around sharing course data, and so were keen to develop a way of producing a feed in the data format XCRI-CAP (exchanging course data, course advertising profile). XCRI-CAP is an internationally recognised data standard for course information, and could form the basis of a national system for aggregating information about courses. The JISC funding call seemed to fit well with these activities and aspirations, and we therefore bid for funding in both Stage 1 and Stage 2 of the call, and were delighted to be given an opportunity to take part in this programme. Taking part in this programme has been beneficial for the University. Some of these benefits have been internal, such as work carried out to ensure the appropriate management of course and module data, and to generate a KIS feed. Other project outputs are readily accessible to other HEIs. We have used open source tools to build a re-usable, scalable XCRI-CAP web service that could be adopted by other institutions.

Our solution was designed from the outset to be scalable and secure

We wanted to ensure that our XCRI-CAP service was independent of any one particular type of student record system, so we designed it with very loose coupling

Our solution was designed to be reusable, so that other institutions could adopt it if they wished to

It is portable as it will run on Linux or Windows technology

It is extensible and will take account of any future changes to the specification through automated code generation tools

It is flexible as it can produce feed outputs in a variety of formats

Our solution relies on open source technology rather than on proprietary tools

It's free for others to use

3 Main Body of Report

3.1 Project Outputs and Outcomes

Output / Outcome Type (e.g. report, publication, software,

knowledge built)

Brief Description and where to find it

Outputs

Work package 1 – synchronise data from our Course and Module design tool

Software Course Data Synchronisation xml for feeding approved records from the Course and Module Design tool to the central Student Records System. Internal to University of Sussex.

Work package 2 – create KIS feed

KIS data – XML file System generated data feed in XML for HESA The feed is delivered directly to HESA and the information provided is then made available to prospective students through the Unistats widget on the University's own prospectus pages,



of 18

and via the Unistats site itself. For example, see: http://www.sussex.ac.uk/study/ug/2014/1673/30138 http://unistats.direct.gov.uk/Subjects/Overview/10007806-24790 Technical Design Description available at: http://blogs.sussex.ac.uk/coursedata/2012/10/22/3-kis-technical-design-doc/

Work package 3 – create XCRI-CAP data feed and associated products

XCRI-CAP data feed XCRI-CAP 1.2 system generated data feed, including all Undergraduate and Postgraduate courses offered by the University of Sussex. Publically available http://xcri.sussex.ac.uk/courses/ Technical Design Document - http://blogs.sussex.ac.uk/coursedata/project-documents/

Java Enterprise Edition v6 web service to produce XCRI-CAP data

In order to produce our XCRI-CAP data, we developed a web service application using Java Enterprise Edition v6. Other institutions can download the code in order to explore our approach and try it out with their own data. https://github.com/sussexcoursedata/course_data_project

General deliverables

Project Blog Updates provided on project progress and technical journey Available at http://blogs.sussex.ac.uk/coursedata

Reports for JISC Project Plan (agreed revision) Agreed revision available at http://blogs.sussex.ac.uk/coursedata/project-documents/

6-monthly interim reports

Final report

Completion Report

6 monthly reports and the completion report are internal to the project and JISC. The final report is available at: http://blogs.sussex.ac.uk/coursedata/project-documents/

License agreements Creative commons and open source license details provided and investigated for JAXB, GSON, JERSEY MIT License used for all code released: http://opensource.org/licenses/mit-license.php

Internal and external reporting Project updates within the community and for internal distribution to stakeholders Poster link http://blogs.sussex.ac.uk/coursedata/xcri-cap-feed-poster/

Outcomes

Information Provision Current and prospective students have access to course information data to aid selection of courses

Business Process Enhancement Project documentation evidencing objectives met for KIS

Business Process Enhancement Policies in place for KIS, course data work flows to support the

http://www.sussex.ac.uk/study/ug/2014/1673/30138

http://unistats.direct.gov.uk/Subjects/Overview/10007806-24790

http://blogs.sussex.ac.uk/coursedata/2012/10/22/3-kis-technical-design-doc/

http://blogs.sussex.ac.uk/coursedata/2012/10/22/3-kis-technical-design-doc/

http://xcri.sussex.ac.uk/courses/

https://github.com/sussexcoursedata/course_data_project

http://blogs.sussex.ac.uk/coursedata

http://opensource.org/licenses/mit-license.php

http://blogs.sussex.ac.uk/coursedata/xcri-cap-feed-poster/



of 18

University’s Curriculum Review Process

Improved technical infrastructure Knowledge gain on open source software and processes to support REST web services

Knowledge built within the community

Participating in dissemination activities as requested, making project outputs available with a Creative Commons license

Business Compliance Providing the XCRI-CAP and KIS feeds

Outputs will remain available until at least 31 March 2016.

3.2 How did you go about achieving your outputs / outcomes?

3.2.1 Overall project management and governance

IT Services has been fortunate enough to have received JISC funding for a number of projects in the past. One of the common features of the resulting projects, in our experience, has been that it has been a struggle to integrate them within the existing workload and working practices of our department. At the point where the bid is being prepared, the team creating the project plan and work package breakdown have relatively limited information about the context for the work packages they are describing. They do not have a full understanding of the other important projects that the department will be working on during the lifetime of the JISC project, and they do not have full knowledge of the resources that will be needed or available to complete the project. This means that the initial project plan is a "best guess" and that a lot of the assumptions it contains will be incorrect. So by the time the project is funded and recruits a project manager, the initial project plan is already "wrong". Even though JISC make it very clear that project plans can be adapted as the project unfolds, having an unrealistic plan associated with the project can cause problems and confusions for newly recruited project managers and more junior team members. We have also sometimes found difficulties with bringing appropriate resources into our JISC projects. Whilst the core project team understand the importance of the project, and indeed are often partially or wholly funded through the project, more peripheral colleagues may not understand exactly where the externally funded project fits in with the day-to-day work of the department. All projects need to draw on expertise from across the department, and beyond it. It can be hard to get requests for expertise to be prioritised against other flagship projects when the project is not incorporated into the normal approach to project governance within the department. For our Course Data Stage 2 project, we decided to try to describe work packages in a different way in our bid and its associated documents. We identified a number of work packages, and outlined the milestones that these work packages would need to achieve in order to deliver. But we did not attempt to allocate timings to these packages (other than those that were externally dictated such as the Key Information Set data feed). Instead, we decided that each work package would be run within the normal governance framework that we use in IT Services for all of our projects or change requests. That meant that each work package would be made active at an appropriate point where resource was available and within the constraints of the mandated delivery dates. At the point it became active, it would be allocated to a member of the Projects and Business Analysis team who would be responsible for planning it and moving it between the various stages of its development. At each stage, required resource would be allocated depending on availability and suitability. In effect, this meant that we structured our project as a number of mini-projects held together by an over-arching programme. In our bid documentation, we did not try to outline any dates or resources for these projects.



of 18

The overall JISC project was managed by Jane Major who was responsible for coordinating each of the work packages and ensuring that they reported to the Sussex Course Data project team. She also undertook the communication with the JISC programme team. Jane also managed the XCRI-CAP work package itself, within the governance framework of IT Services. Evaluation of this approach is provided in section 3.2.3.4 below

3.2.2 Changes to our aims and objectives When we commenced our project in January 2012, there were 4 main areas of work within the scope of the project:

Undertake further development work on the University’s Course and Module Design Tool

Develop a web service to satisfy the Key Information Set (KIS) requirement

Build an XCRI-CAP service using SOAP web services

Develop appropriate policy for all of the above The two sections below outline changes to our aims and objectives.

3.2.2.1 Course and Module Design Tool (CMDT) Our original bid contained work packages for the further development of a Course and Module Design Tool (CMDT). Work had originally been started on this in 2011 to support our institution's ambitious plans for curriculum review. This involved redesigning all of the University's courses and modules to use a new simplified credit structure and a new academic year built of two 12 week teaching terms, ready for the academic year 2012/13. Phase 1 of this work was for a standalone tool that was not integrated with the University's student system. As each course and module was redesigned, the tool was used to ensure that all required information was collected and validated. It allowed new courses and modules to be created, but did not offer any editing features. It did not have the functionality to enable changes to be made to already running courses or modules. At the point when we wrote the bid, we were being asked to develop this tool further so that it would provide a system that could be used for on-going creation and maintenance for all of the University's course and module definitions. However, early in 2012 there was some re-definition of institutional priorities by our senior management. IT Services were asked to re-allocate resources to enable the implementation of major systems including a new Finance system and a Conference and Residential Management tool. The continued development of the CMDT was therefore no longer a priority activity. Instead, the institution only required us to provide a robust, tested solution to transfer data from the existing Curriculum Planning tool into the live database tables within our student system. In April 2012, we therefore agreed with the JISC Course Data Programme Manager that we would scale back on the work packages defined for the CMDT, and deliver only the Curriculum Planning data synchronisation tool.

3.2.2.2 Key Information Set data feed In our original plan, we assumed we would build a web service to satisfy the requirements of the Key Information Set (KIS). However, as further details about the requirements were made available, we



of 18

realised that a web service was not required and that a simple flat file of XML would be far more appropriate. We therefore modified our project outputs and outcomes accordingly.

3.2.3 The project stories

Fig 1

3.2.3.1 Curriculum Planning Tool (CPT) & Data Synchronisation/Migration As previously described, the University undertook a review of all of its courses and modules for academic year 2012/13, using an in-house developed Curriculum Planning Tool (CPT) which stored data for the new courses and modules in its own separate data tables. Every course and module due to run in 2012/13 was reviewed, with the following objectives:

to ensure that all course learning outcomes were appropriate

to validate that course learning outcomes were fulfilled by at least one module

to ensure course and module learning outcomes were tested by assessment

to restructure the module for the new 12 week teaching term

to review the credit value for the module in line with a new simplified approach So the first step in our project to “make the most of our course data” was to ensure that this newly revised course and module data was migrated and into our central repository (the Oracle database). This meant that our existing Course and Module management Oracle forms for the central database needed updating to support these changes.



of 18

A data migration working group met weekly to discuss and resolve any issues arising. Oracle forms were developed to enable Academic Registry staff to undertake the migration, on a school and department basis as necessary. These were tested thoroughly and bug fixed using data from two schools:

Law, Politics and Sociology

Engineering and Informatics In the background, school curriculum teams were finalising all of their data. This was driven by the University’s Assistant Registrar for Student Progress and Assessment. Once each school was ready, their course and module data within the CPT was given a status of ‘Ready to Migrate’. All existing modules were end-dated on the database, and then the School by School migration process created new versions of modules using the data from the CPT ready for the 2012/13 academic year. The next step was to copy back the 2012 versions of modules to the 2011 and 2010 cohorts, so that all students are taking the same versions of modules with the correct number of credits. Using the CPT was a one off exercise and the teams would resume working with the Oracle web forms from our central repository once the migration was completed. This minimised changes to business process in the longer term but also meant that staff had a short but intense period of support for the initial change. The CPT became a temporary facility and was, in effect, decommissioned as we could not resource the product for continued development. Quality controls were developed, including a tool to facilitate validation checks to identify missing or mismatched data. In addition to this, a staff team was charged with running reports to make visual checks of the data. A security layer was put in place to give schools access to only their own data. This work was led by Assistant Registrar for Student Progress and Assessment, as the business lead for this element of the project. All data migration was completed within schedule.

3.2.3.2 Key Information Set data The delivery date for the Key Information Set (KIS) work package was determined externally by HESA. The IT Services Change Advisory Board therefore initiated this project in February 2012.. A KIS Operational Group was created to provide co-ordination and management of the operational aspects to KIS preparation at Sussex, including oversight of management information, student systems, IT infrastructure and communications. It reported to the Strategic Data Reporting, Optimisation and Forecasting Group which is responsible for the strategic aspects of KIS. As this is the first year of the KIS, and due to the Curriculum Review, it was agreed with HESA that Sussex would present an estimate of key statistics rather reporting on existing data. Database tables to hold the KIS data were created and Oracle forms were updated to enable maintenance of the KIS data associated with courses and modules. KIS types were identified and scripts written to populate these attributes. The process was led by members of the Governance team who has worked with other stakeholders to identify how related data will be provided – for example Residences, and the Careers, Development and Employability Centre (CDEC) The XML schema for the delivery of the KIS data was defined and distributed by HESA. We delivered this work in September 2012 by producing an XML file for transfer to the KIS web service, which was completed to KIS standards and passed the validation requirements. The Quality



of 18

Assurance methods were documented in the Executive Summary of Business for Audit Committee in May 2012. The data is now available for 2013 Undergraduates in the KIS widget. The validation of the data used in KIS complies with QAA guidelines (Quality Assurance Agency). The outputs from this work package included attendance at the HESA briefing meetings; the creation of a briefing document to the Audit Committee, a mapping exercise of required data; technical design document and the completion of the data file to transfer KIS information. We have not been able to obtain detailed statistics from Unistats about the ways in which Sussex University data is being accessed by students. However, from 27 September 2012 up to 7 January 2013, the University of Sussex 2013 prospectus pages containing the KIS widget were viewed almost 300,000 times. The KIS Technical Design Document is available here: http://blogs.sussex.ac.uk/coursedata/project-documents/ Quality Controls included Unit testing carried out in a development environment and review of the data by peers.

3.2.3.3 XCRI-CAP web service The IT Services Change Advisory Board allocated resource to enable the XCRI-CAP project to become active from June 2012.

3.2.3.3.1 Identifying, validating and signing off the data This process was carried out by a business analyst assigned to the project, and then validated by our Head of Student Systems. The first step was to review the mandatory and optional fields in the XCRI-CAP standard to ensure that the required data was being collected and to establish exactly how to capture it by querying our Student Records system. It was then agreed which fields would be populated in the University of Sussex XCRI-CAP feed. We identified all XCRI-CAP mandatory fields, and then added in any further fields that were already part of our current marketing dataset. We were pleased to find that our existing database already contained all of the mandatory fields, so we did not have to organise additional data collection. http://blogs.sussex.ac.uk/coursedata/project-documents/

3.2.3.3.2 Designing the technical solution The figure below shows our original technical plan for producing the web service.

http://blogs.sussex.ac.uk/coursedata/project-documents/



of 18

Fig 2

In thinking about the original design at the point when we were bidding for the project, we evaluated risks of making our institutional data available through an XCRI-CAP feed. One of the issues we identified was that we wanted to avoid creating a new route for denial of service attacks by enabling someone to repeatedly call the SOAP service. As the data is built via a fairly complex query, this could potentially load our institutional database and disrupt performance. This is one reason why we chose to have a separate set of tables for the XCRI-CAP Repository outside of our Student Records system. The other arguments for this approach were that we wanted to ensure the system would be adaptable in the face of changes to our underlying student system. We also felt that this loose coupling would make it easier for us to release the service to other institutions. However, when we came to the point in the project where we needed to create the XCRI-CAP repository data store, it was agreed that we should utilise a new schema within an existing database rather than a new database instance. This was seen as desirable because it fitted in with our internal policy of trying to prevent the proliferation of databases that each needs managing by our Database Administrator. The XCRI-CAP database tables were therefore set up as a schema within our central Oracle database. That meant that any denial of service attack against the feed would still have the potential to disrupt our central database service. We therefore had to re-visit our approach, and we decided that we would query the XCRI-CAP repository once every 24 hours to build an XML representation of the data, and use that for our SOAP service. The REST service was another possible target for denial of service attacks. This risk was addressed/removed as the REST service now only queries the XCRI-CAP XML file, which is created



of 18

daily from our database. (See Fig 3 diagram below). This means that our central database is not queried, and is therefore a successful mitigation procedure to increase our security by removing direct attacks on our data source.

3.2.3.3.3 Implementing the system Rob Brownsell took the lead on the technical implementation of the XCRI-CAP system. The system uses Java Enterprise Edition tools, and is designed to run as an application on the application server Glassfish. Glassfish is available free and is a robust application server that is already used for deploying web services at the University of Sussex. Working with Glassfish has the added benefit that other institutions could try out our solution for free. One of the benefits we had identified in advance of undertaking this project was that it would give us an opportunity to develop skills in the most recent version of Java Enterprise Edition – version 6 - and the Glassfish application server version 3. Final technical plan

Fig 3

Quality Controls included:

validation testing of the feed against other institutional data sources,

validation of the feed with the official validation tool http://validator.xcri.co.uk/

unit testing, see http://blogs.sussex.ac.uk/coursedata/2013/01/08/a-word-on-our-unit-testing/

stress and load testing,

walk-throughs by peer developers for the technical design.

http://validator.xcri.co.uk/

http://blogs.sussex.ac.uk/coursedata/2013/01/08/a-word-on-our-unit-testing/



of 18

3.2.3.3.4 How other institutions can benefit from our XCRI-CAP solution We hope that other institutions might find our overall approach of interest. Further information can be found on our project blog, at http://blogs.sussex.ac.uk/coursedata/ The source code of our application is available publicly at: https://github.com/sussexcoursedata/course_data_project It is made available under the MIT open source licence (http://opensource.org/licenses/mit-license.php), which is a very permissive open licence. Our web service is available at http://xcri.sussex.ac.uk/courses/. It contains over 460 different courses at undergraduate, postgraduate taught and postgraduate research levels.

3.2.3.4 Policy The University has agreed to make its XCRI-CAP feed available for use without charge from 1 April 2013 until 31 March 2016. We shall evaluate the usage of this information feed at the end of this period and, based on the benefits this delivers, decide whether to continue its provision. This will clearly be influenced by the wider community acceptance and use of XCRI-CAP.

3.3 What did you learn?

3.3.1 Overall project management and governance As described above in section 3.2.1, we structured this project as a number of mini-projects held together by an over-arching framework and managed by our Course Data project manager. We hoped that this would provide a better solution to project governance for JISC-funded projects. In the past, we have sometimes found difficulties with:

ensuring that the JISC project plan remains meaningful despite the changing demands on the department

allocating staff to projects at appropriate times to fit in with overall demands on IT Services

ensuring that core project staff are able to integrate their work with others in the institution Informal evaluation suggests that this approach was a success. We have found that our approach of determining work package priorities and tasks dynamically enabled us to manage the work effectively during a time of change with limited resources. Our work packages were much easier to resource and manage since we were using an existing framework in which everyone already understood the roles that were expected of them. This had very positive benefits. It enabled us to deploy key people into the JISC work packages at times that optimised the overall workflow within the department rather than according to a schedule that had been drawn up many months earlier. Pulling in peripheral team members to provide particular expertise was far easier, since the work packages were fully integrated into the department and there was therefore a greater understanding of priorities for completion and legitimacy. We did find there were some issues to be aware of with this approach. It was challenging for the project manager to collate information from the various mini-projects. Since the mini-projects are relatively autonomous, the overall project manager has to ensure he or she has access to the appropriate project members to capture all of the issues and nuances of the project for reporting purposes. In retrospect, we can see that we have not had such rich data from one of our work packages as might otherwise have been the case (work package 1, course data synchronisation tool).

http://blogs.sussex.ac.uk/coursedata/




http://xcri.sussex.ac.uk/courses/



of 18

We have debated within the team about whether this approach would be applicable to other projects. It seems to us that it is ideally suited to projects where:

the core project team need to pull in and coordinate the work of a wide range of colleagues in order to achieve the project goals

the institution or department already has existing governance approach that defines and shapes the way that these staff work together, and the ways that resource is allocated.

So we would think that this approach would definitely be relevant for other institutions to explore, particularly for technical projects.

3.3.2 A better understanding of our Course Data

As previously discussed, the timing of the Course Data project fitted extremely well with our portfolio review and enabled us to make a number of improvements to our data and to the access that key staff have to reports on our data. For example, the KIS work package identified that there were data requirements from some key staff that were not at that stage being fulfilled, and we have been able to rectify this by enabling reporting for data items such as contact hours. The XCRI-CAP work package identified that there was some missing data in our course descriptions, and has helped us to understand the ownership of data and the business processes associated with this.

3.3.3 XCRI-CAP First of all, the project has enabled us to see the value of the XCRI-CAP format as a way of sharing and aggregating data. The project has enabled us to really see the power of Glassfish application server 3 and Java EE 6 in the development and deployment of both REST and SOAP web services. As our data for courses and modules was already in a relatively mature state, little change was required in order to deliver on the XCRI-CAP dataset. We feel that producing an XCRI-CAP feed would be an extremely worthwhile exercise for institutions that have yet to centralise all their course data.

3.3.3.1 XCRI-CAP challenge – the uncertain future of XCRI-CAP One challenge we have faced in this project is the on-going management of the XCRI-CAP data process and in embedding XCRI-CAP into institutional practices. We feel this is due to the uncertain future of XCRI-CAP in the higher education information landscape. We have had difficulties in engaging senior managers with the need to allocate their staff time to building robust procedures for managing the XCRI-CAP data into the future. We believe this is due to an "adoption / credibility" paradox:



of 18

Until there are powerful XCRI-CAP aggregators with reach into student recruitment markets, the value of XCRI-CAP will not be realised and institutions will struggle to prioritise it given the other demands on their limited resources But Until institutions realise the value of XCRI-CAP and develop their feeds, large powerful aggregators will not be developed

Clearly, the Course Data programme has been an attempt to incentivise participation and lower the barrier to powerful aggregators being developed. We are aware of the work that the Programme team have been doing in trying to engage with UCAS, however, XCRI-CAP is not yet something that an institution must create in order to survive. With the current pressures on HEI resources, it is not easy for us to encourage fundamental change to business processes where the value of the change is not yet proven. We noticed that, for the KIS component of the project, it was extremely easy to get buy-in across the University for creating the business processes required for the feed. A failure to deliver the feed and to maintain the required data structures for next year’s feed would have real consequences for the institution. However, for the XCRI-CAP component of the project this has not been so straightforward. For example, we have had issues with missing data in data sources – it has sometimes been hard to work out whose job it is to fix these issues. The reasons for this are complex. It could be that the data is not yet being made available by the school, or it could be that the data is fully available but contains incomplete records. Also, flags can be set at various levels that prevent some of the data being made public via our prospectus system; in some cases this is to prevent duplication due to the structure of the data. Publications also have the ability to switch off courses or data fields depending on requests from departments. Working out the workflow and processes for all of these intersecting issues would require considerable painstaking effort and liaison between various University stakeholders. At the moment, these stakeholders take the view that our provision of data is not ‘broken’ as it is working satisfactorily for the purposes that they require of it. We are keen to experiment with the Facebook integration which has recently been released, and hope that by providing some immediate value to our institution we can more easily embed XCRI-CAP into the institution.

3.4 Immediate and future impact Within the institution there have been a number of benefits derived from this project that have had an immediate impact and many of these impacts will continue to benefit us in the future:

The data synchronisation between our Course Design Tool and our student system was delivered on time to meet the University’s scheduled audit and saved significant time and effort for users who did not have to re-key data. Use of the online system allowed us to avoid physical paper trails and bottlenecks. We are already seeing the benefits of the redesigned curriculum and expect these benefits to continue into the future.

Our KIS feed was delivered on time. As of 7 January 2013, the 2013 Undergraduate Prospectus pages including the KIS widget had been viewed 292,098 times. Unistats have



of 18

not been able to provide any data on click-through, but we do feel some satisfaction that almost a third of a million page views took place in the first term of operation.

New fields added to our web forms for core KIS data mean we are better able to control and monitor the data. The Data and Management Information Co-ordinator in the Office of Governance and Secretariat will take on the role of maintaining this information. Data integrity has improved as the ability to monitor and control the data has been improved.

The KIS requirements are changing again for academic year 13/14, and we feel that the work done within this project has left us in a good position for further development.

Through the KIS work package, the Data and Management Information Co-ordinator now has upfront access to aggregated contact time and assessments for courses and modules previously not available.

The KIS work has facilitated Governance to conduct a benchmarking exercise to compare assessment methods in the University with other institutions – we are able to easily check whether our bias is coursework or exam based. This exercise was approved by the Performance Committee.

Our XCRI feed is live and available, and can be used right now to promote University courses, for example using the Facebook widget which we are currently exploring and which we hope will be available for prospective students next year.

Technical skills in Glassfish 3, Java EE6 and REST have been developed as a result of this project. We are already intending to reuse these technologies in forthcoming projects.

Benefits for the wider community include:

Prospective students have access to clear and consistent metrics about the courses they are interested in via the KIS widget on the University of Sussex 2013 Undergraduate prospectus pages.

Data from Sussex University are incorporated into the Unistats site, enabling students to search and compare the course offerings they are interested in.

Our XCRI-CAP feed is already available to support the development of aggregators. In the future this may aid the widespread implementation of XCRI-CAP as a standard for sharing course related information across the sector.

The release of our implementation of XCRI-CAP using open source technologies means that other institutions can use our solution, which lowers the barrier for entrance into XCRI-CAP.

4 Conclusions and recommendations

4.1 General Conclusions

The Course Data project has helped us to understand the mechanisms and flow of our course data. This has given us a better perspective on the complexities of how course data is structured - from course creation to the marketing to interested parties. The work we did in identifying the decision points (approvals etc.) and the decision-makers/changers who control what course data is publicly available was particularly useful. The Self-assessment Framework exercise gave us a retrospective insight into the relative maturity of our data. However, we still found areas where we were able to improve our data and processes.



of 18

Combined with the University’s efforts on curriculum review, our participation in this project has really helped us to improve our Course Data.

4.1.1 Conclusions relevant to the wider community and to JISC

4.1.1.1 XCRI-CAP in the institution Where institutions scored very low on their initial Self-Assessment exercise, we would suggest that the value of developing an XCRI-CAP feed would be high, as working towards XCRI-CAP compliance is likely to move these institutions forward considerably. Where an institution already has relatively mature structures and workflow for course data, it may be harder to introduce the XCRI-CAP workflow into existing processes, since this will involve making changes to processes which are currently working well to support the institution in core business areas. Despite the availability of funding, it can be difficult to promote change of business processes without a very clear requirement for that change. We feel that this will be a barrier to the many institutions in seeking a long term legacy for their XCRI-CAP work packages. We feel this will be particularly the case until there is sector-wide mandatory adoption of XCRI-CAP as a data exchange format. Recommendation to JISC: Agreement with bodies such as UCAS that XCRI-CAP is an appropriate format for reporting on prospective courses will be crucial to ensure the survival of the XCRI-CAP implementations created with Stage 2 Course Data funding.

4.1.1.2 XCRI-CAP and KIS There is a strong similarity between the purpose of XCRI-CAP and KIS datasets, so it might make sound sense from an institutional point of view to investigate merging these two datasets into a single format.

4.1.1.3 Overall project management and governance We attempted to address some issues we had previously experienced with JISC project planning and resourcing by describing our JISC project work packages as mini-projects within the existing project management governance structure of IT Services. This worked very well, and we would consider using a similar approach for other funded projects where it was appropriate. Recommendation to JISC: For future funding programmes, we would recommend that it might be worth considering whether there could be benefits to this approach, and finding ways of building it into the bidding process in a more streamlined way.

5 Implications for the future XCRI-CAP could provide a useful standard for the exchange of course related information.



of 18

However, we believe that many institutions will struggle to maintain accurate XCRI-CAP data feeds for future years unless there is sector-wide adoption of the XCRI-CAP format, for example if UCAS adopt it as a mandatory requirement. Our code for implementing a web-service for an XCRI-CAP v1.2 data feed is available in GitHub at: https://github.com/sussexcoursedata/course_data_project Others can certainly build on this work, which is licenced with a permissive open source licence, the MIT licence (http://opensource.org/licenses/mit-license.php) Our project website is available at: http://blogs.sussex.ac.uk/coursedata/. Long term project contacts: Jane Major, Project Manager [email protected] Carol Shergold, Head of learning systems [email protected]

6 References http://www.jisc.ac.uk/whatwedo/programmes/elearning/coursedata.aspx http://unistats.direct.gov.uk/find-out-more/key-information-set http://www.hesa.ac.uk/content/view/1833/640/ http://www.thestudentsurvey.com/the_nss.html#.USymIle6Ogk



http://blogs.sussex.ac.uk/coursedata/



http://www.jisc.ac.uk/whatwedo/programmes/elearning/coursedata.aspx

http://unistats.direct.gov.uk/find-out-more/key-information-set

http://www.hesa.ac.uk/content/view/1833/640/

jisc final report template - sussex...

Documents