SnapValet ARBTeam 03

1

SnapValet ARB Team Evaluation

Molly Karcher

2

Strengths and Weaknesses: Operational ViewStrengths

• All members are friendly, collaborative, and punctual in regards to deadlines

• Quick and decisive in task delegation; good sense of communal responsibility

• Use of online collaboration tools (Google groups, Bugzilla, Winbook, Facebook messages, etc.

Weaknesses

• Deliverables generated very close to deadlines, leaves minimal time for verification

• Lack of availability of remote team member during normal workday hours

3

Strengths and Weaknesses: Technical View

Strengths

• All computer science Masters students; ability to quickly and effectively learn new technologies

• Collectively, strong familiarity with MySQL and relational databases

• Collectively, strong familiarity with Java, so learning Android shouldn’t be that painful

Weaknesses

• Lack of mobile development experience (on both iOS and Android platforms)

• Lack of familiarity with transaction management tools/APIs

• There remain a lot of uncertainties in technical requirements

4

WinWin Conditions

  Agree Potentially Open

Admin Interface    

WC_3383 WC_3385 WC_3387 WC_3391

Advertisements     WC_3210

Geolocation Checkin WC_3203    

Mobile Transactions WC_3392 WC_3204  

NotificationsWC_3384, WC_3390 WC_3205  

Profile Management WC_3208    

QR Code Reader     WC_3215

5

SnapValet ARB Operations Concept DescriptionAbhinandan Patni

6

Outline

• System Purpose

• Shared Vision

• Proposed System

• Benefits Chain Diagram

• System Boundary

• Desired Capabilities and Goals

7

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.

8

Shared Vision

9

Proposed System – Entity Relationship Diagram

10

Proposed System – Business Workflow Diagram

11

Benefits Chain Diagram

12

System Boundaries

13

Desired Capabilities

• Mobile Payment Gateway (OC1)

• Car Pick-Up Request (OC2)

• Queue Look-Up (OC3)

• Ticket Number Details (OC4)

• Notifications (OC5)

• Admin Interface (OC6)

• Advertisements and Suggestions (OC7)

• Transaction Summary (OC8)

14

LEVELS OF SERVICE• Response Time – Simple (Must Have)

• Availability (Should Have)

• Security (Must Have)

• Maintainability (Must Have)

15

Organizational and Operational Transformations

• Need for central tablet per valet parking area.

• Valet head for each position.

• Employee IDs a must.

• Update the list of restaurants serviced.

Customers have to enter ticket numbers

Valet heads are notified of requests on the tablet.

Customers are notified on their smartphones by valet staff.

Payment can be done via mobile transaction.

16

SnapValet ARB PrototypeBrian Vanover

17

Outline

• SnapValet Intro

• Basalmiq Mockups

• Google Places API

18

Registration

Valet employees will have a login autogenerated when employers add them via a web application

Employees will use this login to register by providing the login along with the additional requested information.

19

Geolocation Check-in

Both customers and valet employees will check in to locations using geolocation

Locations will be suggested using the Google Places API

Locations will be filtered based on a radial proximity and place type

20

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

21

Payment

Customers will have the option of paying cash or mobile.

Payment will be verified before release of the vehicle

22

Valet Interface

Request Queue Shift Management

23

Google Places APIhttp://greenbay.usc.edu/csci577/fall2014/projects/team03/Valuation/PRO/geolocation_prototype.html•Lat/Long plugged in for demonstrative purposes•Venues limited to restaurants, nightclubs, shopping malls, movie theaters, lodging•Radial/nearby parameters varied

24

SnapValet RequirementsRidhima Manjrekar

25

Outline

• Customers

• Valet Company

• Valet Operators

• System

26

Customers

• [WC_3208]Create and manage my SnapValet profile

• [WC_3205]Request for my car via the app

• [WC_3203]check into/select a location through my mobile

phone so that the I can pay for my valet

• [WC_3392]either request or request and pay for valet so

that I have the option to not enter in my credit card

information if I don’t want to

• [WC_3215]enter my ticket number from the valet ticket so

that I can request my car now/later.

27

Valet Company

• [WC_3204]offer an easier payment option- credit card

• [WC_3391]Use the system to maintain more reliable

transactional data

28

Valet Operators

• [WC_3384]receive real-time requests from customers in an

organized queue

• [WC_3387]have my own login and check-in location

• [WC_3386]see if a customer has paid or not in the queue

so that I know whether to collect cash.

• [WC_3390]send notifications to the customer that their car

is ready

29

System

• [WC_3213]The application shall be secure - channel is

encrypted. (SSL) .

• [WC_3216]The budget for the project shall not exceed

$10,000

30

SnapValet ARB SSADDitong Ding

31

Outline

• System Context

• Artifacts & Information

• Behavior

32

System Context

Customer

Valet Operator

Valet Company

Request car/Pay with app

Manage Employee/Return tip

Get request/Charge fee

33

Customer Profile

Establishment Location

Valet Operator Profile

Valet Company Profile

Payment LogCar Retrieval Log * 1

*

1

*

1

1 *

1

*

1 1

* *

Artifacts & Information

34

Customer

Valet Company

Valet Operator

Valet Process

Account Management

<<Include>>

Register

Log in

<<Include>>

Check In

Manage Employee

Hire Valet Operator

Fire Valet Operator

<<Include>>

<<Include>> Return Tip

<<Include>>

User

BehaviorValet Service

Employee Management

Account Management

35

Life Cycle Plan

-Saikarthik Desiraju

36

Life Cycle Strategy

• ICSM and Architected Agile

>One incremental commitment cycle

>Weekly team meetings, Client meetings, Defect

Tracking

>Next Milestone: Development Commitment Review

• Foundations phase strategy:

>Assess scope of the project

>Develop necessary skills/tech

>Elaborate software architecture

>Identify COTs

>Prototype modules

37

Stakeholder rolesRole Team Member

Client Mona A

Project Manager Brian Vanover

Feasibility Analyst Xiaoting Bi

Operational Concept Engineer

Abhinandan Patni

IIV & V , Quality focal point

Molly Karcher

Requirements Engineer Ridhima Manjrekar

Software Architect Ditong Ding

Life Cycle Planner Saikarthik Desiraju

Operational Concept Engineer, Developer

New Team Member (CS577b)

System Maintainer SnapValet employee38

Stakeholder responsibilities &Project Plan

39

Stakeholder responsibilities &Project Plan

40

Stakeholder responsibilities &Project Plan

41

Stakeholder responsibilities &Project Plan

42

Stakeholder responsibilities &Project Plan

43

Resource Estimation

• 7 member team • 2 semester project• Total hours required ~1100hrs. • Each member works for 16hrs/week for 10

weeks of development• Number of modules :5• Programming Language : Java• Total budget ~$10,000

44

Scale Driver Value

PREC High (2.48)

FLEX High(2.03)

RESL Low(5.65)

TEAM High(2.19)

PMAT Low(6.24)

Scale Factors & Cost Drivers

Cost Driver ValueRELY Nominal

(1.00)DATA High

(1.14)DOCU Nominal

(1.00)CPLX Nominal

(1.00)RUSE Very High

(1.15)TIME Nominal

(1.00)STOR Nominal

(1.00)PVOL Low

(0.87)

Cost Driver Value

ACAP High (0.85)

PCAP High(0.88)PCON Nominal

(1.00)APEX Low (1.10)LTEX Low (1.09)PLEX Very Low

(1.19)TOOL Very High

(0.78)SITE Extra High

(0.80)SCED Nominal(1.

00)

Profile Management & Login

45

COINCOMOII Estimate

46

Feasibility Evidence Description

Xiaoting Bi

47

Business Case Analysis

48

Business Case Analysis

Cost & Benefits

49

Personnel Costs

50

Hardware and Software Costs

Personnel Costs (cont.)

51

Benefit Analysis

For client:

For users:

52

ROI Analysis

53

Risks

54

Risks (cont.)

55

Risks (cont.)

56

Process Feasibility

57

Process Feasibility (cont.)

58

1.Persona : Gem

Basic DemographicAge: 23Hometown: Los AngelesMarital Status: SingleJob: Student of USC

AttributesShe does not take change with her.

User Scenario:She wanted to go to a restaurant but she’s

not used to taking change with her. So she

downloaded SnapValet and was able to pay

by her credit card.

Goals:No need to pay cash.

Information Source:Advertisement

59

2.Persona: Tom

Basic DemographicAge: 27Hometown: Los AngelesMarital Status: SingleJob: Sales manager

AttributesImpatient in waiting for a valetoperator to pick his car back.

User Scenario:He usually goes out for a dinner but he’s impatient in waiting a valet operator parking his car and picking his car back. Yesterday he went to a restaurant and it’s so busy. So he used SnapValet to request his car back before he went out waiting outside.

Goals:He does not want to wait too long to pick his car back.

Information Source:Advertisement

60

3.Persona : Angela

Basic DemographicAge: 42Hometown: Los AngelesMarital Status: SingleJob: Accountant

AttributesImpatient in waiting for a valetoperator to park her car and doesnot want to add her bank accountin the app.

User Scenario:She had to go to a restaurant to celebrate her friend’s birthday. But she still had a lot of work to do at night. So she use SnapValet to request her car back without waiting outside for a long time. As she didn’t want to add her bank account in the app, she paid by cash.

Goals:She doesn’t need to wait too long for giving her car to a valet operator and pays by cash.

Information Source:Friends

61

4. Persona: Jerry

Basic DemographicAge: 31Hometown: Los AngelesMarital Status: SingleJob: Valet operator of SM valet company

AttributesHardworking

User Scenario:He is a valet operator of SM valet company. After parking a car for a user, he went to central device and found that a driver requesting his car, so he picked the car back and sent a notification to the user that the car was available.

Goals:Higher salary and tips.

62

5. Persona : Bob

Basic DemographicAge: 40Hometown: Los AngelesMarital Status: MarriedJob: Manager of SM Valet Company

AttributesDecisive, trying to improve profitfor company.

User Scenario:He is a manager of SM valet company. As it’s inconvenient for users to pay cash, SM companydecided to use SnapValet. Valet Operators are

arranged to certain locations and valet service

fee can be charged via credit card or cash. They

provide two choices for users.

Goals:Make more profits.

63

Quality Focal PointMolly Karcher

64

Traceability Matrix

OCD Requirements Use Case Test CaseOC-1 Mobile Payment Gateway WC_3204

UC-2UC-4 TBD

OC-2 Car pick-up request WC_3392 WC_3215 UC-2 TBD

OC-3 Queue Look-up

WC_3392 WC_3386 WC_3384

UC-1 UC-2 TBD

OC-4 Ticket Number Details WC_3215

UC-2UC-4 TBD

OC-5 Notifications WC_3390 WC_3205

UC-1UC-2 TBD

OC-6 Admin Interfacing

WC_3391 WC_3387WC-3386WC_3385

UC-1UC-4UC-5UC-6UC-7 TBD

OC-7 Transaction Summary WC_3391 UC-7 TBDOC-8Advertisements & Suggestions WC_3210 UC-2 TDB

65

Current Defects

• All current confirmed defects will not need to be addressed

until development stage

• Relevant non-component activities and deliverable defects

are all resolved/verified.

• Stats: Total (40), Confirmed (6), Verified (34)

66

Defect Prevention & Identification Strategies

• Continuous reprioritization of defect list, integration into

feature-development schedule, and assignment to correct

team members

• IIV&V member responsibility, to be completed weekly or by

team sprint-planning meeting

• Quality control through version control (Git)

• Informal code reviews through merge/pull requests

• Testingo Continuous integration + automated testing

o Test-driven/test-first development strategy

67