1. SnapValet ARB Team 03 1

2. Test Plan & Cases Molly Karcher 2

3. Testing Strategy Overview Unit testing JUnit & Eclipse Value-based prioritization Automated Functional Testing Using Android ActivityMonitor Functional tests map to TC-01 through TC-07 from TCP Requirements-Test traceability Test suite run on-commit Formal Quality Testing (Acceptance Testing) Functional tests performed manually on clients pointing to a deployed production box 3

4. Functional Test Cases TC-01-01 Create a Driver User Profile TC-01-02 Create a Valet User Profile TC-01-03 Edit a Driver User Profile TC-02-01 Check-in at Location as Valet TC-02-02 Create a new Valet Shift TC-02-03 Receive Retrieval Requests on Valet Queue TC-02-04 Acknowledge & Edit Customer Retrieval Requests on Valet Queue TC-02-05 Send Re-parking Notification from Valet Queue TC-02-06 Close out Valet Shift TC-03-01 Driver Check-in at Location 4

5. Functional Test Cases TC-04-01 Car Retrieval Request TC-05-01 Process Mobile Payment through App TC-05-02 Opt out of Mobile Payment TC-05-03 Post-Pickup Confirmation Email & Receipt TC-06-01 Create Valet Company Administrative Account TC-06-02 Add Employees through Administrative Account TC-06-03 Add Managed Locations through Administrative Account TC-06-04 Remove Employees through Administrative Account TC-06-05 Remove Managed Locations through Administrative Account TC-07-01 Scale to 25,000 Users. 5

6. Example: TC-04-01 Car Retrieval Request 6

7. SnapValet ARB Team Evaluation Molly Karcher 7

8. Strengths and Weaknesses: Operational View Strengths All members are friendly, collaborative, and punctual in regards to deadlines Strong sense of communal responsibility for deliverables Client is very available, agreeable, and responsive Quick and decisive in task delegation; good sense of communal responsibility Use of online collaboration tools (Google groups, Bugzilla, Winbook, Facebook messages, etc. Better cross-role collaboration since first ARB Weaknesses Deliverables generated very close to deadlines, leaves minimal time for verification Lack of availability of remote team member during normal workday hours Becoming less conscientious about sending meeting minutes and updating Bugzilla tasks as final exams for other classes approach Will lose one teammate in 577b 8

9. Strengths and Weaknesses: Technical View Strengths All computer science Masters students - quickly & effectively learn new technologies Strong familiarity with MySQL Strong familiarity with Java (easy transition to Android) Some of the team took Web Tech this semester COTS tools nailed down and prototyped Weaknesses Lack of mobile development experience Lack of familiarity with Braintree API Scope creep Lack of experience building scalable systems from scratch 9

10. Overall Project Evaluation Detailed/feasible, though very ambitious schedule for 577b – Development will need to be very closely tracked to ensure we maintain schedule. All high risks have been identified as requirements stabilized, and all have mitigation plans, but have not actually be mitigated yet – At present, not all Win Conditions have been prototyped Technical architecture was developed very thoroughly and with collaboration of entire team, so it is very well understood – Should ease initial phases of development & learning curve for all developers 10

11. Operations Concept Description Abhinandan Patni 11

12. Outline System Purpose Shared Vision Proposed System Benefits Chain Diagram System Boundary Desired Capabilities and Goals 12

13. System Purpose To enable cashless transactions for valet parking payment. To increase the speed of the valet pick-up service. To improve the valet experience of customers. To facilitate better transaction and account management for valet companies. 13

14. Shared Vision 14

15. Proposed System – Entity Relationship Diagram 15

16. Proposed System – Business Workflow Diagram 16

17. Benefits Chain Diagram 17

18. System Boundaries 18

19. Desired Capabilities Mobile Transaction (OC1) Notifications (OC2) Admin Interfacing (OC3) Geolocation Checkin (OC4) Profile Managment (OC5) Advertisements and Suggestions (OC7) 19

20. LEVELS OF SERVICE Response Time – 1-3 seconds between screens. Availability – Maximum downtime of 10 mins during heavy usage hours (Weekdays – 6-9pm, Weekends – 6-10pm) Security – In addition to intrusion and cyber attacks, we have developed a few functionality test cases to account for other security flaws. Maintainability – Will be handled by a SnapValet employee once the project is complete next May. Modularity in code to keep things simple. Scalability – Adapt the system for multiple servers and to handle around 100 requests at the same time. 20

21. Organizational and Operational Transformations Need for central tablet per valet parking area. Employee IDs a must. Update the list of restaurants serviced. Customers have to enter ticket numbers Valets are notified of requests on the tablet. Customers are notified on their smartphones by valet. Payment can be done via mobile transaction. 21

22. Prototype II Brian Vanover 22

23. Outline SnapValet Refresher Java Client-Server Simulation Request & Pay Retrieve & Return (started) Android/Java Braintree Proof of Concept 23

24. Vehicle Request Following check-in, customers can request their vehicle by entering the number on the ticket that was given to them by the valet. This will generate a request that will be displayed in the valet queue following a prompt for payment Request Activity -requestTicketNumber -validateTicketNumber -putExtra -startPaymentActivity 24

25. Payment Customers will have the option of paying cash or mobile. Payment will be verified before release of the vehicle Payment Activity -getLocationFee -Realized efficiency -requestTip -validateTip (double) -putExtraPayment -submitRequest -startThanksActivity 25

26. Request Queue Interface for Valet interaction with request queue QueueActivity -CRUD Operations -displayQueue -parseResponse -Efficiency Realization QueueUpdateRetriever -New Thread -run(): request updates from server periodically 26

27. SnapValetServer Main -Socket -Case-based Parsing -Simulated DBs QueueUpdater -addValetRequest -updateQueue 27

28. Braintree API Android/Java Simple demonstration of credit card transaction 28

29. Requirements Ridhima Manjrekar 29

30. Outline High Priority Requirements Major changes Not agreed/Potentially agreed Future Requirements 30

31. High Priority Requirements Geo-location check-in : both customer and the valet Secure payment transaction : credit card information encrypted System to be available during heavy usage hours Valet companies to be registered to manage their employees and transactions. Valet to receive real time requests from the customers Valet to be able to notify the customer 31

32. Major Changes Tips not pooled now Braintree app to be used for payment transaction Valet company will not get detailed report of transaction Valet company have to be registered with Snapvalet and should provide their employee details. Profile management of employees Customer just gets notified once Cost for valet service can be changed by the valet 32

33. Not agreed/potentially agreed Establishments to be able to send advertisements System shall be capable of running an iOS client What kind of transaction report the valet company will get 33

34. Future Requirements To be able to work on multiple servers about 100 requests at the same time Code to be modular to isolate defects Advertisements and Suggestions 34

35. Architecture Ditong Ding 35

36. Outline System Context Artifacts & Information Behavior (Use case Diagram) Hardware Component Diagram Software Component Diagram Deployment Diagram Class Diagram Sequence Diagram (for two major use cases) 36

37. System Context 37

38. Artifacts & Information 38

39. Behavior (Use case Diagram) 39

40. Hardware Component Diagram 40

41. Software Component Diagram 41

42. Deployment Diagram 42

43. Class Diagram 43

44. Sequence Diagram 44

45. Saikarthik Desiraju Life Cycle Plan 45

46. Stakeholder roles RoleTeam Member ClientMona A Project ManagerBrian Vanover Feasibility AnalystXiaoting Bi IIV & V QFP Molly Karcher Requirements Engineer Tester Ridhima Manjrekar System Architect UML Modeler Ditong Dong Life Cycle PlannerSaikarthik Desiraju Operational Concept Engineer Developer New Team Member (CS577b) System MaintainerSnapValet employee 46

47. Milestones DCR RDCR CCD TRR OCR 47

48. Activities & Responsibilities 48

49. Activities & Responsibilities 49

50. Activities & Responsibilities 50

51. Activities & Responsibilities 51

52. Core Capabilities IDTraceCapabilityDescriptionPriorityIteration 1UC-1,5 TC-02-01, TC- 03-01 Geo-Location check in A customer and a valet should be able to check-in at the establishment (location) they are at. High1 2UC-6, OC-1 TC-05-01 Mobile transactionA customer should be able to pay for valet service using his credit card on the application. High1 3UC-6, OC-4 TC-04-01 Ticket number entryThe customer must be able to enter his valet ticket number into the application. High1 4UC-6, OC-2 TC-04-01 Request VehicleA customer should be able to request for his vehicle via the app. High1 5UC-4, OC-5 TC-02-04 Retrieval Notification A customer should receive a notification on his device when his vehicle is being retrieved. High1 6UC-4, OC-3 TC-02-04 Queue : RetrieveThe valet is able to visually validate the ticket number and then notify the customer of car retrieval. High1 7UC-4, OC-3 TC-02-04 Queue : Report “invalid” ticket number The valet is able to notify a customer that he/she entered a wrong ticket number High1 8UC-4, OC-3 TC-02-04 Queue : Close out request A valet is able to close out a served request and remove it from the queue High1 9UC-2, TC-02-02, TC-02-06 Start and close out a shift A valet should be able to start a shift for other valets to add on to and be able to close out a shift. High1 10UC-2,7, TC-01- 01, TC-01-02, TC-01-03 Profile managementA customer and a valet are able to register and create a profile on the app. High1 52

53. Risk Management & Contingency Plans  No new team member & developer : Ridhima Manjrekar will be the Operational Concepts engineer.  Prototyping continues in the winter break.  Starting development early. 3 rd week of January.  Relevant course work  Continuous assessment of apps workflow. We keep trying to break it. GOAL : Smooth CCD (March 25th,2015) 53

54. Xiaoting Bi Feasibility Evidence Description 54

55. Business Case Analysis Cost & Benefits 55

56. Personnel Costs 56

57. Hardware and Software Costs Personnel Costs (cont.) 57

58. Benefit Analysis For client: For users: 58

59. ROI Analysis 59

60. Risks 60

61. Risks (cont.) 61

62. Risks changed Delete risks: 62

63. NDI/NCS Analysis Connector We use Java/MySQL Connector to enable the mobile application to retrieve and update data from the database. We use PHP/MySQL Connector to enable the web application to retrieve and update data from the database. Legacy System None. 63

64. NDI/NCS Analysis 64

65. Quality Focal Point Molly Karcher 65

66. Metrics Reporting: Estimate vs. Actual Hours 66

67. Metrics Reporting: Defect Status 67

68. Technical Debt Solved Braintree API – Prototyped Google Places API – Prototyped Requirements Volatility – Rapid adaptation Scope creep – Solidification of requirements Unsolved Mobile inexperience – Solve by team completing tutorials Win Conditions un-prototyped – Solve by following 577b development schedule very closely Concurrency – Solve through manual and functional testing Scalability – Solve through manual and functional testing 68

69. Traceability Matrix OCDRequirementsUse CasesTest Cases OC-1 Mobile TransactionWC-3392, WC-3204UC-4, UC-6 TC-04-01, TC-05-01, TC-05-02, TC-05-03 OC-2 Notifications WC-3390, WC-3386, WC-3384, WC-3205UC-4, UC-6 TC-02-03, TC-02-04, TC-02-05, TC-04-01 OC-3 Admin Interfacing WC-3391, WC-3387, WC-3385 UC-8, UC-9, UC-11, UC-13, UC-12 TC-02-02, TC-06-01, TC-06-02, TC-06-03, TC-06-04, TC-06-05 OC-4 Geolocation CheckinWC-3215, WC-3203UC-1, UC-5TC-02-01, TC-03-01 OC-5 Profile ManagementWC-3387, WC-3208 UC-2, UC-5, UC-7 TC-01-01, TC-01-02, TC-01-03 OC-6 AdvertisingWC-3210UC-5TC-03-01 69

70. Questions? 70