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
Weaknesses
• 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
• 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 1st 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 25th 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 8th 2015
•
TC-07 Load Testing (01)
•
Server Unit Testing – 70% coverage
Formal Quality & Acceptance Testing – April 15th 2015
9
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
Life Cycle Plan
Ridhima Manjrekar
27
Stakeholder roles
Role
Team Member
Client
Mona A
Project Manager, Developer
Brian Vanover
Feasibility Analyst, Developer
Patrick 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 Maintainer
SnapValet employee
28
Milestones
DCR
RDCR
TRR
CCD
OCR
29
Activities & Responsibilities
30
Activities & Responsibilities
31
Activities & Responsibilities
32
Iteration Plan
Iteration 0 – Preparation
1.
2.
3.
4.
5.
Train new team members for project details.
Meet with client to verify the requirements
Set up develop environment
Designing the database
Developers get familiar with Play frameworks and PhoneGap
33
Iteration Plan
Iteration 1 – Core Capability
1.
2.
3.
Login and profile management
Geo location check-in
Connecting the database to valet side and customer side operations
of the app
4.
5.
6.
7.
GUI design and implementation
Develop payment functionality
Prototyping PhoneGap
Finishing test plan
34
Iteration Plan
Iteration 2 – Full Capability
1.
2.
3.
4.
5.
Valet side Website
Improved user interface
Preparing user manual /demo video
Product installation and Transition
Rigorous Integration testing
35
Core Capabilities
ID
1
2
3
4
5
6
7
8
9
10
Trace
UC-1,5
TC-02-01, TC03-01
UC-6, OC-1
TC-05-01
Capability
Geo-Location check
in
Description
A customer and a valet should be able to
check-in at the establishment (location)
they are at.
Mobile transaction A customer should be able to pay for valet
service using his credit card on the
application.
UC-6, OC-4
Ticket number entry The customer must be able to enter his
TC-04-01
valet ticket number into the application.
UC-6, OC-2
Request Vehicle
A customer should be able to request for
TC-04-01
his vehicle via the app.
UC-4, OC-5
Retrieval
A customer should receive a notification
TC-02-04
Notification
on his device when his vehicle is being
retrieved.
UC-4, OC-3
Queue : Retrieve
The valet is able to visually validate the
TC-02-04
ticket number and then notify the
customer of car retrieval.
UC-4, OC-3
Queue : Report
The valet is able to notify a customer that
TC-02-04
“invalid” ticket
he/she entered a wrong ticket number
number
UC-4, OC-3
Queue : Close out
A valet is able to close out a served
TC-02-04
request
request and remove it from the queue
UC-2, TC-02-02, Start and close out a A valet should be able to start a shift for
TC-02-06
shift
other valets to add on to and be able to
close out a shift.
UC-2,7, TC-01- Profile management A customer and a valet are able to
01, TC-01-02,
register and create a profile on the app.
TC-01-03
Priority
High
Iteration
1
High
1
High
1
High
1
High
1
High
1
High
1
High
1
High
1
High
1
36
Feasibility Evidence
Description
Patrick Horng
37
Business Case Analysis
38
Personnel Cost
39
ROI Analysis
40
NDI/NCS Analysis
NDI/NCS
Google Places
Braintree
Usages
Interactively maps for
searching and displaying
places
Mobile transaction
platform
Comments
Positive points:
- Freeware
- Widely used
Positive points:
- Widely used and trustworthy for performance
MySQL
Database
Positive points:
- Freeware
- Suitable for Large/Small scale systems
- Widely used and trustworthy for performance
- Client’s requirement
Play Framework
Framework – app
development
Positive points:
- Freeware
- Platform independent
- Web app development conforms to client
requirement for iOS and Android development
Bootstrap
Styling responsive web
design
Positive points:
- Freeware
- Widely used
41
Risk Analysis
Risks
Inexperience with mobile
development may hinder
system development
(Personnel Shortfalls)
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)
Mobile transactions may
create an insecure
environment and foster the
breach of sensitive data
(Value Conflict)
Risk Exposure
Potential
Risk
Probabil
Magnitu
Exposur
ity Loss
de
e
10->3
1
10->3
4
4
16
6
2
12
Risk Mitigations
Use of Play Framework to
remove platform dependency.
Learning curve is now
dependent on Play Framework
which is not that difficult to
pick up.
The team will conduct multiple
rounds of win negotiations to
ensure that both clients and
developers are satisfied with
the agreed deliverables and
system requirements
The team will learn and apply
best practices for securing the
application.
42
Risk Analysis – Cont’d
Risk Exposure
Risks
Potential Probabilit
Risk
Risk Mitigations
Magnitude y Loss
Exposure
Unclear full understandings of
2
6
12
The client and project manager
the current process model for
will conduct user interviews of
valet parking may cause
valet companies and operators.
developers and acquirers to fall
The team will develop various
out of sync with user win
workflow solutions and discuss
conditions (SCS Lack of
these with the users.
Involvement)
Valet operations at unofficial
1
9
9
The team will apply risk
events/venues such as
avoidance pending client
concerts/football games or
approval.
large house parties may not be
locatable by geolocation APIs
(NDI Conflict)
Current valet business process
8
5
40
The client and project manager
regarding transaction
will discuss current transaction
management may be
management practices with two
incompatible with proposed
large, Los Angeles-based valet
SnapValet transaction
companies.
management solutions (SCS
Lack of Involvement / Value
Conflict)
43
Risk Analysis – New
Risks
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
New client driven requirements
regarding changes to the
transaction process may cause
the schedule to fall behind due
to scope creep
A low colocation rate (i.e. high
number of DEN students) may
hamper team cohesion,
cooperation, and
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
Risk Exposure
Potential Probabilit
Risk
Risk Mitigations
Magnitude
y Loss
Exposure
8
8
64
The team will only agree to develop
the minimum sufficient conditions
for the web interface such as
registration and employee
addition/deletion
9
8
72
The developers will meet with the
client to discuss which win
conditions she is willing to sacrifice
for new requirements
7
10
70
The project manager will recontact missing team members and
establish guidelines for effective
communication
9
7
63
The team will develop and test in
parallel. As components are added,
they will immediately be tested by
our IVV team
44
Risk Analysis – Removed
Risks
Developers schedules may
prevent developers from
completing Android training
in a reasonable time
(Inflated Expectations)
Uncertainties surrounding
profile management may
cause the interface to be too
complex/confusing
(Human-System Integration
Shortfalls)
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)
Risk Exposure
Potential
Risk
Probabil
Magnitu
Exposur
ity Loss
de
e
10
1
10
2
5
10
5
2
10
Risk Mitigations
The team will take advantage
of group development sessions
such as team meetings and
hack nights to complete the
android tutorials
Information gathered from
user interviews will be used in
conjunction with interface and
profile architecture
prototyping
The team will evaluate various
mobile transaction
management NDIs and
choose two that will be
prototyped in parallel in a
mobile development
environment.
45
Traceability Matrix
OCD
Requirements
Use Cases
Test Cases
UC-4, UC-6
TC-04-01, TC-05-01,
TC-05-02, TC-05-03
TC-02-03, TC-02-04,
TC-02-05, TC-04-01
OC-1 Mobile Transaction
WC-3392, WC-3204
OC-2 Notifications
WC-3390, WC-3386,
WC-3384, WC-3205
UC-4, UC-6
OC-3 Admin Interfacing
WC-3391, WC-3387,
WC-3385
UC-8, UC-9, TC-02-02, TC-06-01,
UC-11, UC-13, TC-06-02, TC-06-03,
UC-12
TC-06-04, TC-06-05
OC-4 Geolocation Checkin
WC-3215, WC-3203
UC-1, UC-5
TC-02-01, TC-03-01
OC-5 Profile Management
WC-3387, WC-3208
UC-2, UC-5,
UC-7
TC-01-01, TC-01-02,
TC-01-03
OC-6 Advertising
WC-3210
UC-5
TC-03-01
46
Definition of Done
•
•
•
•
•
•
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
47
Metric Results I – Estimate vs. Actual Hours
120
Number of Hours
100
80
60
Estimated
Actual
40
20
0
0
5
10
15
20
25
Week
48
Metric Results II – Defect Status
22
21
20
12
11
10
Week
9
8
Defects Reported
7
Defects Resolved
6
Total Open
5
4
3
2
1
0
0
2
4
6
8
10
Number of Defects
12
14
16
49
Technical Debt
Issues
Possible Solutions
1. Requirements volatility
• Interactive admin web interface
• Advertisement win condition
Sit down with client (Mona) and have
another Win Win negotation. Bimonthly 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 scheduling
Pseduo-agile meetings. Need to
include DEN students more often.
4. Hard coding
Temporary due to initial development.
Need to reduce/minimize the amount
of hard-coding.
5. Automated testing
Boy Scout – incremental testing and
feedback.
50
Questions?
51