SnapValet ARB RDCR Global Trojan Solutions – Team 03 1

SnapValet ARB Team Evaluation Molly Karcher

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

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

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

Test Plan & Cases Molly Karcher 6

Testing Strategy Overview Unit testing Eclipse & JUnit Value-based prioritization Targeting 70% unit test coverage on core API Automated Functional Testing Validation on one client operating system Functional tests map to TC-01 through TC-07 from TCP Requirements-Test traceability Test suite run on-commit Formal Quality & Acceptance Testing Functional tests performed manually on clients pointing to a deployed production box 7

Testing Preparation Hardware Local development: laptop Formal acceptance testing: deployment box, client devices Software SnapValet codebase Unit Testing – Eclipse, MySQL, JUnit plug-in Functional Testing – Xcode, KIF framework 8

Test Schedule Test Suite Milestone 1 – March 1 st 2015 TC-01 User Profiles (01-03) TC-03 Geolocation Check-in (01) TC-06 Admin Accounts (01-05) Server Unit Testing - 20% coverage Core Capabilities Drivethrough – March 25 th 2015 TC-04 Car Retrievals (01) TC-05 Payments (01-03) TC-02 Valet Queue (01-06) Server Unit Testing – 50% coverage Transition Readiness Review – April 8 th 2015 TC-07 Load Testing (01) Server Unit Testing – 70% coverage Formal Quality & Acceptance Testing – April 15 th

Operations Concept Description Brian Vanover 10

Outline System Boundary 11

System Boundaries 12

SnapValet ARB Prototype III Global Trojan Solutions – Team 03 13

Outline Play Framework Client-Server Web Application Prototype Valet/Customer Login Valet/Customer Check-in Customer payment/vehicle request Valet Company Management Interfaces Employee Manager Venue Manager PhoneGap Integration o Android 14

Play Framework Client-Server Web Application Prototype Models -Customer -Location -User -Valet -ValetCheckin -User -ValetCompany -ValetRequest Views -employeemanager -index -venuemanager -Checkincustomer -checkinvalet Controller -Application -CustomerController -ValetController 15

PhoneGap Integration Android iOS Pending developer license 16

SnapValet ARB SSAD Global Trojan Solutions – Team 03 17

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) 18

System Context 19

Artifacts & Information 20

Behavior (Use case Diagram) 21

Hardware Component Diagram 22

Software Component Diagram 23

Deployment Diagram 24

Class Diagram 25

Sequence Diagram 26

Ridhima Manjrekar Life Cycle Plan 27

Stakeholder roles RoleTeam Member ClientMona A Project Manager, DeveloperBrian Vanover Feasibility Analyst, DeveloperPatrick Horng IIV & V QFP Molly Karcher Requirements Engineer, Life Cycle Planner, Developer Ridhima Manjrekar System Architect UML Modeler, Developer Ditong Ding Operational Concept Engineer Developer Brian Bousman System MaintainerSnapValet employee 28

Milestones DCR RDCR CCD TRR OCR 29

Activities & Responsibilities 30

Activities & Responsibilities 31

Activities & Responsibilities 32

Iteration Plan Iteration 0 – Preparation 1. Train new team members for project details. 2. Meet with client to verify the requirements 3. Set up develop environment 4. Designing the database 5. Developers get familiar with Play frameworks and PhoneGap 33

Iteration Plan Iteration 1 – Core Capability 1. Login and profile management 2. Geo location check-in 3. Connecting the database to valet side and customer side operations of the app 4. GUI design and implementation 5. Develop payment functionality 6. Prototyping PhoneGap 7. Finishing test plan 34

Iteration Plan Iteration 2 – Full Capability 1. Valet side Website 2. Improved user interface 3. Preparing user manual /demo video 4. Product installation and Transition 5. Rigorous Integration testing 35

Core Capabilities IDTraceCapabilityDescriptionPriorityIteration 1UC-1,5 TC-02-01, TC 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 Mobile transactionA customer should be able to pay for valet service using his credit card on the application. High1 3UC-6, OC-4 TC Ticket number entryThe customer must be able to enter his valet ticket number into the application. High1 4UC-6, OC-2 TC Request VehicleA customer should be able to request for his vehicle via the app. High1 5UC-4, OC-5 TC Retrieval Notification A customer should receive a notification on his device when his vehicle is being retrieved. High1 6UC-4, OC-3 TC 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 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 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 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 , TC-01-02, TC Profile managementA customer and a valet are able to register and create a profile on the app. High1 36

Patrick Horng Feasibility Evidence Description 37

Business Case Analysis 38

Personnel Cost 39

ROI Analysis 40

NDI/NCS Analysis 41 NDI/NCSUsagesComments Google PlacesInteractively maps for searching and displaying places Positive points: - Freeware - Widely used BraintreeMobile transaction platform Positive points: - Widely used and trustworthy for performance MySQLDatabasePositive points: - Freeware - Suitable for Large/Small scale systems - Widely used and trustworthy for performance - Client’s requirement Play FrameworkFramework – app development Positive points: - Freeware - Platform independent - Web app development conforms to client requirement for iOS and Android development BootstrapStyling responsive web design Positive points: - Freeware - Widely used

Risk Analysis 42 Risks Risk Exposure Risk Mitigations Potential Magnitu de Probabil ity Loss Risk Exposur e Inexperience with mobile development may hinder system development (Personnel Shortfalls) 10->31 Use of Play Framework to remove platform dependency. Learning curve is now dependent on Play Framework which is not that difficult to pick up. Client uncertainties and changes regarding system workflow requirements i.e. admin console and/or web application may cause the project to expand out of scope (Underdefined Plans and Requirements) 4416The team will conduct multiple rounds of win negotiations to ensure that both clients and developers are satisfied with the agreed deliverables and system requirements Mobile transactions may create an insecure environment and foster the breach of sensitive data (Value Conflict) 6212The team will learn and apply best practices for securing the application.

Risk Analysis – Cont’d 43 Risks Risk Exposure Risk Mitigations Potential Magnitude Probabilit y Loss Risk Exposure Unclear full understandings of the current process model for valet parking may cause developers and acquirers to fall out of sync with user win conditions (SCS Lack of Involvement) 2612The client and project manager will conduct user interviews of valet companies and operators. The team will develop various workflow solutions and discuss these with the users. Valet operations at unofficial events/venues such as concerts/football games or large house parties may not be locatable by geolocation APIs (NDI Conflict) 199The team will apply risk avoidance pending client approval. Current valet business process regarding transaction management may be incompatible with proposed SnapValet transaction management solutions (SCS Lack of Involvement / Value Conflict) 8540The client and project manager will discuss current transaction management practices with two large, Los Angeles-based valet companies.

Risk Analysis – New 44 Risks Risk Exposure Risk Mitigations Potential Magnitude Probabilit y Loss Risk Exposure New requirements for an administrative web interface for valet companies may cause the project to fall out of scope and prevent developers from finishing the program on time and within budget 8864The team will only agree to develop the minimum sufficient conditions for the web interface such as registration and employee addition/deletion New client driven requirements regarding changes to the transaction process may cause the schedule to fall behind due to scope creep 9872The developers will meet with the client to discuss which win conditions she is willing to sacrifice for new requirements A low colocation rate (i.e. high number of DEN students) may hamper team cohesion, cooperation, and communication 71070The project manager will re- contact missing team members and establish guidelines for effective communication The team's late adoption of a web framework and PhoneGap may result in hastly development/implementation that leaves inadequate time/resources for testing and quality assurance 9763The team will develop and test in parallel. As components are added, they will immediately be tested by our IVV team

Risk Analysis – Removed 45 Risks Risk Exposure Risk Mitigations Potential Magnitu de Probabil ity Loss Risk Exposur e Developers schedules may prevent developers from completing Android training in a reasonable time (Inflated Expectations) 101 The team will take advantage of group development sessions such as team meetings and hack nights to complete the android tutorials Uncertainties surrounding profile management may cause the interface to be too complex/confusing (Human-System Integration Shortfalls) 2510Information gathered from user interviews will be used in conjunction with interface and profile architecture prototyping There is uncertainty surrounding the selection of a transaction management NDI/COTS which may lead to selection of an improper or mobile incompatible product (NDI Conflicts) 5210The team will evaluate various mobile transaction management NDIs and choose two that will be prototyped in parallel in a mobile development environment.

Traceability Matrix 46 OCDRequirementsUse CasesTest Cases OC-1 Mobile TransactionWC-3392, WC-3204UC-4, UC-6 TC-04-01, TC-05-01, TC-05-02, TC OC-2 Notifications WC-3390, WC-3386, WC-3384, WC-3205UC-4, UC-6 TC-02-03, TC-02-04, TC-02-05, TC 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 OC-4 Geolocation CheckinWC-3215, WC-3203UC-1, UC-5TC-02-01, TC OC-5 Profile ManagementWC-3387, WC-3208 UC-2, UC-5, UC-7 TC-01-01, TC-01-02, TC OC-6 AdvertisingWC-3210UC-5TC-03-01

Definition of Done 47 Automated unit/integration testing completed All test plans/cases written and passed (Acceptance tested) All code documented properly All functionalities and features documented in user manual All code checked into Github (VC repository) All code deployed onto demo server; deployable on Android and iOS devices

Metric Results I – Estimate vs. Actual Hours 48

Metric Results II – Defect Status 49

Technical Debt 50 IssuesPossible Solutions 1.Requirements volatility Interactive admin web interface Advertisement win condition Sit down with client (Mona) and have another Win Win negotation. Bi- monthly updates for client. 2. Lack of domain experience Problems with Play Framework and Scala and setting up environment Have not used other APIs before (Braintree/Google Places/Bootstrap) Go through tutorials; have other teammates help each other overcome the learning curve. 3. Infeasible schedulingPseduo-agile meetings. Need to include DEN students more often. 4. Hard codingTemporary due to initial development. Need to reduce/minimize the amount of hard-coding. 5. Automated testingBoy Scout – incremental testing and feedback.

Questions? 51