Transition Plan (TP)

Transcription

1 Transition Plan (TP) SnApp Voice Communication System Team 05 Divij Durve IIV&V Harsh Mhatre System/Software Architect Khyati Thakur Prototyper Monica Varhale Feasibility Analyst Nikita Gupta Project Manager Shlok Naik Operational Concept Manager Shruti Gotmare Life Cycle Planner Sushmaja Bondili Requirements Engineer

2 Version History Date Author Version Changes made Rationale 11/29/14 MV,SG 1.0 Original template for use for TRR Initial draft for use for TRR package package ii

3 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 Transition Objectives Transition Process Strategy Preparing for Transition Hardware Preparation Software Preparation Site Preparation Stakeholder Roles, Responsibilities and Schedule... 9 iii

4 Table of Tables Table 1: Transition Schedule... Error! Bookmark not defined. TP_TRR_F14a_T05_V1.0.doc iv Version Date: 11/29/14

5 Table of Figures No table of figures entries found. TP_TRR_F14a_T05_V1.0.doc v Version Date: 11/29/14

6 1. Transition Strategy Since we are automating the clients system, our transition plan is about making our client aware of the newly designed functionality for the system. This section describes the objectives and processes involved in deployed our application on client s system. 1.1 Transition Objectives Our transition objective includes the following: Extend of capability transitioned: We will be delivering all the capabilities that are we have agreed upon in the Win-book. Apart from capabilities we will be also delivering all the related system artifacts. Number and nature of transition sites: Our system has only one transition site i.e. Heroku and the nature is homogeneous because it is deployed on Heroku server so the same application can be used on all the systems at the user site. Degree of post transition developer support: There is no post transition developer support for our system. We will be providing our client with the user manual which he can refer in future. Also, our client is well aware of the system functionalities as we developed our system collaboratively with our client. Degree of validation of operational satisfaction of stakeholder objectives: Through the client interaction meetings, s and core capability drive through our client have expressed his satisfaction with the capabilities developed by the team. Also, our client constantly reviews the functionalities implemented and he provides us necessary feedback which drives the development process. Nature of product transition: We are automating our clients existing voice communication system and we are adding more functionalities to the system to make it fast and efficient. Our client will be testing the system against the sample test data to ensure all the functionalities are working as per his needs. 1.2 Transition Process Strategy The transition phase for our team would last for one week. We will be performing following activities in the transition phase: We will be implementing all the improvements suggested by our client in the core capability drive through. We will be implementing the additional features suggested by our client in the core capability drive through. 6

7 We will be deploying the improved system on the Heroku cloud Our client will be testing the system based on the sample test data to check whether all the functionalities have been implemented properly and the application is running on Heroku. We will be providing user manual to our client and delivering the system artifacts for maintenance on the client side. 7

8 2. Preparing for Transition Following are the preparations done by the team for transition: 2.1 Hardware Preparation The system requires following hardware preparation for the transition: A Linux machine with internet connection to test the working of the website. Heroku server where we will be deploying our web application. Mobile devices for testing purposes which is capable of receiving calls from a third party service provider like the Twilio. 2.2 Software Preparation The system requires following software preparation for the transition: Ruby on Rails software installed on machine Gitlab: source control purpose PostgreSQL: We need a database to check if the data is properly entered in our systems backend Heroku cloud access: We need Heroku cloud access to check if the system runs on herouku s environment Twilio APIs Web Browser: Since VCS is a web based application, we will be requiring a web browser for testing our application s compatibility across different browsers 2.3 Site Preparation No specific site preparation is required. Any system with can be used for running our application is deployed on Heroku with provides all the required and necessary services for running the application. 8

9 3. Stakeholder Roles, Responsibilities and Schedule Table 1: Transition Schedule Date Role Responsibility Location 11/21/14 Team of Implemented and integrated the client specified USC Developers improvements and deployed on Heroku 11/26/14 Team of Testers Developed the test plans and test cases and also documented the user manual. 11/29/14 Team of Perform testing in accordance with the test cases Testers and resolve any issues encountered 12/03/14 Team Demonstrated the application to the client and obtained the client feedback. USC USC Client Location 9