Feasibility Evidence Description (FED) for NDI/ NCS Version 3.1
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 / Rationale /09/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.
11/7/11 / Monty / 2.4 / · Minor bug fix / · The changes were mostly spell errors ( eg swiffy, r1 –reviewer 1)
11/20/11 / Monty / 3.0 / · Added section 6 / · The last section was filled.
12/01/11 / Monty / 3.1 / · Fixed bugs, updated the risks / · The risks have been updated and the bugs have been fixed (raised during ARB)
Table of Contents
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. Process Feasibility 2
3. Risk Assessment 3
4. NDI/NCS Feasibility Analysis 5
4.1 Assessment Approach 5
4.2 Assessment Results 5
4.3 Feasibility Evidence 7
5. Business Case Analysis 10
5.1 Market Trend and Product Line Analysis 10
5.2 Cost Analysis 11
5.3 Benefit Analysis 13
5.4 ROI Analysis 13
6. Conclusion and Recommendations 15
Table of Tables
Table 1: Rationales for Selecting NDI-intensive 2
Table 2: Requirement Prioritization 2
Table 3: Risk Assessment 3
Table 4: NDI/NCS Products Listing 5
Table 5: Evaluation Criteria – NDI /NCS Attributes 6
Table 6: Evaluation Criteria - NDI/NCS features 6
Table 7.1: Evaluation Results Screen Matrix (attributes) 7
Table 8: Level of Service Satisfiability Evidence 8
Table 9: Level of Service Implementation Strategy 8
Table 10: Capability Feasibility Evidence 8
Table 11: Evolutionary Feasibility Evidence 9
Table 12: Market Trend and Product Line Analysis 10
Table 13: Personnel Costs 11
Table 14: Hardware and Software Costs 12
Table 15: Benefits of System 13
Table 16: ROI Analysis 13
FED_DCP_F11a_T07_V3.1 15 Version Date: 12/01/11
Feasibility Evidence Description (FED) for NDI/ NCS Version 3.1
Table of Figures
Figure 1: ROI Analysis Graph 14
FED_DCP_F11a_T07_V3.1 15 Version Date: 12/01/11
Feasibility Evidence Description (FED) for NDI/ NCS Version 3.1
1. Introduction
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.
1.2 Status of the FED Document
Sections have been added for the Business analysis and the process feasibility. All sections have been completed. The changes have been made to tailor it for the DC package. The risks have been updated.
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 in 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 / New team members:
Since most of the team will be unavailable for 2 semesters we may need new team members for the next semester.
We will need more team members to join us next semester with skill set of php and MySQL to join us. / 9 / 7 / 90 / Prototype has been developed for the Data migration, sales website and hosting HTML5 on Moodle.
2 / Dependencies: One of the requirements related tosystemautomation hasa direct dependency on a 3rdpartywhichis currently integrating the course merchant moduleinto Moodle. 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. / 3 / 9 / 36 / We have prototyped the functionality using PayPal.
3 / 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. / 3 / 9 / 27 / The client will have to provide the team with the environment. Clarity will share the sandbox. This has been agreed upon.
Clarity will be sharing the schema and the data for the new database.
Prototype have been developed for Schema migration assuming all scenarios – one to one, one to many, many to one and many to many table migration.
David has installed Moodle on his website and the prototypes (sales website and HTML5 videos on Moodle) have been developed on the Moodle platform.
4. NDI/NCS Feasibility Analysis
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.
4.2 Assessment Results
4.2.1 NDI/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, 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.
4.2.2 Evaluation 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 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 / 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 files 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 it and get more help from the vendor.
4.2.3 Evaluation Results Screen Matrix
The table below present 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 / Swiffy / AVG / Total / Flash to HTML5 Converter / AVG / TotalReviewer 1 / Reviewer 2 / Reviewer 1 / Reviewer 2 / Reviewer 1 / Reviewer 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 table below presents 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)
No / W / Wallaby / AVG / Total / Swiffy / AVG / Total / Flash to HTML5 Converter / AVG / TotalReviewer 1 / Reviewer 2 / Reviewer 1 / Reviewer 2 / Reviewer 1 / Reviewer 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
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 / 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