1 / 13

Testing Resourcing H1 2008

Testing Resourcing H1 2008. Q4 2007 / Q1 and Q2 2008 Resourcing - Assumptions. End of year resource position is BDC – 12 resources INDIA – 15 resources Onshore – Chris/Ajay

foy
Download Presentation

Testing Resourcing H1 2008

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Testing Resourcing H1 2008

  2. Q4 2007 / Q1 and Q2 2008 Resourcing - Assumptions • End of year resource position is • BDC – 12 resources • INDIA – 15 resources • Onshore – Chris/Ajay • ANZ regression for SPU conducted by BDC / AU 4.3 testing conducted by BDC i.e. no PCA involvement in 08 (needs to be confirmed with local AU management) • Activity Set for 2008 is as follows: • Support Pack Upgrade • R4 GSS patches 16, 17, and possibly 18 • Release 4.3 (R4.2+SCR’s+3.3 content+R4.2 patches) • Product Test on AU and UK – first time on R4 codeset • Regression Product Test on US / NZ for 3.3 content plus any AU / UK fixes • ITC on AU and UK – major activity, first time on R4 codeset • Regression ITC on US / NZ • R4.3 patches assumed to fall into Q3

  3. General • Are we really in a position where we can assume we will be able to have a constant resource profile going forward? • What happens after R4.3 currently? Only known activity set is R4.3 patches then a next release c. 6 months later • Resource implications on other areas of the project - Retalix? Ops Arch? Design? Need to ensure that a test-view is supportable by other areas of the program.

  4. 4.3 Option 1 – All countries tested concurrently

  5. 4.3 Option 1 – All countries tested concurrently • Assumptions • Testing of 4.3 can’t start until May as will be in build until end April • PT / ITC for 4.3 for AU and UK is substantial as first time on R4 codeset • Regression test for US / NZ for 3.3 functionality introduced plus SCR’s – patch content has been tested as deployed • Pro’s • Economies of scale - testing all countries in parallel is most efficient in terms of overhead e.g. defect management, test management, as is spread across largest activity set and overall duration of test phase is shortest from beginning of first country to completion of last country. • Gets us to goal of common codeset for all countries the soonest of any option – end of June • Least complex in terms of code management – single version of code, common patches, regression testing happens real-time • Con’s • Resource profile suggests a ramp-down for Q1 followed by a ramp-up for R4.3 testing • Peaks at 20 BDC resources • Large excess capacity in BDC between early March and early May assuming can’t ramp down and up again • Has the most parallel activities of any option – though not as bad as R4 and manageable • Open Questions • Could suppliers achieve this ramp-down / ramp-up, and at what cost? • Would this result in different rates being applied – Doug has indicated that contract rates are long-term and he doesn’t believe this profile would be in the spirit of this arrangement • Is this viable from a deployment/deployment support perspective to go live simultaneusly? • What about Retalix capacity to support this level of effort?

  6. 4.3 Option 2a – US / NZ then AU / UK

  7. 4.3 Option 2a – US / NZ then UK /AU • Assumptions • Testing of 4.3 can’t start until May as will be in build until end April • PT / ITC for 4.3 for AU and UK is substantial as first time on R4 codeset • Regression test for US / NZ for 3.3 functionality introduced plus SCR’s – patch content has been tested as deployed • Pro’s • R4.3 to US / NZ by mid-June • Less moving parts than option 1 • Con’s • R4.3 to AU / UK at end July • Resource profile still ramps down Q1 as with option 1, and then still ramps up as with option 1, only ramp-up is later and not so steep • Larger excess capacity in BDC than option 1?( because if we don’t ramp down the larger team size is required later) • Longer overall test phase duration – overhead cost increases as a result of extended duration • Less ‘clean’ in terms of codelines – a version into production for US / NZ while version still in test. Any production fixes need to be carried forward and any test fixes regression tested. • Open Questions • Is end July for R4 to AU/UK palatable to the respective businesses? • Is the ramp-up of resources for AU/UK achievable by suppliers given that things are unclear beyond July and it is likely to be a ramp-down subsequently?

  8. 4.3 Option 2b – UK /AU then US/NZ • Assumptions • Per Option 2a • Can’t accelerate by retaining higher AU/UK headcount because PT duration is planned to coincide with the duration of ITC, and it is limited how much you can condense duration of ITC by throwing bodies at it • On that basis, timelines are per option 2a - UK/AU by mid-June, US/NZ by late July

  9. 4.3 Option 3a – As per 2a but with constant resource profile

  10. 4.3 Option 3a – As per option 2a but with constant resource profile • Assumptions • Testing of 4.3 can’t start until May as will be in build until end April • PT / ITC for 4.3 for AU and UK is substantial as first time on R4 codeset • Regression test for US / NZ for 3.3 functionality introduced plus SCR’s – patch content has been tested as deployed • Pro’s • Smoothest resource profile (only small rampup of 2FTE)– capacity-based planning. • R4.3 to US / NZ by mid-June as per option 2 • Less moving parts than option 1 • Con’s • R4.3 to AU / UK early September • Longer overall test phase duration – overhead cost increases as a result of extended duration • Less ‘clean’ in terms of codelines – a version into production for US/NZ while version still in test. Any production fixes need to be carried forward and any test fixes regression tested. • Open Questions

  11. 4.3 Option 4 – Move R4 PT left for AU / UK • Assumptions • Test on R4.2 + P16 with AU / UK config applied • Pro’s • Shift risk left by testing earlier for AU / UK • Smooths resource profile • Con’s • Ops Arch unable to have build for us to test on until March. Doesn’t help with period of under-utilisation in Q1. • How valid is this testing given level of change on top of product we are testing? It will not contain patch 16, SCR’s, or 3.3 content carried forward. • Larger overall test effort – early testing plus required regression testing on the final version of the code is greater total effort than testing once on 4.3 proper • Open Questions

  12. Summary

  13. Recommendation • Preferred approach is to look at option 2a or 3a • Moves us towards long-term capacity-based model • Team size ‘feels’ right

More Related