architecture review board
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
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 ConceptProject Constraints
12
Operational ConceptWorkflow comparison
13
Operational ConceptProposed New System – Element Relationship
Diagram
14
Operational ConceptSystem Capabilities
15
Operational ConceptLevel of Services
16
Prototype
To mitigate high-risk.Base of future implementation“To simulate interactions between
users and applications” ——from ICSM-EPG
Goals
17
PrototypePage 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 PrototypingEvolutionary PrototypingFront-end designTransition 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 RolesStakeholder Responsibility in each phasePlans for 577b
Rebaseline 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 RoleWanghai 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/14Concept: Since there might be some changes
during the winter break, we have to prepare and reflex those changes in the documents.
Deliverables: Updated documentsMilestone: 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/14Task: Core capability implementationCapability:
Profile ManagementPosting Surgical SlotsReservationSearch ManagementEmail Alert
41
Plan for 577bConstruction Iteration2
Duration: 3/31/14 to 4/18/14Task: Full capability implementationCapability:
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 system2. 4/23 Deliver the system and documents3. 4/24 Provide training to the clients and
maintainer4. 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 preparationAmazon AWS(Jenkins Server, App Server, Database Server): Association of Elastic IPs, security groups configurationSW preparationSupport Documentation, Github repository, GoDaddy Domain, DBMS, Jenkins MSSite preparationBackup data
47
Transition PlanSchedule
48
Support PlanSupport EnvironmentHardwareAmazon AWS and associated documentsJenkins ServerDatabase ServerApp Server
49
Support PlanSupport EnvironmentSoftware
50
Support PlanSupport EnvironmentSoftware
51
Support PlanSupport EnvironmentSoftware
52
Support PlanSupport EnvironmentSoftware
53
Support PlanSupport EnvironmentSoftware
54
Support PlanSupport EnvironmentFacilitySecurity Group Configuration, Backup data, Association of Elastic IPs
55
Support Plan Release StrategyDescription (New Features and Important Changes since the previous releaseUpcoming Changes that will be incorporated in future releasesKnown 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
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 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
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 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 Cost Benefit(Effort Saved)
Cumulative Cost
Cumulative Benefit ROI
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 CaseTC-01 User log inTC-02 User log outTC-03 Create profileTC-04 View profileTC-05 Update profileTC-06 Upload attachmentTC-07 Receive email notificationTC-08 Reset PasswordTC-09 Create new userTC-10 Modify/delete userTC-11 Post surgical slotTC-12 View posted surgical slot
72
Test CasesID Test CaseTC-13 Update posted surgical slotTC-14 View reservation requestTC-15 Confirm reservation requestTC-16 Decline reservation requestTC-17 Search surgical slotTC-18 Submit reservation requestTC-19 View submitted reservation requestTC-20 Cancel submitted reservation requestTC-21 Synchronize calendarTC-22 Set up reminderTC-23 Make paymentTC-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 c
ompl
eted
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 ActiveN
umbe
r of
de
fect
s
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