Transcript greenbay.usc.edu

SnapValet ARB
Team 03
1
SnapValet ARB Team Evaluation
Molly Karcher
2
Strengths and Weaknesses: Operational View
Strengths
Weaknesses
• 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.
• 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
Weaknesses
• 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
• 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
Admin Interface
Open
WC_3383
WC_3385
WC_3387
WC_3391
Advertisements
WC_3210
Geolocation Checkin
WC_3203
Mobile Transactions
WC_3392
WC_3204
Notifications
WC_3384,
WC_3390
WC_3205
Profile Management
WC_3208
QR Code Reader
WC_3215
5
SnapValet ARB Operations
Concept Description
Abhinandan 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
2.
Shared Vision
Shared Vision
2.1 Overview of the sy stem
Assumptions
·
Users/Drivers prefer using mobile payment to a cash transaction.
·
People trust mobile payment systems.
·
Valet companies prefer mobile payments to cash transactions.
·
There isn’t already a similar competitive functionality in other existing applications.
·
SnapValet indeed speeds up facilitation of valet service.
·
A noteworthy amount of customers often do not carry cash for valet.
·
Our users would rather prefer using an android phone to other platforms.
Stakeholders
· Developers
· SnapValet
Cost
·
·
·
·
·
Initiatives
· Develop System
· Market Campaign
-End user: social
media
· Direct Sales
· Networking
Conference/Trade
Shows
Time
Marketing Costs
Maintenance Costs
Team Building
Infrastructure
-Web Servers
- Third party transaction
management
Value
Beneficiaries
Propositions
· To speed up
· Drivers / users
valet process
· SnapValet
· Improve cashless
clients
valet experience
-Valet
for customers
Companies
-Restaurants
· Expand potential
-Hotels
customer base
· Sponsors /
for valet.
Investors
· Better valet
account/transacti
on management.
· Enable Direct
Advertising
· Increase revenue
and profits
Benefit (Metrics)
·
A faster, more convenient way to
valet park.
·
Increase market share to include
non-cash carrying customers.
·
3% revenue/ transaction
·
Prestige for developing a
successful, popular mobile app
·
A reputable grade in CSCI 577a
·
Experience developing mobile
apps
·
Experience working in a diverse
team
Table 1: The Program Model of SnapValet
9
Operational Concept Description (OCD)
Version 1.1
Element Relationship Diagram
Proposed
System – Entity Relationship Diagram
3.3.1
EXTERNAL
WEBSITE
Valet
Company
adds
Employee
Information
USER
Once
authenticated,
allows check-in
Request
for car
CAR REQUEST
SYSTEM
Login
Login
Valet
runner
fetches Car
CAR
Allow
payment
MySQL
DATABASE
VALET
HEAD
GEOLOCATION
MODULE
PAYMENT
GATEWAY
Notifies
Valet Head
via queue
system
NOTIFICATION
SYSTEM
QUEUE
SYSTEM
VALET COMPANY
ACCOUNTS
Valet Staff
taken to
directly to
Queue
System
10
Operational Concept Description (OCD)
3.3.2
Version 1.1
Business Workflows
Proposed System – Business Workflow Diagram
Following is the business workflow of SnapValet. The boxes in green denote the notable
changes in the workflow from the present system.
11
Business Workflow of SnapValet
Benefits Chain Diagram
Operational Concept Description (OCD)
Version 1.1
12
bothered by valet parking. The app also provides a seamless way to keep track of payments and
facilitates faster valet process for valet companies and valet runners as well. We believe that this is a
compelling reason for both, the general public and valet companies to use the app. We plan to provide
this service in Los Angeles, and as far as our market research goes, this app is one of a kind.
System Boundaries
2.3 System Boundary Environment
-
SnapValet
Team
Customers
Registration System
Notification System
Queuing System
Payment System
Geo-location System
Car Request System
Support Infrastructure
- Java
- MySQL
- Apache
- Google Maps API
- Payment API
Valet
Companies
Investors
Google
Maps
API
Payment
API
Internet
Valet
Staff
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 Prototype
Brian 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 API
http://greenbay.usc.edu/csci577/fall2014/projects/te
am03/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 Requirements
Ridhima 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 SSAD
Ditong Ding
31
Outline
•
•
•
System Context
Artifacts & Information
Behavior
32
System Context
Request car
/Pay with app
Customer
Manage Employee
/Return tip
Get request/
Charge fee
Valet Company
Valet Operator
33
Artifacts & Information
1
Establishment Location
1
*
Car Retrieval Log
*
*
1
Customer Profile
1
*
*
Payment Log
*
1
Valet Operator Profile
1
*
1
Valet Company Profile
34
Behavior
Valet Service
Log in
Valet Process
<<Include>>
Customer
Check In
Account Management
<<Include>>
User
Valet Operator
Return Tip
<<Include>>
Register
Account
Management
Employee
Management
Hire Valet Operator
<<Include>>
Manage Employee
Valet Company
<<Include>>
Fire Valet Operator
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 roles
Role
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 employee
38
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 Factors
& Cost Drivers
Profile Management & Login
Scale Driver
PREC
FLEX
RESL
TEAM
PMAT
Cost Driver
Value
Cost Driver
Value
RELY
Nominal
(1.00)
High
(1.14)
Nominal
(1.00)
Nominal
(1.00)
Very High
(1.15)
Nominal
(1.00)
Nominal
(1.00)
Low (0.87)
ACAP
High (0.85)
PCAP
PCON
High(0.88)
Nominal
(1.00)
Low (1.10)
Low (1.09)
Very Low
(1.19)
Very High
(0.78)
Extra High
(0.80)
Nominal(1.
00)
Value
High
(2.48)
High
(2.03)
Low
(5.65)
High
(2.19)
Low
(6.24)
DATA
DOCU
CPLX
RUSE
TIME
STOR
PVOL
APEX
LTEX
PLEX
TOOL
SITE
SCED
45
COINCOMOII Estimate
46
Feasibility Evidence
Description
Xiaoting Bi
47
Business Case Analysis
48
Business Case Analysis
Cost & Benefits
49
Personnel Costs
50
Personnel Costs (cont.)
Hardware and Software Costs
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 Demographic
User Scenario:
Age: 23
Hometown: Los Angeles
Marital Status: Single
Job: Student of USC
She wanted to go to a restaurant but she’s
Attributes
She does not take change with her.
not used to taking change with her. So she
downloaded SnapValet and was able to pay
by her credit card.
Information Source:
Advertisement
Goals:
No need to pay cash.
59
2.Persona: Tom
Basic Demographic
User Scenario:
Age: 27
Hometown: Los Angeles
Marital Status: Single
Job: Sales manager
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.
Attributes
Information Source:
Impatient in waiting for a valet
operator to pick his car back.
Advertisement
Goals:
He does not want to wait
too long to pick his car back.
60
3.Persona : Angela
Basic Demographic
User Scenario:
Age: 42
Hometown: Los Angeles
Marital Status: Single
Job: Accountant
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.
Attributes
Impatient in waiting for a valet
operator to park her car and does
not want to add her bank account
in the app.
Information Source:
Friends
Goals:
She doesn’t need to wait too long
for giving her car to a valet
operator and pays by cash.
61
4. Persona: Jerry
Basic Demographic
User Scenario:
Age: 31
Hometown: Los Angeles
Marital Status: Single
Job: Valet operator of SM
valet company
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.
Attributes
Hardworking
Goals:
Higher salary and tips.
62
5. Persona : Bob
Basic Demographic
User Scenario:
Age: 40
Hometown: Los Angeles
Marital Status: Married
Job: Manager of SM Valet
Company
He is a manager of SM valet company. As it’s
inconvenient for users to pay cash, SM company
decided 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.
Attributes
Goals:
Decisive, trying to improve profit
for company.
Make more profits.
63
Quality Focal Point
Molly Karcher
64
Traceability Matrix
OCD
OC-1
Mobile Payment Gateway
OC-2
Car pick-up request
Requirements
OC-3
Queue Look-up
OC-4
Ticket Number Details
OC-5
Notifications
OC-6
Admin Interfacing
OC-7
Transaction Summary
OC-8
Advertisements & Suggestions
Test Case
WC_3204
Use Case
UC-2
UC-4
WC_3392 WC_3215
UC-2
TBD
WC_3392 WC_3386
WC_3384
WC_3391
WC_3387
WC-3386
WC_3385
UC-1
UC-2
UC-2
UC-4
UC-1
UC-2
UC-1
UC-4
UC-5
UC-6
UC-7
WC_3391
UC-7
TBD
WC_3210
UC-2
TDB
WC_3215
WC_3390 WC_3205
TBD
TBD
TBD
TBD
TBD
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 featuredevelopment schedule, and assignment to correct team members
•
IIV&V member responsibility, to be completed weekly or by team sprintplanning meeting
•
Quality control through version control (Git)
•
•
Informal code reviews through merge/pull requests
Testing
o
Continuous integration + automated testing
o
Test-driven/test-first development strategy
67