Feasibility Evidence Description (FED)
Cash Doctor 3.0
Team 12
Name 1st Role 2nd Role Alisha Parvez Developer Life Cycle Planner Ekasit Jarussinvichai Developer Prototyper Kenneth Anguka IV&V Engineer Tester Danny Lee Quality Focal Point Trainer Le Zhuang Developer Feasibility Analyst Shreya Sharma Automation Tester Tester Steven Helferich Project Manager Developer Xichao Wang Tester Operational Concept Engineer
Feb 8, 2015 Feasibility Evidence Description Version 4.0
Version History Date Author Versio Changes made Rationale n 09/28/14 LZ 1.0 Initiate draft of FED First draft based on the template 10/12/14 LZ 2.1 Update draft of FED For FCP 10/13/14 LZ 2.2 Finish section 1 – 5 For FCP Reconcile cost estimation 10/20/14 LZ 2.3 Adjust the NDI analysis For FCP Complete FED Updated NDI description For DCP 11/23/14 LZ 3.0 Modified Capability Feasibility Updated LOS feasibility For DCP Modified Process Feasibility 12/01/14 LZ 3.1 Add Evaluation Summary for NDIs Improve ROI Analysis 12/02/14 LZ 3.2 Correct minor mistakes For DCP Revise risk management Deliver DCP 12/07/14 LZ 3.3 Revise ROI estimation Re-estimate risks For RDCR 02/08/15 LZ 4.0 Revise cost analysis Remove OCR requirement
CashDoctor 3.0 ii Version Date: 02/08/2015 Feasibility Evidence Description Version 4.0 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. Business Case Analysis...... 2 2.1 Cost Analysis...... 3 2.2 Benefit Analysis...... 5 2.3 ROI Analysis...... 5 3. Architecture Feasibility...... 7 3.1 Level of Service Feasibility...... 7 3.2 Capability Feasibility...... 7 3.3 Evolutionary Feasibility...... 9 4. Process Feasibility...... 10 5. Risk Assessment...... 12 6. NDI/NCS Interoperability Analysis...... 14 6.1 Introduction...... 14 6.2 Evaluation Summary...... 14
CashDoctor 3.0 iii Version Date: 02/08/2015 Feasibility Evidence Description Version 4.0
Table of Tables
Table 1: Personnel Costs...... 3 Table 2: Hardware and Software Costs...... 4 Table 3: Benefits of CashDoctor 3.0...... 5 Table 4: ROI Analysis...... 5 Table 5: Level of Service Feasibility...... 7 Table 6: Capability Requirements and Their Feasibility Evidence...... 8 Table 7: Rationales for Selecting Architected Agile Model...... 10 Table 8: Risk Assessment...... 12 Table 9: NDI Products Listing...... 14 Table 10: NDI Evaluation...... 14
CashDoctor 3.0 iv Version Date: 02/08/2015 Feasibility Evidence Description Version 4.0
Table of Figures
Figure 1: ROI Analysis Graph...... 6 Feasibility Evidence Description Version 4.0
A.1. Introduction A.1.1 Purpose of the FED Document
The Feasibility Evidence Description (FED) is maintained to provide the Success-Critical Stakeholders of CashDoctor 3.0 project with business case analysis, risk assessment and other feasibility evidence. It identifies business case, risks, costs, benefits and issues that may occur in the development life cycle. In particular, it reveals the business case of CashDoctor and the mitigation plans for risks. The FED also contains feasibility analysis of NDI/NCSs that may be applied on CashDoctor 3.0.
A.1.2 Status of the FED Document The risk of the incapability of OCR component has been eliminated.
Risk identification and assessment has been finished in evaluation phase.
This version is a part of Rebaselined Development Commitment Package.
CashDoctor 3.0 1 Version Date: 02/08/2015 Feasibility Evidence Description Version 4.0
A.2. Business Case Analysis
Business case analysis is conducted to clarify the business values of the artifacts. It reflects win- win condition and provides stakeholders with detailed information of how the products will profit and whom the beneficiaries are. During the development of CashDoctor 3.0, some requirements may be changed. However, the rationale for a decision of requirement changes should be based on the business value described in the following analysis. All the win-conditions should be originated from the initiatives. ASSUMPTIONS Users will share info and provide reviews. Corporations will push their employees to use it via incentives. People will move away from insurance providers if it saves them money. Providers will benefit from using cash. Providers will use the system. Stakeholders Initiatives Value Proposition Beneficiaries (Who?) (What?) (Why?) (For Whom?) Developers Develop the system Easy-access Healthcare Cash doctor (for price & healthcare consumers - review/rating). information becomes individual and Search and share available to corporate. healthcare consumers. Health care information. Increased time and providers. Market the dollar savings for Cash doctor app/system patients and (includes student o Corporate healthcare consumers team) marketing strategy. in general. o Individual Make cash doctor marketing strategy. more accessible and o Provider marketing functional than strategy. current website.
Cost Benefits Development time (in person-hours) Decreased healthcare expense of consumers Hardware (hosting server) and corporations Software (Apple license, Google play license) Increased availability of healthcare Maintenance information Increased doctors’ profits Decreased time for finding healthcare coverage
CashDoctor 3.0 2 Version Date: 02/08/2015 Feasibility Evidence Description Version 4.0 A.2.1 Cost Analysis
This section will analyze all the costs in the business model to evaluate an approximate overall cost of development and maintenance of CashDoctor 3.0. All the maintenance cost is based on the assumption that the active user base will be doubled every year in the first three years.
.2.1.1 Personnel Costs
The personnel cost is measured in terms of personal effort (hours) devoted to the project. For stakeholders except developers, their personal efforts are estimated in the following table. The maintenance cost is the time our client spent promoting the app. The profit would
Table 1: Personnel Costs
Activities Time Spent (Hours) Development Period (24 weeks) Exploration, Valuation and Foundation Phase (12 weeks) Client meetings [2 hrs/week * 12 weeks * 1 person] 24 Client Win-win sessions [2 hrs/session * 2 sessions * 1 person] 4 Prototyping Presentation [1 hr * 1 person] 1 Architecture Review Boards [2hrs * 1 person] 2 Subtotal 31 Development and Operation Phase (12 weeks) Client meetings [4 hrs/week * 12 weeks * 1 person] 48 Client training seed users [2 hrs/week * 12 weeks * 1 person] 24 Architecture Review Boards [2 hrs * 1 person] 2 Performing core capabilities drive-through [2 hrs * 1 person] 2 Subtotal 76 Maintenance Period (Annual) Promoting the app [20 hrs/week * 50 weeks * 1 person] 1000 Subtotal 1000 Total 2014 (development) 31 2015 (development + maintenance) 576 2016 (maintenance) 1000 2017 (maintenance) 1000 2018 (maintenance) 2000
.2.1.2 Hardware and Software Costs
The hardware and software costs are divided into three parts: development cost, operational cost and transition cost. Almost all the NDIs used in our project is either free COTS, or open source software. The development cost consists of the hardware (cell phones) for testing and an iOS developer license for iOS development. The operational cost includes the
CashDoctor 3.0 3 Version Date: 02/08/2015 Feasibility Evidence Description Version 4.0
Table 2: Hardware and Software Costs
Type Cost($/year) Development Cost (only the first year) COCOMO II 0 IntellXDK 0 Android SDK 0 Xcode 0 Winbook 0 Test Cell Phones 1200 iOS developer license (annual) 100 Operational Cost (every year in operation) App Store on iOS 0 Google Play on Android 0 Database Management 300 Hosting 200 Security 100 Backup 100 Transition Cost
According to the assumption (see 2.2) that the user base will be increased rapidly every year since 2016, the Web Hosting cost (increased server number) and Promotion cost (increased salesmen number and Ads number) will be increased for purchasing more servers and support more users. We are not sure how many users can one server handle exactly. Assume it is 10000. Then at the beginning of 2018, a new server should be added. So the hardware cost of 2018 will be higher than 2017. We also plan to double our marketing in 2018 when userbase hits 10000. Therefore, the personnel time cost will also be increased. The time cost should be converted to dollar by 30$/hour, which is a reasonable hourly salary for experienced salespeople. So, the cost would be:
Year Personnel Time Personnel Cost Software/Hardware Total Cost (hour) (dollar) Cost (dollar) (dollar) 2014 31 930 1300 2230 2015 576 17280 700 17980 2016 1000 30000 700 30700 2017 1000 30000 700 30700 2018 2000 60000 700 60700
CashDoctor 3.0 4 Version Date: 02/08/2015 Feasibility Evidence Description Version 4.0 A.2.2 Benefit Analysis
It is estimated that $600 billion dollars are spent on health care in USA every year. The following revenue analysis is user based. Userbase Assumption: The product CashDoctor 3.0 would have a userbase at first 4 years after the release in 2015 as presented in the following table. The userbase is the number of active users who will frequently use our product for at least a year. Year Optimistic Conservative 2015 500 250 2016 2,000 1,000 2017 8,000 4,000 2018 20,000 10,000 Revenue Assumption: According to our client, every active user will approximately contribute 10 to 20 dollars to the company with their effort on promoting the transparency of the health cares market. So the Revenue can then be calculated in this way: Optimistic Revenue = Optimistic Userbase * $20 Conservative Revenue = Conservative Userbase * $10 The profit will be revenue minuses cost.
Table 3: Benefits of CashDoctor 3.0
Year Optimistic Conservative Optimistic Conservative Revenue Revenue Profit Profit 2014 0 0 -2230 -2230 2015 10000 2500 -7980 -15480 2016 40000 10000 9300 -20700 2017 160000 40000 129300 9300 2018 400000 100000 339300 39300
CashDoctor 3.0 5 Version Date: 02/08/2015 Feasibility Evidence Description Version 4.0 A.2.3 ROI Analysis
Table 4: ROI Analysis
Cumulative Cumulative Cumulative Profit Profit Profit Revenue ROI ROI Year Cost Cost (opti) (opti) (cons) (cons) (opti) (cons) 2014 2230 2230 -2230 -2230 -2230 -2230 -1.00 -1.00 2015 17980 20210 -7980 -10210 -15480 -17710 -0.51 -0.88 2016 30700 50910 9300 -910 -20700 -38410 -0.02 -0.75 2017 30700 81610 129300 128390 9300 -29110 1.57 -0.36 2018 60700 142310 339300 467690 39300 10190 3.29 0.07
Figure 1: ROI Analysis Graph
ROI Analysis
4 3 2 Opt 1 Con 0 -1 2014 2015 2016 2017 2018 -2
CashDoctor 3.0 6 Version Date: 02/08/2015 Feasibility Evidence Description Version 4.0
A.3. Architecture Feasibility A.3.1 Level of Service Feasibility
Table 5: Level of Service Feasibility
Level of Service Requirement Product Satisfaction LOS-1: Number of users: Product Strategies: Using Ke Solution (NDI) on the server, System should be able to Optimizing the API to reduce the response time. support at least 1000 Process Strategies: Use load/stress testing tools like Grinder or simultaneous users. Pylot to test the capability of the server. Analysis: The Ke Solution on the server is responsible for handling parallel connections. And it will not be a problem as a result of communications with the development team of Ke. LOS-2 System should run on Product Strategies: Using cross-platform united native API set iPhone, Android, and Windows - Apache Cordova (NDI), Web Technologies phone. Process Strategies: Test all our test cases on Android, iOS and Windows phone. Analysis: The Apache Cordova provides most of the native APIs like retrieving GPS location and camera image, which makes it possible to write hybrid applications with native functionalities and Web technologies including Bootstrap, jQuery and Backbone.js. LOS-3 System should be Product Strategies: Using Google Map accurate within a 5 mile radius Process Strategies: Test the accuracy at different geolocations: at a 90% confidence interval. urban area, metropolitan, etc. Analysis: The Google Map is a well-known application which has already been tested for accuracy. LOS-4 System must be Product Strategies: Using Bootstrap UI, design for women appealing to the target Process Strategies: Survey, asking for opinions on UI. consumer (80% female). Analysis: The bootstrap UI has light color and big, cute buttons, which will definitely be attractive to our target users. LOS-5 The system must be easy Product Strategies: Using Bootstrap UI, intuitive design to use and intuitive by all users. Process Strategies: Test it with target users. Analysis: The bootstrap UI would ensure that. We also have two team members taking CSCI 588 UI Design will help enhance the UI. A.3.2 Capability Feasibility
CashDoctor 3.0 7 Version Date: 02/08/2015 Feasibility Evidence Description Version 4.0
Table 6: Capability Requirements and Their Feasibility Evidence
Capability Requirement Product Satisfaction OC-1 Manual Information Software/Technology used: Backbone.js, Bootstrap, Ke Solution Search: The application APIs should enable consumers Feasibility Evidence: Creating forms is easy with HTML. to search healthcare Backbone.js is able to create a JSON message and send it to Ke. information by imputing Searching healthcare information is handled by Ke. location, code, price and Referred use case diagram: UC4, UC5, UC9 specialty. OC-2 Geo-Location Software/Technology used: Google Map, Apache Cordova Search: The application Feasibility Evidence: Google Map provides APIs for that. Cordova should be able to find provides the native GPS location API for the geolocation consumers’ location and coordinates. show relevant providers Referred use case diagram: UC3, UC4, UC5, UC9 around. OC-3 Price Comparison: Software/Technology used: Backbone.js, Bootstrap, Ke Solution The application should APIs enable consumers to Feasibility Evidence: The API of Ke sends the data of prices from compare price between different providers. And the comparison will be done locally with different providers. Backbone.js. The results will be displayed using Boostrap. Referred use case diagram: UC9 OC-4 User Registration: Software/Technology used: Backbone.js, Bootstrap, Ke Solution The application should APIs enable consumers to Feasibility Evidence: Bootstrap creates a form and Backbone.js register as a user. creates the JSON message and send it to Ke. Ke will add a new record in database. Referred use case diagram: UC11, UC2, UC12 OC-5 Price Sharing: The Software/Technology used: Backbone.js, Bootstrap, Ke Solution application should enable APIs users to share healthcare Feasibility Evidence: Similar to OC-1. services price by manually Referred use case diagram: UC4 imputing or capturing invoice. OC-6 Provider Rating: Software/Technology used: Backbone.js, Bootstrap, Ke Solution The application should APIs enable users to rate Feasibility Evidence: Similar to OC-4. providers and create a Referred use case diagram: UC8 review. OC-7 Networking: The Software/Technology used: Backbone.js, Bootstrap, Ke Solution application should enable APIs users to create a private Feasibility Evidence: Similar to OC-4. network and join existing Referred use case diagram: UC7 networks. OC-8 Profile Software/Technology used: Backbone.js, Bootstrap, Ke Solution Management: The APIs
CashDoctor 3.0 8 Version Date: 02/08/2015 Feasibility Evidence Description Version 4.0 application should enable Feasibility Evidence: Similar to OC-4. users to create and manage Referred use case diagram: UC3, UC13 a health profile. OC-9 Notification Software/Technology used: Backbone.js, Bootstrap, Ke Solution Management: The APIs application should enable Feasibility Evidence: The notification (push) is supported by users to subscribe form Android, iOS and Windows phones. The system APIs are included providers to get update in Cordova. notifications. And it also Referred use case diagram: UC7 allows users to filter notifications. A.3.3 Evolutionary Feasibility
No evolutionary requirements were specified in win-win session.
CashDoctor 3.0 9 Version Date: 02/08/2015 Feasibility Evidence Description Version 4.0
A.4. Process Feasibility
The following form indicates the process selection criteria with which we chose the NDI- intensive model as our process model. In the “Importance”, the level of importance of the criteria to the project is from 1 to 3, representing Low, Medium and High. In the “Project Status”, the level of how the criteria fits the project is measured by 0 to 4, representing Very Low, Low, Medium, High and Very High.
Table 7: Rationales for Selecting Architected Agile Model
Criteria Importance Project Status Rationales 30 % of NDI/NCS features 2 4 The CashDoctor uses proprietary Ke Solution as its back-end CMS engine. The free-source backbone.js provides REST communication with server and MVS architecture. The hybrid app is based on Apache Cordova, which utilizes system APIs for a Web technologies. Furthermore, Tesseract OCR provides the core capability of converting images to texts. Single NDI/NCS 1 0 No single NDI/NCS solution can satisfy our requirements. Unique/ inflexible business 2 1 The business process is neither process unique, nor inflexible. Need control over 3 3 The app may need new feature upgrade / maintenance to accommodate the changing market. Rapid deployment 3 3 The client is eager to take the market before its rivals. So the speed of development would count into its success. Critical on compatibility 3 3 Apache Cordova enables the app work on all major mobile platforms with little compatibility issue. Internet connection 3 3 The Internet connection is independence necessary. Otherwise the app won’t work. Need high level of services 2 2 The client wants the product to / performance support 1000 simultaneous connection.
CashDoctor 3.0 10 Version Date: 02/08/2015 Feasibility Evidence Description Version 4.0
Need high security 3 2 High security is critical because the health care information of users are private and sensitive. Asynchronous 2 2 Asynchronous communication communication is wanted to support more users. Be accessed from 3 4 Accessibility is critical to anywhere mobile apps. If the users cannot connect to our service, they will give up the app. Critical on mass schedule 1 2 The schedule is strict. constraints Lack of personnel 1 1 Most developers have little capability experience in mobile development at beginning. Require little upfront costs 1 1 No upfront costs. Require low total cost of 1 2 Very low cost of ownership. ownership The server is prepared already. Not-so-powerful local 1 1 We have good local machines. machines
CashDoctor 3.0 11 Version Date: 02/08/2015 Feasibility Evidence Description Version 4.0
A.5. Risk Assessment
The following table indicates all the risks that might happen during the development phase. Some risks already avoided during the foundation phase will not be listed here, including Scalability uncertainty, OCR failure on mobile platform, Team cohesion failure.
Table 8: Risk Assessment
Risk Exposure Risks Potential Probability Risk Risk Mitigations Magnitude Loss Exposure Back-end incompatibility: 9 9 81 - Communicate with the client’s Our system architecture and data flow co-worker to make sure the may be incompatible with the existing standards and interfaces of his back-end CMS Ke. CMS. Platform inconsistency: 6 8 48 - Use test-driven development to The hybrid app is developed in front- make sure every version of the end technology and distributed on both app is compatible to the Android and iOS. However, the UI of platforms. two platforms have very different design criteria. So the “one design for two platforms” may cause problems once the product is released. For example, the iOS App Store may reject the app for it does not obey Apple’s design rules. Performance limitation: 8 6 48 - Communicate with the client’s The capability of the backend serer is co-worker to understand the unknown and the performance of the capability of the server product relies on the response time of the server. Therefore, the deficiency of the server may compromise the mobile app product. Personal time constraints: 7 8 56 - Talk with teammates to arrange Developers may be as well committed to meetings and work at time slots other courses and activities, which may available for everyone. reduce the time spent on this project. Personal capability deficiency: 8 7 56 - Learn and try those Developers are not familiar with the technologies. Web technologies used in the project. - Do prototypes. Client time constrains: 10 1 10 - Try to get used to video The client is an enthusiastic busy meetings. businessman who flied to India and - Arrange meetings as early as Thailand investigating the market. He possible. may possibly have no time to set up meetings with us as the project is going on. Unattractiveness to target users: 7 2 14 - Find some potential users and After removing OCR, the invoice might test it. seem to long for a user to fill the form. The complexity of creating the invoice my lower the attractiveness of this app. Geolocation share and search failure: 7 3 21 - Look up and learn other
CashDoctor 3.0 12 Version Date: 02/08/2015 Feasibility Evidence Description Version 4.0
The backend database currently has no company’s solution to this solution to store and search invoice problem. based on its geolocation. Collaboration inefficiency: 9 7 63 - Try to communicate with our We are collaborating with client’s co- client and the co-worker. worker who administrates the backend CMS and offers us database interface. This collaboration might fail during development if the co-worker is not motivated to assist us.
Modification since last version: 1. Removed risks a. OCR failure: the requirement is removed. b. Scalability uncertainty: scalability proven. c. Team cohesion failure: team already cohered. 2. Re-estimated risks a. Backend incompatibility: probability of loss is raised because of the numerous technical problems related to KE engine in prototype development. b. Personal time constraint: probability of loss is raised because of the rising pressure from other courses that the team members take. c. Personal capability deficiency: probability of loss is raised because of difficulties in learning backbone. d. Client time constrains: the potential magnitude is raised and the potential loss is lowered. 3. Added risks a. Unattractiveness of long invoice for users: we remove the OCR component so the users have to fill the invoice themselves. As the invoice gets long, the app is less attractive. b. Geolocation share and search failure: we have no solution currently for this requirement. c. Collaboration inefficiency: the backend administrator is not responding sometimes.
CashDoctor 3.0 13 Version Date: 02/08/2015 Feasibility Evidence Description Version 4.0
A.6. NDI/NCS Interoperability Analysis A.6.1 Introduction .6.1.1 COTS / GOTS / ROTS / Open Source / NCS
Table 9: NDI Products Listing
NDI/NCS Products Purposes Ke Solution Provides an interface to the backend database. Google map Provides accurate geolocation of the users.
.6.1.2 Legacy System
There is already a website running on Ke Solution. It provides basic health care information sharing and searching. We have to add many features to satisfy our win-condition, so that we have to re-design our own app from scratch. A.6.2 Evaluation Summary
Table 10: NDI Evaluation
NDI Usages Comments Ke Solution Backend engine Fast and secure. Google map Geolocation Accurate and reliable, widely adopted in industry, free.
CashDoctor 3.0 14 Version Date: 02/08/2015