Feasibility Evidence Description (FED) for NDI/ NCS Version 3.0

Feasibility Evidence Description (FED)

Leamos

Team number 7

Name Email Address Primary Role Secondary Role Monty Shah [email protected] Project Manager Life Cycle Planner David Wiggins [email protected] IIV&V Off-campus Shaper Pragya Singh [email protected] System Architect Prototyper Requirements Shantanu Sirsamkar [email protected] Feasibility Analyst Engineer Operational Concept Suchita Doshi [email protected] Prototyper Engineer Swapnil Savdekar [email protected] Life Cycle Planner System Architect

Version Date 11/20/2011 Feasibility Evidence Description (FED) for NDI/ NCS Version 3.0

FED_DCP_F11a_T07_V3.0 ii Version Date: 11/20/11 Feasibility Evidence Description (FED) for NDI/ NCS Version 3.0

Version History Date Author Versio Changes made Rationale n  The document was created with  Created document, added section 09/27/11 Monty 1.0 the risks that the project faces 5 and how to mitigate them. 10/05/11 Monty 1.1  Modified section 5  Fixed bugs as reported by David.  The risks have been modified post the win-win negotiation  Changed to template for NDI with the client. The section 1 has 10/08/11 Monty 2.0  Added section 1,3,4.1, 4.2.1 and been added as part of the Core 4.2.2 FC package. The project features are to be built on the Moodle platform hence is a NDI project.  The sections were added as part  Added section 2, 5 and other of the draft FC package. The 10/14/11 Monty 2.1 sections of 4. Modified section 1, bugs were modified as per the 4 based on the bugs review given by the TA and the QA.  The document bugs were fixed, 10/18/11 Monty  Fixed bugs 2.2 table descriptions were added.  The changes were respect to the 10/23/11 Monty 2.3  Changes made to all sections review during the ARB session.  Minor bug fix  The changes were mostly spell 11/7/11 Monty 2.4 errors ( eg swiffy, r1 –reviewer 1) 11/20/11 Monty 3.0  Added section 6  The last section was filled.

FED_DCP_F11a_T07_V3.0 iii Version Date: 11/20/11 Feasibility Evidence Description (FED) for NDI/ NCS Version 3.0

Table of Contents

Feasibility Evidence Description (FED)...... i

Version History...... iii

Table of Contents...... iv

Table of Tables...... v

Table of Figures...... vi 1. Introduction...... 1 1.1 Purpose of the FED Document...... 1 1.2 Status of the FED Document...... 1 2. Process Feasibility...... 2 3. Risk Assessment...... 4 4. NDI/NCS Feasibility Analysis...... 6 4.1 Assessment Approach...... 6 4.2 Assessment Results...... 6 4.3 Feasibility Evidence...... 8 5. Business Case Analysis...... 11 5.1 Market Trend and Product Line Analysis...... 11 5.2 Cost Analysis...... 11 5.3 Benefit Analysis...... 13 5.4 ROI Analysis...... 13 6. Conclusion and Recommendations...... 15

FED_DCP_F11a_T07_V3.0 iv Version Date: 11/20/11 Feasibility Evidence Description (FED) for NDI/ NCS Version 3.0

Table of Tables

Table 1: Rationales for Selecting Architected Agile Model...... 2 Table 2: Requirement Prioritization...... 2 Table 3: Risk Assessment...... 4 Table 4: NDI/NCS Products Listing...... 6 Table 5: Evaluation Criteria – NDI /NCS Attributes...... 7 Table 6: Evaluation Criteria - NDI/NCS features...... 7 Table 7: Evaluation Results Screen Matrix...... 8 Table 8: Level of Service Satisfiability Evidence...... 9 Table 9: Level of Service Implementation Strategy...... 9 Table 10: Capability Feasibility Evidence...... 9 Table 11: Evolutionary Feasibility Evidence...... 10 Table 12: Market Trend and Product Line Analysis...... 11 Table 13: Personnel Costs...... 11 Table 14: Hardware and Software Costs...... 12 Table 15: Benefits of xxx System...... 13 Table 16: ROI Analysis...... 13

FED_DCP_F11a_T07_V3.0 v Version Date: 11/20/11 Feasibility Evidence Description (FED) for NDI/ NCS Template Version 2.4

Table of Figures

Figure 1: ROI Analysis Graph...... 14

Version Date 11/20/2011 Feasibility Evidence Description (FED) for NDI/ NCS Version 3.0

A.1. Introduction A.1.1 Purpose of the FED Document

The purpose of the FED document is to document the business case analysis of the Centro Latino Organization which includes the cost of the project being undertaken. It also points to the benefits/savings the project will bring to the organization and the timeline for the return of investment. The FED also describes the risks in the project and the plan to mitigate them.

A.1.2 Status of the FED Document

Sections have been added for the Business analysis and the process feasibility. The risks have remained unchanged so far. All sections have been complete except section 6. The changes have been made to tailor it for the FC package. The risks have been modified as per the recent client visit.

FED_DCP_F11a_T07_V3.0 1 Version Date: 11/20/11 Feasibility Evidence Description (FED) for NDI/ NCS Version 3.0

A.2. Process Feasibility

Table 1: Rationales for Selecting NDI-intensive

Criteria Rationales Size, Complexity Based on the requirements, the project size is big. The requirements are complex (high) since the requirements deal with modifying the existing code base of a third party course merchant which is always very difficult. Change Rate % /Month 3%, changes will be low. Criticality Medium, the system in use is for teaching students. If the system went down the data is still available in the database and once the system is up the students can resume from where they stopped. NDI Support This is NDI intensive, we will be using Moodle Platform and will be developing requirements on top of the platform. Org/Personnel Capability The developers are ramping up on php which will be used to a large extent. The developers have ramped up on HTML5 and how to embed the videos in HTML5. Key Stage I Activities : Complete Valuation, including the Foundations Commitment Incremental Definition Review and Development Commitment Review. Key Stage II Activities: Rebaselined Foundations phase and Development phase will Incremental Development, be completed. Including The Rebaselined Development Operations Commitment Review and Operation Commitment Review Time per Build; Time per build, we will require 3 months to complete the Time per Increment functionality as required (will need 577b period to complete the requirements). Time per Increment: we will need about 3 weeks per increment.

Table 2: Requirement Prioritization

Priority Requirements References Increment # 1 Convert Flash files to HTML5 WC_478 1 2 Migrate the data from old to new database WC_252 1 3 Generate reports WC_985 1 4 Add lessons to Leamos and proper documentation WC_986 1 5 Forgot password WC_244 2 We need to create a user friendly interface for students 2 (should have bigger text ,continuous flow , minimizing 6 WC_725 clicks , less distractions )

Sales website, automatic creation of accounts, 1 7 WC_245 organizations to be able to manage students

A.3. Risk Assessment

The risks that are being faced at this point of time are mentioned in the table below. The risk has been described and the Potential Magnitude (if the risk occurs), the loss (if the risk occurs) are mentioned for each risk. Also how we can mitigate the risk is mentioned in the last column.

Table 3: Risk Assessment

Risk Exposure Risks Potential Probability Risk Mitigations ID Risk Exposure Magnitude Loss 1 Learning curve: Our project 9 10 90 We are planning to needs to be integrated with the create a setup of the Moodle platform. The task of Moodle platform and understanding Moodle platform understand its in order to add code is complex. working. 2 Time constraint: We may be 9 10 90 We will need to get unable to complete all the the priority of the requirements in the given time requirements from (1 semester) frame because the the client. project scope is so large. We will have to extend the project to We will need more a 2 semester project. team members to join us next semester Also since most of the team will with skill set of php be unavailable for 2 semesters and MySQL to join we may need new team us. members for the next semester. 3 Dependencies: One of the 8 9 72 The dependencies requirements related have been to system automation has a communicated to the direct dependency on a client. 3rd party which is currently integrating the course merchant We will mock the module into Moodle. Any delay implementation. on the implementation of the Course Merchant will have a direct impact on the team’s implementation of the requirement. Bugs in implementation of Course merchant will also cause delays on the implementation side. 4 Environment: In order to get 8 9 72 The client will have started we will need the exact to provide the team development environment as with the environment. the current implementation. This has been Also for the migration of data, a agreed upon. copy of the old database system with the mapping details Steve, who has with the new database will need knowledge about the to be handed over to the team. backend, will be transferring the database to the team.

5 Testing Automation feature: 9 8 72 The client and team Testing the automation account will need to find a feature requirement is going to way to bypass the be difficult since it involves the money transfer course merchant module which phase in the course involves money transfer. The merchant in order to transfer of control to the enable testing the automation module will occur automation feature. only after money has been transferred using the course merchant. This dependency will make it difficult to test the automation feature as each time we will need to transfer money using the course merchant module. 6 Talent Management: Since 9 4 36 To mitigate this risk, most of the team which has we will be recording already ramped up might not be our learning’s, to present in the next semester, speed up the ramp there is a risk that the new up process for the members will need to be new members. ramped up again.

A.4. NDI/NCS Feasibility Analysis A.4.1 Assessment Approach

The client is currently using the Moodle 1.9 platform. All the requirements are to be built on the existing Moodle platform so no other NDI needs to be assessed. We have to work on the Moodle platform to complete all the requirements requested by the client.

For converting flash files to HTML5, we need to evaluate tools. There are many tools available in the market which can achieve this conversion including Wallaby, Swiffy, Flash to HTML5 Converter. The goal is to have a tool which can convert without having bugs. The converted HTML5 should work on all modern browsers. The strategy is to use trial versions and evaluate the tools. A.4.2 Assessment Results .4.2.1 NDI/NCS Candidate Components (Combinations)

Table 4: NDI/NCS Products Listing

NDI/NCS Products Purposes Moodle, Wallaby Moodle is a Course management platform which enables courses to be made available online.

Wallaby converts flash files (.fla) to HTML5. Moodle, Swiffy Moodle is a Course management platform which enables courses to be made available online.

Wallaby converts flash files (.fla) to HTML5. Moodle, Flash to HTML5 Converter Moodle is a Course management platform which enables courses to be made available online.

Flash to HTML5 Converter converts flash files (.fla) to HTML5.

FED_DCP_F11a_T07_V3.0 6 Version Date: 11/20/11 Feasibility Evidence Description (FED) for NDI/ NCS Version 3.0 .4.2.2 Evaluation Criteria

Table 5: Evaluation Criteria – NDI /NCS Attributes

No. Evaluation Criteria – NDI/NCS attributes Weight A1 Vendor support 20 A2 Documentation Understandability 20 A3 Maturity of product 10 A4 Cost of License 10 Ability to convert long (30 minutes) flash files 30 A5 (functionality) A6 Ease of installation 10 Total 100

In the above table, the attributes and the weight of the criteria with respect to the other attributes are mentioned. The attributes are the most important attribute that the client wants of the NDI.

Table 6: Evaluation Criteria - NDI/NCS features

No. NDI/NCS Features/ sub features Weight F1 Error Logging 50 F2 .fla and .swf file extension support 50 Total 100

The above table mentions the most critical features we are expecting from the NDI features. The client has both .swf and .fla files. So if any .fla are missing, we should still be able to proceed with the .swf files. If an error occurred, the error should be logged so that we can trace and get more help from the vendor.

.4.2.3 Evaluation Results Screen Matrix

FED_DCP_F11a_T07_V3.0 7 Version Date: 11/20/11 Feasibility Evidence Description (FED) for NDI/ NCS Version 3.0 The below table indicates the results of the evaluation of attributes done on the 3 candidates. Based on the values provided by the reviewer, clearly Wallaby is the preferred tool.

Table 7.1: Evaluation Results Screen Matrix (attributes)

Flash to HTML5 Wallaby Swiffy AVG Converter No W Revi Revi AVG Total AVG Total Revi Revi Total Revie Revie ewe ewer ewer ewer wer 1 wer 2 r 1 2 1 2 A1 20 10 10 10 200 1 1 1 20 10 10 10 200 A2 20 10 10 10 200 1 1 1 20 5 5 5 100 A3 10 10 10 10 100 1 1 1 10 5 5 5 50 A4 10 10 10 10 100 10 10 10 100 1 1 1 10 A5 30 10 10 10 300 1 1 1 30 10 10 10 300 A6 10 10 10 10 100 10 10 10 100 10 10 10 100

Total 100 100 100 100 1000 24 24 24 270 41 41 41 760

The below table indicates the results of evaluations done on features of the 3 candidates. Wallaby and Swiffy are free, Flash to HTML5 has a license fee. Swiffy converts only small flash files. The flash files which need to convert are large and hence we cannot use Swiffy.

Table 7.2: Evaluation Results Screen Matrix (features)

Flash to HTML5 Wallaby Swiffy Converter AVG No W Revi Revi AVG Total AVG Total Revi Revi Total Revie Revie ewe ewer ewer ewer wer 1 wer 2 r 1 2 1 2 F1 50 5 5 5 250 0 0 0 0 5 5 5 250 F2 50 10 10 10 500 5 5 5 250 10 10 10 500

Total 100 15 15 15 750 5 5 5 250 15 15 15 750

A.4.3 Feasibility Evidence

The capability feasibility of the requirements has been described below:

.4.3.1 Level of Service Feasibility

Table 8: Level of Service Satisfiability Evidence

Level of Service Win Condition Rationale Usability – System should be easy to use The User interface needs to be very easy to use

to enable users to easily adapt to the website. We plan to achieve this by having bigger fonts and we will also do a testing on a set of students and check if it is more usable than before.

Table 9: Level of Service Implementation Strategy

Level of Service Win Condition Product Satisfaction WC_241 Product Strategies: Make the user interface easier to use Process Strategies: Use bigger text size, good fonts. Analysis: The students can easily adapt to a easier user interface since they are still learning how to read and write.

.4.3.2 Capability Feasibility

Table 10: Capability Feasibility Evidence

Capability Requirement Product Satisfaction CR-1: Authentication and Software/Technology used: php, MySQL authorization Feasibility Evidence: We will need to write code in php as part of the client login functionality which will authenticate and authorize the client. Also for students we will implement the forgot password page. Referred use case diagram: UC1, UC2 CR-2 : HTML5 lessons Software/Technology used: php, html5 Feasibility Evidence: The php currently display the flash files, we will need to use HTML5 to embed the videos and use php to display the same. Referred use case diagram: UC3 CR-3: Sales websites, Software/Technology used: php, MySQL account creation, Feasibility Evidence: The sales website will be created using php Management of the and the backend will be MySQL. This will then call the Course Students by the Merchant services which will then pass the control back to us, post organizations. which we will create account for customer and enable him to create / manage student accounts based on the number of licenses he bought. Referred use case diagram: UC4, UC5, UC6 CR-4: Adding new lessons Software/Technology used: php, MySQL and documentation Feasibility Evidence: We will manually add new lessons to Moodle using php and MySQL and we will document the same so that the maintainers can follow the steps and add new lessons on their own.

Referred use case diagram: UC7

.4.3.3 Evolutionary Feasibility

Table 11: Evolutionary Feasibility Evidence

Evolutionary Win Condition Rationale ER-1: Add course module In future Leamos is going to add more courses to the existing courses. This is possible but due to time constraints, its going to be a separate project by itself, so instead, we are going to provide a good documentation to be add courses for now.

A.5. Business Case Analysis A.5.1 Market Trend and Product Line Analysis

Table 12: Market Trend and Product Line Analysis

Moodle php mySQL Market Trend Moodle is the most A popular language. Use mySql is a free database popular Learning primarily on the open solution, which is used Management Software source platforms. by a lot of open source in the market. The web platforms like Moodle. traffic details are as It has more than 25% follows: Moodle : 150 market share. per million, Sakai : 20 per million. So its far ahead of its competitors. Product Line Owned by Moodle Open source Owned by Oracle which started in the year (founded in the year 1999. It has a very stable 1977), has stable Learning Management product used by most System (currently the open source products as most popular). a backend.

A.5.2 Cost Analysis

.5.2.1 Personnel Costs

Table 13: Personnel Costs

Activities Time Spent (Hours) Valuation and Foundations Phases: Time Invested (CS577a, 12 weeks) Client: Meeting at office/site [0.5 hours/week * 12 weeks * 2 persons] 12 Communication between client and the team members which includes 24 email, phone [1 hour/week * 12 weeks * 2 persons] Win Win Session [1 hours * 3 * 2 person] (twice we had win win + we 6 had to call clients 1 more time for the win-win tool) Architecture Review Boards (ARB) [1 hour * 2 times * 2 persons] 4 (includes a board member from the clients location.

Total: 46

Development and Operation Phases: Time Invested (CS577b, 12weeks) (This is an approximation) Client: Meeting at office [1hours/week * 6 weeks * 2 persons] 12 Maintainer: Meeting via Email, Phone, and other Channels [2 hours/week * 72 12weeks * 3 persons] Architecture Review Boards and Core Capability Drive-through session [1.5 13.5 hours /week* 3 times * 3 persons] Deployment of system in operation phase and training - Installation & Deployment [3hours/week * 1 times * 2 person] 14 - Training & Support [2 hours/week * 2 times * 2 person] Client/Client Representatives Communication via Email, Phone, and other 24 Channels [2 hour/week * 12 weeks * 1 persons] Total: 181.5

Maintenance [5 hours/week * 52 weeks] 260

.5.2.2 Hardware and Software Costs

Table 14: Hardware and Software Costs

Type Cost Comments Moodle platform $0 Currently being used and is open source. Webserver $0 Apache is being used which is open source MySQL $0 Open source backend which is free Php $0 Php has no license fee Flash to html5 conversion tool $0 If wallaby is going to be used after the clients consent then it’s free. Total $0

FED_DCP_F11a_T07_V3.0 12 Version Date: 11/20/11 Feasibility Evidence Description (FED) for NDI/ NCS Version 3.0 A.5.3 Benefit Analysis

Table 15: Benefits of System

Current activities & resources used % Reduce Time Saved (Hours/Year)

Report generation (every week the client spends 8 hours per month and after the 87.5 84 automation, the client will spend 1 hour per month) Client calls currently 100 calls per month (10 min per call). This includes for creating accounts and solving forgot password issues which the new system aims to automate. 50 179.16 Plus during certain times of the year (around 2 weeks) the client receives 100 calls per week. This will be reduced. Maintaining of old system will not be used any more. Currently the client spends 1 hour per week on maintaining the old system. 100 104 After migration of data, the client will no longer use the old system. Total 367.16 A.5.4 ROI Analysis

10% increase in maintenance of the system. (Value assumed as given in EPG)

The table below gives an idea of how soon the return of investment will be returned to the client. Its calculates the cost and the benefits. The benefits outdo the cost eventually. The cost column is taken from the table 14 and the benefit is taken from table 16.

Table 16: ROI Analysis

Benefit Cumulative Cumulative Year Cost ROI (Effort Saved) Cost Benefit 2011 181.5 0 181.5 0 -1 2012 260 367.16 441.5 367.16 -0.20 2013 260 367.16 701.5 734.32 0.04 2014 260 367.16 961.5 1101.48 0.127 2015 260 367.16 1221.5 1468.64 0.167

Figure 1: ROI Analysis Graph

A.6. Conclusion and Recommendations

As per the feasibility evidence result following is the list of recommendations.  NDI Intensive process pattern is the most suitable process for the project  Wallaby achieves the requirement to convert flash files to html5.  The business case analysis shows that the project is feasible.

The document is complete and might change based on the future client interaction.

FED_DCP_F11a_T07_V3.0 15 Version Date: 11/20/11