The Contractor’s Solution Sample Clauses

The Contractor’s Solution the technical proposal from the Contractor which sets out an overview of the proposed solution supported by the necessary detail of the Contractor’s response to the Authority’s Requirements The Contractor will provide services to assist the Authority to initiate the IdAMS Delivery Project. As part of this work the Contractor’s team will: Work with nominated representatives of the 5 projects identified in Section 1.1 above to identify, clarify, agree and baseline a consolidated set of functional and non-functional requirements for extensions to the existing IdAMS solution. These will documented in a Requirements Matrix (D1) which will be reviewed with representatives of the consuming projects and approved by the Authority’s IdAMS Project Manager Investigate the status of the existing IdAMS solution in the DTE, VOTE and LIVE environments, identifying any remedial work to both environments and solution that may be necessary prior to beginning work on extending the IdAMS solution. The team will also identify changes to the environments, solution and supporting documentation required to meet the consolidated functional and non-functional requirements. The output of this work will be documented in an IdAMS Design review document (D2) Produce a Delivery Approach and Governance Plan (D3) defining the overall project approach to delivery including: Project governance Roles and resources Requirements management Risk and Issue management Change control Communications. Produce and maintain a high level Project Plan (D4) for the initiation phase Produce and maintain a Risks, Issues, Assumptions and Dependencies Log (D5) for the initiation phase Investigate the cause of the ADFS issues identified with the implementation of the current IdAMS solution in Live and provide recommendations Work to identify any additional remedial or implementation work that may reasonably be progressed in advance of completion of Project Initiation. Any such work to be agreed with the Authority via a FSC Change Note prior to execution.

The Contractor’s Solution the technical proposal from the Contractor which sets out an overview of the proposed solution supported by the necessary detail of the Contractor’s response to the Authority’s Requirements 1) Two new wizard screens shall be created to allow users to be mapped to one of the new organisation groups 2) Changes shall be implemented to the User Details and User Summary screens to show the new organisational drop downs 3) Amendments to the LSC Security Database shall be made to support the 2 new organisational groups 4) Changes shall be made to extract the new organisation master data from PIMS/CPDS The changes shall be tested according to the Test Plan and Test Approach as per section 1.2. The changes shall be implemented as a maintenance release in accordance with the Release Plan as per section 1.2 The Contractor shall produce or update the following deliverables: Work Package The Functional Specification The Test Approach The Test Plan Detail Design SIT Scripts SIT Report OAT Plan OAT Report Release Plan The Application Overview Document (AOD) Post Implementation Support End of Project Report It is important to recognise that these changes will need to be co-ordinated with other LASS changes and which may have an impact on the overall timelines proposed as per section 3.3. A maximum period of 4 weeks is included for PIS at which point a decision will be made by the Authority and Capgemini to either exit PIS or back out the system and continue UAT or Operational testing. Dependencies: SFA to populate new agency structure in PIMs. Details of structure will need to be available by 15/05/2012 New structure will need to be implemented in PIMs by 22/05/2012 Capgemini will import new PIMS structures into the test environments Assumptions: Authorisation from the Agency to commence will be given by 21/05/2012

The Contractor’s Solution the technical proposal from the Contractor which sets out an overview of the proposed solution supported by the necessary detail of the Contractor’s response to the Authority’s Requirements Removed as reserved information Removed as reserved information Removed as reserved information Removed as reserved information Removed as reserved information Removed as reserved information Removed as reserved information Removed as reserved information Removed as reserved information Removed as reserved information Removed as reserved information Removed as reserved information Removed as reserved information Removed as reserved information Removed as reserved information Removed as reserved information Removed as reserved information Removed as reserved information Removed as reserved information Removed as reserved information Removed as reserved information Removed as reserved information Removed as reserved information Removed as reserved information Removed as reserved information Removed as reserved information Removed as reserved information Removed as reserved information Removed as reserved information Removed as reserved information

The Contractor’s Solution the technical proposal from the Contractor which sets out an overview of the proposed solution supported by the necessary detail of the Contractor’s response to the Authority’s Requirements Please refer to the: Implementation and Testing Contractor’s Solution [Ref.: 5] and the Course Directory and Learner Passport Integration Design Contractor’s Solution [Ref.: 6] An objective of this FSC is to minimise the risk of performance issues in the live environment following the deployment of the NCS web portal onto the B2C Platform. Subject to IM Services approval, it is planned that this risk will be mitigated by performing indicative performance tests in the newly built B2C environment in live. The capacity of the test team has been designed based on approximately 300 Test Scripts and 3 Test Cycles.

The Contractor’s Solution the technical proposal from the Contractor which sets out an overview of the proposed solution supported by the necessary detail of the Contractor’s response to the Authority’s Requirements 1.1 is an enabler to other programmes or projects the dependencies will be logged in the dependency log and pro-actively managed. The Target milestones and Target Dates for the Delivery phase are given in Section 3.3. The mapping of deliverables to the Service Gates can be confirmed as:

The Contractor’s Solution the technical proposal from the Contractor which sets out an overview of the proposed solution supported by the necessary detail of the Contractor’s response to the Authority’s Requirements 1) BRS (for handover to LARA 1.1 Project) RMADS meeting review with the Data Service Data Management 12/13 Functional Specification Issued for Review Online Systems 12/13 Functional Specification Issued for Review Amalgamation 12/13 Specification Issued for Review (on behalf of the IA) LIS 12/13 Functional Specification Issued for Review Refresh of DC test environment from live. Migration Review for 12/13 with the IA Draft DC 12/13 HLSD Issued for Internal Review Draft DC/LIS 12/13 Test Approach Commencement of Technical investigation Stream including analysis of Multi-threading, Multi-byte (extended character) support in LIS/DC, Net TCP OPA proof of concept development, LIS 11/12 baseline performance metrics, and Multi-year PB2 support. Architecture & Design workshops OLDC Development based on received specifications (i.e. Oracle schema) LIS Development based on received specifications Commencement of DC/LIS Test Plans (DC, LIS & NFR) Note: Only the BRS versions stated above have been used to determine this contractors solution An Amalgamation BRS will be produced as part of Stage 1 this will be a joint effort between Capgemini and the Authority (although ownership will remain with the Authority). The BRS will state which Release the requirement is targeted for. The architectural investigation stream above will include a series of technical investigations where it may be jointly agreed that the best course of action would be to make a targeted enhancement to the 11/12 Data Collection system in order to forecast its ability to meet an NFR and/or address an area of operational concern for 12/13. This would not have secured Service Gateway 2 or 3 prior to release. It is proposed the project submit a detailed change note with a targeted test approach for each change. It is proposed that all DC, PFR and LIS Releases would share SG0 and 6. Each stage would require a separate Service Gate 1 and 5 with a split SG2, 3, and 4 for each release. Based on a project board decision on the 22nd March 2012 (ref: Minutes, section 3.4) and subsequent meetings with the IM Services programme, no ‘re-engineering’ work will be undertaken on the Amalgamation component of LIS.

The Contractor’s Solution the technical proposal from the Contractor which sets out an overview of the proposed solution supported by the necessary detail of the Contractor’s response to the Authority’s Requirements To achieve the requirements specified in section 1 of this FSC, the Contractor has defined the following areas of work: Update the Back to Centre (BtC) functionality in the live environment to address the issues identified as Quick Wins. the production of an indicative transition and stabilisation plan arising from investigation and discovery, and including implementation of non Quick Wins issues. This objective of this plan is to enable the Authority to achieve the remainder of the overall objectives of the IM Portal Stabilisation project as described in the overview part of section 1.

The Contractor’s Solution the technical proposal from the Contractor which sets out an overview of the proposed solution supported by the necessary detail of the Contractor’s response to the Authority’s Requirements 1. Test Planning & Scripting Test planning and scripting in support of this FSC. Test Plan drafted and issued to the Authority Prepare test scripts. 2. Early BST SIT (phase 1) BST against an initial release of IdAMS and the DCFT Solution. Connectivity testing Release notes review Review Partner SIT and/or UAT sign-off against entry criteria. 3. BST SIT (phase 1) BST scenarios S1 – S13 (as in the table below). BST (non CCM/Match and Claim) Validate test results in the DCFT repository 4. BST UAT (phase 1) Repeat phase 1 BST with witnessing by the Authority. A single run of BST tests as a subset of the Authority UAT Plan. 5. BST OAT (phase 1) Testing of scenarios S1 – S14 (as in the table below), following BST UAT (phase 1) sign off Repeat BST with CCM R1 (excluding CCM R2/Match and Claim). 6. Early BST SIT (phase 2) BST against early CCM R2/Match and Claim. Connectivity testing Release notes review Review local SIT and/or UAT sign-off against entry criteria. 7. BST SIT (phase 2) BST scenarios S15 – S23 (as in the table below). BST (CCM R2/Match and Claim) 8. BST UAT (phase 2) Repeat phase 2 BST with witnessing by the Authority. A single run of BST tests as a subset of the Authority UAT Plan. 9. BST OAT (Phase 2) BST scenarios S15 – S23 (as in the table below), following BST UAT (phase 2) sign off Repeat BST (CCM R2/Match and Claim). The BST will comprise the following scenarios: S1 Set up users in IDAMS S2 Login in to the Portal S3 Set up collections on the Portal S4 Processing a Provider’s 13/14 ILR XML file - test 1 “No funding” S5 Processing a Provider’s 13/14 ILR XML file - test 2 “Fully valid with all funding models” S6 Processing a Provider’s 13/14 ILR XML file - test 3 “Fully invalid” S7 Processing a Provider’s 13/14 ILR XML file - test 4 “mixture of valid and invalid” S8 Processing a Provider’s 13/14 ILR XML file - test 5 “multiple file submissions for provider” S9 Processing return of monthly EAS data S10 Processing of previously submitted EAS data S11 Install the Desktop Service as a Provider User S12 Provider can enter data via online form (POL replacement) and create an ILR for submission via the portal S13 Provider can submit an XML file (single) S14 Update Contract Data in DCFT via CCM S15 Import Summarised Actuals into CCM from DCFT (not month end) S16 ILR ...

The Contractor’s Solution the technical proposal from the Contractor which sets out an overview of the proposed solution supported by the necessary detail of the Contractor’s response to the Authority’s Requirements The NetBackup software on the master, media servers and clients software within this FSC will be upgraded. The current versions are all consistent with version 6.5.6. These will be upgraded to version 7.5 which is the latest version. Upgrade approach Initially phases 1-3 will take place to build and upgrade the TOLBUS001 master server, phases 4-6 will then follow for the upgrade of the media and client software: Build a new TOLBUS001 master server and complete the NetBackup 7.5 upgrade. Pre-upgrade activities Upgrade the software Post upgrade configuration. Ongoing support of new master server and decommission of existing server Media server and client software upgrade Master Server upgrade Build of the new TOLBUS001 Server. The steps in this process will be as per below: Rebuild of the current TOLVCB001 media server to Windows 2008 and higher/same spec processor and memory as the existing master server. Installation of software and core components from the existing server as defined in the pre-implementation activities. Check connectivity Review the running of the server for 48 hours to ensure the server is operating as per original server. Pre-upgrade activities Initially there will be an analysis of the current TOLBUS001 Server - TOLBUS001.lsc.local. This detail will then be used to ensure the correct data is replicated onto the new server. Prior to the software upgrade each media server will be subject to pre-upgrade checks. These upgrade checks will reduce the risk of the upgrade and confirm that the software environment is configured appropriately. The pre-upgrade tasks are: Run a catalogue backup on the master server Check the consistency of the NetBackup EMM database on the master server De-activate the backup policies and storage lifecycle policies De-activate the disk storage staging units De-activate the media server. Upgrade Netbackup software Upon confirmation of stabilisation on the new server and completion of the pre-upgrade activities the software upgrade will be undertaken on the server using Symantec guidance. The upgrade will initially be undertaken on the master server and if successful Netbackup will be upgraded on the Media and then Client Servers. Post upgrade activity Server integrity check Upon completion of the Netbackup upgrade the following ...