Architecture Review Board Team 11 Surgery Assist 1

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, Wanghai Gu Answerer: Wanghai Gu, Yu Fang

TP&SP: Speaker: Wanghai Gu Answerer: Wanghai Gu, Yu Fang

FED: Speaker: Zhen Li Answerer: Zhen Li, Yu Zhang, Heguang Liu

TPC: Speaker: Xiheng Yue Answerer: Xiheng Yue, Yu Zhang

QFP: Speaker: Xiheng Yue Answerer: Xiheng Yue, Yu Zhang

3

Surgery Assist OverviewSurgery 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 EvaluationEstablished 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 ConceptShared Vision

9

Operational ConceptBenefit Chain Diagram

10

Operational ConceptSystem Boundary Diagram

11

Operational Concept

Project Constraints

12

Operational ConceptWorkflow comparison

13

Operational ConceptProposed New System – Element Relationship

Diagram

14

Operational ConceptSystem Capabilities

15

Operational Concept

Level of Services

16

Prototype

To mitigate high-risk.Base of future implementation“To simulate interactions between

users and applications”

——from ICSM-EPG

Goals

17

Prototype

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.

High risk items:

18

Prototype

Extreme Prototyping

Evolutionary Prototyping

Front-end design

Transition from prototype to actual implementation

19

ArchitectureUse Case Diagram

20

ArchitectureArtifacts & Information Diagram

21

ArchitectureSystem Structure

Hardware ComponentDiagram

Software ComponentDiagram

DeploymentDiagram

22

ArchitectureClass Diagram

23

ArchitectureCOTS / GOTS / ROTS / Open Source / NCS

24

Architecture

25

Architecture

26

ArchitectureNDI/NCS Evaluation

27

ArchitectureLogin Sequence Diagram

28

ArchitectureReservation Sequence Diagram

29

Life Cycle PlanTeam 11

30

OverviewEstimation

Team Member Roles

Stakeholder Responsibility in each phase

Plans for 577bRebaseline Foundation Iteration1 Core Capabilities Iteration2 Full Capabilities Transition Iteration

31

32

33

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.

34

Team Member RolesMember Role

Wanghai Gu Project Manager Requirement EngineerBuilder & Trainer

Longfeng Jia Operational ConceptEngineerBuilder & Tester

Xiheng Yue Software Architecture IV&VBuilder & Trainer

New Member1 Feasibility AnalystBuilder & Tester

New Member2 Life Cycle PlannerTester

35

Stakeholder Responsibilityin each phase

Member Rebaseline Construction Transition

David (client) Elaborate any changes of Requirements

Provide feedback and suggestions to team

Participate in training process

Wanghai Gu Elaborate any changes in requirements

Building database system; Build Reservation and Slots posting management

Transition from localhost to client‘s server; Maintainer Training

Longfeng Jia Elaborate any changes in operational concept

Improve security of running service; Construct Profile System

Adjust Hardware and Software environment; Maintainer Training

Xiheng Yue Elaborate architecture Coordinate back-end and front-end; Build Search System

Transition from localhost to client's server; Customer Training

New Member1 Elaborate feasibility evidence

Building database system; Build Reservation and Slots posting management

Adjust Hardware and Software environment; Customer Training

New Member2 Elaborate life cycle plan

Implementation for Email Alert; Main Tester

Testing and Fix bugs ; Problem solving

36

Required Skills for New MembersNew Member1

Main Responsibility: Building database system for Doctor profile and Surgical Slots.

Required Skills: Good communication and documentationJava, MSSQL, JDBC, JavaScript, jQuery, Tomcat

Server ,ICSMMain Responsibility: Unit testing for required module.Required Skills:

Good communication and documentationJava, MSSQL, JavaScript, JSF, Junit, JDBC, Apache Tomcat

Server, ICSM

37

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

38

Plan for 577bRebaselined Foundation Phase

39

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

40

Plan for 577bConstruction Iteration1

Duration: 2/14/14 to 4/16/14

Task: Core capability implementation

Capability:Profile ManagementPosting Surgical SlotsReservationSearch ManagementEmail Alert

41

Plan for 577bConstruction Iteration2

Duration: 3/31/14 to 4/18/14

Task: Full capability implementation

Capability:PaymentMonitor (System log monitoring)

42

Plan for 577bDevelopment Phase - Construction Iteration

43

Plan for 577bDevelopment Phase - Transition Iteration

44

Transition PlanTasks(transition : 4/18/14- 4/28/14)

1. 4/18-4/22 Configure and adjust the final system

2. 4/23 Deliver the system and documents

3. 4/24 Provide training to the clients and maintainer

4. 4/26 Provide training to users

45

Transition Plan (Documents)

Feasibility Evidence DescriptionLife Cycle PlanMaintenance ManualOperational Concept DescriptionPrototype ReportQuality Management PlanTraining PlanTransition PlanTest Procedures and RequirementsTest Plan and CasesSupporting Information DocumentSystem and Software Architecture DescriptionUser Manual

46

Transition PlanHW preparation

Amazon AWS(Jenkins Server, App Server, Database Server): Association of Elastic IPs, security groups configuration

SW preparation

Support Documentation, Github repository, GoDaddy Domain, DBMS, Jenkins MS

Site preparation

Backup data

47

Transition PlanSchedule

48

Support PlanSupport Environment

Hardware

Amazon AWS and associated documents

Jenkins Server

Database Server

App Server

49


Software

50


Software

51


Software

52


Software

53


Software

54


Facility

Security Group Configuration, Backup data, Association of Elastic IPs

55

Support Plan Release Strategy

Description (New Features and Important Changes since the previous release

Upcoming Changes that will be incorporated in future releases

Known Bugs and Limitations)

Pre-Alpha (interim product)V1.XX

Alpha (first internal product build)V2.XX

Beta (first real-world product version)V3.XX

Release Candidate (potential final products)V4.XX

General Availability (final version)V5.XX

56

Feasibility Evidence NDI/NCS Assessment approach-

Criteria-based Assessment

NDI/NCS Products Purposes

Google Map Provide a friendly user interface to display the searched surgery centers in a two dimensional fashion

Microsoft Bing Map Similar to Google Map can provide a map view on search results

Google Calendar Provide a friendly user interface to display the reservation schedule of a doctor, and the posted surgical slots timetable of a surgery center.

30 Boxes Alternatives to deliver calendar service

PayPal Provide a financial platform to accomplish the payments

Stripe Alternatives of payment platform to deliver online payment service

NDI/NCS Alternatives

57

Feasibility Evidence NDI/NCS Criteria- NDI/NCS Attribute

No. Evaluation Criteria – NDI/NCS attributes Weight

1 Inter-component Compatibility 12

2 Product performance 10

3 Functionality 16

4 Flexibility 12

5 Maturity of product 7

6 Vendor support 8

7 Security 14

8 Ease of use 9

9 Ease of maintain 10

10 Scalability 12

Total 100

58

Feasibility Evidence NDI/NCS Criteria- NDI/NCS Feature

No. NDI/NCS Features/ sub features Weight

1 Alert Management 22

2 Payment16

3 Profile Management14

4 Reservation Management14

5 Search12

6 Surgical slot posting management11

7 System monitor11

Total100

59

Feasibility Evidence NDI/NCS evaluation-Evaluation Results

Screen Matrix

No W R1 R2 R3 AVG

Total R1 R2 R3 AVG Toal

A1 10 10 9 10 9.7 29 6 7 6 6.3 19

A2 10 8 8 10 8.7 26 6 8 7 7.0 21

A3 13 13 10 12 11.7 35 10 12 13 11.7 35

A4 10 10 7 9 8.7 26 10 10 10 10.0 30

A5 7 6 7 5 6.0 18 5 5 6 5.3 16

A6 7 5 7 7 6.3 19 7 7 7 7.0 21

A7 12 10 10 10 10.0 30 12 12 12 12.0 36

A8 9 8 8 8 8 24 6 6 6 6 18

A9 10 9 9 10 9.3 28 9 8 10 9.0 27

A10 12 10 12 9 10.3 31 10 10 11 10.3 31

Total 100 89 87 90 88.63 266 81 85 88 84.7 254

Google Calendar VS. 30 Boxes

60


Screen Matrix

No W R1 R2 R3 AVG


A1 10 10 9 10 9.7 29 10 10 10 10.0 30

A2 10 8 8 10 8.7 26 9 8 10 9.0 27

A3 13 12 12 11 11.7 35 12 12 12 12.0 36

A4 10 9 7 10 8.7 26 10 10 8 9.3 28

A5 7 7 7 5 6.3 19 6 5 5 5.3 16

A6 7 5 7 8 6.7 20 5 4 6 5.0 15

A7 12 10 12 11 11.0 33 7 6 12 8.3 25

A8 9 4 8 8 6.7 20 7 6 8 7.0 21

A9 10 9 6 10 8.3 25 7 8 10 8.3 25

A10 12 10 12 10 10.7 32 7 9 9 8.3 25

Total 100 84 88 93 88.3 265 80 78 90 82.7 248

Google Map VS. Microsoft Bing Map

61


Screen Matrix

No W R1 R2 R3 AVG


A1 10 10 9 10 9.7 29 6 7 6 6.3 19

A2 10 8 8 10 8.7 26 6 8 7 7 21

A3 13 13 10 12 11.7 35 10 12 13 11.7 35

A4 10 10 7 9 8.7 26 10 10 10 10 30

A5 7 6 7 5 6 18 5 5 6 5.3 16

A6 7 5 7 7 6.3 19 7 7 7 7 21

A7 12 12 12 12 12 36 12 12 12 12 36

A8 9 9 9 9 9 27 6 6 6 6 18

A9 10 9 9 10 9.3 28 9 8 10 9 27

A10 12 10 12 9 10.3 31 10 10 11 10.3 31

Total 100 92 90 93 91.7 275 81 85 88 84.7 254

PayPal VS. Stripe

62

Feasibility Evidence Evaluation Results

Component Purpose Advantage over alternatives

Google Map Map service Inter-component compatibility, ease of use

Google Calendar Calendar service Better support

PayPal Online payment service

Security

63

Feasibility Evidence Business Case-Cost Analysis

Activities Time Spent /Hours

Development Period (24 weeks)

Valuation and Foundations Phases: Time Invested (CS577a, 12 weeks)

Client: Meeting via email, phone, and other channels [4 hrs/week * 12 weeks * 1 people] 48

Client: Win-Win session meeting with team and 577 instructor (2hrs/week * 2 times* 1 people) 4

Architecture Review Boards [2 hrs * 2 times * 1 people] 4

Valuation and Foundations Phases: Time Invested (CS577a, 12 weeks)

Client: Meeting via email, phone, and other channels [10 hrs/week * 12 weeks * 1 people] 120

Client: Training new users(Surgery Center) [5 hrs/week * 12 weeks * 1 people] 60

Architecture Review Boards and Core Capability Drive-through session [2 hrs*3times*1 people] 6

Maintainer: Meeting via email, phone, and other channels to get familiar with the system [5 hrs/week * 12 weeks * 2people] 120

Sales team: Advertise the system to clients, meeting with clients [5 hrs/week * 12 weeks * 2 people] 120

Deployment of system in operation phase and training - Installation and Deployment [5 hrs * 2 times * 2 people] - Training and Support [5 hrs * 2 times * 2 people]

40

Total 522

Maintenance Period (1 year)

Sales team: - Advertise the system to clients[10 hrs/week * 52weeks * 2 person] - Training new clients [10 hrs/week * 52 weeks * 2 person]

2080

Maintenance: Monitor user activities [20 hrs/week* 52 weeks * 2 person] 2080

Total 4160

64

Feasibility Evidence Business Case-Cost Analysis(Hardware and Software Costs-Development)

Type Cost($/year) Rationale

Java Spring Framework

0 The Spring Framework is an open source application framework

Microsoft SQL Server

0 Microsoft freeware edition is available

Apache Tomcat Server

0 Apache Tomcat Sercer is an open source web server and servlet container

JDBC driver 0 Free software component

Domain host: GoDaddy

12.99 GoDaddy makes it look like .com domains cost $10 for the first year and $15 for every year after that.

Cloud Hosting* 350 Amazon EC2 charges fee based on the time and data usage, in operational phase we assume we will need light usage.

Google Map Service 0 Google JavaScript Maps API v3, 25 000 usage limit(per day), 1,000 excess map loads(in U.S. dollars) will cost $0.50. In development there won’t be more than 25000 usages per day.

Google Calendar Service

0 The Google Calendar API has a courtesy limit of 100,000 queries per day. But you can change the limit in the project in Google Cloud Console.

PayPal Service 0 PayPal API charges 1.5% + 0.29USD / transaction, in the development phase we assume there will be no transaction going on.

Total 362.99

65

Feasibility Evidence Business Case-Cost Analysis(Hardware and Software Costs-Operation)

Type Cost($/year) Rationale

Cloud Hosting* 1396.8 Amazon EC2 charges fee based on the time and data usage, in operational phase we assume we will need light usage.

Domain host: GoDaddy 12.99 GoDaddy makes it look like .com domains cost $12.99 every year.

Google Map Service 0 Google JavaScript Maps API v3, 25,000 usage limit(per day), 1,000 excess map loads(in U.S. dollars) will cost $0.50. In this phase the everyday usage will not exceed this number.

Google Calendar Service 0 The Google Calendar API has a courtesy limit of 100,000 queries per day. But you can change the limit in the project in Google Cloud Console.

PayPal Service 3774 PayPal charges 1.5% + 0.29USD / transaction. Assume annual payment from the PayPal for the surgeons is 240k and 50*12=600 transactions.

Total 5183.79

66

Feasibility Evidence Business Case-Benefit Analysis

Current activities & resources used % Reduce Time Saved (Hours/Year)

Surgery room reservation process

Surgery Centers (1hrs/reservation * 30000reservations)20% 6000

Doctors (1hrs/reservation * 30000 reservations) 30% 9000

Search for ideal surgery rooms

Doctors (0.25hrs/search * 1000searches week*52week)80% 10400

License verification process

Surgery Centers (0.5hr/verification * 30000 reservations)10% 1500

Schedule Management

Surgery Centers (4hr/week * 52 weeks*10 Surgery Centers)50% 1040

Total 27940

67

Feasibility Evidence Business ROI Analysis

2013.9 2014.9 2015.9 2016.9

-2

-1

0

1

2

3

4

5

6

Year CostBenefit

(Effort Saved)Cumulative

CostCumulative

BenefitROI

2013-2014 522 0 522 0 -1.00

2014-2015 4419 27940 5259 27940 4.31

2015-2016 8838 55880 14097 83820 4.95

2016-2017 17676 111760 31773 195580 5.15

68

Feasibility Evidence

Page flow may be unconnected and too confusing: Page flow incomplete or confusing->our system is less attractive to customers

Major Risks

Mitigation

- Properly design the sequence diagram in SSAD. Define connection between pages, making it both logically clear and fits user habit.

- Prototype the page flow.

User interface may be undesirable: UI unattractive or UI doesn’t keep users informed and given appropriate feedback. -> User not prefer to use our system

Mitigation

-Design attractive and user-friendly user interface.

-Prototype on each user page, based on user scenario.

69

Feasibility Evidence Conlusion

1) NCS process pattern is the most suitable process for the project. Since we need to add features and UI to the legacy system, which mainly rely on network service.

2) Google Map, Google Calendar, PayPal and Spring JavaMail are currently our choice for implementing the features that matches Win-Win condition.

3) The business case analysis shows a very positive trend on ROI based on the data our client provided.

70

Acceptance Test Plan and Cases

71

Test CasesID Test Case

TC-01 User log in

TC-02 User log out

TC-03 Create profile

TC-04 View profile

TC-05 Update profile

TC-06 Upload attachment

TC-07 Receive email notification

TC-08 Reset Password

TC-09 Create new user

TC-10 Modify/delete user

TC-11 Post surgical slot

TC-12 View posted surgical slot

72

Test CasesID Test Case

TC-13 Update posted surgical slot

TC-14 View reservation request

TC-15 Confirm reservation request

TC-16 Decline reservation request

TC-17 Search surgical slot

TC-18 Submit reservation request

TC-19 View submitted reservation request

TC-20 Cancel submitted reservation request

TC-21 Synchronize calendar

TC-22 Set up reminder

TC-23 Make payment

TC-24 Page loading time

73

Test Case Example 1

74

Test Case Example 2

75

Quality Focal Point

76

Metrics Reporting: Progress Indicator

1 2 3 4 5 6 7 8 9 10 11 12 13 14 150

10

20

30

40

50

60

Initial PlanActual

Cum

ulati

ve ta

sks

com

plet

ed

Date

77

Metrics Reporting: Defects Status

1 2 3 4 5 6 7 8 9 10 11 12 13 14 150

5

10

15

20

25

Closed/WeekOpened/WeekTotal Active

Nu

mb

er

of

defe

cts

Date

78

Technical DebtSolved:

1. Inserting Google Maps into the website, using it to show location of surgery centers and distance from doctor users to them.

2. Inserting Google Calendar into the website so that surgery centers can post slot on it and doctors can reserve slot from it. Synchronize reserved slot with user’s Google Calendar.

3. Email notification. Sending email to users with activities related to their account like reservation confirmed/declined, requests submitted.

79

Technical DebtRemaining:

1. Scalability. Even though we choose JSP as our back-end, but since we don’t have experience building large scale website, in terms of visitors number, we are not sure about the scalability of the system.

2. Concurrency. Surgery center delete a posted slot while doctor reserving it. Doctor cancel a reservation request while surgery center confirming it.

3. Payment system. Need to learn how to let the user pay using their credit card or Paypal in the website.

80

Traceability MatrixOCD

User Requirements

Use Cases Test Cases

OC-1

WC_2774, WC_2763, WC_2734, WC_2429

UC-14, UC-15, UC-16, UC-09, UC-08, UC-10, UC-31

TC-14, TC-15, TC-16, TC-18, TC-19, TC-20, TC-21

OC-2

WC_2754, WC_2753, WC_2736, WC_2426, WC_2423

UC-01, UC-02, UC-03, UC-04, UC-05, UC-06, UC-28

TC-01, TC-02, TC-03, TC-04, TC-05, TC-06, TC-08

OC-3

WC_2434, WC_2422, WC_2419, WC_2418, WC_2415, WC_2410, WC_2409

UC-27, UC-32 TC-07, TC-22

OC-4

WC_2739, WC_2432, WC_2428

UC-07 TC-17

OC-5

WC_2775, WC_2761 UC-11, UC-12, UC-13 TC-11, TC-12, TC-13

OC-6

WC_2276, WC_2425 UC-26, UC-30 TC-23

OC-7

WC_2767, WC_2766, WC_2765, WC_2764

UC-25, UC-20, UC-21, UC-22, UC-19, UC-17, UC-18,

TC-09, TC-10