Feasibility Evidence Description (FED)

Transcription

1 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 Simone Lojeck : IV&V, Shaper, QFP February, 20, 2013

2 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 /21/2012 Ihsan Tolga /22/2012 Ihsan Tolga 2.00 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. Formatting Program model revised Architecture feasibility defined and added. Process Feasibility defined, graded and added. Risk assessment table updated with the current stage of the project. 10/23/2012 Ihsan Tolga 2.1 Captions and footers are updated. 10/28/2012 Ihsan Tolga 2.2 Bugs resolved. Risk assessment table revised. 10/30/2012 Ihsan Tolga 2.3 Captions, risk table revised, bugs fixed. 11/03/2012 Ihsan Tolga 2.4 Defects fixed with respect to the ARB comments. 11/12/2012 Ihsan Tolga 2.5 Defects fixed. Bad data removed. 11/25/2012 Ihsan Tolga 3.0 Defect fixed. Cost/Benefit analysis revised, ROI recalculated. Feasibility evidences revised. Risk assessment table revised. 12/04/2012 Ihsan Tolga 3.1 Bugs fixed. Section 6 added. Risk table revised. ROI table fixed. 12/13/2012 Ihsan Tolga 3.2 Comment from the DCR ARB added, related bugs resolved. Ambiguous risk definitions were detailed. Section 1 definitions were detailed. Program model is compatible with current OCD. Feasibility attributes defined according to the mutual agreement between stakeholders. Architecture feasibility defined with respect to the OCD and SSAD. Footer information and table captions are compatible. Updated for ARB presentation and current risk status. Risk table is current for the FCP. Fixes according to the ARB review. Defects resolved and tables were updated. Defects were fixed and changes were made with respect to the ARB comments and evaluation of FC Package. Defects were fixed. Section 6 was added. NDIs are shown. Risk mitigation table was updated. Tables were revised with respect to the DCR ARB comments, Bugs are fixed. ii

3 Date Author Version Changes made Rationale 02/07/2013 Ihsan Tolga /20/2013 Ihsan Tolga 4.1 Feasibility evidences updated, risk table revised. Bugs fixed with respect to the comments. Table revision with respect to ARB comments. NDI/NCS analysis remade. Risk mitigation updated. Feasibility evidence statements clearer. Revised risk mitigation table. Added NDI/NCS items, revised evolution, risk mitigation tables. iii

4 Table of Contents Feasibility Evidence Description (FED)... i Version History... ii Table of Contents... iv Table of Tables... v Table of Figures... vi 1. Introduction Purpose of the FED Document Status of the FED Document Business Case Analysis Cost Analysis Benefits Analysis ROI Analysis Architecture Feasibility Level of Service Feasibility Capability Feasibility Evolutionary Feasibility Process Feasibility Risk Assessment NDI/NCS Interoperability Analysis Introduction Evaluation Summary iv

5 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... 6 Table 6: Level of Service Feasibility... 7 Table 7: Capability Requirements and Their Feasibility Evidences... 8 Table 8: Evolutionary Requirements and Their Feasibility Evidences... 9 Table 9: Rationales for Selecting Architected Agile Model Table 10: Risk Assessment Table 11: NDI Products Listing Table 12: NDI Evaluation v

6 Table of Figures Figure 1: ROI Analysis Graph... 6 vi

7 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 Rebaselined Development Commitment Package. (Version 4.1) Sections required for entering to the Rebaselined Development Phase are revised and evaluated for the RDCP. Existing sections and tables are re-updated with respect to the comments during the latest ARB evaluations. Comments related to algorithm modules and solving methods are added after the first iteration of CS577b course in the new semester. Project risks and mitigation plans are revised / rescored for the new version and described in more detailed view. Some bugs and defect related to the format are treated. Defects were removed with respect to the ARB session comments. NDI/NCS evolution table was revised. Cost analysis, benefits analysis and Return-on-Investment analysis were re-evaluated and added to the new version under the Section 2. There is no recorded change related to them. Resolved risks were removed and existing ones were updated. Architecture and process feasibility sections which were updated with respect to the OCD, SSAD and updated COCOMO estimations were added. Bad data were removed. Person-hours quantities are updated. Risks related to solver algorithm and mathematical analysis were alleviated, thus they are expressed in feasibility section and the risk management table was updated with respect to this. Before Rebaselined Development Commitment Review ARB session, risk table and assessment plan were updated. 1

8 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

9 2.1 Cost Analysis 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 * ( people)] Online client win-win sessions [2 hours * 3 sessions * 7 people] 42 Architecture review boards [2 hours * 3 sessions * 6 people] 36 Subtotal 246 Development and Transition Phase: (CSCI 577b 12 Weeks) Online client meetings via video-conference [2 hours/week * 12 weeks * ( people)] Maintainer training sessions 30 System Transition (Installing on school web-site, starting hosting) 60 Architecture review boards [2 hours * 3 sessions * 6 people] 36 User training [3 sessions] 30 Commitment Reviews, Client Negotiations 30 Subtotal 354 Maintenance Period(Annual) Maintenance 240 Course Information Submission 90 Subtotal 350 TOTAL 950 3

10 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. JDBC 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 4

11 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 40% 1500 hours [1,5 hour Average for one student, 2500 students * 1,5hour = 3750 hours] Administrative helping students to build study plans 50% 216 hours [10 min average per student, 2500 students * 10 min = 433 hours] Students build study plans 80% 4000 hours [2 hour average per student, 2500 students * 2 = 5000 hours] Informing students about their graduate requirements 40% 83 hours [5 minutes average per student, 2500 students * 5mins = 208 hours] TOTAL 5799 hours *Averages are sum of three semesters per year. 5

12 2.3 ROI Analysis Return-on-Investment analysis of the Student Scheduling System project is given in the Table 5 below and related graph is shown in Figure 1. Table 5: ROI Analysis Year Cost Benefit Cumulative Cost Cumulative Benefit ROI * ** ** *For only fall semester (1 year s benefit/3; system will be available before Fall 2013) **10% increase annual in maintenance cost Figure 1: ROI Analysis Graph Dots show the end year values Year and time spots. ROI 6

13 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 LOS-1: Returned Results LOS-2: The system must calculate the results within 2 minutes. Product Satisfaction Product Strategies: Java, MySQL Process Strategies: Organize database, connect database to user interface Analysis: The current system is manual. The draft solver algorithm works well with the given example schedule constraints. The project solves this problem by constructing a course schedule and saves great deal of time spent on it. Product Strategies: Java, MySQL, Using prototype algorithm/constraint solver with test-case constraint with respect to the formalism for specifying requirements. 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. The prototype algorithm solves multi-constraint scheduling problems in several seconds with given test-case constraints. Yet with more than a thousand constraints in effect for the same solution, it exceeds the given time in some situations. (Selecting linear programming methods possible) It is not expected to increase rapidly. Relaxation of this requirement is being discussed. Not guaranteed solution for every given case is the most possible relaxation. 7

14 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 CR-1: Schedule Construction: System will find best possible schedule match, if it exists for the student, using information entered by the student. CR-2: Degree Requirements Storage: Information regarding degree requirements will be stored in the database CR-3: Course Information Storage: Information regarding the different courses that can fulfill degree requirements will be stored in the database CR-4: User Interface: Students and administrators will be able to access the system using a user interface CR-5: User Login: Students and Administrators will be able to login and will be displayed either the student or administrative side of the product 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. CR-7: Administrator Supplied Information: System will accept administrator supplied information including course information and degree requirements. CR-8: Issue Resolution: If schedule construction fails, system will return suggestions for the student so that a schedule can be successfully created. Product Satisfaction Software/Technology used: Java Feasibility Evidence: Current draft constraint solver works within limits for majority of cases with given constraints. Referred use case diagram: SSAD process diagram, solver module. Software/Technology used: MySQL Feasibility Evidence: Administrative side can input the course data with the user interface and we defined test-case course information and constraints which work well with the draft solver algorithm. Referred use case diagram: SSAD process diagram. Software/Technology used: MySQL Feasibility Evidence: Test-case course information and constraints were defined and we set an agreement upon the format with the customer. Database connection structure is defined. Referred use case diagram: SSAD process diagram. Software/Technology used: Java Feasibility Evidence: Some user interface classes and pages were implemented as initial versions and an agreement was set with the customer upon these user interface pages. Referred use case diagram: Prototype report. Software/Technology used: Java Feasibility Evidence: Index page and user interface pages can get user data and approved as appropriate by the customer. Referred use case diagram: Prototype report, SSAD process diagram. Software/Technology used: Java Feasibility Evidence: Algorithm/solver draft version works well with current test-case constraints and input zones and information types were defines with respect to the constraint arguments. Relaxation for response time is being discussed with the customer which can provide a complete satisfaction. Referred use case diagram: SSAD process diagram, design class diagram. Software/Technology used: Java Feasibility Evidence: Prototype algorithm/solver works well with the given test-case constraints and course information. Controller classes collect the input data. Administrative side has input fields for course definitions. Referred use case diagram: SSAD process diagram, design class diagram. Software/Technology used: Java. Feasibility Evidence: System throws an error message or does no operation for blank data or false data. (Error message.) Work is in progress for heuristic methods to be able to lead user to input correct data.) Referred use case diagram: SSAD process diagram, design class diagram. 8

15 3.3 Evolutionary Feasibility Evolutionary requirements with related feasibility evidence are given in Table 8. Table 8: Evolutionary Requirements and Their Feasibility Evidences Evolutionary Requirement ER-1: The administrative in the customer side must have the capability of adding new courses or changing the course requirements and information. Product Satisfaction Software/Technology used: Java, MySQL Feasibility Evidence: System architecture was designed by considering this fact, and administrative controller was coded to enable administrative side to add new courses or altering requirements / information related. There are Add Course pages to get new course data from administrative and compose related data in database via controller classes and database connection. Referred use case diagram: SSAD Behavior Section, OCD System Capability Description 9

16 4. Process Feasibility Rationales for selecting architected agile model as the project model are given in the Table 9 below. Table 9: Rationales for Selecting Architected Agile Model Criteria Importance Project Status Rationales 30 % of NDI/NCS features 1 1 The project uses JDK, MySQL and Apache for the server side. There is an agreement on using them currently. Single NDI/NCS 1 1 There is no strong need for single NDI/NCS use. Unique/ inflexible business process Need control over upgrade / maintenance 2 3 All of the requirements are constant which assessed from the client meeting. So the change rate is calculated as 1% per month. 1 3 The system needs low level maintenance after delivery. The training sessions will be held for maintainers. Rapid deployment 1 1 There is no need for rapid development for the project. Critical on compatibility 1 2 Criticality is medium-low. Because the current system runs even it is slow. There is no immediate or vital need for this system to begin operating. And there is strict constraint on platform selection. Internet connection independence 1 1 The system will work on web-page so the internet connection is vital for the system. Need high level of services / performance 2 4 There is moderate level of services and performance for the project. Need high security 1 2 There is no high level of security for the system, there will be no course registration or account for the student side. Asynchronous communication 1 1 There will be synchronized communication between modules for stability. Be accessed from anywhere 1 2 The system has to have capability to be accessed anywhere since it is a web-based system. Critical on mass schedule constraints 2 3 The student scheduling system project is a medium size project which we realized after analyzing the required system and client meetings. According to the COCOMO estimations Lack of personnel capability 1 2 The project team members are capable with the tools and analyzing skill for the project. Require little upfront costs 1 2 There will be no monetary cost for the project. Require low total cost of ownership 1 1 There will be no monetary cost for the project and it is developed for the CS577 students for class. Not-so-powerful local machines 1 3 The servers of the Stevens Institute of Technology are capable to run the system according to the customer. 10

17 5. Risk Assessment In this section of the Feasibility Evidence Description document, the Table 10 below shows the possible risk of the system and related mitigation plans. Potential magnitudes, probabilities of loss and calculated risk exposures are identified in the same rows of their related risks. Table 10: Risk Assessment Risk Exposure Risks Potential Probability Risk Risk Mitigations Magnitude Loss Exposure Undeveloped complex algorithm Developing an early algorithm during Foundations Phase as a prototype which works with a smaller domain. Long response (for study plan building) time compared to the requirements Prototyping constraint solver module with test-case information in the foundation phase for benchmarking and feedback.. Not designated maintainers It is mentioned to the client (Nature of CS577a/b schedule) since it is client side s responsibility to maintain system after the transition phase. Stevens web hosting maintainers may be responsible for this role. The interface required by the customer and provided by the development team may be different. Team process inexperience related to ICSM methods. Requirements Volatility (New procedures by Stevens management) Prototyping complete user interfaces in the foundation phase and give feedbacks from the customer about its defects and strong points and setting a final agreement upon them Following ICSM EPG guideline, package reviews by TAs and evaluations Prototyping, weekly negotiations, sharing implemented modules with customer. Relaxation negotiations. 11

18 6. NDI/NCS Interoperability Analysis 6.1 Introduction After our search and evaluations, we decided to use CHOCO Java library to use in the solver module COTS / GOTS / ROTS / Open Source / NCS Table 11: NDI Products Listing NDI/NCS Products CHOCO Java Library JDBC Java Database Connectivity MySQL PLAY Framework Purposes To use its defined functions/classes in the solver module. It is an open source library thus it brings no extra cost for the project. It will be used for interconnecting database module to schedule builder and view control modules. It is used for implementing database entities and module. (Course information, constraints.) This open source framework for Java provides a strong basis for web-based application, saves time on implementing user interface and controllers Connectors In the project: we use JDBC Database Connector to connect course information as an input from the users/administrators to course information database module which is being implemented with MySQL. Also for the opposite direction, the data should be retrieved from the database for solver algorithm to calculate constraints and build a study plan. 12

19 6.1.3 Legacy System There is no software legacy system for the project. In the other words; they are building study plans at Stevens Institute of Technology manually by using common course tracks and recommendations. So the system is going to replace this manual system. 6.2 Evaluation Summary Table 12: NDI Evaluation NDI Usages Comments CHOCO Java Library Solver module Saves great deal of time for schedule constraint solving and mathematical constraint models. It has good help documents and brings no extra costs JDBC Java Database Connectivity Connection of Database module to other modules since it is an open source library. It will be used for interconnecting MySQL bases database module to schedule builder, authentication and view control modules. It brings no extra costs. MySQL Database It is quite capable for the database needs and brings no extra costs since it is open source. PLAY Framework User interface, Controllers It is a quality-proven, commonly used framework for web-based applications and saves a great deal of time on implementing controller / interface classes, interactions and instances. With this aid, more focus can be given on more risky aspect of the project. 13