JISC Project Plan Template - Sussex Blogsblogs.sussex.ac.uk/coursedata/files/2013/03/Project-Plan-Sussex-2…Page 1 of 20 Document title: Project Plan for University of Sussex Course

Project Identifier: University of Sussex Course Data Stage 2 Version: Contact: Carol Shergold Date:20 November 2011 Revised 24 May April 2012

Page 1 of 20 Document title: Project Plan for University of Sussex Course Data Stage 2 Last updated: 24 May 2012

JISC Project Plan

Project Information

Project Identifier To be completed by JISC

Project Title Sussex University Course Data Stage 2

Project Hashtag

Start Date 3rd

Jan 2012 End Date 31st March 2013

Lead Institution University of Sussex

Project Director Carol Shergold

Project Manager Jane Major

Contact email [email protected]

Partner Institutions none

Project Webpage URL

Programme Name Course Data: Making the most of Course Information

Programme Manager Ruth Drysdale

Document Information

Author(s) Carol Shergold

Project Role(s) Project Director

Date 20 November 2011 Filename

URL

Access This report is for general dissemination

Document History

Version Date Comments

1.2 19 April 2012 Revised with reduced scope (and price)

1.25 20 April 2012 Revisions

1.26 24 May 2012 Minor corrections.

Project Identifier: University of Sussex Course Data Stage 2 Version: Contact: Carol Shergold Date:20 November 2011 Revised 24 May 2012


Table of Contents

1. Project Overview .............................................................................................................................. 3

1.1 Project Summary ........................................................................................................................ 3 1.2 Objectives................................................................................................................................... 3 1.3 Anticipated Outputs and Outcomes ........................................................................................... 4 1.4 Overall Approach ....................................................................................................................... 5 1.5 Anticipated Impact ...................................................................................................................... 7 1.6 Stakeholder Analysis .................................................................................................................. 7 1.7 Related Projects ......................................................................................................................... 8 1.8 Constraints ................................................................................................................................. 8 1.9 Assumptions ............................................................................................................................... 8 1.10 Risk Analysis ............................................................................................................................ 9 1.11 Technical Development .......................................................................................................... 10 1.12 Standards ............................................................................................................................... 12 1.13 Intellectual Property Rights .................................................................................................... 13

2 Project Resources .......................................................................................................................... 13 2.1 Project Partners ....................................................................................................................... 13 2.2 Project Management ................................................................................................................ 13 2.3 Project Roles ............................................................................................................................ 14 2.4 Programme Support ................................................................................................................. 16

Detailed Project Planning ...................................................................................................................... 17 3.1 Evaluation Plan ........................................................................................................................ 17 3.2 Quality Assurance .................................................................................................................... 17 3.3 Dissemination Plan .................................................................................................................. 19 3.4 Exit and Embedding Plans ....................................................................................................... 19 3.5 Sustainability Plans .................................................................................................................. 19

Appendices ........................................................................................................................................... 20 Appendix A. Project Budget............................................................................................................... 20 Appendix B. Workpackages .............................................................................................................. 20



1. Project Overview

1.1 Project Summary Executive summary The overall aim of the Course Data project at the University of Sussex is to improve the information that we provide to students and prospective students and to support an on-going radical overhaul of degree programmes at the University. The project will support students' decision-making by providing automated creation of two important data feeds – the Key Information Set (KIS) and XCRI-CAP v1.2. Background to the project Currently, the University is undertaking a review of its courses and modules under the leadership of the Pro-VC for Teaching and Learning, Professor Clare Mackie. This Curriculum Review is being undertaken to enable the adoption of a more standard structure for course offered by the University; to ensure clear connections between course objectives, learning outcomes and, where appropriate, professional accreditation; to retain the Sussex tradition of multidisciplinary study, which ensures breadth as well as depth in our students’ learning experience; and to enable further efficiency gains in course delivery. QAA has indicated that it will be including an assessment of the ‘quality of public information’ being provided by institutions for prospective students as part of Institutional Review. The University of Sussex is undertaking its review early in 2013 and this increases the importance of undertaking the work outlined here. Project aims The aims of the project are to:

increase our institutional readiness for XCRI-CAP and adopt appropriate policies and procedures to support the goals of the institution for transforming and validating its course offerings

to produce outputs based on this data to provide improved information for students and prospective students, including XCRI-CAP v1.2 and KIS

1.2 Objectives Objectives for policy and change management:

o Curriculum review takes place o policy is adopted for external access to XCRI-CAP data

Objectives for streamlining course data processes: o promote a single central source of “the truth” about university courses and modules

by building a process to transfer data from the Course and Module Design tool into the main student records system

Objectives for providing high quality information for students and prospective students: o implement and host an XCRI-CAP 1.2 system-generated feed for undergraduate,

postgraduate, full and part time programmes o build an application to deliver the Key Information Set data for KIS collection 2012/13

and beyond o the University is able to provide consistent data for students, such as course

handbooks based on the reviewed courses and modules and compliant with the new University standards for course and module definitions



1.3 Anticipated Outputs and Outcomes

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

knowledge built)

Brief Description

Outputs

Data feed XCRI-CAP 1.2 system generated data feed available for external providers to access, with associated documentation (defined in section 1.11 to include requirements, design documents, test reports, and usage notes) as a SOAP service and as a REST service

Data feed KIS collection 2012/13 system generated data feed for HESA, with associated documentation (defined as above)

Software (internal use due to specificity of implementation) Documentation and background materials of benefit to whole sector



Course Data Synchronisation for feeding approved records from the Course and Module Design tool to the central Student Records System

Downloadable code Make code and documentation for the XCRI-CAP 1.2 solution available

Downloadable code Make code and documentation for the KIS feed available

Project blog A way of sharing and documenting the actual process of implementing an XCRI-CAP feed, and addressing challenges of Course Data processes. Updated monthly (by the PM)

Reports for JISC project plan

6-monthly interim reports

final report

completion report

License agreements Creative commons / open source licenses for all tangible outputs

Outcomes

Information provision Current and prospective students have access to data they need to make important choices and to support them in their study

Business process enhancement Required policies in place to support activities of University

Business process enhancement

Business process enhancement Support for the University’s Curriculum Review process

Improved technical infrastructure Use the XCRI-CAP project to kick start upgrade of software required 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



1.4 Overall Approach Important issues to be addressed Key issues to be addressed by projects with the Course Data Stage 2 programme include:

institutional change is required in order to bring about improvements; technical solutions are not enough

accurate data in an appropriate format must be available to prospective students to enable them to make the best possible choices

ensuring interoperability of data by using standards-based approaches

sharing knowledge and good practises across the sector How the work will be structured Please see diagram in section 1.1 (a) Institutional policy and procedures A work package to develop institutional policy and procedures will be led by Sharon Jones, the Academic Registrar. Policy will be developed within the framework of the University’s strategic direction and existing plans and formally adopted at the University’s Teaching and Learning Committee. Operational procedures will be developed to implement these policies in liaison with key stakeholders in the Registry and within the academic Schools. New procedures will be rolled out across the institution through the work of the project champion, with appropriate training and communication. (b) Course and module design tools The Student Record System at the University of Sussex is based on software developed by Oracle as part of the national Management and Administrative Computing (MAC) Initiative, set up in 1988. The institution has made a large number of substantial enhancements to this system, including an extensive web portal for staff and students that forms the backbone of many business processes in the University. The web portal provides a huge range of applications and services for staff and students, ranging from online registration for students; individual student timetables including assessment deadlines; assessment marks management; publication of degree results; university purchasing; booking and documenting staff training; incident reporting and many more. The web portal is implemented using an object oriented PHP framework that was developed in-house to provide an extensible, flexible Model-View-Controller style architecture. The portal architecture allows the developer to write queries against the institution’s Oracle database, and then automatically builds the result set into PHP objects for display or processing. Complex requirements can be met by extending the PHP classes that are defined within the architecture. An application has already been developed within this framework to support our Curriculum Review. . A work package will be organised to support the development of course data synchronisation. to will enable records within our Student Record System to be updated from information within the Course and Module design tool. (c) Developing web services Our overall technical approach for the production of the XCRI-CAP 1.2 and KIS feeds is to utilise Java Enterprise Edition (Java EE) 6. This provides developers with tools that can improve their ability to build robust, scalable, secure web services.



Our intention where possible will be to build in a data abstraction layer into our designs. This has two major benefits. Internally, it ensures that our solution is future-proof, as it isolates components within the design that may change and reduces dependencies. From a sector-wide perspective of offering benefit from this project to the broader JISC community, it supports re-use of applications produced at Sussex in other institutions. The diagram below shows the proposed architecture for our XCRI-CAP 1.2 feed. It utilises our existing approach to generating web services in which we use JAXB to automate the creation of classes based on the XSD. This can allow web services to be developed in an efficient way without the need for time consuming and error-prone manual coding of classes.

The current method of producing web services supports SOAP services, but as part of the background work for the Course Data Stage 2 project we will update the application server to a version that also supports REST web services. By the end of the project we will be able to provide an XCRI-CAP v1.2 feed via a SOAP web service and will have explored issues involved in implementing a REST web service. The feed will include undergraduate and postgraduate, part-time and full-time courses. A similar approach would be adopted for the KIS SOAP-based web service. Scope and boundaries The diagram in section 1.1 shows the overall scope of the project. Our institution’s current course offerings are focussed around the traditional modes of

Full-time Undergraduate degrees and

Full-time or part-time taught postgraduate degrees

Full-time or part-time research postgraduate degrees



We intend to expose all of these programmes in our XCRI-CAP v1.2 feed. Critical success factors Specified policy is adopted by the University (see section1.2) Data synchronisation from the Course and Module Design tool into our live database is scalable, accurate and bug free XCRI-CAP feed provides timely, correct, syntactically valid XCRI-CAPv1.2 data that we are able to validate using supplied tools KIS feed provides accurate data in compliant XML for KIS collection 2012/13 XCRI-CAP and KIS web services run in a scalable and secure way that does not introduce a new attack surface for University systems

1.5 Anticipated Impact

Impact Area Anticipated Impact Description

Be more effective / save money . The improved data will reduce confusion and wasted resource

Have a positive impact on wider society

Development of KIS and XCRI-CAP data feeds from a number of institutions will enable the JISC and others to bring about overall improvement of how students access information about courses

Be ready for technology needs in the future

Development of XCRI-CAP feed within the institution will allow us to be ready for future changes in the way that this information is provided. The project will help us to develop our capacity to provide web services based on a RESTian approach. Our KIS and XCRI-CAP Java solutions will be available for institutions to download

1.6 Stakeholder Analysis

Stakeholder Interest / stake Importance (H/M/L)

Professor Clare Mackie, Pro-Vice Chancellor for Teaching and Learning

Strategic lead for the development of the portfolio and restructuring of the academic year together with admissions and the student experience

H

Sharon Jones, Academic Registrar Responsible for design and management of policy and procedures for curriculum development and admissions and will lead on information for prospective students

H



Stakeholder Interest / stake Importance (H/M/L)

Academic Office Responsible for providing data relating to the curriculum, assessments, quality assurance

H

Marketing Ensures that the University’s course offerings are presented as well as possible to prospective students

H

Current students Need accurate, timely, well designed information on their course and modules

H

Prospective students Need accurate information on what their academic study and life experiences would be if they chose to study at Sussex

H

Faculty Want to be able to produce new and revised courses and modules as efficiently as possible.

H

Heads of School Consistent and coherent course offerings

H

External organisations like UCAS, HESA, QAA Need readily available data H

1.7 Related Projects Outputs from the Curriculum Design programme strand have already been useful to the institution, when we were first exploring how to support the institution’s Curriculum Review. We will continue to use the experience and tools developed within this strand as we work on our Course Data Stage 2 project. In particular, the JISC Design Studio is a highly useful resource. If appropriate, assets could be contributed into this repository.

1.8 Constraints The University is scheduled for a QAA Institutional Review in March 2013. A number of key deliverables will therefore need to be in place well in advance of this date. The KIS data set needs to be available by September 2012. When working as part of a group of projects, it is always useful to be roughly in step with other projects so that you can take part in discussion about implementation details along with others. This means that time tabling for the work on the XCRI-CAP feed will probably be partly led by the pace at which other institutions are going with the project.

1.9 Assumptions We note that there are discussions about tightening some data definitions in the XCRI-CAP 1.2 standard to make resulting feeds more comparable across a large number of provider institutions. We are keen to participate in this, but note the importance of managing change within the standard at a time when a large number of developers are all working with it.



We are keen to develop flexible, useful web services for XCRI-CAP 1.2 and assume that there will be a need to work as a community to agree a common set of parameters so that, for example, a third party could invoke the web service just to find all part time, postgraduate courses.

1.10 Risk Analysis

Risk Description Prob (P) 1 – 5

(1 = low 5 = high)

Severity (S)

1 – 5 (1 = low

5 = high)

Risk Score (PxS)

Detail of action to be taken

(mitigation / reduction / transfer / acceptance)

Delays introduced by staff recruitment

3 5 15 We are starting the recruitment process in November 2011, with the agreement from HR that we will terminate the process if no funding is available The developer post is required for back-filling; development work on the Course Data project will generally be undertaken by existing developers, so work can start in advance of appointment if we plan projects carefully. While we await the appointment of a project manager, Carol Shergold will carry out the PM function.

Not able to recruit appropriately qualified staff

3 5 15 We shall make use of contracted programming staff. We have identified an individual who is suitable to undertake the project manager role

Work fails to be completed on time

1 5 5 Project management structures will be in place to ensure that work packages are completed in a timely way. There is a strong institutional drive for us to deliver on this project.



Risk Description Prob (P) 1 – 5

(1 = low 5 = high)

Severity (S)

1 – 5 (1 = low

5 = high)

Risk Score (PxS)

Detail of action to be taken

(mitigation / reduction / transfer / acceptance)

Institutional culture changes around managing courses and modules are not successful

4 3 12 The need to change our approach to Curriculum Review and course and module approvals is already a high priority for the Pro-Vice-Chancellor for Teaching and Learning and the Academic Registrar. The institution has a large stake in this project, as evidenced by its high level of institutional contribution.

XCRI-CAP 1.2 standard is modified during the project after we have carried out significant development work on it, rendering some of our work invalid

1 3 3 Agree timescales for any changes with Programme Manager and adjust work packages as required to ensure the version is stable before undertaking significant development effort.

The XCRI-CAP team are not able to use JAXB with the XCRI-CAP XML schema

2 4 8 Working without JAXB would require more lines of code to be written and so would extend the time taken on the work package. Our risk mitigation in this situation would be to spend less time exploring the RESTian approach to generating an XCRI-CAP web service.

1.11 Technical Development IT Services at the University of Sussex have historically practiced a waterfall method of software development but are adopting a more agile approach of managing releases in time bound iterations to produce prioritised requirements in smaller tranches. We have a well-established framework for our projects that ensures the quality of the resulting deliverables. Each of the work packages will be managed as a (small) project within this framework. The framework itself is described below.



Requirements

Requirements will be gathered at the start of the work package or at iteration, using a standard requirements template.

Requirements are expected to be modified during the development life cycle as a result of feedback from users and as new requirements evolve.

Requirements are version controlled and signed off by the user or subject matter expert. Changes to requirements are subject to change control procedures.

Test plans and user documentation will be based on the requirements documents

For the XCRI-CAP and KIS workpackages, requirements are supplied through the XML schemas and associated documentation

Design

Technical design is documented in a standard technical design document template

The technical design is subject to a walk through by a group of peer developers to ensure quality and consistency.

Coding

Coding of the software solution will follow the design described in the technical design document.

Code is written to be self-documenting through the use of appropriate annotation.

Code is version controlled using appropriate version control software.

Code is modular and tests are created for each module.

Code is developed in an appropriate development environment.

Quality control and audit processes

Testing

Each work package project will define the testing approach and standards to be adhered to during the development process.

Unit testing will take place in the development environment and will be performed by the developer.

Unit tests will be documented in a spread sheet showing expected and actual results.

Once the code is successfully unit tested it will be released into a test environment, when it will be tested independently (by a business analyst or a tester) against requirements. This testing will take the form of system and integration testing as appropriate.

If appropriate the software will be load tested and (network) penetration tested. If appropriate the software will be subject to user acceptance testing. For XCRI-CAP 1.2 and KIS web services, the feeds will be validated against XML validators and using any specific validation tools issued.

All tests, results and faults will be recorded in test logs.

Required corrections will be recorded in change requests raised by the tester and assigned to the developer. Repeat tests will be carried out on all fixes. Test log entries will be cross-referenced to resulting change requests.



Following successful independent testing at a level suitable for the type of software, the code is versioned, and released into the live environment. Where appropriate, it will be made available from the project website.

Change control

The work package projects will be subject to the standard change control procedures currently in use for projects and software development.

A change request is recorded in the IT request tracking system; it is assigned a level of change – significant, major or minor. An order of magnitude estimate of the time required to make the change is included in the tracker ticket to support resource planning.

Depending on the impact of the change on the overall project it may require approval by the project team or the project board. The parameters to decide what level of change can be approved by which mechanism will be agreed at the outset of the project.

Configuration management processes

Software and documentation is base-lined and version controlled

Software and documentation is securely stored using CVS, Subversion or Source Safe depending on the type of software

Intermediate versions of software are retained

Changes to software and documentation are controlled, authorised, and auditable

Releases of software and documentation have been quality assured (i.e. tested, versioned, and documented).

Documentation

Each work package project will produce requirements, design, system and user documentation at the relevant stages of its life cycle

These documents will form part of the overall project deliverables

The documents will be versioned controlled and have appropriate sign offs included

The project will provide requirements, design, and system documentation, and submit documentation in the source format (e.g. Word, Excel, Visio) and as PDF

Information about the specific approaches and technologies to be used in the Course Data project is detailed in section 1.4 and 1.12, as well as in the work packages in appendix B.

1.12 Standards

Name of standard or

specification

Version Notes

XCRI-CAP 1.2 will be tested using the XCRI-CAP validator distributed as part of the Course Data Stage 2 programme

KIS KIS collection 2012/13

specified by HESA

JavaEE 6 programming environment

JAX-WS 2.1 SOAP services

JAXB JDK 1.6 XML binding



Name of standard or

specification

Version Notes

JAX-RS 2.0 REST services

EJB 3.1

RSS for dissemination of updates to project website / blog

SQL Oracle’s implementation of SQL standard

PHP

1.13 Intellectual Property Rights The University of Sussex will own the IP created by the project - all team members for the project will be employees of University whose work-related IP is already assigned to the University. We will use an appropriate open source license for any software that is released. Project documentation will be published on the project website with a Creative Commons license.

2 Project Resources

2.1 Project Partners

None

2.2 Project Management The project management framework for the Course Data project is represented in the diagram below:



There will be an overall Project Board, whose membership will comprise:

Chair: Professor Clare Mackie, Pro-Vice Chancellor Secretary: Sue Goodwin Members: Sharon Jones, Academic Registrar Marcus Williams, Director of Student Recruitment Rob Read, Director of Communications a Head of School (to be agreed) Iain Stinson, Director of IT Services Julia Darnell, Assistant Director IT Services with responsibility for Corporate Information Systems Carol Shergold, Head of Learning Systems Course Data project manager Jane Major

It is envisaged that the project Board will meet five times during the project: at Project Inception (ideally in December 2011); to approve the project plan during January 2012; aligned with the dates for the production of interim report; and at the end of the project. Additional meetings would be arranged if required. There will be a Project Team whose core membership will comprise:

Chair: Project Manager Carol Shergold Julia Darnell Iain Stinson

The Project Team will meet monthly. Its main role will be to coordinate and oversee the activity of the work package projects, and to undertake appropriate communications. Notes from its monthly meetings will be shared on the project blog and will be made available to the Project Board. Sharon Jones, the Academic Registrar, will manage work package 1. This will ensure that the required changes to policy and procedures are taken forward at the appropriate level within the University. Work packages 2 to 6 are focused on technical delivery. Each of these technical projects will be managed as a standard small project within the IT Services project governance framework (see section 1.11 for detailed description). We believe that this will offer a robust method of ensuring that the required work for the Course Data project is properly resourced and embedded within the institution. A new developer and business analyst will be recruited to enable IT Services to increase its general level of capacity and so free up sufficient resource to staff the technical work packages. The Project Team will liaise with staff working on the work packages, and bring them into meetings appropriately.

2.3 Project Roles

Team Member Name

Role Contact Details (all

@sussex.ac.uk)

Days per week to be spent on

the project

Professor Clare Mackie

Pro-Vice-Chancellor for Teaching and Learning. Key stakeholder for Course Data

C.A.Mackie 5 days over whole project



Team Member Name

Role Contact Details (all

@sussex.ac.uk)

Days per week to be spent on

the project

Sharon Jones Academic Registrar Sharon.Jones 8days over whole project

Iain Stinson Director, IT Services manages overall resource to deliver technical aspects of project

Iain.Stinson 10 days over whole project

Julia Darnell Associate Director, IT Services manages resource to deliver technical aspects of project

J.Darnell 10 days over whole project

Jane Major Project Manager j.f.major 2,5 days/week

Carol Shergold Head of Learning Systems, Project Director

C.Shergold 0.5 days/week

Rob Brownsell Business Applications Developer XML, web services

R.J.Brownsell contribution will be back-filled

to be agreed Head of School 5 days over whole project

Project roles within the work package projects will be allocated flexibly at the time of work package project inception (see explanation in section 2.2 above). The roles specified here are broadly non-technical, and are required for stakeholder liaison and to support change management. Professor Clare Mackie, Pro-Vice-Chancellor, Teaching and Learning Clare Mackie has been described as a transformational leader in HE, following a 16 year career in private practice. In 1998 Clare was appointed as the youngest Professor and Head of School of Pharmacy at the Robert Gordon University, the oldest School of Pharmacy in the UK. Innovation in teaching and learning received international recognition in 2000 by Clare being invited to establish the first World Health Organisation Collaborating Centre for Pharmaceutical Care and Curriculum Development, with responsibility for Africa and the newly independent Russian States. In 2004 Clare moved from the oldest School to establish a new School of Pharmacy at the Medway Multiversity Campus (a partnership between Kent and Greenwich) The School achieved early success and a national reputation for the quality of its students, its innovative portfolio of courses and student satisfaction of 98% in its first NSS. From 2007-10 Clare was Pro-Vice-Chancellor at Kent with responsibility for the Medway Campus and the student experience across all Campuses, with the Campus growing to over 10,000 students (6,000 FTEs) and Kent achieving top NSS scores over this period. In 2010 she joined Sussex to help deliver ‘Making the Future’ and has embarked on a major transformational change project to review the academic portfolio and restructure the academic year to meet student expectations in time for the new 2012 fees regime. Sharon Jones, Academic Registrar Sharon has recently joined the University from the University of Cork where she held a similar appointment; before joining Cork, Sharon was a senior member of the registry at the University of Brighton. She brings considerable experience in designing and implementing effective management processes within student and course administration. Iain Stinson, Director of IT Services Iain Stinson’s background is in computer science and he has held senior management roles in university computing services for more than twenty-five years. He has led a number of JISC projects and has participated in the management of JISC projects undertaken by colleagues in his department / institution. Iain is presently a member of the policy committee for the UK Federation (access management).



Julia Darnell, Assistant Director IT Services (Corporate Information Services) Julia Darnell is responsible for the strategic development of the University’s Corporate Information Services. Julia has worked at Sussex for 3.5 years and has played a significant part in the University’s adoption of new business systems (and processes). She has considerable experience in IT from previously work in both local government and the private sector. Carol Shergold, Head of Learning Systems Responsible for strategic development of the University’s VLE and other e-learning tools from a technical perspective. Led the JISC-funded MINTED and XMarks projects, also involved in the JISC-funded SPLASH project and co-led the SkillClouds project. Rob Brownsell Worked with other colleagues at the University to introduce a standard platform for producing web services from within business application services. Many of these services are now critical to the functioning of key systems within the University and include PBS, passport scanning, programmes and courses information (service fed to main web site), student data upload (for University partner institutions) and integration with our new finance system. The platform is based on the Java EE stack (primarily using EJB technology). Prior to this, Rob had experience of producing web services using other technologies such as Apache AXIS and took part in a number of projects where web services were used to integrate systems. Training needs An early task of the Online Approvals Workflow Management project will be to determine how to implement a workflow engine. Increased awareness of Enterprise Architecture and Service Design could be useful here. The project manager and business analyst will need training in the fundamentals of XCRI-CAP and KIS. Rob Brownsell, who is taking a lead on the development of the XCRI-CAP feed, will need to take part in in-depth technical training or peer skill sharing on XCRI-CAP. Members of the work package team focussing on the KIS will need to attend the various briefing events and training days that are being organised nationally to support this initiative.

2.4 Programme Support The team would appreciate support from the Programme team and from other peer projects in interpreting and working with the XCRI-CAP and KIS standards. We would appreciate any advice and support on our project, such as project health checks. We would be interested in joining up with any locally based projects to offer each other peer review, and welcome the Programme team facilitating this.



Detailed Project Planning

3.1 Evaluation Plan Evaluation for this project will be managed internally using our existing processes for project governance. If the overall Programme Support team introduce a system of peer review within the strand, we would be keen to take part in this, particularly to provide feedback on our externally facing material.

Timing Factor to Evaluate Questions to Address Method(s) Measure of Success

Policy Has the institution adopted a policy regarding external access to XCRI-CAP data?

Review policy Policy exists

Policy Has the institution adopted a policy on whether or not to charge for XCRI-CAP data?

Review policy Policy exists

At interim review and end of project

Policy Has the institution improved its readiness for a sound XCRI-CAP implementation?

Re-run XCRI-CAP self-assessment exercise

Score improves

Course Data Synchronisation tool

Does the feed create valid records in the SRS?

random testing

newly created records in SRS match those in the Course and Module Design system

XCRI-CAP and KIS data feeds

Does each feed provide correct data on University courses?

random testing

data in feed matches information available from other sources

XCRI-CAP v1.2 data feed

Is XML structure of feed compliant?

use supplied validator

feed is compliant

KIS data feed Is XML structure of feed compliant?

use supplied validator

feed is compliant

XCRI-CAP and KIS web services

Does web service introduce any new attack surface?

penetration testing

no new attack surface can be identified

Project board meetings

Overall progress Is the project delivering intended outputs in a timely fashion?

Project Board monitors progress

Milestones achieved

3.2 Quality Assurance

Output / Outcome Name

Policy and procedures

When will QA be carried out?

Who will carry out the QA work?

What QA methods / measures will be used?

Ongoing Academic office Review of draft policy

At committee stage Relevant committee Scrutinising policy prior to adoption




Course data synchronisation tool




During development process

Business analysts, testers and developers, coordinated by PM

Standard approach described in section 1.11

After release PM Review number of change requests needed to fix faults post release

Ongoing Peer reviewers or “critical friends”

Documentation will be reviewed


XCRI-CAP v1.2 web service and feed with COOL URI






Standard approach, described in section 1.11,


Network penetration testers Penetration testing to identify any flaws in system security

Ongoing Peer project reviewers or other "critical friends"


Towards end of development process

Peer project Peer reviewers will download and install code


Key Information Set (KIS) web service and feed






Standard approach described in section 1.11


Network penetration testers Penetration testing to identify any flaws in system security

Ongoing Peer project reviewers or other "critical friends"



Project plan




Project board meeting in January 2012

PM will validate the project plan using JISC documentation.

PB will review and sign off the plan

ongoing PM will update plan as required

PB will review and sign off the plan



3.3 Dissemination Plan

Timing Dissemination Activity Audience Purpose Key Message

Ongoing Internal dissemination Internal stakeholders

Briefing sessions Updates with progress

Towards end of project

XCRI-CAP web service code made available

Other education institutions

To reduce development effort required in other institutions

Implementation of XCRI-CAP

3.4 Exit and Embedding Plans

Project Outputs/Outcomes

Action for Take-up & Embedding Action for Exit

Business process enhancements and changed institutional practices

Internal dissemination, adopted policy

Institutional documentation

Internal deployment of: Synchronisation * XCRI-CAP web service * KIS web service

All of these outputs have been developed within the institutional business systems of the University, and so will be taken up and embedded in the normal way

Normal ongoing maintenance of university business systems will ensure sustainability

XCRI-CAP code available for download

Agree on online code repository to use

Ensure code is available in online code repository

KIS code available for download

Agree on online code repository to use

Ensure code is available in online code repository

Documentation from development of software tools, reports, other documentation

Ensure documentation is available on project web site

Retain project website as agreed with JISC

3.5 Sustainability Plans Please see section 3.4 which covers sustainability



Appendices

Appendix A. Project Budget provided as a separate Excel file Budget Overview Sussex 8-11 Course Data FINAL.xlsx

Appendix B. Workpackages provided as a separate Word file Work Packages Sussex 4-12 Course Data Stage 2 Revised.doc

Documents

JISC Project Plan Template - Sussex Blogsblogs.sussex.ac.uk/coursedata/files/2013/03/Project-Plan-Sussex-2…Page 1 of 20 Document title: Project Plan for University of Sussex Course