1 / 80

Architecture Review Board

Architecture Review Board. Team 11 Surgery Assist. ARB Agenda. SurgeryAssist ARB Overview Speaker: Heguang Liu Answer er : Heguang Liu OCD Speaker: Heguang Liu Answerer: Heguang Liu, Yu Fang Prototype Speaker: Longfeng Jia Answerer: Longfeng Jia , Yu Zhang

dinh
Télécharger la présentation

Architecture Review Board

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. Architecture Review Board Team 11 Surgery Assist

  2. ARB Agenda • SurgeryAssist ARB Overview Speaker: Heguang Liu Answerer: Heguang Liu • OCD Speaker: Heguang Liu Answerer: Heguang Liu, Yu Fang • Prototype Speaker: Longfeng Jia Answerer: Longfeng Jia, Yu Zhang • SSAD: Speaker: Yu Zhang Answerer: Yu Zhang, Heguang Liu • LCP: Speaker: Yu Fang, WanghaiGu Answerer: WanghaiGu, Yu Fang • TP&SP: Speaker: WanghaiGu Answerer: WanghaiGu, Yu Fang • FED: Speaker: Zhen Li Answerer: Zhen Li, Yu Zhang, Heguang Liu • TPC: Speaker: XihengYue Answerer: XihengYue, Yu Zhang • QFP: Speaker: XihengYue Answerer: XihengYue, Yu Zhang

  3. Surgery Assist Overview • Surgery Assist is a website that provide interactions between doctors and Surgery Centers. • Main activities available online: SC can provide their available surgical slots to the doctors to view and choose from doctors are allowed to register ,upload their information and reserve a surgical slot . • Goal for the current project:To offer a specialized reservation solution that optimally connects doctors and SCs to improve the scheduling process and fill vacant surgical slots.

  4. Major Changes • Top risks change from possible problems in “process complexity and account identification” to “page flow connection and UI usability” • Improved NDI/NCS components identification and evaluation in OCD, FED, SSAD • Designed a feasible system architecture and integration solution, conforms all the WinWin conditions and prototype. • Designed complete test plan and cases to cover use case and level of service • Reached an agreement with client and developed most of the frontend based on our architecture. • Develop construction, transition and support (CTS) initial cycle plan with iteration plan for 577b

  5. Team’s strong& weak points Operational View • Strong Points • We are very willing to contribute and very hardworking. • We maintain the same goal, respect each other’s work and highly cooperative. • We are good team players and have good project management. • Our client is very informative and considerate, always respects our work. • Week Points • None of us have taken the Software engineering related course before or have experience in the Software management. • Our course load is heavy which may sometimes limit our time spending in the project. Technical View • Strong Points • We are familiar with most language and platform using in this project, such as Java, MSSQL, JavaScript, Apache Tomcat Server • Week Points • We are still students, thus lack of industrial experience.

  6. Overall Project Evaluation • Established a complete system architecture, including detailed class/sequence/schema design, NDI/NCS evaluation and integration solution. • All high risks have been identified, top 4 risks have been successfully resolved by architecture and prototype, others’ management has been well planned in LCP. • Developed most of the frontend as client request, based on our architecture, meets all WinWin conditions, consistent with OCD, LCP, also conforms to prototype. • Designed a detail and feasible plan for 577b, to finish the development and resolve remaining risks.

  7. Operational Concept • SurgeryAssist System is a specialized web based online reservation system that optimally connects surgeons and outpatient surgery centers to improve the scheduling process and fill vacant surgical slots. • For outpatient surgery centers seeking to have their surgery rooms optimally filled, thereby covering the large operating costs from underutilization of their facility. • For surgeons seeking surgical slots who are frustrated with the current antiquated scheduling system. System Objectives

  8. Operational Concept Shared Vision

  9. Operational Concept Benefit Chain Diagram

  10. Operational Concept System Boundary Diagram

  11. Operational Concept Project Constraints

  12. Operational Concept Workflow comparison

  13. Operational Concept Proposed New System – Element Relationship Diagram

  14. Operational Concept SystemCapabilities

  15. Operational Concept Level of Services

  16. Prototype Goals • To mitigate high-risk. • Base of future implementation • “To simulate interactions between users and applications” ——from ICSM-EPG

  17. Prototype High risk items: • Page flow may be unconnected and too confusing: Our system should be based on two sets of tightly connected page flow, one for doctors and the other for surgery center. If not properly designed, page flow may be incomplete and confusing. • User interface may be undesirable: UI may not fascinating and attractive as David expected. And the users will not prefer to use our system if UI doesn’t keep users informed and given appropriate feedback.

  18. Prototype • Extreme Prototyping • Evolutionary Prototyping • Front-end design • Transition from prototype to actual implementation

  19. Architecture Use Case Diagram

  20. Architecture Artifacts & Information Diagram

  21. Architecture System Structure Hardware Component Diagram Software Component Diagram Deployment Diagram

  22. Architecture Class Diagram

  23. Architecture COTS / GOTS / ROTS / Open Source / NCS 

  24. Architecture

  25. Architecture

  26. Architecture NDI/NCS Evaluation

  27. Architecture Login Sequence Diagram

  28. Architecture Reservation Sequence Diagram

  29. Life Cycle Plan Team 11

  30. Overview • Estimation • Team Member Roles • Stakeholder Responsibility in each phase • Plans for 577b • Rebaseline Foundation • Iteration1 Core Capabilities • Iteration2 Full Capabilities • Transition Iteration

  31. Estimation • Assume 15 hours/week of dedicated effort per person • Assume 10 of the 12 weeks fill the development phase (72% of the total effort estimates); the final two weeks are for product transition into operations. • Assume 100/hours/person-month for COCOMO estimates • According to COCOMO II Estimates for CSCI577 and above assumptions, one team member effort = 15*10/100/0.72=2.08 COCOMO II person months. The most likely effort from the COCOMO estimation above is 8.99, so the total team members need for this project = 8.99/2.08= 4.32 • Conclusion: we need 5 team members in total in 577b semester.

  32. Team Member Roles

  33. Stakeholder Responsibilityin each phase

  34. Required Skills for New Members • New Member1 • Main Responsibility: Building database system for Doctor profile and Surgical Slots. • Required Skills: • Good communication and documentation • Java, MSSQL, JDBC, JavaScript, jQuery, Tomcat Server ,ICSM • Main Responsibility: Unit testing for required module. • Required Skills: • Good communication and documentation • Java, MSSQL, JavaScript, JSF, Junit, JDBC, Apache Tomcat Server, ICSM

  35. Plan for 577bRebaselined Foundation Phase • Duration: 1/13/14 to 2/21/14 • Concept: Since there might be some changes during the winter break, we have to prepare and reflex those changes in the documents. • Deliverables: Updated documents • Milestone: Rebaselined Development Commitment Review

  36. Plan for 577bRebaselined Foundation Phase

  37. Plan for 577bDevelopment Phase • Duration: 2/14/14 to 4/28/14 • Concept: In this phase, we focused on the implementation and the transition of the project. • Deliverables: Project with full capabilities, Transition Package • Milestone: Perform Core Capability Drivethrough, Transition Readiness Review, Operational Commitment Review • Duration: • Construction iteration1(core capability): 2/14/14 to 4/16/14 • Construction iteration2(full capability): 3/31/14 to 4/18/14 • Transition iteration: 4/18 to 4/28/14

  38. Plan for 577bConstruction Iteration1 • Duration: 2/14/14 to 4/16/14 • Task: Core capability implementation • Capability: • Profile Management • Posting Surgical Slots • Reservation • Search Management • Email Alert

  39. Plan for 577bConstruction Iteration2 • Duration: 3/31/14 to 4/18/14 • Task: Full capability implementation • Capability: • Payment • Monitor (System log monitoring)

  40. Plan for 577bDevelopment Phase - Construction Iteration

  41. Plan for 577bDevelopment Phase - Transition Iteration

  42. Transition Plan • Tasks(transition : 4/18/14- 4/28/14) • 4/18-4/22Configure and adjust the final system • 4/23Deliverthesystemanddocuments • 4/24Providetrainingtotheclientsandmaintainer • 4/26Providetrainingtousers

  43. Transition Plan(Documents) • Feasibility Evidence Description • Life Cycle Plan • MaintenanceManual • Operational Concept Description • Prototype Report • Quality Management Plan • Training Plan • Transition Plan • Test Procedures and Requirements • Test Plan and Cases • Supporting Information Document • System and Software Architecture Description • User Manual

  44. Transition Plan • HWpreparation AmazonAWS(JenkinsServer,AppServer,DatabaseServer):AssociationofElasticIPs,securitygroupsconfiguration • SWpreparation SupportDocumentation,Githubrepository,GoDaddyDomain,DBMS,JenkinsMS • Sitepreparation Backupdata

  45. Transition Plan Schedule

  46. Support Plan • SupportEnvironment • Hardware AmazonAWSandassociateddocuments JenkinsServer DatabaseServer AppServer

  47. Support Plan • SupportEnvironment • Software

  48. Support Plan • SupportEnvironment • Software

More Related