Feasibility Evidence Description (FED) for NDI/ NCSVersion 2.3
Feasibility Evidence Description (FED)
Leamos
Team number 7
Name / Email Address / Primary Role / Secondary RoleMonty Shah / / Project Manager / Life Cycle Planner
David Wiggins / / IIV&V / Off-campus Shaper
Pragya Singh / / System Architect / Prototyper
Shantanu Sirsamkar / / Requirements Engineer / Feasibility Analyst
Suchita Doshi / / Prototyper / Operational Concept Engineer
Swapnil Savdekar / / Life Cycle Planner / System Architect
Version History
Date / Author / Version / Changes made / Rationale09/27/11 / Monty / 1.0 /
- Created document, added section 5
- The document was created with the risks that the project faces and how to mitigate them.
10/05/11 / Monty / 1.1 /
- Modified section 5
- Fixed bugs as reported by David.
10/08/11 / Monty / 2.0 /
- Changed to template for NDI
- Added section 1,3,4.1, 4.2.1 and 4.2.2
- The risks have been modified post the win-win negotiation with the client. The section 1 has been added as part of the Core FC package. The project features are to be built on the Moodle platform hence is a NDI project.
10/14/11 / Monty / 2.1 /
- Added section 2, 5 and other sections of 4. Modified section 1, 4 based on the bugs
- The sections were added as part of the draft FC package. The bugs were modified as per the review given by the TA and the QA.
10/18/11 / Monty / 2.2 /
- Fixed bugs
- The document bugs were fixed, table descriptions were added.
10/23/11 / Monty / 2.3 /
- Changes made to all sections
- The changes were respect to the review during the ARB session.
Table of Contents
Feasibility Evidence Description (FED)
Version History
Table of Contents
Table of Tables
Table of Figures
1. Introduction
1.1Purpose of the FED Document
1.2Status of the FED Document
2. Process Feasibility
3. Risk Assessment
4. NDI/NCS Feasibility Analysis
4.1Assessment Approach
4.2Assessment Results
4.3Feasibility Evidence
5. Business Case Analysis
5.1Market Trend and Product Line Analysis
5.2Cost Analysis
5.3Benefit Analysis
5.4ROI Analysis
6. Conclusion and Recommendations
Table of Tables
Table 1: Rationales for Selecting Architected Agile Model
Table 2: Requirement Prioritization
Table 3: Risk Assessment
Table 4: NDI/NCS Products Listing
Table 5: Evaluation Criteria – NDI /NCS Attributes
Table 6: Evaluation Criteria - NDI/NCS features
Table 7: Evaluation Results Screen Matrix
Table 8: Level of Service Satisfiability Evidence
Table 9: Level of Service Implementation Strategy
Table 10: Capability Feasibility Evidence
Table 11: Evolutionary Feasibility Evidence
Table 12: Market Trend and Product Line Analysis
Table 13: Personnel Costs
Table 14: Hardware and Software Costs
Table 15: Benefits of xxx System
Table 16: ROI Analysis
FED_FCP_F11a_T07_V2.31Version Date: 10/23/11
Feasibility Evidence Description (FED) for NDI/ NCSVersion 2.3
Table of Figures
Figure 1: ROI Analysis Graph
FED_FCP_F11a_T07_V2.31Version Date: 10/23/11
Feasibility Evidence Description (FED) for NDI/ NCS Version 2.3
1.Introduction
1.1Purpose 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.
1.2Status 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.
2.Process Feasibility
Table 1: Rationales for Selecting NDI-intensive
Criteria / RationalesSize, 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 : Incremental Definition / Complete Valuation, including the Foundations Commitment Review and Development Commitment Review.
Key Stage II Activities: Incremental Development, Operations / Rebaselined Foundations phase and Development phase will be completed. Including The Rebaselined Development Commitment Review and Operation Commitment Review
Time per Build;
Time per Increment / Time per build, we will require 3 months to complete the 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
6 / We need to create a user friendly interface for students (should have bigger text ,continuous flow , minimizing clicks , less distractions ) / WC_725 / 2
7 / Sales website, automatic creation of accounts, organizations to be able to manage students / WC_245 / 1
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
Risks / Risk Exposure / Risk MitigationsID / Potential Magnitude / Probability Loss / Risk Exposure
1 / Learning curve: Our project needs to be integrated with the Moodle platform. The task of understanding Moodle platform in order to add code is complex. / 9 / 10 / 90 / We are planning to create a setup of the Moodle platform and understand its working.
2 / Time constraint: We may be unable to complete all the requirements in the given time (1 semester) frame because the project scope is so large. We will have to extend the project to a 2 semester project.
Also since most of the team will be unavailable for 2 semesters we may need new team members for the next semester. / 9 / 10 / 90 / We will need to get the priority of the requirements from the client.
We will need more team members to join us next semester with skill set of php and MySQL to join us.
3 / Dependencies: One of the requirements related tosystemautomation hasa direct dependency on a 3rdpartywhichis currently integrating the course merchant moduleintoMoodle. Any delay on the implementation oftheCourse 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. / 8 / 9 / 72 / The dependencies have been communicated to the client.
We will mock the implementation.
4 / Environment: In order to get started we will need the exact development environment as the current implementation.
Also for the migration of data, a copy of the old database system with the mapping details with the new database will need to be handed over to the team. / 8 / 9 / 72 / The client will have to provide the team with the environment. This has been agreed upon.
Steve, who has knowledge about the backend, will be transferring the database to the team.
5 / Testing Automation feature: Testing the automation account feature requirement is going to be difficult since it involves the course merchant module which involves money transfer. The transfer of control to the automation module will occur 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. / 9 / 8 / 72 / The client and team will need to find a way to bypass the money transfer phase in the course merchant in order to enable testing the automation feature.
6 / Talent Management: Since most of the team which has already ramped up might not be present in the next semester, there is a risk that the new members will need to be ramped up again. / 9 / 4 / 36 / To mitigate this risk, we will be recording our learning’s, to speed up the ramp up process for the new members.
4.NDI/NCSFeasibility Analysis
4.1Assessment 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, Swify, 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.
4.2Assessment Results
4.2.1NDI/NCS Candidate Components (Combinations)
Table 4: NDI/NCS Products Listing
NDI/NCS Products / PurposesMoodle, Wallaby / Moodle is a Course management platform which enables courses to be made available online.
Wallaby converts flash files (.fla) to HTML5.
Moodle, Swify / 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.
4.2.2Evaluation Criteria
Table 5: Evaluation Criteria – NDI /NCS Attributes
No. / Evaluation Criteria – NDI/NCS attributes / WeightA1 / Vendor support / 20
A2 / Documentation Understandability / 20
A3 / Maturity of product / 10
A4 / Cost of License / 10
A5 / Ability to convert long (30 minutes) flash files (functionality) / 30
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 attributesare the most important attribute that the client wants of the NDI.
Table 6: Evaluation Criteria - NDI/NCS features
No. / NDI/NCS Features/ sub features / WeightF1 / 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.3Evaluation Results Screen Matrix
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)
No / W / Wallaby / AVG / Total / Swify / AVG / Total / Flash to HTML5 Converter / AVG / TotalR1 / R2 / R1 / R2 / R1 / R2
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 / 1000 / 270 / 760
The below table indicates the results of evaluations done on features of the 3 candidates. Wallaby and Swify are free, Flash to HTML5 has a license fee. Swify converts only small flash files. The flash files which need to convert are large and hence we cannot use Swify.
Table 7.2: Evaluation Results Screen Matrix (features)
No / W / Wallaby / AVG / Total / Swify / AVG / Total / Flash to HTML5 Converter / AVG / TotalR1 / R2 / R1 / R2 / R1 / R2
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 / 750 / 250 / 750
4.3Feasibility Evidence
The capability feasibility of the requirements has been described below:
4.3.1Level of Service Feasibility
Table 8: Level of Service Satisfiability Evidence
Level of Service Win Condition / RationaleUsability – 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 SatisfactionWC_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.2Capability Feasibility
Table 10: Capability Feasibility Evidence
Capability Requirement / Product SatisfactionCR-1: Authentication and authorization / Software/Technology used: php, MySQL
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, account creation, Management of the Students by the organizations. / Software/Technology used: php, MySQL
Feasibility Evidence: The sales website will be created using php and the backend will be MySQL. This will then call the Course Merchant services which will then pass the control back to us, post 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 and documentation / Software/Technology used: php, MySQL
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.3Evolutionary Feasibility
Table 11: Evolutionary Feasibility Evidence
Evolutionary Win Condition / RationaleER-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.
5.Business Case Analysis
5.1Market Trend and Product Line Analysis
Table 12: Market Trend and Product Line Analysis
Moodle / php / mySQLMarket Trend / Moodle is the most popular Learning Management Software in the market. The web traffic details are as follows: Moodle : 150 per million, Sakai : 20 per million. So its far ahead of its competitors. / A popular language. Use primarily on the open source platforms. / mySql is a free database solution, which is used by a lot of open source platforms like Moodle. It has more than 25% market share.
Product Line / Owned by Moodle which started in the year 1999. It has a very stable Learning Management System (currently the most popular). / Open source / Owned by Oracle (founded in the year 1977), has stable product used by most open source products as a backend.
5.2Cost Analysis
5.2.1Personnel 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 email, phone [1 hour/week * 12 weeks * 2 persons] / 24
Win Win Session [1 hours * 3 * 2 person] (twice we had win win + we had to call clients 1 more time for the win-win tool) / 6
Architecture Review Boards (ARB) [1 hour * 2 times * 2 persons] (includes a board member from the clients location. / 4
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 * 12weeks * 3 persons] / 72
Architecture Review Boards and Core Capability Drive-through session [1.5 hours /week* 3 times * 3 persons] / 13.5
Deployment of system in operation phase and training
- Installation & Deployment [3hours/week * 1 times * 2 person]
- Training & Support [2 hours/week * 2 times * 2 person] / 14
Client/Client Representatives Communication via Email, Phone, and other Channels [2 hour/week * 12 weeks * 1 persons] / 24
Total: / 181.5
Maintenance [5 hours/week * 52 weeks] / 260
5.2.2Hardware and Software Costs
Table 14: Hardware and Software Costs
Type / Cost / CommentsMoodle 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
5.3Benefit 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 automation, the client will spend 1 hour per month) / 87.5 / 84
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. Plus during certain times of the year (around 2 weeks) the client receives 100 calls per week. This will be reduced. / 50 / 179.16
Maintaining of old system will not be used any more. Currently the client spends 1 hour per week on maintaining the old system. After migration of data, the client will no longer use the old system. / 100 / 104
Total / 367.16
5.4ROI 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
Year / Cost / Benefit(Effort Saved) / Cumulative Cost / Cumulative Benefit / ROI
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