Overview
Background
The Scientia Enterprise applications (Enterprise) are the University's chosen application suite for providing a centralised Timetabling service.
The Timetabling programme is now focused on the business-as-usual project activity to maintain and deliver small enhancements to fine tune the Timetabling service available to staff and students.
Scope
This project will focus on delivering the high priority enhancements identified for 2014/15 by the Timetabling Unit team in partnership with Programme Owner, IS Apps Management and Project Services.
Four enhancements have been marked as high priority at the time of writing the brief. The first three will be funded by TTU Programme, the 4th will be out of scope until estimated and budget agreed with College of Science and Engineering to transfer the days.
1. Deliver new SPDA v2 (E1)
What
The main aim of the project is to install a new version of the Timetabling SPDA software.
Why
The current Timetabling process has limited performance capacity and high support costs. The new version of the SPDA promises:
- more stability
- increased automation of tasks
- performance improvements
How
We will develop a test harness which will be used to measure and compare the performance of the current and new versions of the SPDA.
Risks
- the new version may not deliver the expected benefits
- current performance issues may be related to other components
- the new version may introduce new problems
The project may have to make a decision not to implement the new version and restore the Test and Dev environments to their original state.
Deliverables
- test harness to measure performance
- upgraded SPDA
- performance report
- information to inform the processes required to handle the start of term load
Success Criteria
- increased performance – Production Management to define
- reduced support costs – Production Management to define.
Estimates:60d.
Delivery in Feb 2015 (it is required before March 2015 when the roll forward is switched over to 2015/16).
2. Learn feed (E2)
A data feed from the Scientia Reporting Database to Learn has been deployed in 2013 as part of STU226. A new building block has been developed but remains in Dev because of deployment issue with Dev Learn.
The new build has already been completed and needs to be deployed.
Estimates 5d
Dependency: issue with Learn in Dev environment stopping from deploying. This is to be investigated by Apps Support, outwith this project's scope.
3. Other SPDA refinements (E3)
The list of three refinements will be reviewed after the SPDA 1st enhancement has been delivered. At the time of writing the brief, they were:
a-Programme data against student set. Scientia will advise what the mapping is.
This will fix the load of programme of study for students. It should be a small task to update the SPDA Link Definition, and needs input from Scientia. The data is already in EUCLID and in SAT (Shared Academic Timetable) stage table. Configuration only is required. Need to add destination to the Syllabus Plus database (SDB).
b-Reducing number of SPDA feeds.
There are currently 2 feeds from IDM and EUCLID. This carries the risk of conflicts and duplications of student data sets (one with course enrolment and one without). When duplication occurs, it requires ad hoc manual reconciliation by Timetabling Unit/Production.
c. Change IDM data source to EUCLID. Note this is to be put on hold until the Roll Forward has been completed in March 15.
Current issue: the EUCLID feed to IDM only presents current student information, Timetabling requires future student information, e.g. SITS SCE record is created with a future start date that relates to the academic year that Timetabling are planning. As such IDM is a bit late in presenting information. This would require a new view in EUGEX and a slight re-wiring of the staging tables in Timetabling (SATSTAGE) but would present student information as soon as it is available. By adding academic year into the EUGEX view it would be possible to move the student sets generation from the Non-Academic SPDA to the Academic SPDA removing the chance of duplicate student sets being created.
If the data source could not be done, the synchronisation could be achieved via a manual load.
Delivery of the SPDA refinementswill be done as per remaining budget and prioritisation with sponsor.
4. XML data feed for schools (E4)
Schools across the university use a variety of timetabling data to fulfil their existing business processes. The Shared Academic Timetabling project has delivered a centralised timetabling system, and there is a requirement for a feed of data held within this system for consumption locally within the schools. XML has been identified as the preferred format for this data.
Full funding would come from the College of Science and Engineering. This will dealt with by a new scope if the funding is agreed (estimates being provided to CSE).
To start in Feb 2015.
Objectives/ Deliverables
Reference | Details | Priority |
O1 | Install and deliver new SPDA v2
| Must |
D1 | Agree benchmark: test harness to measure performance
| Must |
D2 | Upgrade SPDA to version 2
| Must |
D3 | Performance Report
| Must |
D4 | Document process to handle next term load
| Should |
O2 | Deploy feed for Learn from the Scientia Reporting Database
| Must |
D5 | Deploy the last updated building block to Learn from Dev, Test and Live Timetable database.
| Must |
O3 | Other SPDA refinements (D6 is the highest priority)
| Should |
D6 | Programme data against student set.
| Must (higher than D7/8) |
D7 | Reducing number of SPDA feeds. | Should |
D8 | IDM change of data source to EUCLID. | Should |
Out of Scope
·Objective 1: only issues related to Scientia SPDA will be addressed.
·Objective 2: only issues to Lean feed from Timetable will be addressed. Issue with non-Live Learn will have to be managed separately. Assume that issue on Dev Learn will be managed by Apps Man so that Dev can then be aligned with Test.
Benefits
Objective 1
1 | Performance improvements |
2 | More stability of existing Scientia product |
3 | Reduce manual effort: failure of the current SPDA costs IS Support days. From beginning August to mid-October IS Production has spent 29 days on SPDA issues. The rebuild of the database early October is showing better performance of the current SPDA though. |
Objective 2
1 | Timetable data related to jointly taught and variant activities are in line in Learn. They are currently keyed in manually by Timetabling Team for 4 to 5 schools using Learn for tutorials. This could require more work if other schools decide to use Learn for timetable. |
Objective 3
1 | Staff can see the student’s programme of study. |
2 | Reducing the number of data feed will remove duplicates. This will reduce Production overheads and resource on the server (which takes substantial space). |
3 | The students’ course details (school, programme of study, student name) are available as soon as the data is available in EUCLID (students are rolled forward end June), enabling better allocation within schools. |
Success Criteria
Ref | Deliverable Reference | Description | Measure |
1 | D1, D3 | Increased performance: at the moment it fails when there are over 1,000 records in the queue to be processed | Handle bigger load than 1,000 |
2 | D1, D2, D4 | Reduced support costs. They were 29 days recorded by IS Production between August and mid October. | Production to define |
3 | D5 | Timetabling Unit does not need to key in jointly taught and variant activities. |
|
4 | D6 | The students’ programme of study is displayed | Displayed in Student Set table and in activity template allocation editor |
5 | D7 | Fewer duplicate records are created. | Timetabling can measure against 14/15 duplicate data |
6 | D8 | Staff can see the students’ course details data earlier from beginning July. |
|