Feasibility Evidence Description (FED)

Transcription

1 Feasibility Evidence Description (FED) Cash Doctor 3.0 Team 12 Name Alisha Parvez Ekasit Jarussinvichai Kenneth Anguka Kshama Krishnan Le Zhuang Shreya Sharma Steven Helferich Xichao Wang Roles Life Cycle Planner, Feasibility Analyst Requirements Engineer, Prototyper IV&V Requirement Engineer Prototyper, System/Software Architect Feasibility Analyst, System/Software Architect System/Software Architect, Requirements Engineer Project Manager, Operational Concept Engineer Operational Concept Engineer, Life Cycle Planner Dec 2, 2014

2 Feasibility Evidence Description of CashDoctor 3.0 Version 3.2 Version History Date Author Version Changes made Rationale 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 10/20/14 LZ /23/14 LZ 3.0 Reconcile cost estimation Adjust the NDI analysis Complete FED Updated NDI description Modified Capability Feasibility For FCP For DCP 12/01/14 LZ 3.1 Updated LOS feasibility Modified Process Feasibility Add Evaluation Summary for NDIs Improve ROI Analysis For DCP 12/02/14 LZ 3.2 Correct minor mistakes For DCP Feasibility Evidence Description ii Version Date: 12/02/2014

3 Feasibility Evidence Description of CashDoctor 3.0 Version 3.2 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 Purpose of the FED Document Status of the FED Document Business Case Analysis Cost Analysis Benefit Analysis ROI Analysis Architecture Feasibility Level of Service Feasibility Capability Feasibility Evolutionary Feasibility Process Feasibility Risk Assessment NDI/NCS Interoperability Analysis Introduction Evaluation Summary Feasibility Evidence Description iii Version Date: 12/02/2014

4 Feasibility Evidence Description of CashDoctor 3.0 Version 3.2 Table of Tables Table 1: Personnel Costs... 3 Table 2: Hardware and Software Costs... 4 Table 3: Benefits of xxx System... Error! Bookmark not defined. Table 4: ROI Analysis... Error! Bookmark not defined. Table 5: Level of Service Feasibility... 7 Table 6: Capability Requirements and Their Feasibility Evidence... 8 Table 7: Evolutionary Requirements and Their Feasibility Evidence... Error! Bookmark not defined. Table 8: Rationales for Selecting Architected Agile Model Table 9: Risk Assessment Table 10: NDI Products Listing Table 11: NDI Evaluation Feasibility Evidence Description iv Version Date: 12/02/2014

5 Table of Figures Figure 1: ROI Analysis Graph... 5

6 1. Introduction 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 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 draft Development Commitment Package. Feasibility Evidence Description 1 Version Date: 12/02/2014

7 2. Business Case Analysis Business case analysis is conducted to clarify the business values of the artifacts. It reflects winwin 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 Cash doctor Develop the system (for price & review/rating). Market the app/system o Corporate marketing strategy. o Individual marketing strategy. o Provider marketing strategy. Cost Development time (in person-hours) Hardware (hosting server) Software (Apple license, Google play license) Maintenance Increase price transparency of health care costs. Increased time and dollar savings for patients and healthcare consumers in general. Empowering the consumer to make a more educated choice about healthcare expenditures Enable consumers/patients to evaluate or provide feedback on healthcare services for community benefit. Revolutionize the industry and profit. Healthcare consumers - individual and corporate. Health care providers. Cash doctor (includes student team) Benefits Decreased healthcare expense of consumers and corporations Increased availability of healthcare information Increased doctors profits Decreased time for finding healthcare coverage Feasibility Evidence Description 2 Version Date: 12/02/2014

8 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 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) (development + maintenance) (maintenance) (maintenance) (maintenance) 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 Feasibility Evidence Description 3 Version Date: 12/02/2014

9 Table 2: Hardware and Software Costs Type Cost($/year) Development Cost Java OCR 0 COCOMO II 0 IntellXDK 0 Android SDK 0 Xcode 0 Winbook 0 Test Cell Phones 1200 ios developer license (annual) 100 Operational Cost App Store on ios 0 Google Play on Android 0 Servers 1000 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 Then at the beginning of 2018, a new server should be added. So the hardware cost of 2018 will be higher than We also plan to double our marketing in 2018 when userbase hits 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 Cost (hour) Personnel Cost (dollar) Software/Hardware Cost (dollar) Total (dollar) Benefit Analysis It is estimated that $600 billion dollars are spent on health care in USA every year. The following benefit analysis is user based. Feasibility Evidence Description 4 Version Date: 12/02/2014

10 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 ,000 1, ,000 4, ,000 10,000 Benefit Assumption: 1% of the money one person spent on health care can be saved by the price transparency provided by CashDoctor 3.0 on average. And Benefit (the money saved) can then be calculated in this way: Benefit = $600 billion * (userbase / population of US) * 1% Revenue Assumption: 15% of the money saved of our users can be converted into CashDoctor s revenue. The Revenue can then be calculated in this way: Revenue = $600 billion * (userbase / population of US) * 1% * 15% Table 3: Benefits of CashDoctor 3.0 Year Optimistic Revenue Conservative Revenue Optimistic Profit Conservative Profit ROI Analysis Table 4: ROI Analysis Cumulative Revenue (con) Cumulative Revenue (opt) ROI (con) ROI(opt) Year Cost Cumulative Cost Revenue (con) Revenue (opt) Feasibility Evidence Description 5 Version Date: 12/02/2014

11 Figure 1: ROI Analysis Graph ROI Analysis Opt Con Feasibility Evidence Description 6 Version Date: 12/02/2014

12 3. Architecture Feasibility 3.1 Level of Service Feasibility Table 5: Level of Service Feasibility Level of Service Requirement LOS-1: Number of users: System should be able to support at least 1000 simultaneous users. LOS-2 System should run on iphone, Android, and Windows phone. LOS-3 System should be accurate within a 5 mile radius at a 90% confidence interval. LOS-4 System must be appealing to the target consumer (80% female). LOS-5 The system must be easy to use and intuitive by all users. Product Satisfaction Product Strategies: Using Ke Solution (NDI) on the server, Optimizing the API to reduce the response time. Process Strategies: Use load/stress testing tools like Grinder or 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. Product Strategies: Using cross-platform united native API set - Apache Cordova (NDI), Web Technologies 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. Product Strategies: Using Google Map Process Strategies: Test the accuracy at different geolocations: urban area, metropolitan, etc. Analysis: The Google Map is a well-known application which has already been tested for accuracy. Product Strategies: Using Bootstrap UI, design for women Process Strategies: Survey, asking for opinions on UI. Analysis: The bootstrap UI has light color and big, cute buttons, which will definitely be attractive to our target users. Product Strategies: Using Bootstrap UI, intuitive design 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. 3.2 Capability Feasibility Feasibility Evidence Description 7 Version Date: 12/02/2014

13 Table 6: Capability Requirements and Their Feasibility Evidence Capability Requirement OC-1 Manual Information Search: The application should enable consumers to search healthcare information by imputing location, code, price and specialty. OC-2 Geo-Location Search: The application should be able to find consumers location and show relevant providers around. OC-3 Price Comparison: The application should enable consumers to compare price between different providers. OC-4 User Registration: The application should enable consumers to register as a user. OC-5 Price Sharing: The application should enable users to share healthcare services price by manually imputing or capturing invoice. OC-6 Provider Rating: The application should enable users to rate providers and create a review. OC-7 Networking: The application should enable users to create a private network and join existing networks. OC-8 Profile Management: The Product Satisfaction Software/Technology used: Backbone.js, Bootstrap, Ke Solution APIs Feasibility Evidence: Creating forms is easy with HTML. Backbone.js is able to create a JSON message and send it to Ke. Searching healthcare information is handled by Ke. Referred use case diagram: UC4, UC5, UC9 Software/Technology used: Google Map, Apache Cordova Feasibility Evidence: Google Map provides APIs for that. Cordova provides the native GPS location API for the geolocation coordinates. Referred use case diagram: UC3, UC4, UC5, UC9 Software/Technology used: Backbone.js, Bootstrap, Ke Solution APIs Feasibility Evidence: The API of Ke sends the data of prices from different providers. And the comparison will be done locally with Backbone.js. The results will be displayed using Boostrap. Referred use case diagram: UC9 Software/Technology used: Backbone.js, Bootstrap, Ke Solution APIs Feasibility Evidence: Bootstrap creates a form and Backbone.js creates the JSON message and send it to Ke. Ke will add a new record in database. Referred use case diagram: UC11, UC2, UC12 Software/Technology used: Backbone.js, Bootstrap, Ke Solution APIs Feasibility Evidence: Similar to OC-1. Referred use case diagram: UC4 Software/Technology used: Backbone.js, Bootstrap, Ke Solution APIs Feasibility Evidence: Similar to OC-4. Referred use case diagram: UC8 Software/Technology used: Backbone.js, Bootstrap, Ke Solution APIs Feasibility Evidence: Similar to OC-4. Referred use case diagram: UC7 Software/Technology used: Backbone.js, Bootstrap, Ke Solution APIs Feasibility Evidence Description 8 Version Date: 12/02/2014

14 application should enable users to create and manage a health profile. OC-9 Notification Management: The application should enable users to subscribe form providers to get update notifications. And it also allows users to filter notifications. Feasibility Evidence: Similar to OC-4. Referred use case diagram: UC3, UC13 Software/Technology used: Backbone.js, Bootstrap, Ke Solution APIs Feasibility Evidence: The notification (push) is supported by Android, ios and Windows phones. The system APIs are included in Cordova. Referred use case diagram: UC7 3.3 Evolutionary Feasibility No evolutionary requirements were specified in win-win session. Feasibility Evidence Description 9 Version Date: 12/02/2014

15 4. Process Feasibility The following form indicates the process selection criteria with which we chose the NDIintensive 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 Need control over upgrade / maintenance unique, nor inflexible. 3 3 The app may need new feature 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 independence Need high level of services / performance 3 3 The Internet connection is necessary. Otherwise the app won t work. 2 2 The client wants the product to support 1000 simultaneous connection. Feasibility Evidence Description 10 Version Date: 12/02/2014

16 Need high security 3 2 High security is critical because the health care information of users are private and sensitive. Asynchronous communication Be accessed from anywhere Critical on mass schedule constraints Lack of personnel capability 2 2 Asynchronous communication is wanted to support more users. 3 4 Accessibility is critical to mobile apps. If the users cannot connect to our service, they will give up the app. 1 2 The schedule is strict. 1 1 Most developers have little experience in mobile development at beginning. Require little upfront costs 1 1 No upfront costs. Require low total cost of ownership Not-so-powerful local machines 1 2 Very low cost of ownership. The server is prepared already. 1 1 We have good local machines. Feasibility Evidence Description 11 Version Date: 12/02/2014

17 5. Risk Assessment The following table indicates all the risks that might happen during the development. Some risks that are already avoided during the foundation phase will not be listed here. Table 8: Risk Assessment Risks OCR failure on mobile platform: The OCR module we use is built on Windows/Unix and not yet tested on Android/iOS. The module may fail on mobile OS. Back-end incompatibility: Our system architecture and data flow may be incompatible with the existing back-end CMS Ke. Platform inconsistency: The hybrid app should be designed with HTML/CSS and distributed on both Android and ios. However, the UI of 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: The capability of the client s server is unknown and the performance of the product relies on the response time of the server. Therefore, the deficiency of the server may compromise the mobile app product. Scalability uncertainty: The product is designed for 1000 simultaneous users. However, the requirement may easily be lifted to more users. The scalability of the product is still unknown. Personal time constraints: Developers may be as well committed to other courses and activities, which may reduce the time spent on this project. Client time constrains: The client is an enthusiastic busy Risk Exposure Potential Magnitude Probability Loss Risk Exposure Risk Mitigations Test the component and try to make a prototype. (already avoided by prototyping) Communicate with the client s coworker to make sure the standards and interfaces of his CMS. (already avoided by prototyping) - Make the architecture flexible Do incremental development after the first product with basic features is released and accepted Communicate with the client s coworker to understand the capability of the server Try to learn scalability issues and build scalable architecture at the first stage Talk with teammates to arrange meetings and work at time slots available for everyone Try to get used to video meetings. - Arrange meetings as early as Feasibility Evidence Description 12 Version Date: 12/02/2014

18 businessman who flied to India and Thailand investigating the market. He may not possible have time to set up meetings with us as the project is going on. Team cohesion failure: The team is composed of seven developers and one client from different backgrounds and cultures. It is possible that the difference may cause misunderstandings and unhappiness, which will damage the cohesion. possible Try to spend more time with teammates even after work and be good friends - Seek assistance from the CS577 faculty Feasibility Evidence Description 13 Version Date: 12/02/2014

19 6. NDI/NCS Interoperability Analysis 6.1 Introduction COTS / GOTS / ROTS / Open Source / NCS Table 9: NDI Products Listing NDI/NCS Products Ke Solution Google map Tesserate OCR Apache Cordova Purposes Provides an interface to the backend database. Provides accurate geolocation of the users. Retrieves useful information from an image of a medical bill, providing the core feature: sharing price by snapshots. Provides unified native APIs on different mobile platforms, making it possible to run Web codes using system calls Connectors In this project, we use Bootstrap, jquery and BackboneJS to enable the web application use system APIs creating requests, sending requests in JSON to Ke CMS system and retrieve response from the database on server side 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. 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. Tesserate OCR Convert image to data Widely adopted in industry, still being improved, free. Apache Cordova Unify platforms Reliable, free. Feasibility Evidence Description 14 Version Date: 12/02/2014