Closure Report
Project Summary
The primary aim of this project was to upgrade the outdated version of Grouper (v.2.2) that the University had been running to v.2.3.0 as part of compliance.
Scope
The scope of the project was limited to upgrading the previously active version of Grouper to the latest published release. As part of this upgrade DEV/TEST and LIVE environments were each to be upgraded. It was also necessary to instigate communications with owners of downstream services to advise them of any likely impact or modifications brought about by the upgrade.
Analysis of Resource Usage:
Staff Usage Estimate: 68 days
Staff Usage Actual: 90 days
Staff Usage Variance: 32%
Other Resource Estimate: £0
Other Resource Actual: £0
Other Resource Variance: 0%
Outcome
Ref. |
Objectives / Deliverables |
Success Criteria |
Priority |
Outcome |
O1 |
Upgrade to new version |
Version 2.3.0 installed and working as specified
|
Must have |
|
D1 |
Upgrade DEV/TEST and LIVE to V2.3.0 |
Systems upgraded, working and support upgraded Grouper application |
Must have |
Achieved |
O2 |
Manage communications with stakeholders |
|
Must have |
|
D2 |
Produce a viable communications plan |
A viable communications plan |
Must have |
Achieved |
D3 |
Delivery of a communications plan to stakeholders |
Stakeholders engaged in line with plan |
Must have |
Achieved |
O3 |
Leverage Benefits of new core functionality |
|
Must have |
|
D4 |
PSP Configuration and performance improvements |
Missing dynamic in Central Auth and AD feeds resolved A sync test between versions will be benchmarked to ascertain and prove performance improvement. |
Could |
Delivered but see 'issues' below |
D5 |
Better and more useful UI |
UI Extension to allow Attribute and Inheritance Configuration in use |
Could |
Delivered but see 'issues' below |
|
|
|
|
|
Explanation for variance:
-
Effort
As can be seen from the figures above, the overall effort increased upon the original estimate of 68 days to a total of 90 days. This initial estimate was made as part of the planning stage (November), and was re-estimated again in January as the project moved to integration. However, another estimate was carried out in late February and this produced a new total of 90 days. This was adjusted as part of the issue raised at this time to seek approval of the increased budget. The main reason given was that the project burn rate had already 'over-used' 11 days of the project budget, and that this, allied with effort required for the outstanding work at that point, meant the project needed an extra 22 days.
The following table shows a breakdown of estimate v. actual for each stage. This shows that the additional effort was required for acceptance and rework (after the build work), although the project team have subsequently reported that less time was given for formal UAT, and the additional time in this stage was for peer testing; for unplanned effort, and for project management time. This latter is attributable to the project being extended:
Stage/Task | Estimate (days) | Actual | Difference |
---|---|---|---|
Project Management/QA | 21 | 27.5 | 6.5 |
Planning | 9.5 | 10 | 0.5 |
Build | 8 | 5.5 | (2.5) |
Integration | 13.5 | 8.5 | (5) |
Acceptance/Rework | 7 | 16 | 9 |
Deployment | 7 | 9.5 | 2.5 |
Unplanned | 0 | 11 | 11 |
Closure | 2 | 2 | 0 |
Total | 68 | 90 | 22 |
-
Time
There was two delays to the original dates indicated at the initiation of the project. The first of these a delay of about six weeks to the Planning milestone. This was attributable to the demands for project management resource earlier in the financial year. The second delay was because of the extra work (see above) that the acceptance testing and rework added to the project timeline and this added several more weeks to the anticipated milestones, with an eventual delivery of the upgrade into LIVE at the beginning of May.
-
Scope
There was a change to the scope, as the work to migrate the configuration from PSP to PSP-NG was descoped early on in the project. This ultimately turned out to be more difficult than expected due to a lack of documentation on the Grouper site and a couple of show-stopping bugs in the PSP-NG code, mostly around handling group names with non alpha-numeric characters (in particular "+", "," and "\"). Fortunately it transpired that we could still use the PSP connector and config from our Grouper 2.2 setup. This is something that we might want to look at again in future upgrades but it should be classed as a separate unit of work and with hindsight we would need to allocate more man-hours to this work than we had currently although our estimate was based on previous upgrades and the previous migration to the PSP configuration during the Grouper 1.5 -> 2 upgrade.
Key Learning Points
Grouper configuration - see the notes above concerning the change of scope that removed the configuration from the scope of this upgrade. It is recommended that any future looks at this part of the work, and that moving to PSP-NG might be a project in itself.
The project team are also in agreement that it would be good practice to establish a patching strategy for Grouper. This could also be enhanced by having more frequent upgrades.
THe project team did not receive any great levels of support from the Grouper community. This should be borne in mind for any future work so that there is no dependency or overly high expectation with regard to this.
Outstanding Issues
Deliverable Ref: D4
This deliverable was poorly worded, but it refers to an issue whereby the real-time psp did not appear to be synchronising new groups until they had members which would hopefully be resolved by the upgrade. In the event, the issue occurred during Integration testing and on investigation it was discovered that it actually relates to a timing problem whereby there is a 5-second window every 5 minutes during which new groups can be synchronised with Central Auth before a separate Grouper task has had time to assign the group its globally-unique identifier. This confirmed that the issue is not actually a Grouper bug. It has been raised as an IDM/Grouper Issue.
Deliverable Ref: D5
Again, this deliverable was poorly worded, but it means that post-upgrade, the new UI Attribute Inheritance feature will be in active use. The feature was tested during UAT. It is also undergoing its first live usage via Unidesk call I180516-0436.