Feasibility Evidence Description (FED)

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

Zheng Lu : NDI NCS Evaluator, NDI/NCS Acquirer, Prototyper, Implementation Team member

Simone Lojeck : IV&V, Shaper, QFP

Version History

Date / Author / Version / Changes made / Rationale /
09/30/12 / Ihsan Tolga / 1.0 / · Initial FED for exploration phase. / · Risk assessment added.
10/11/12 / Ihsan Tolga / 1.1 / · Version history, table of contents, table of tables, table of figures added.
· Risk assessment table revised, detailed.
· Cost / benefit / ROI analysis added.
· Bugs fixed.
· Section 1 revised. / · Ambiguous risk definitions were detailed.
· Section 1 definitions were detailed.
10/21/2012 / Ihsan Tolga / 1.12 / · Formatting
· Program model revised / · Program model is compatible with current OCD.
10/22/2012 / Ihsan Tolga / 2.00 / · Architecture feasibility defined and added.
· Process Feasibility defined, graded and added.
· Risk assessment table updated with the current stage of the project. / · Feasibility attributes defined according to the mutual agreement between stakeholders.
· Architecture feasibility defined with respect to the OCD and SSAD.
10/23/2012 / Ihsan Tolga / 2.1 / · Captions and footers are updated. / · Footer information and table captions are compatible.
10/28/2012 / Ihsan Tolga / 2.2 / · Bugs resolved. Risk assessment table revised. / · Updated for ARB presentation and current risk status.
10/30/2012 / Ihsan Tolga / 2.3 / · Captions, risk table revised, bugs fixed. / · Risk table is current for the FCP.
11/03/2012 / Ihsan Tolga / 2.4 / · Defects fixed with respect to the ARB comments. / · Fixes according to the ARB review.
11/12/2012 / Ihsan Tolga / 2.5 / · Defects fixed. Bad data removed. / · Defects resolved and tables were updated.

Feasibility Evidence Description (FED) i

Version History ii

Table of Contents iii

Table of Tables iv

Table of Figures v

1. Introduction 1

1.1 Purpose of the FED Document 1

1.2 Status of the FED Document 1

2. Business Case Analysis 2

2.1 Cost Analysis 3

2.2 Benefits Analysis 4

2.3 ROI Analysis 5

3. Architecture Feasibility 6

3.1 Level of Service Feasibility 6

3.2 Capability Feasibility 6

3.3 Evolutionary Feasibility 8

4. Process Feasibility 9

5. Risk Assessment 11

6. NDI/NCS Interoperability Analysis 12

Table of Tables

Table 1: Program Model 2

Table 2: Personnel Costs 3

Table 3: Hardware and Software Costs 4

Table 4: Benefits of Student Scheduling System Project 5

Table 5: ROI Analysis 5

Table 6: Level of Service Feasibility 6

Table 7: Capability Requirements and Their Feasibility Evidences 6

Table 8: Evolutionary Requirements and Their Feasibility Evidences 8

Table 9: Rationales for Selecting Architected Agile Model 9

Table 10: Risk Assessment 11

Table of Figures

Figure 1: ROI Analysis Graph 5

FED_FCP_F12a_T06_V2.5.doc Version Date: 11/12/2012

Feasibility Evidence Description (FED) for Student Scheduling System Version 2.5

1. Introduction

1.1 Purpose of the FED Document

The purpose of the Feasibility Evidence Description is to reveal/track the risks related to system in early stages, to report the evidences of project feasibility in terms of business case analysis, risk assessment, ROI, architectural feasibility, evolutionary feasibility and process feasibility and provide mitigation plans for identified risks.

1.2 Status of the FED Document

This version belongs to Final FC Package. (Version 2.5)

Sections required for passing to the Foundations Phase are added and evaluated for the FCP. Existing sections and tables are improved with respect to the comments during the ARB. Comments related to algorithm prototyping are going to be added after the first iterations of foundations phase. Project risks and mitigation plans are revised / rescored in this new version and described in more detailed view.

Table of contents, tables, figures and version history are added.

Some bugs and defect related to the format are treated. Hardware and software costs tables are merged.

Cost analysis, benefits analysis and Return-on-Investment analysis were reevaluated and added to the new version under the Section 2.

Resolved risks were removed and existing ones were updated.

Architecture and process feasibility sections which were updated with respect to the OCD, SSAD and current COCOMO estimations were added.

Bad data were removed. Person-hours quantities are updated.

2. Business Case Analysis

Program model which serves a basis of the project is given below as Table 1.

Table 1: Program Model

Assumptions:
· Students and advisor will use the new system.
· Available courses and degree requirements will be kept up to date.
Stakeholders / Initiatives / Value Propositions / Beneficiaries
· Developers
· Undergraduate students of Stevens (undergraduate CS, IS, and CyS majors)
· Course directors
· Advisers
· Administrators
· Software maintainers / · Deliver the system.
· Fill the data base with initial data.
· Inform new students about the systems.
· Hold training sessions for students.
· Move server from USC hosting to Stevens hosting and maintain the server.
· Enhance the system. / · Save advisers’ and students’ time
· Reduce students’ frustration
· Reduce number of mistakes in a schedule made by students / · Stevens’ students (undergraduate CS, IS, and CyS majors)
· Stevens’ advisors (undergraduate CS, IS, and CyS majors)
Cost
- Personnel costs
- Hardware costs
- Software costs / Benefits
- Decrease effort and time to build study plans.
- Decrease frustration resulted from lack of understanding degree requirements.
- Create system availability for anytime and anywhere with internet connection.
- Increase understanding of degree requirements by the students.

2.1 Cost Analysis

2.1.1 Personnel Costs

Personnel costs of the project in terms of effort are given in Table 2 below.

Table 2: Personnel Costs

ACTIVITIES / TIME SPENT (Hours)
Development Period (24 Weeks)
Exploration, Valuation and Foundations Phase: (CSCI 577a 12 Weeks)
Online client meetings via video-conference [2 hours/week * 12 week * (6+1 people)] / 168
Online client win-win sessions [2 hours * 3 sessions * 7 people] / 42
Architecture review boards [2 hours * 3 sessions * 6 people] / 36
Analyzing current system & identifying shared vision / 40
System and software requirements development / 15
Analyzing proposed system / 15
Defining required architecture / 10
Defining life-cycle plan / 20
User interface prototyping / 5
Producing feasibility evidences / 15
Quality management, debugging / 15
Creating project website / 15
Documenting / 40
Team meetings / 30
Subtotal / 466
Development and Operation Phase: (CSCI 577b 12 Weeks)
Online client meetings via video-conference [2 hours/week * 12 weeks * (6+1 people)] / 168
Maintainer training sessions / 20
Architecture review boards [2 hours * 3 sessions * 6 people] / 36
Implementation [10 hours * 3 people * 10 weeks] / 300
Testing / 100
Performing core capabilities drive-through / 10
Verifying and validating work products / 20
User training [3 sessions] / 6
Prototyping / 10
Commitment Reviews, Client Negotiations / 10
Documenting / 20
Maintenance Period(Annual)
Maintenance / 80
Course Information Submission / 40
Subtotal / 120
TOTAL / 1196

2.1.2 Hardware and Software Costs

The hardware and software cost lists belong to the system are given below in Table 3 separately.

Table 3: Hardware and Software Costs

Development
TYPE / COST / RATIONALE
Java SDK / $0 / Since it is open source software, there is no cost for this item.
MySQL Dev. Kit / $0 / Since it is open source software, there is no cost for this item.
Balsamiq / $0 / Free demo version is used for project, thus there is no cost for this item.
COCOMOII / $0 / Since it is available for CSCI577 students’ use, there is no cost for this item.
Microsoft Project / $0 / USC grants free license for this software so there is no cost for this item.
BugZilla / $0 / USC grants free license for this software so there is no cost for this item.
Winbook / $0 / Since it is available for CSCI577 students’ use, there is no cost for this item.
iStudio / $0 / Since it is available for CSCI577 students’ use, there is no cost for this item.
PHP SDK / $0 / Since it is open source software, there is no cost for this item.
Apache Web Server / $0 / Since it is open source software, there is no cost for this item.
Subtotal / $0
Operation
TYPE / COST / RATIONALE
Hardware Web-Server / $0 / The current server of Stevens Institute of Technology will be used for this item. So there is no additional cost.
Hardware Web-Hosting / $0 / The current hosting of Stevens Institute of Technology will be used for this item. So there is no additional cost.
TOTAL / $0

2.2 Benefits Analysis

Reducing time and effort of study plan buildings and face-to-face conversations between advisors-students of course plan discussions. They are given in Table 4 below.

Table 4: Benefits of Student Scheduling System Project

Current Methods / Activities* / % Reduce / Time Saved (Hour/Year)
Students to realize degree/course requirements
[1,5 hour Average for one student, 2500 students * 1,5hour = 3750 hours] / 40% / 1500 hours
Administrative helping students to build study plans
[10 min average per student, 2500 students * 10 min = 433 hours] / 50% / 216 hours
Students build study plans
[2 hour average per student, 2500 students * 2 = 5000 hours] / 80% / 4000 hours
Informing students about their graduate requirements
[5 mins average per student, 2500 students * 5mins = 208 hours] / 40% / 83 hours
TOTAL / 5799 hours

*Averages are sum of three semesters per year.

2.3 ROI Analysis

Table 5: ROI Analysis

Year / Cost / Benefit / Cumulative Cost / Cumulative Benefit / ROI
2012 / 466 / 0 / 466 / 0 / -1.00
2013 / 730 / 1933* / 1196 / 1933 / 0.62
2014 / 132** / 5799 / 1328 / 7733 / 4.82
2015 / 145** / 5799 / 1473 / 13534 / 8.18

*For only fall semester (1 year’s benefit/3)

**10% increase annual in maintenance cost

Figure 1: ROI Analysis Graph

3. Architecture Feasibility

3.1 Level of Service Feasibility

In Table 6 below, the level of service requirements are stated with their feasibility evidences next to each.

Table 6: Level of Service Feasibility

Level of Service Requirement / Product Satisfaction
LOS-1: Returned Results / Product Strategies: Java, MySQL
Process Strategies: Organize database, connect database to user interface
Analysis: The current system is manual. The project aims to save time by synchronizing student-course database and user inputs to build best schedule meet user graduate date. The development team has to implement an algorithm to solve this problem with respect to its constraints.
LOS-2: The system must calculate the results within 2 minutes. / Product Strategies: Java, MySQL
Process Strategies: Optimize algorithm, use solver Java library, provide well-defined database
Analysis: The customer requires the system to build the demanded study plan within 2 minutes, thus the development team must use a strong algorithm capable of solving multi-dimensional scheduling problems and the system has to reach needed data from the database fast.

3.2 Capability Feasibility

System capability requirements negotiated on Win-Win sessions are given in Table 7 with their feasibility evidences.

Table 7: Capability Requirements and Their Feasibility Evidences

Capability Requirement / Product Satisfaction
CR-1: Schedule Construction: System will find best possible schedule match, if it exists, for the student using information entered by the student. / Software/Technology used: Java
Feasibility Evidence: For this requirement, we will prototype a working version of the final deliverable.
Referred use case diagram: SSAD process diagram.
CR-2: Degree Requirements Storage: Information regarding degree requirements will be stored in the database / Software/Technology used: MySQL
Feasibility Evidence: We will build an example database for working prototype.
Referred use case diagram: SSAD process diagram.
CR-3: Course Information Storage: Information regarding the different courses that can fulfill degree requirements will be stored in the database / Software/Technology used: MySQL
Feasibility Evidence: We will build an example database for working prototype.
Referred use case diagram: SSAD process diagram.
CR-4: User Interface: Students and administrators will be able to access the system using a user interface / Software/Technology used: Java
Feasibility Evidence: User interface prototype.
Referred use case diagram: Prototype report.
CR-5: User Login: Students and Administrators will be able to login and will be displayed either the student or administrative side of the / Software/Technology used: Java
Feasibility Evidence: User interface prototype.
Referred use case diagram: Prototype report, SSAD process diagram.
CR-6: Student Supplied Information: System will accept student supplied information to calculate schedule. This includes desired completion semester, courses completed, specific courses desired(if any), year of entry, degree program, specific semesters for specific courses, location of classes. / Software/Technology used: Java
Feasibility Evidence: For this requirement, we will develop working version of the final deliverable with an example database.
Referred use case diagram: SSAD process diagram, design class diagram.
CR-7: Administrator Supplied Information: System will accept administrator supplied information including course information and degree requirements. / Software/Technology used: Java
Feasibility Evidence: For this requirement, we will develop working version of the final deliverable with an example database.
Referred use case diagram: SSAD process diagram, design class diagram.
CR-8: Issue Resolution: If schedule construction fails, system will return suggestions for the student so that a schedule can be successfully created. / Software/Technology used: Java.L
Feasibility Evidence: For this requirement, we will develop working version of the final deliverable with an example database. And it is also showed in user interface diagram.
Referred use case diagram: SSAD process diagram, design class diagram.

3.3 Evolutionary Feasibility

Evolutionary requirements with related feasibility evidence are given in Table 8.