Feasibility Rationale Description (FRD) s3

System and Software Support Plan (SP)

Student Scheduling System

Team06

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

04/13/2013 System and Software Support Plan (SP) Version 1.0

064c06a3d262868ea234800ecd3c986e.doc ii Version Date: 04/13/13 System and Software Support Plan (SP) Version 1.0

Version History

Date Author Versio Changes made Rationale n 04/13/20 Ihsan Tolga 1.0  Support Plan composed.  Ready for IOC2 and TS. Data 13 Environment items and taken from records and responsibilities are defined. conducted sessions. Support strategy defined.

064c06a3d262868ea234800ecd3c986e.doc iii Version Date: 04/13/13 System and Software Support Plan (SP) Version 1.0

Table of Contents

SYSTEM AND SOFTWARE SUPPORT PLAN (SSSP)...... I

VERSION HISTORY...... II

TABLE OF CONTENTS...... III

TABLE OF TABLES...... IV

1. Support Objectives and Assumptions...... 1

1.1 Support Objectives...... 1

1.2 Support...... 1

2. Support Strategy...... 2

2.1 Support Lifetime...... 2

2.2 Release Strategy...... 2

2.3 Release Requirement Determination...... 3

2.4 Release Process...... 3

3. Support Environment...... 4

3.1 Hardware...... 4

3.2 Software...... 4

3.3 Facilities...... 5

4. Support Responsibilities...... 6

064c06a3d262868ea234800ecd3c986e.doc iv Version Date: 04/13/13 System and Software Support Plan (SP) Version 1.0

Table of Tables

Table 1: Release Requirement Determination...... 3

Table 2: Description of Software required in Support Plan...... 4

Table 3: Stakeholders and their supporting responsibilities...... 6

064c06a3d262868ea234800ecd3c986e.doc v Version Date: 04/13/13 System and Software Support Plan (SP) Version 1.0

A.1. Support Objectives and Assumptions

A.1.1 Support Objectives

The main purpose of the System and Software Support Plan is to support the key stakeholders of Student Scheduling System project throughout the transition, operation and the maintenance period.

The main objectives of support plan of Student Scheduling System can be listed as follows:  To provide maintainers of the Student Scheduling System with sufficient capabilities to handle emerging performance issues of the system.  To provide maintainers of the Student Scheduling System with sufficient experience and knowledge to overcome possible malfunctions during the operations phase.  Due to the nature of CS577 course and developer team structure; to provide maintainers of Student Scheduling System with enough resources and capabilities to add new features to the system or modifying the existing ones.  To define environmental variables and hardware / software arguments of the Student Scheduling System.  To provide a supplementary resource for User Manual and Training Plan regarding the transition of the system and initial training concerns. A.1.2 Support

To keep the Student Scheduling System operating and in service properly; several pre- conditions must be kept satisfied all the time system runs. These key requirements are given below as assumptions which should be valid.

 The client side and the school are responsible for web hosting, maintenance and running servers.  The client side is the decision maker of system preference between legacy system and Student Scheduling System. Student advisors should be very familiar about course scheduling and study plans in case of system failures.  The maintainer team is familiar with the architecture and the use cases of Student Scheduling System.  The maintainers are familiar with the course structure and system of the department (Steven’s Institute of Technology). They also have enough knowledge about course relations and levels and credit system.

064c06a3d262868ea234800ecd3c986e.doc 1 Version Date: 04/13/13 System and Software Support Plan (SP) Version 1.0

 The client side will conduct required/demanded upgrades and modifications to the system on their own behalf. The development team cannot be in service after the project delivery due to the CS577b structure and course plan. The documents required are given with final deliverables to the client.  The required hardware, software and site preparations are done by the client side due to long physical distance between development team and the client.

A.2. Support Strategy

A.2.1 Support Lifetime

Until the end of the CS577b Software Engineering Spring 2013 course (05/10/2013); maintenance support and other required technical help will be given by the developer team (Team06) to the client. By this time, user training and dry runs are also held via web-conferences and screen sharing which are also supported by the regular weekly meetings.

Apart from these subjects above; User Manual, Training Plan and other resources (including sample data) are provided to the client by developer team with System and Software Support Plan for future uses/ A.2.2 Release Strategy

The initial full capability version of Student Scheduling System (with respect to the 80% of full capability concern) was provided by Core Capability Drive-through (CCD) session. After CCD, small releases are provided regarding the client concerns and bug fixes until Transition Readiness Review (TRR) with respect to the full customer satisfaction concern of developer team.

It is agreed that; in case client has some minor demands/changes about the system (mostly related to user interface, not internal structures), the developer team might provide new releases after TRR until May 10th 2013, the end of the CS577b course.

The new releases during the operation phase of Student Scheduling System will be issued by maintainers designated by the client side. The required info for future system transformation and maintenance are given with the final deliverables package and they are also available on team webpage.

A.2.3 Release Requirement Determination

The expected primary drivers of new release content of Student Scheduling System are given in the table below.

Table 1: Release Requirement Determination

Drivers Responsible Role Small modification mostly related to user interface of the system and Development Team visualizations. Adding new medium level changes (i.e. new arguments for solver Maintainers algorithm) Small user interface changes, new pages / screens Maintainers Service level improvements and performance advancements Maintainers Recently discovered bug fixes / defect removals Maintainers / Development Team (by the end of CS577b) Changes regarding system environment (New host, hardware change, Maintainers database modifications)

A.2.4 Release Process

After the client side designated its capable maintainer staff and their training session, these maintainer team need to define a policy which can orient the release process given below. It is assumed that the software / hardware environment for the system and the hosting are already up and running.

 Designating people among the maintainers (or outsourcing) for the new release.  The identification of needs / requirements for the new release which also includes the tracked bugs if exist.  Conducting a brief business case analysis and effort / cost calculation for the new release.  Developing the new release. (Includes storing the back-up data and source files, environment variables etc.) Testing the recently developed components and components’ interoperability.  Complete testing of the new release.  Preparing the transition site and hardware / software. Transitioning the new release after the current log is saved.  Updating the users of the system with the new release and informing. Setting up the database with pre-stored data.  Observing the performance of new release, issue resolution if necessary.

A.3. Support Environment

For long-term operating Student Scheduling System, the following hardware / software requirements and the facilities should be acquired by the client side / user side. A.3.1 Hardware

Server Side Hardware Requirements:  Processor : Intel® Xeon E3xxx Processor or equivalent.  Memory : 3GB + 5GB for Database  Data Bandwidth : (Relative to the simultaneous numbers of users.) ~1 Mbit/s  Domain Name and Dedicated IP address  I/O Devices for Maintenance Issues

User Side Hardware Requirements:  Processor : Intel® Centrino/Core/Celeron/PentiumIV; AMD Athlon/Phenom/FX processors or equivalent.  Memory : 1GB  Internet Connection  I/O Devices to operate Web Browsers properly.

A.3.2 Software

Table 2: Description of Software required in Support Plan

Software Requirement: UNIX Server or Windows Server Rationale: To run Student Scheduling System on server machine. User/Operator Manual: www.microsoft.com/ws2012 ; unixhelp.ed.ac.uk Availability Information: Unix is available on Unix web page. Microsoft Server need license. Note: Steven’s Institute of Technology already has required servers.

Software Requirement: Java Runtime Environment Rationale: Required middle layer to operate Java both on user and server machines User/Operator Manual: docs.oracle.com/javase/7/docs/api Availability Information: Java Version 7 Update 17 is available on www.java.com/en/download Note: It is required to run /java files and for PLAY framework

Software Requirement: MySQL Rationale: To maintain and operate a relational database for the system. User/Operator Manual: dev.mysql.com/doc/en Availability Information: MySQL is free and open source database software. Download is available on dev.mysql.com/downloads ; release 5.6.10 Note: It works well with Xampp.

Software Requirement: PLAY Framework for Java/Scala Rationale: Student Scheduling System is based on this Java framework. User/Operator Manual: www.playframework.com/documentation/1.0.1 Availability Information: It is free and version 2.1.1 is available for download on www.playframework.com/download

Note: It is required for maintenance of the system.

Software Requirement: Java Editor (Eclipse) Rationale: To monitor/modify .java source files and related developer actions. User/Operator Manual: www.eclipse.org/documentation Availability Information: Eclipse is open source, free and available on www.eclipse.com/downloads Note: A strong IDE like Eclipse is required for maintenance concerns.

Software Requirement: Xampp Rationale: To access MySQL and Apache Web Server function for maintenance concerns. User/Operator Manual: www.apachefriends.com ; www.apachefriends.org/en/faq-xampp.html Availability Information: Xampp is free and available on www.apachefriends.com Note: It is highly recommended to access MySQL database and for maintenance issues.

Software Requirement: Web Browser (Mainstream browsers i.e. Mozilla Firefox, Google Chrome) Rationale: To access the HTML codes generated by Student Scheduling System. User/Operator Manual: Documentation and manuals are available in related browsers web-page and help tab. Availability Information: Mainstream web browsers are freeware and available in their related pages. Note: Google Chrome or Mozilla Firefox is recommended.

A.3.3 Facilities

Student Scheduling System is a web-based application running on users’ web browser and Java virtual machine and the hosting should be on a web-server running Java as well. As a result; there is no special facility required to run / operate the system particularly.

A.4. Support Responsibilities

Key stakeholder roles for the Student Scheduling System and their related roles / skills are given in the table below. Items for the development team (Team06) cover the period by 05/10/2013 the end of the course and starting of the operation phase of the project lifecycle.

Table 3: Stakeholders and their supporting responsibilities

Stakeholder Supporting roles # Supporting Skills Development Team  Releasing new versions by the end of 5  Implementation skills (Team06) the CS577b course. with Java, MySQL and  Providing User Manual and Training web-app. Plan for customer.  Training knowledge,  Providing System and Software Support Plan for future maintenance.  Web design and knowledge about user  Providing training to the client and interface software. preparing final deliverables with development documents as well. Client (David  Designating maintenance people. 1  Project administration. Klappholz)  Informing students about the new  Project management. Student Scheduling System and leading the operation/transition before Fall  Java, web-app. 2013 semester.

 Receiving feedback from users of the system and planning future releases. Maintainers (for  Maintaining the Student Scheduling 2  Knowledge about Java, maintain) System PLAY framework,  Resolving emerged defects and MySQL, web-app. malfunctions.  Resolving performance issues with the  Knowledge about system. courses and relation between courses in  Tracking shortfalls about the system Steven’s Institute. during operation phase and required features, Maintainers (for  Identifying needs, calculating effort and 1  Knowledge about Java, developing future costs for new releases. PLAY framework, releases)  Planning for new releases, setting MySQL, web-app. environments and storing data.  Knowledge about  Implementing new version releases for courses and relation Student Scheduling System between courses

 Modifying existing controllers, solver  Knowledge about and user interface. HTML and Scala development

064c06a3d262868ea234800ecd3c986e.doc 6 Version Date: 04/13/13