Upload
evan-walton
View
216
Download
0
Embed Size (px)
Citation preview
SnapValet ARB RDCRGlobal Trojan Solutions – Team 03
1
SnapValet ARB Team Evaluation Molly Karcher
Strengths and Weaknesses: Operational ViewStrengths• 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 & CasesMolly 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 20159
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 Integrationo Android
14
Play Framework Client-Server Web Application PrototypeModels-Customer-Location-User-Valet-ValetCheckin-User-ValetCompany-ValetRequestViews-employeemanager-index-venuemanager-Checkincustomer-checkinvaletController-Application-CustomerController-ValetController
15
PhoneGap Integration• Android • iOS
• Pending developer license
16
SnapValet ARB SSADGlobal 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
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 ArchitectUML Modeler, Developer
Ditong Ding
Operational Concept Engineer Developer
Brian Bousman
System Maintainer SnapValet employee28
Milestones
DCRDCR RDCRRDCR
CCDCCD
TRRTRR
OCROCR
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 CapabilitiesID Trace Capability Description Priority Iteration1 UC-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.
High 1
2 UC-6, OC-1TC-05-01
Mobile transaction
A customer should be able to pay for valet service using his credit card on the application.
High 1
3 UC-6, OC-4TC-04-01
Ticket number entry
The customer must be able to enter his valet ticket number into the application.
High 1
4 UC-6, OC-2TC-04-01
Request Vehicle A customer should be able to request for his vehicle via the app.
High 1
5 UC-4, OC-5TC-02-04
Retrieval Notification
A customer should receive a notification on his device when his vehicle is being retrieved.
High 1
6 UC-4, OC-3TC-02-04
Queue : Retrieve The valet is able to visually validate the ticket number and then notify the customer of car retrieval.
High 1
7 UC-4, OC-3TC-02-04
Queue : Report “invalid” ticket number
The valet is able to notify a customer that he/she entered a wrong ticket number
High 1
8 UC-4, OC-3TC-02-04
Queue : Close out request
A valet is able to close out a served request and remove it from the queue
High 1
9 UC-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.
High 1
10 UC-2,7, TC-01-01, TC-01-02, TC-01-03
Profile management
A customer and a valet are able to register and create a profile on the app.
High 136
Patrick Horng
Feasibility Evidence Description
37
Business Case Analysis
38
Personnel Cost
39
ROI Analysis
40
NDI/NCS Analysis
41
NDI/NCS Usages CommentsGoogle Places Interactively maps for
searching and displaying places
Positive points: - Freeware - Widely used
Braintree Mobile transaction platform
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
Risk Analysis
42
Risks
Risk Exposure
Risk MitigationsPotentia
l Magnitu
de
Probability Loss
Risk Exposu
re
Inexperience with mobile development may hinder system development (Personnel Shortfalls)
10->3 1 10->3 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)
4 4 16 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
Mobile transactions may create an insecure environment and foster the breach of sensitive data (Value Conflict)
6 2 12 The team will learn and apply best practices for securing the application.
Risk Analysis – Cont’d
43
Risks
Risk Exposure
Risk MitigationsPotential Magnitud
e
Probability Loss
Risk Exposur
eUnclear 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)
2 6 12 The 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)
1 9 9 The 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)
8 5 40 The 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 MitigationsPotential Magnitud
e
Probability 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
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
New client driven requirements regarding changes to the transaction process may cause the schedule to fall behind due to scope creep
9 8 72 The 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
7 10 70 The 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
9 7 63 The 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 MitigationsPotentia
l Magnitu
de
Probability Loss
Risk Exposu
re
Developers schedules may prevent developers from completing Android training in a reasonable time (Inflated Expectations)
10 1 10 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)
2 5 10 Information 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)
5 2 10 The 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
OCD Requirements Use Cases Test Cases
OC-1 Mobile Transaction WC-3392, WC-3204 UC-4, UC-6
TC-04-01, TC-05-01, TC-05-02, TC-05-03
OC-2 NotificationsWC-3390, WC-3386, WC-3384, WC-3205 UC-4, UC-6
TC-02-03, TC-02-04, TC-02-05, TC-04-01
OC-3 Admin InterfacingWC-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 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
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
Issues Possible 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 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.
Questions?
51