Closure Report
Project Summary
This project aimed to upgrade the SITS system to version 9.7.0 (from 9.5.0) so that the University remained within the maintenance agreement with the software supplier, Tribal. There is always time-pressure on the project as there is only a very limited window in which the LIVE upgrade can be delivered, and this requires a deployment out of hours in order to minimise impact on the wide user-base.
The process is well-understood by an experienced team whose knowledge and commitment once more ensured that the project was delivered on-time, well within budget and with minimal impact to users and to other projects operating in the SITS environment.
Although one of the developer was a new addition to the regular team, he performed extremely well with the excellent support of the regular team and the documentation which has been built up by previous projects. In addition the lead tester took on additional responsibility, including managing the testing team during regression testing, and performed extremely well. The support analyst and technical architect are now very experienced resource for the project team and have the confidence from the heads of production management & Dev services in this role.
Objectives
| Objectives | Priority | Achieved Y/N | Comments |
|---|---|---|---|
|
Must |
Y | |
|
Must |
Y |
|
|
Must |
Y |
|
| 4.Allow sufficient time for testing to reduce chance of critical post-go live issues | Must | Y |
|
| 5. Minimise overall time duration of the upgrade project - so that there is minimal disruption to other project work (ie. quick back-to-back deployments into DEV / TEST / LIVE) | Should | Y |
|
Deliverables
| Deliverables | Priority | Achieved Y/No | Comments | ||||
|---|---|---|---|---|---|---|---|
|
Must |
Y | |||||
|
Must |
Y | |||||
|
Must |
Y | |||||
|
Must |
Y | |||||
|
Must |
Y |
All high, medium and most low priority tests were completed in the initial 3 week window with the exception of the Fees work which contained high and medium priority tests only, which were completed within the 5 weeks. |
||||
|
Must |
Y | |||||
|
Must |
Y | |||||
|
Must |
Y | |||||
|
Must |
Y | |||||
|
Should |
No | |||||
|
Must |
Y | Issue reported in Test was related to the database upgrade project /optimisation configuration was outstanding which we fixed | ||||
|
Could |
No | Being progressed as part of Data Futures project | ||||
|
Must |
Y | |||||
|
Should |
No | Partially done- There was not enough testing resource to do this. For next year plan 3 weeks effort prior to the upgrade in test |
Benefits
| Objectives | Achieved Y/N | Comments |
|---|---|---|
|
Y | |
|
Y | No major one- only small functionality added (i.e. roll back, small changes in clients...) |
|
Y |
|
Additional benefits
-Urmon session restart is now running hourly (was only running it manually). This should improve performance.
-Issues raised and related to existing issues (not upgrade related) were fixed as part of this project.
Analysis of Resource Usage:
Staff Usage Estimate: 200 days (based on previous year effort)
Staff Usage Actual:210 days broken down as follows 97.5 SSP IS days, 112.2 non SSP IS days
Other Resource Estimate: SSP BA & tester- n/a
Other Resource Actual: SSP BA & tester: 81.4 days
Other Resource Variance: n/a
Outcome
Explanation for variance
-The project team did not encounter many issues. Only issue was performance during testing and reported on pciccl 2 LINK
-Noted that non upgrade related issues were addressed as part of this project and increased the effort.
Key Learning Points
1. Live upgrade
-upgrade procedure should be kept as clean as possible (limit to mandatory tasks only) as there is a short window to do it over the week-end. Ensure to do all prep work before the week-end, or move some non -upgrade tasks post upgrade
-proposal to look at improving the procedure for software updates . Scope for addressing this in the RedHat server upgrade (initiated project SAC080). Other option is to apply them in 2 batches: 1st Dev/test, then Trn/Live
-Communication to users: clarify that the Streams updates - the longest downtime- are not required to open SITS to users. There are no expected risks.
-check in advance that all staff have the same access/view so that there is consistency when checking post live changes
2.Dev /Test/ TRN upgrade
N/a
3.Regression testing
-Comment about daily stand up and use of white board- The whiteboard was used effectively but we were limited by non attendance of the stand ups by several key members of the testing resource. It gave us a good visual of progress or the lack of it throughout.
-Single point of failure for testing- ex: fees which requires 3 week of effort to test. It seems this is accepted due to shortage of staff. This is an on going risk worth reported on that project. Mitigation would be to secure resources from the business or another BA to shadow the experienced BA during the regression testing or to invest into more automated testing.
-Invest into transferring all test cases into TestRail at the start of the next project
-Tests were well prioritised and assigned across team members, good coordination from lead tester
-Duration and costs of doing the regression testing : 5 weeks, 50 days effort- This resulted in around 12 issues raised (jquery upgrade related, existing issues)
4. Refresh
Plan is to have one procedure (taken forward as part of Euclid support, see outstanding jira below)
What went well
Overall this year upgrade went very smoothly
The team: this project illustrates the good collaboration between SSP, student systems Operations and IS Apps over two locations:
- team communication worked well with a combination of online chat (Slack) and weekly progress meeting
- team roles were well defined and adhered to, including good engagement from the business represented by student systems operations
- transfer of knowledge to new SSP Dev lead achieved
Outstanding Issues
There are no outstanding issues. However the following JIRA has been kept open, in order that they can be more appropriately picked up by the next SITS upgrade project in 19/20.
- SAC076A-94 - Yellow screen of death when accessing e:Vision via bookmark
And as part of Euclid support:
- SAC076A-99 Hesa Streams need rebuild- This is a support issue and will be dealt as part of Euclid support work. Dev Tech lead to be assigned
- SAC076A-98 review sits refreshes - Not upgrade related. required for the next refresh to review the refresh procedure - Dev Tech lead /SSP dev to coordinate. Part of Euclid support work
More general business issue:
SAC076A-77 RDE table UDFs are duplicating the entity fields (what's the policy if UDF s are changed by supplier and impact processes)