Transition Plan (TP)

Transcription

1 Transition Plan (TP) Cash Doctor 3.0 Team 12 Steven Helferich: Project Manager, Developer Kenneth Anguka: IIV&V Xichao Wang: Operational Concept Engineer, Tester Alisha Parvez: Life Cycle Planner, Developer Ekasit Jarussinvichai: Requirements Engineer, Developer Danny Lee: Tester Le Zhuang: Feasibility Analyst, Developer Shreya Sharma: Software Architect, Developer

2 Transition Plan (TP) Version 1.0 <04/05/15> ii

3 Transition Plan (TP) Version 1.0 Version History Date Author Version Changes made Rationale 04/05/15 XW 1.0 Original Draft Original Draft iii

4 Transition Plan (TP) Version 1.0 Table of Contents TRANSITION PLAN (TP)... I VERSION HISTORY... III TABLE OF CONTENTS... IV TABLE OF TABLES... V TABLE OF FIGURES... VI 1. Transition Strategy Transition Objectives Transition Process Strategy Preparing for Transition Hardware Preparation Software Preparation Site Preparation Stakeholder Roles, Responsibilities and Schedule... 9 iv

5 Table of Tables Table 1: Transition Schedule... 9 TP_ASBUILT_S15b_T12_V1.0.doc v Version Date: 01/12/09

6 Table of Figures No table of figures entries found. TP_ASBUILT_S15b_T12_V1.0.doc vi Version Date: 01/12/09

7 1. Transition Strategy This document provides the information about transition strategy. It includes Transition Objectives and process strategy and it helps to ensure the success of deliver and the maintenance of the product in the future. 1.1 Transition Objectives Extent of capability transitioned: Developers is going to deliver the product with full operation with all functions that client had agreed. It didn t complete all the requirements on the win win negotiations, but client agreed that some of these requirements can be implemented in the futures after backend team improves backend support. Number and nature of transition sites: None. Degree of post-transition developer support: Developers provide technique support on consulting level after transition. Degree of validation of operational satisfaction of stakeholder objectives: The capabilities have been discussed during Win Win Negotiations, Client Meeting and Validation. For the ARB, the client was satisfied with all the functions and user interface. Nature of product transition: This system is a new system. Relation to support objectives: The feedback from client would improve the system and made the user interface more friendly. 1.2 Transition Process Strategy Phasing of cutover: This App is incremental, new functions could add to this app after delivered. Phasing of transition of multiple increments to multiple sites: Not Applicable. Role of alpha-testing, beta-testing, independent operational testing and evaluation: The developers and the success critical stakeholders will do alpha testing. The developers will record the feedbacks. After the system is available to all the users, they could start beta testing. If they have any technical issues they could contact with developers for help. Clients and users will do independent operational testing without any instructions from developers. The success critical stakeholders should do evaluation. 7

8 2. Preparing for Transition This document provides the information that client need to prepare for the transition. 2.1 Hardware Preparation No new hardware is required because client has hardware for their web site. 2.2 Software Preparation Inel XDK. Android OS IOS 2.3 Site Preparation Not Applicable 8

9 3. Stakeholder Roles, Responsibilities and Schedule Table 1: Transition Schedule Date Role Responsibility Location 03/11/15 Developer Develop system Campus 03/12/15 Tester Test product Campus 03/18/15 Developer Fix the bugs Campus 03/24/15 Client Provide feedback and suggestion Campus 03/25/15 Developer Optimized and improved the product Campus 04/02/15 Developer Prepare User Manual Campus 04/20/15 Tester Test products Campus 04/25/15 Developer Fix the bugs Campus 05/04/15 Client Deliver the products Campus Developer 9