Architecture Review Board
Team 11 Surgery Assist
1

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
2

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.
3

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 4

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.
5

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.
6

Operational Concept
System Objectives

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.
7

Operational Concept
Shared Vision
8

Operational Concept
Benefit Chain Diagram
9

Operational Concept
System Boundary Diagram
10

Operational Concept
Project Constraints
11

Operational Concept
Workflow comparison
12

Operational Concept
Proposed New System – Element Relationship Diagram
13

Operational Concept
System Capabilities
14

Operational Concept
Level of Services
15

Prototype
Goals



16

High risk items:
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.
17

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

Architecture
Use Case Diagram
19

Architecture
Artifacts & Information Diagram
20

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

Class Diagram
Architecture
22

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

Architecture
24

Architecture
25

Architecture
NDI/NCS Evaluation
26

Architecture
Login Sequence Diagram
27

Architecture
Reservation Sequence Diagram
28

Life Cycle Plan
Team 11
29

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

31

32

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.
33

Team Member Roles
Member
Wanghai Gu
Role
Project Manager
Requirement Engineer
Builder & Trainer
Longfeng Jia
Xiheng Yue
New Member1
New Member2
Operational Concept
Engineer
Builder & Tester
Software Architecture
IV&V
Builder & Trainer
Feasibility Analyst
Builder & Tester
Life Cycle Planner
Tester
34

Member
David (client)
Wanghai Gu
Longfeng Jia
Rebaseline Construction Transition
Elaborate any changes of
Requirements
Elaborate any changes in requirements
Elaborate any changes in operational concept
Provide feedback and suggestions to team
Building database system;
Build Reservation and
Slots posting management
Improve security of running service; Construct
Profile System
Participate in training process
Transition from localhost to client‘s server; Maintainer
Training
Adjust Hardware and
Software environment;
Maintainer Training
Xiheng Yue Elaborate architecture
New Member1
New Member2
Elaborate feasibility evidence
Elaborate life cycle plan
Coordinate back-end and front-end; Build Search
System
Building database system;
Build Reservation and
Slots posting management
Transition from localhost to client's server; Customer
Training
Adjust Hardware and
Software environment;
Customer Training
Implementation for Email
Alert; Main Tester
Testing and Fix bugs ;
Problem solving
35

 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
36

Plan for 577b
Rebaselined 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
37

Plan for 577b
Rebaselined Foundation Phase
38

Plan for 577b
Development 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
39

Plan for 577b
Construction Iteration1

Duration: 2/14/14 to 4/16/14

Task: Core capability implementation
 Capability:

Profile Management

Posting Surgical Slots

Reservation

Search Management

Email Alert
40

Plan for 577b
Construction Iteration2

Duration: 3/31/14 to 4/18/14

Task: Full capability implementation
 Capability:

Payment

Monitor (System log monitoring)
41

Plan for 577b
Development Phase - Construction Iteration
42

Plan for 577b
Development Phase - Transition Iteration
43

Transition Plan

Tasks(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
44

Transition Plan (Documents)
 Feasibility Evidence Description
 Life Cycle Plan
 Maintenance Manual
 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
45

Transition Plan
 HW 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
46

Schedule
Transition Plan
47

Support Plan

Support Environment

Hardware
Amazon AWS and associated documents
Jenkins Server
Database Server
App Server
48

Support Plan

Support Environment

Software
Table 1: Description of Software required in Support Plan
Software Requirement:
Rationale:
User/Operator Manual:
Availability Information:
Note:
GoDaddy Domain name
The website needs a domain
Maintenance manual http://www.godaddy.com/
Username and password required, Annual fee to keep the domain name
49

Support Plan

Support Environment

Software
50

Support Plan

Support Environment

Software
51

Support Plan

Support Environment

Software
52

Support Plan

Support Environment

Software
53

Support Plan

Support Environment

Facility
Security Group Configuration, Backup data, Association of
Elastic IPs
54

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
55

Feasibility Evidence
NDI/NCS Products Purposes
Google Map
Microsoft Bing Map
Google Calendar
30 Boxes
PayPal
Stripe
Provide a friendly user interface to display the searched surgery centers in a two dimensional fashion
Similar to Google Map can provide a map view on search results
Provide a friendly user interface to display the reservation schedule of a doctor, and the posted surgical slots timetable of a surgery center.
Alternatives to deliver calendar service
Provide a financial platform to accomplish the payments
Alternatives of payment platform to deliver online payment service
56

Feasibility Evidence
NDI/NCS Attribute
No. Evaluation Criteria – NDI/NCS attributes
1 Inter-component Compatibility
2 Product performance
3 Functionality
4 Flexibility
5 Maturity of product
6 Vendor support
7 Security
8 Ease of use
9 Ease of maintain
10 Scalability
Total
14
9
10
12
100
7
8
16
12
Weight
12
10
57

Feasibility Evidence
NDI/NCS Feature
No.
NDI/NCS Features/ sub features
1 Alert Management
2 Payment
3 Profile Management
4 Reservation Management
5 Search
6 Surgical slot posting management
7 System monitor
Total
Weight
12
11
11
100
22
16
14
14
58

Feasibility Evidence
Evaluation Results Screen Matrix
Google Calendar VS. 30 Boxes
No W R1 R2 R3 AV
G
A1
A2
10
10
10
8
9
8
10
10
9.7
8.7
A3
A4
13
10
13
10
10
7
12
9
Total R1 R2 R3 AV
G
29
26
6
6
7
8
6
7
6.3
7.0
11.7
35
8.7
26
10 12
10 10
13
10
Toal
19
21
11.7
35
10.0
30
A5
A6
A7
A8
7
7
12
9
A9 10
A10 12
9
10
Total 100 89
6
5
10
8
9
12
87
7
7
10
8
10
9
90
5
7
10
8
6.0
6.3
18
19
10.0
30
8 24
9.3
28
10.3
31
88.63
266
5
7
5
7
12 12
6 6
9 8
10 10
81 85
10
11
88
6
7
12
6
5.3
7.0
16
21
12.0
36
6 18
9.0
27
10.3
31
84.7
254
59

Feasibility Evidence
Evaluation Results Screen Matrix
Google Map VS. Microsoft Bing Map
No W R1 R2 R3 AV
G
A1
A2
10
10
10
8
9
8
10
10
9.7
8.7
A3
A4
A5
A6
A7
A8
7
7
13
10
12
9
A9 10
A10 12
9
10
Total 100 84
7
5
12
9
10
4
10
10
93
5
8
11
10
11
8
6
12
88
7
7
12
7
12
8
11.7
35
8.7
26
6.3
6.7
19
20
11.0
33
6.7
20
8.3
25
10.7
32
88.3
265
Total R1 R2 R3 AV
G
29
26
10 10
9 8
Toal
10 10.0
30
10 9.0
27
6
5
7
7
12 12
10 10
5
4
6
6
7
7
8
9
80 78
12 12.0
36
8 9.3
28
5 5.3
6 5.0
16
15
12 8.3
8 7.0
10 8.3
25
21
25
9 8.3
25
90 82.7
248
60

Feasibility Evidence
Evaluation Results Screen Matrix
PayPal VS. Stripe
No W R1 R2 R3 AV
A1
A2
A3
A4
A5
A6
10
A7
A8
12
9
A9 10
A10 12
Total 100
10
13
10
7
7
10
8
13
10
6
5
12
9
9
10
92
9
7
7
7
8
10
12
9
9
12
90
10
G
9.7
9
5
7
10 8.7
12 11.7
8.7
6
6.3
12
9
10
9
12
9
9.3
10.3
36
27
28
31
93 91.7 275
26
18
19
Total R1 R2 R3 AV
G
29 6 7 6 6.3
26
35
6 8
10 12
Toal
7 7
19
21
13 11.7
35
10 10
5
7
5
7
12 12
6 6
9 8
10 10
81 85
12
6
10
10
6
7
12
6
9
10
5.3
7
36
18
27
30
16
21
11 10.3
31
88 84.7
254
61

Feasibility Evidence
Component
Google Map
Google Calendar
PayPal
Purpose
Map service
Calendar service
Online payment service
Advantage over alternatives
Inter-component compatibility, ease of use
Better support
Security
62

Feasibility Evidence
Activities
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]
Client: Win-Win session meeting with team and 577 instructor (2hrs/week * 2 times* 1 people)
Architecture Review Boards [2 hrs * 2 times * 1 people]
Valuation and Foundations Phases: Time Invested (CS577a, 12 weeks)
Client: Meeting via email, phone, and other channels [10 hrs/week * 12 weeks * 1 people]
Client: Training new users(Surgery Center) [5 hrs/week * 12 weeks * 1 people]
Architecture Review Boards and Core Capability Drive-through session [2 hrs*3times*1 people]
Maintainer: Meeting via email, phone, and other channels to get familiar with the system [5 hrs/week * 12 weeks * 2people]
Sales team: Advertise the system to clients, meeting with clients [5 hrs/week * 12 weeks * 2 people]
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]
Total
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]
Maintenance: Monitor user activities [20 hrs/week* 52 weeks * 2 person]
Total
Time Spent
/Hours
120
60
6
120
120
40
48
4
4
522
2080
2080 63
4160

Feasibility Evidence
(Hardware and Software
Costs-Development)
Type Cost($/year) Rationale
0 Java Spring
Framework
Microsoft SQL Server
Apache Tomcat
Server
JDBC driver
Domain host:
GoDaddy
Cloud Hosting*
Google Map Service
Google Calendar
Service
PayPal Service
Total
0
0
0
12.99
350
0
0
0
362.99
The Spring Framework is an open source application framework
Microsoft freeware edition is available
Apache Tomcat Sercer is an open source web server and servlet container
Free software component
GoDaddy makes it look like .com domains cost $10 for the first year and $15 for every year after that.
Amazon EC2 charges fee based on the time and data usage, in operational phase we assume we will need light usage.
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.
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 API charges 1.5% + 0.29USD / transaction, in the development phase we assume there will be no transaction going on.
64

Feasibility Evidence
(Hardware and Software
Costs-Operation)
Type Cost($/year) Rationale
Cloud Hosting*
Domain host: GoDaddy
Google Map Service
Google Calendar Service
PayPal Service
1396.8
12.99
0
0
3774
Amazon EC2 charges fee based on the time and data usage, in operational phase we assume we will need light usage.
GoDaddy makes it look like .com domains cost
$12.99 every year.
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.
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 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
65

Feasibility Evidence
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)
Search for ideal surgery rooms
Doctors (0.25hrs/search * 1000searches week*52week)
30 % 9000
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)
Total
50 % 1040
27940
66

Feasibility Evidence
Year
2013-2014
2014-2015
2015-2016
2016-2017
Cost
522
4419
8838
17676
Benefit
(Effort Saved)
0
27940
55880
111760
Cumulative
Cost
522
5259
14097
31773
Cumulative
Benefit
0
27940
83820
195580
ROI
-1.00
4.31
4.95
5.15
2
1
0
-1
-2
6
5
4
3
2013,9 2014,9 2015,9 2016,9
67

Feasibility Evidence
 Page flow may be unconnected and too confusing:
Page flow incomplete or confusing->our system is less attractive to customers
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.
68

Feasibility Evidence

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.
69

Acceptance Test Plan and Cases
70

ID
TC-01
TC-02
TC-03
TC-04
TC-05
TC-06
TC-07
TC-08
TC-09
TC-10
TC-11
TC-12
Test Cases
Test Case
User log in
User log out
Create profile
View profile
Update profile
Upload attachment
Receive email notification
Reset Password
Create new user
Modify/delete user
Post surgical slot
View posted surgical slot
71

ID
TC-13
TC-14
TC-15
TC-16
TC-17
TC-18
TC-19
TC-20
TC-21
TC-22
TC-23
TC-24
Test Cases
Test Case
Update posted surgical slot
View reservation request
Confirm reservation request
Decline reservation request
Search surgical slot
Submit reservation request
View submitted reservation request
Cancel submitted reservation request
Synchronize calendar
Set up reminder
Make payment
Page loading time
72

Test Case Example 1
73

Test Case Example 2
74

Quality Focal Point
75

60
50
40
30
20
Initial Plan
Actual
10
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Date
76

25
20
15
10
Closed/Week
Opened/Week
Total Active
5
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Date
77

Technical Debt

:
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.
78

Technical Debt

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.
79

Traceability Matrix
OCD User Requirements Use Cases Test Cases
OC-
1
OC-
2
OC-
3
WC_2774, WC_2763,
WC_2734, WC_2429
WC_2754, WC_2753,
WC_2736, WC_2426,
WC_2423
WC_2434, WC_2422,
WC_2419, WC_2418,
WC_2415, WC_2410,
WC_2409
OC-
4
OC-
5
OC-
6
OC-
7
WC_2739, WC_2432,
WC_2428
WC_2775, WC_2761
WC_2276, WC_2425
WC_2767, WC_2766,
WC_2765, WC_2764
UC-14, UC-15, UC-16, UC-09,
UC-08, UC-10, UC-31
UC-01, UC-02, UC-03, UC-04,
UC-05, UC-06, UC-28
TC-14, TC-15, TC-16, TC-18, TC-
19, TC-20, TC-21
TC-01, TC-02, TC-03, TC-04, TC-
05, TC-06, TC-08
UC-27, UC-32
UC-07
UC-11, UC-12, UC-13
UC-26, UC-30
TC-07, TC-22
TC-17
TC-11, TC-12, TC-13
TC-23
UC-25, UC-20, UC-21, UC-22,
UC-19, UC-17, UC-18,
TC-09, TC-10
80