Feasibility Evidence Description (FED)

Transcription

1 Feasibility Evidence Description (FED) Cash Doctor 3.0 Team 12 Name 1 st Role 2 nd 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

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 /01/14 LZ 3.1 Reconcile cost estimation Adjust the NDI analysis Complete FED Updated NDI description Modified Capability Feasibility Updated LOS feasibility Modified Process Feasibility Add Evaluation Summary for NDIs Improve ROI Analysis For FCP For DCP For DCP 12/02/14 LZ 3.2 Correct minor mistakes For DCP 12/07/14 LZ /08/15 LZ 4.0 Revise risk management Revise ROI estimation Re-estimate risks Revise cost analysis Remove OCR requirement Deliver DCP For RDCR CashDoctor 3.0 ii Version Date: 02/08/2015

3 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 CashDoctor 3.0 iii Version Date: 02/08/2015

4 Table of Tables Table 1: Personnel Costs... 3 Table 2: Hardware and Software Costs... 4 Table 3: Benefits of CashDoctor 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 Table 8: Risk Assessment Table 9: NDI Products Listing Table 10: NDI Evaluation CashDoctor 3.0 iv Version Date: 02/08/2015

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

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 Rebaselined Development Commitment Package. CashDoctor Version Date: 02/08/2015

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?) Developers Cash doctor (What?) Develop the system (for price & review/rating). Search and share healthcare information. Market the app/system o Corporate marketing strategy. o Individual marketing strategy. o Provider marketing strategy. (Why?) Easy-access healthcare information becomes available to consumers. Increased time and dollar savings for patients and healthcare consumers in general. Make cash doctor more accessible and functional than current website. (For Whom?) Healthcare consumers - individual and corporate. Health care providers. Cash doctor (includes student team) Cost Development time (in person-hours) Hardware (hosting server) Software (Apple license, Google play license) Maintenance Benefits Decreased healthcare expense of consumers and corporations Increased availability of healthcare information Increased doctors profits Decreased time for finding healthcare coverage CashDoctor Version Date: 02/08/2015

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 CashDoctor Version Date: 02/08/2015

9 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 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) CashDoctor Version Date: 02/08/2015

10 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 ,000 1, ,000 4, ,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 Revenue Conservative Revenue Optimistic Profit Conservative Profit ROI Analysis Table 4: ROI Analysis Cumulative Profit (opti) Cumulative Revenue (cons) Year Cost Cumulative Cost Profit (opti) Profit (cons) ROI (opti) ROI (cons) CashDoctor Version Date: 02/08/2015

11 Figure 1: ROI Analysis Graph 4 3 ROI Analysis Opt Con CashDoctor Version Date: 02/08/2015

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 CashDoctor Version Date: 02/08/2015

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 CashDoctor Version Date: 02/08/2015

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. CashDoctor Version Date: 02/08/2015

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. CashDoctor Version Date: 02/08/2015

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. CashDoctor Version Date: 02/08/2015

17 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. Risks Back-end incompatibility: Our system architecture and data flow may be incompatible with the existing back-end CMS Ke. Platform inconsistency: The hybrid app is developed in frontend technology 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 backend serer 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. Personal time constraints: Developers may be as well committed to other courses and activities, which may reduce the time spent on this project. Personal capability deficiency: Developers are not familiar with the Web technologies used in the project. Client time constrains: The client is an enthusiastic busy businessman who flied to India and Thailand investigating the market. He may possibly have no time to set up meetings with us as the project is going on. Unattractiveness to target users: After removing OCR, the invoice might seem to long for a user to fill the form. The complexity of creating the invoice my lower the attractiveness of this app. Table 8: Risk Assessment Risk Exposure Potential Magnitude Probability Loss Risk Exposure Risk Mitigations Communicate with the client s co-worker to make sure the standards and interfaces of his CMS Use test-driven development to make sure every version of the app is compatible to the platforms Communicate with the client s co-worker to understand the capability of the server Talk with teammates to arrange meetings and work at time slots available for everyone Learn and try those technologies. - Do prototypes Try to get used to video meetings. - Arrange meetings as early as possible Find some potential users and test it. Geolocation share and search failure: Look up and learn other CashDoctor Version Date: 02/08/2015

18 The backend database currently has no solution to store and search invoice based on its geolocation. Collaboration inefficiency: We are collaborating with client s coworker 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. company s solution to this problem Try to communicate with our client and the co-worker. 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 Version Date: 02/08/2015

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 Purposes Provides an interface to the backend database. Provides accurate geolocation of the users 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. CashDoctor Version Date: 02/08/2015