Transition Plan (TP) Version 2.7 Version no x.xx
Transition Plan (TP)
Student Scheduling System
TEAM #06
Douglass Kinnes: Project Manager, Quality Focal Point, Implementation Team member
Alexey Tregubov: System Architect, UML Modeler, Implementation Team member
Mihir Daptardar : Operational Concept Engineer, Quality Focal Point, Tester
Ihsan Tolga : Life Cycle Planner, Feasibility Analyst, Implementation Team member
Simone Lojeck : IV&V, Quality Focal Point, Shaper
Version History
Date / Author / Version / Changes made / Rationale /12/05/12 / Ihsan Tolga / 1.0 / · Section 1,3 documented.
· Initial transition plan formed. / · Lack of information for a detailed transition plan. Initial values added.
12/13/2012 / Ihsan Tolga / 1.1 / · Bugs resolved, table changes made, template data removed. / · Bugs resolved, tables were revised with respect to the comments during the DCR ARB session.
02/07/2013 / Ihsan Tolga / 2.0 / · Preparing for Transition added. Bugs resolved. / · Core Transition preparation plans added. Defects removed.
02/20/2013 / Ihsan Tolga / 2.1 / · Transition schedule revised. Software preparation list added. / · Transition schedule and related items are revised with respect to the ARB comments.
02/27/2013 / Ihsan Tolga / 2.2 / · Bugs fixed. Preparation added. / · Bugs fixed with added information.
03/27/2013 / Ihsan Tolga / 2.3 / · Transition Process Strategy revised. / · Strategy updated. Added item for preparation.
04/13/2013 / Ihsan Tolga / 2.5 / · Added items for IOC2. Strategy modified. Sw/Hw and site preparations updated. Objectives modified. Schedule revised. / · Updates made with respect to updated knowledge and conducted CCD, development period and tests.
04/20/2013 / Ihsan Tolga / 2.7 / · Preparations revised, errors fixed with respect to the ARB comments. / · Updates, fixes made after full capability system. Ready for TS.
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 6
1.1 Transition Objectives 6
1.2 Transition Process Strategy 7
2. Preparing for Transition 8
2.1 Hardware Preparation 8
2.2 Software Preparation 8
2.3 Site Preparation 9
3. Stakeholder Roles, Responsibilities and Schedule 10
iii
TP_IOC2_S13b_T06_V2.7 Version Date: 04/20/13
Transition Plan (TP) Table of Contents
Table of Tables
Table 1: Transition Schedule 10
iii
TP_IOC2_S13b_T06_V2.7 Version Date: 04/20/13
Transition Plan (TP) Table of Contents
Table of Figures
No table of figures entries found.
iii
TP_IOC2_S13b_T06_V2.7 Version Date: 04/20/13
Transition Plan (TP) Version 2.7
1. Transition Strategy
The transition process is planned after all the development iterations are completed. The client performed a brief product check and provided some feedbacks before the last planned iteration and so that the final changes were made during this last iteration.
There is a particular user training and delivery of user manual in the last iteration. Training Material document and User Manual document are the base documents to be followed for this training phase. The client’s feedback/review is also added to the results of transition readiness review and will complete the acceptance of the product as project team’s final deliverables.
The transition process consists of:
· Delivery of the source codes and executable files (or installation package) to the client side.
· Delivery of user manual files and documents.
· Delivery of the project documents and artifact for future maintenance uses.
· Delivery of the instruction for setting up the system on client side web-server.
1.1 Transition Objectives
· Successful delivery/transition of the complete final software product and its full capabilities with respect to the win conditions and system (and evolutionary) requirements defined in the beginning and modified throughout the project’s lifecycle.
· Successful completion of the user training session and receiving positive feedback about the User Manual.
· Successfully delivering of the user manual files and documents and receiving acknowledgement.
· Delivering system source codes for future maintenance or upgrade needs.
· Ensuring that the delivered product runs properly and with full of its features on client side’s web server. It has to be done before the system get fully operational in Fall 2013 semester at Stevens Institute of Technology.
· Successful delivery of the project artifacts and documents to provide resources for maintainer people. Source codes will also be delivered to the client.
· Getting first experience feedback about the system’s operability to track the possible defects early and conduct resolving actions immediately.
· Receiving user training feedback and provide technical help with the possible shortfalls or missing points.
1.2 Transition Process Strategy
The transition phase is planned in the development phase (It is defined as Development – Transition Phase) of Student Scheduling System project. The system will be delivered and set up at once and there will be independent test runs between the final delivery and additional client side test will be run until Fall 2013 starting dates. Both stakeholders are agreed to take benefit from this time period.
The Student Scheduling System is designed and perceived as a web-based application running on JVM (Java Virtual Machine) and customer side is decided as responsible for future maintenance work. For this purpose, development documents and source codes of the project with supplementary comments will be given during the transition of the Student Scheduling System to expedite customer side’s orientation to gain initial capabilities to maintain the system.
The alpha tests were run on developers’ virtual web-server machines (Using Java PLAY framework’s capabilities) and beta tests were conducted University of Southern California Longbeach server. The client side does not plan to use the new system before Fall 2013 semester so there will not be an instantaneous phase between the former manual system and the new scheduling system. The beta tests have taken place during the second iteration and are evaluated as client’s final review of acceptance. A part of these test were held during CCD (Core Capability Drive-through session.
While the transition process; it is planned to get real-time feedback from client about system’s running to solve possible issues upfront.
2. Preparing for Transition
Transition process preparation covers hardware, software and destination site aspects which are listed below.
Through the development process of Student Scheduling System, individual test runs and implementation runs are conducted in each implementation team member’s own computer’s local host and preferred web browser since it is the fastest way to observe changes, actions and functions. And also MySQL database and Xampp were installed in each member’s computer to run database tier of the system.
Before the CCD, a dry run was held with the client as a training session for both CCD and general delivery of the final product. Both in this dry run, CCD and also for last implementation period, system was run on USC Longbeach web host to test functionality. Some minor performance issues were recorded during these test runs which are due to some internal problem of selected server.
2.1 Hardware Preparation
· Client-side web server: There is no person-hour given by development team. Client side is responsible for this readiness.
· End product package transferring environment (online): One person from development team will archive the running version of system on Longbeach server along with the existing database (it can also be archived as a virtual machine. The development team is responsible for this preparation. The package will be sent via online due to long distance between client and developer team.
· Sufficient data storage embedded in client-side web server for storing course information and added data and log files: There is no person-hour given by development team. Client side is responsible for this preparation. Initial volume of data will not represent the average need of data storage for system operation.
· A personal computer to represent a student’s computer to enter the Student Scheduling System and use the functions on running web host.
2.2 Software Preparation
The software required to be installed on the system for transition are as follows:
· Windows Server 2008 / Unix Server: License for Windows Server needed if client side decides to operate the system on Windows Server 2008.
· Java Virtual Machine Version 6 (7 recommended): No license required. Approval is received by client side upon using JVM. It is to be installed upon the system and the client (student) terminals.
· MySQL Server: No license required.
· Java Script 1.8.5: No license required.
· XAMPP: Recommended for future developers and maintenance issues.
Main deliverable software files are formed in groups as follows:
· Controllers
o Admin
o Auth
o Constructors
o Solver
o Util
· Model
o Entities
o .Model
· Views
o Forms
o .Views
· Conf
· Db
2.3 Site Preparation
Client’s current system and website is hosted by the school and the new system is going to be installed on this host machine. In addition to this, because the developers and client side are located in different states, the preparation of site responsibility belongs to the client.
User Manual and Training Material serve as the main source of training for the clients (both administrative and student side of the system). The User Manual is accessible in system itself. Maintenance site and preparations are also be covered by the client because of the reasons stated above.
3. Stakeholder Roles, Responsibilities and Schedule
Table 1: Transition Schedule
Date / Role / Responsibility / Location04/19/2013 / Team, TAs, Professor / TRR ARB. TAs and the professors will evaluate the project’s readiness for transition. / Salvatori Building, Web Conference.
04/12/2013 / Builder, Tester / Checking the transition requirements for the product transition. / Development Team Location
04/15/2013 / Builder, Project Manager / Evaluating/checking final deliverables, installation files, executable files, user manual documents. / Development Team Location
04/11/2013 / Builder / Preparing and checking the user’s manual documents. / Development Team Location
04/09/2013 / Tester / Performing alpha tests before delivery/transition. / Development Team Location
04/08/2013 / Builder, Trainer / Provide user training via web-conference. / Development Team Place, Client (via web conference)
04/19/2013 / Team, Client / Providing/Receiving final client feedback/review as acceptance review. / Development Team Place, Client (via web conference)
04/19/2013 / Builder, Tester / Performing defect resolution, final additions. / Development Team Location
04/17/2013 / Client / Performing beta tests, feedback. / Client’s Location
04/19/2013 / Builder, Tester / Defect resolution with respect to the client’s feedback. / Development Team Location
04/20/2013 / Team, Client / Delivery/installation of final products, installation instructions. / Development Team Place, Client
04/22/2013 / Trainer, Client / Extra user training for missing points / Delivery of TS package / Development Team Place, Client (via web conference)
04/29/2013 / Team, Client, TAs, Professor / Operational Commitment Review for Initial Operational Capability. Client, TAs and the professor will evaluate the final deliverables operational capability and readiness. / Salvatori Building, Web Conference
05/07/2013 / Client / Client will evaluate the final deliverables and project’s success. / Client’s Location
Until CS577b ends 05/10/2013 / Team / Operational support for the client and software maintainers. Close out report. / Development Team Place, Client (via web conference)
iii
TP_IOC2_S13b_T06_V2.7 Version Date: 04/20/13