1 / 74

TEAM 4 FCR PRESENTATION

TEAM 4 FCR PRESENTATION. TEAM STRONG POINTS. Operationally: Open communication with team via Slack and online meetings Good dynamics within development team and with clients Technically:

cadee
Download Presentation

TEAM 4 FCR PRESENTATION

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TEAM 4 FCR PRESENTATION

  2. TEAM STRONG POINTS Operationally: • Open communication with team via Slack and online meetings • Good dynamics within development team and with clients Technically: • Skill set across team members are diverse such that it covers most key skills (e.g., software knowledge, systems engineering knowledge, graphic design experience, etc.) • DEN students provide current industry experience to team

  3. TEAM WEAK POINTS Operationally: • Work schedule and time difference between DEN and on-campus students limit fully attended team meetings to one hour (Tuesday, 7-8pm) • Lack of management experience Technically: • Team lacks security and server-side scripting knowledge for a product that requires handling of sensitive information (e.g., full names, credit card, SSN, etc.) • Team lacks domain and operational knowledge - HIPAA- and PCI-compliance, Architecture, Data formats, EHR management

  4. System Purpose

  5. Shared Vision

  6. Benefits Chain Diagram Assumptions • Users will spend time to set up the system • Offices will work as a unit Users Enter all product information Add transactions from patients Users Easy addition of new transactions Easy addition of product recommendations Easy addition of new visits Easy insight into data Create an always on system Create premade customizable reports Developers Add recommendations for patients Enter all patients Developers Doctors Users

  7. Users • Patient monitoring • Inventory tracking • Task management • User profile and permission control • Sales tracking • Report viewing • Document storage Doctors Billing Infrastructure: • Javascript/CSS/HTML • Core language • Database • Cloud system Admins System Interface Figure 2: System Boundary and Environment Calendar Notifications and Emails

  8. Goals

  9. WEB PROTOTYPE UPDATE:

  10. DASHBOARD • Smaller buttons • Task summary & Top tasks • Help & Tutorials buttons

  11. TASKS (ALERTS) • Assignee • Criticality->Priority • Eliminated duplicate info

  12. Name, Allergies & Meds at top • Different tabs PATIENT RECORD

  13. PRODUCTS • No Alerts • Product list form -> Full page • New fields (Code & Description) • New Buttons

  14. No custom forms • Upload feature • View in new tab FORMS

  15. REPORTS • No custom reports/rules • No saving previously generated reports

  16. Top-Level Architecture

  17. Hardware Architecture

  18. SoftwareArchitecture

  19. DeploymentArchitecture

  20. Database Schema

  21. ClassDiagram

  22. Use CasesDiagram

  23. NDI/NCS DecisionUpdates • Switching to near complete dependence on AWS tools and infrastructure. • Update on Forms implementation: • Store files themselves in S3. • Updates on Reports implementation: • Generate pre-determined reports. • Open Source Software: • GitHub hosting, Tomcat Server, Spring Framework. Angular.IO, and more

  24. Life Cycle Strategy Operating under Schedule As Independent Variable (SAIV) Holistic Office is following a Net-Centric Services process Incorporation of already developed infrastructure and web service systems • AWS • Elastic Beanstalk • deployment, from capacity provisioning, load balancing, auto-scaling to application health monitoring. • CodePipeline • Runs unit tests/E2E tests; establishes order of deployment and build • IAM • Performs identity access management, only allowing access to based on a user’s permissions.

  25. Stakeholder Responsibilities - Foundations Clients: Assess prototypes and selected COTS costs. Evaluate projected system performance and refine acceptable thresholds Project Manager: Continue project planning, monitoring, and task allocation Operational Concept Engineer: Ensure operational concept reflects changes Requirements Engineer: Monitor requirements modifications and progress on incorporation System Architect: Assess architecture for chosen foundations phase alternative

  26. Stakeholder Responsibilities - Foundations Feasibility Analyst: Assess feasibility evidence for selected alternative UML Modeler: Lead generation of UML models for DCR documentation Prototyper: Lead prototype development. Identify priorities of remaining capabilities to prototype Life Cycle Planner: Evaluate life cycle plan and consider adjustments based on foundations progress. IIV&V: Verify and validate documentation for DCR. Track JIRA tickets and progress. Finalize testing plans for development. Quality Focal Point: Lead planning and conducting of testing

  27. Stakeholder Responsibilities - Foundations Additional Stakeholders: User: We expect to incorporate users, especially doctors, during the development phase. Our clients have conducted research and relayed potential user’s input to us thus far Maintainers: Have not yet been hired. Currently expect to incorporate during the development phase

  28. Project Plan - Foundations Planned Objectives • Final list of COTS • Finalize planned interfaces between COTS • Refining performance and scale expectations • Establishing Security and Compliance Framework • HIPAA Expert Meeting • Development Phase Preparation • Development Libraries • Angular JS, Spring Framework, etc. • AWS Tools • Web interface, configuration, etc.

  29. Project Plan - Foundations Milestones: • Hands-on Client Feedback • Front-end Demo • Flow testing with real users • Back-end Demo • Testing of AWS • Data Representation • Development Commitment Review • Review Feedback • Updating of Documents • Transition Plan Drafting

  30. Project Plan

  31. COCOMO II Estimation

  32. Resource Estimation - Scale Drivers

  33. Resource Estimation - Front-end Highlights

  34. Resource Estimation - Back-end Highlights

  35. Resource Estimation - E2E Highlights

  36. COCOMO II Estimation Assume 10 weeks of development, 12 hours/week, 8 team members. Based on EC13 Slide 27: 8 team member = 8 * 1.67 = 13.36 COCOMO person months of effort With the current estimate, the team will not be able to complete the project within the given timeframe. However, there is still uncertainty in some estimates such as the true module sizes • Subject to final decisions on COTS, performance thresholds to be narrowed in the Foundations phase • Disaggregate the modules to remove evolutionary requirements • Investigate SLOC estimates with Hands-on Feedback

  37. Requirements and WinBook (SSRD) Roles: • Doctor - licence owners • Administrator - managers • Users - User who has access to files and may have limited access when deleting and altering files, includes Doctors and Administrators • Patients - Clinic customers, receive services but cannot access the website • App owner - Kristen & Rich Ford • Vendor - companies who sell product to doctors for resale • Accountant (Billing)- administrative person who does not have access to patient medical information. • Stakeholders: • Clients (App owner) - project-specific stakeholder • Developer

  38. Requirements - COTS Integration • As a doctor, I want this app to integrate with my scheduling application. • As a user, I can import vendor product information with a .csv file. • As a user, I can create an invoice for my patients. • As an administrator, I am able to save and retrieve patient records/historyfrom within the system. • As an administrator, I am able to view a report/history of product purchases and patient records. • As a doctor, I would be able to purchase a subscription for Holistic Office.

  39. Requirements - Security • As a developer, the website should be protected against SQL injection, XSS and CORS attacks. • As a user, I want the website to handle all my personal information like my SSN and credit card info safely and securely. • As a user, I want to securely handle billing for subscription.

  40. Requirements - Access Privileges • As a developer, we have to provide separate access privileges to patient documents. • As a user, I can match patients to products. • As a doctor, I can recommend products for my patients in their file. • As an administrator, I can manage patient data and products on my doctor's behalf. • As a user, I am able to register new products in the database and create new patient records. • As an user, I can access information such as articles or videos that will train me to use the system. • As a user, I can create tasks with alerts for other users.

  41. Requirements Prioritized (using WinBook)

  42. Requirements Prioritized (using WinBook) (contd)

  43. Cost Analysis - Personnel (Development Period)

  44. Cost Analysis - Personnel (Maintenance Period)

  45. Cost Analysis - Hardware & Software Cost Web services costs include:* AWS EC2 * S3 * RDS (Aurora) * ELB * CloudWatch * Data transfer feeTotal cost for Operations will be around $265k per year.

  46. Benefit Analysis - Revenue • Subscription fee estimation: $199 / month. • We estimate that 240 new practices will subscribe to Holistic Office each year • Expect 5% of practices will choose to leave their subscriptions each year.

  47. ROI Analysis * Cost (hours) and benefits (hours) values are both rounded up to nearest integer, ROI is rounded up to the third integer after the decimal point. * Assume costs will increase by 10% every year from the second year.

  48. Risk Assessment

  49. Risk Assessment (contd.)

  50. Risk Assessment (contd.)

More Related