Transition Plan (TP) Version 4.0 Version no x.xx
Transition Plan (TP)
The Log Angeles Community Garden Inventory and Locator
Team 13
Ardalan Yousefi Project Manager
Cole Cecil Integrated Independent Verification & Validation
Jeff Tonkovich Implementer
Shi-Xuan Zeng (Gary) Tester
04/26/12
Version History
Date / Author / Version / Changes made / Rationale /11/10/11 / Larry / 0.1 / · Initial version / · In preparation for DC package
11/28/11 / Larry / 0.2 / · Removed empty points from 1.1 transition objectives and added more description to 1.2 phasing of cut-over, and clarified the last objective of the transition schedule to indicate the source code and documentation deliverable. / · IIVVer feedback
01/30/12 / Ardalan / 0.3 / · Added approximate dates to the Transition Schedule / · DCP TA feedback
02/05/12 / Jeff / 1.0 / · Added section 2.0 / · In preparation for RDC package
03/24/12 / Jeff / 2.0 / · Minor updates / · In preparation for IOC #1
04/08/12 / Jeff / 2.1 / · Updated Section 1.1, 2.2 & Table 1 / · Added additional details for TRR including additional deployment details and revamped deployment schedule
04/15/12 / Jeff / 3.0 / · Version update / · In preparation for TS Set
04/26/12 / Jeff / 4.0 / · Updated Section 3 / · Deployment at Client’s site
· Final Release
Table of Contents
Transition Plan (TP) i
Version History ii
Table of Contents iii
Table of Tables iv
Table of Figures v
1. Transition Strategy 1
1.1 Transition Objectives 1
1.2 Transition Process Strategy 2
2. Preparing for Transition 3
2.1 Hardware Preparation 3
2.2 Software Preparation 3
2.3 Site Preparation 3
3. Stakeholder Roles, Responsibilities and Schedule 4
ii
TP_IOC3_S12b_T13_V4.0.doc Version Date: 04/26/12
Transition Plan (TP) Table of Contents
Table of Tables
Table 1: Transition Schedule 4
ii
TP_IOC3_S12b_T13_V4.0.doc Version Date: 04/26/12
Transition Plan (TP) Table of Contents
Table of Figures
No table of figures entries found.
ii
TP_IOC3_S12b_T13_V4.0.doc Version Date: 04/26/12
Transition Plan (TP) Version 4.0
1. Transition Strategy
The Transition Plan (TP) document describes the objectives and the strategy necessary, as well as various preparations and schedule needed to ensure the successful transition for the developed system to be put in operation.
1.1 Transition Objectives
The main objective for the transition is to deliver the developed system to the client LANLT by the CS577 student team. Various dimensions of the success associated with this transition include:
· Extent of capability transitioned:
All the core and must-have requirements and capacities agreed upon by the client and the development team will be provided by the system and it will be a new and a fully operational system.
· Number and nature of transition sites:
The system will be deployed to a single web hosting account, either at the current web hosting account used by the client or a new web hosting account of the client’s choosing.
· Degree of post-transition developer support:
There will be no formal support from the development team after the system and related documents are handed over to the client as part of the agreement and contract. Informally, individual members from the development team may provide support at their own discretion.
In addition, the client has expressed a desire to hire some/all of the current development team on as contractors for the LANLT organization to both maintain the system and various other requirements not agreed upon for CS577 (e.g. non-core capabilities such as driving directions, photos of gardens, etc).
· Nature of product transition:
The system is a new web-based system the client will be using upon inspection and deployment. The client will use existing manual methods until the system is up and running and automates the manual methods.
1.2 Transition Process Strategy
There are three parts to the transition process strategy:
· Phasing of cutover:
The new system will be deployed to a test-bed first then tested and verified by the client before the system is to be deployed on the target web hosting account. Since the system is brand new and not a new version of the existing system, the client shall keep a copy of the currently used spreadsheet for the garden information and update both the system database and the spreadsheet until such time the client is satisfied that the system is working perfectly and retire the spreadsheet.
· Phasing of transition of multiple increment to multiple sites:
There will be only one increment to one single site. No multiple increment delivery is expected nor will the system be deployed to multiple sites.
· Role of alpha-testing, beta-testing, independent operation testing and evaluation:
Alpha-testing will be done by the development team regularly as the system is being developed. It will be mixed with unit-testing during the development phase to make sure typical and trivial problems are discovered before beta-testing and client inspection.
Beta-testing will follow by alpha-testing, and will be conducted by the client, with development team present to gather feedbacks and concerns to allow the development team to refine the system.
Independent operation testing will be conducted by both the client and the IIVVer on a version of the system on a test-bed to verify the system is operational with no outstanding problems and concerns. The client then will evaluate whether to go ahead with the actual deployment of the system.
2. Preparing for Transition
Transitioning to a new hardware and software platform simultaneously is a significant and non-trivial task. If the deployment of the new system is to be successful, great care must be taken in ensuring the transition is as well thought-out as possible.
2.1 Hardware Preparation
The recommended hardware setup for the website is as follows:
· Processor: Intel(R) XEON E3220 processor
· Memory: 2.00 GB
· 80 GB/mo Bandwidth
· Dedicated IP address
2.2 Software Preparation
The software required for the website is as follows:
· Windows Server 2008
· IIS 7.0
· ASP.NET 4.0
· MS SQL 2008 R2
2.3 Site Preparation
Since the Client’s current system is hosted externally and no mention has been made of switching to internal hosting, all site preparation is understood to be the responsibility of the host provider.
3. Stakeholder Roles, Responsibilities and Schedule
The stakeholders and their responsibilities with respect to the transition plan and the schedule are the following:
Table 1: Transition Schedule
Date / Role / Responsibility / Location02/24 / Implementer / Deploy the system on testbed server / Implementer’s site
03/28 / Client, IIV&V / Client provides feedback during the core capability drive through of the system. / USC
04/17 / Implementer, Tester / Finish refining and modifying the system based on client feedback / Implementer’s site
04/21 / Tester, IIVV&V,
Implementer,
Client / Verify the system and make any necessary changes / fixes. / Implementer’s site
04/28 / Implementer, Client / Deploy the system on final web hosting server at the Client’s site / Client’s site
04/28 / Development Team, Client / Deliver the system source-code package and all related documentation to the Client. Client fills out Closeout Report Form. / Implementer’s site
04/30 / Trainer, Client / Provide training to the client and any other members of the LANLT organization who attend. / Implementer’s site
ii
TP_IOC3_S12b_T13_V4.0.doc Version Date: 04/26/12