Transition Plan (TP)

Transcription

1 Transition Plan (TP) Mission Science Information and Data Management System 3.0 Team 3 Fei Yu: Project Manager, Life Cycle Planner Yinlin Zhou: Prototyper, Operational Concept Engineer Yunpeng Chen: Requirements Engineer Jingwen Peng: Builder, UML Modeler Chenguang Liu: System Architect Steven Lee: Requirements Engineer, IIV&V, Quality Focal Point

2 ii

3 Version History Date Author Version Changes made Rationale 11/24/13 CL 3.0 Original template for all the sections Initial draft iii

4 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_TRR_F13a_T03_V3.0 v Version Date: 11/25/13

6 Table of Figures No table of figures entries found. TP_TRR_F13a_T03_V3.0 vi Version Date: 11/25/13

7 1. Transition Strategy This document provides information of the developed Mission Science Information and Data Management System 3.0. It includes the transition objectives and the transition process strategy. It ensures the success of the final deliverables in the transition process and maintenance of the product in future. 1.1 Transition Objectives Extent of capability transitioned: The development team will deliver the system with full operation, which the developers and the client had agreed on. It completed all the requirements those were mutually agreed upon in the Win win negotiations. Number and nature of transition sites: It would be installed on one single and homogenous site. Degree of post-transition developer support: One person would be the maintainer in the future who will provide help to support the system after the transition phase. Also, documents will be provided to the clients and users. The users will also be trained on how to use this system so that they can work on it independently. 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 an improvement in existing operation. Relation to support objectives, e.g., data collection to support evolution planning. The feedback from client would improve the system and made the user interface more friendly. The collection of errors in logs would help to improve the system in the future. 1.2 Transition Process Strategy Phasing of cutover: The system is instantaneous (cold turkey). Merging the new forms and new tables into the original system and the update system is achievable. Phasing of transition of multiple increments to multiple sites: The transition would initially be done on one single site. After it enhanced to a complete and working system, it would later on be transitioned to multiple sites. 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 The client should prepare for both hardware and software environment for transition. 2.1 Hardware Preparation No new hardware is required since the system would be updated on existing system. 2.2 Software Preparation OS: Windows 7 Application: Microsoft Access Site Preparation Computer rooms for training, power supply Computers with updated database and running Microsoft access 2010, supplies Backup computer for testing of program 8

9 3. Stakeholder Roles, Responsibilities and Schedule Table 1: Transition Schedule Date Role Responsibility Location 11/18/13 Coder Develop system King Hall 11/22/13 Tester Test product in acceptance environment King Hall 11/24/13 Coder Fix the bugs and issues found during testing King Hall 11/25/13 Client Provide feedback and suggestion Tutor Hall 11/28/13 Coder Work on optimization and improvement with the King Hall client s suggestion and feedback. 11/30/13 Coder Prepare User Manual King Hall 12/06/13 Coder, Deploy the system and train the client and all the user Tutor Hall Trainer, and client 12/09/13 Trainer Deliver thorough documentation to the client Tutor Hall Coder: Fei Yu, Yinlin Zhou, Jingwen Peng, Chenguang Liu, Yunpeng Chen Tester: Fei Yu, Yinlin Zhou, Jingwen Peng, Chenguang Liu, Yunpeng Chen Trainer: Yinlin Zhou Maintainer: Fei Yu 9