Important Announcement
PubHTML5 Scheduled Server Maintenance on (GMT) Sunday, June 26th, 2:00 am - 8:00 am.
PubHTML5 site will be inoperative during the times indicated!

Home Explore Pro Group Proposal for Mobile App.v2

Pro Group Proposal for Mobile App.v2

Published by littlej1990, 2017-07-15 22:51:28

Description: Pro Group Proposal for Mobile App.v2

Search

Read the Text Version

Mobile App Development Proposal June 13th, 2017 Prepared for: Kit Loong Commercial Tyre Group Prepared by: Pro Group

Mobile App Development June 13th, 2017IntroductionPro Group are pleased to submit a proposal for the development of a mobile application to Kit LoongCommercial Tyre Group.Our team are expert in developing and providing cost-effective IT solutions including web and mobileapplications. Additionally, with the knowledge and experience we accumulated for years in the tyreindustry, we are confident in giving Kit Loong something unique that will help grow your business.The following proposal will set a project road map from start to finish.Project OverviewKit Loong has an existing call centre system that keeps records of all the requests for tyre breakdownassistance. Currently, the requests are made by truck drivers via typical phone calls to the call centre/ person-in-charge, which has brought along issues such as:  Drivers might not report their location correctly  Phone calls might not be always picked upObjectives  Create a native Android mobile application which, once downloaded onto driver’s phone, will allow them to request for breakdown assistance  Facilitate simple and clear user interface with minimal user input  Support for English and Malay languages  Increase accuracy of driver’s location  Attain KPI for rescue requests 2

Mobile App Development June 13th, 2017Technical Terms and AbbreviationsFirebase A mobile and web application development platform built on Google infrastructure that provides services such as Realtime Database, Hosting andFirebase Cloud Crash Reporting.Messaging (FCM) One of the Firebase services, which is a cross-platform solution for deliveringGPS Location messages and notifications at no cost. Formerly known as Google CloudPush Notification Messaging (GCM).Web Service GPS coordinates, which are formed by two components, latitude andRESTful Web longitude to pinpoint an exact location.Service A message that pops up on a mobile device. Users do not have to be in the app or using their devices to receive the push notifications. A component resides on a Web server that provides information and services to other network applications using standard Web protocols. A type of lightweight Web service that makes use HTTP protocols.Driver ModuleUse Case Diagram Figure 1 – Driver Use Case DiagramFigure 1 illustrates all the actions that a driver can perform with the mobile application. Therequirements and details for each use case are explained in the following sections. 3

Mobile App Development June 13th, 2017Account Activation Figure 2 – Driver Account Activation Process FlowOn the first launch (first time use) of the mobile application, the application will display the currentphone number of the device. Driver is required to confirm the phone number before proceeding tothe activation process.Activation of the phone number will trigger the Web Service (Kit Loong Backend System) toauthenticate/activate the phone number. Once it is authenticated/activated, mobile application statewill be updated and driver will be able to access the full features of the application. 4

Mobile App Development June 13th, 2017Submission of Rescue Request Figure 3 – Rescue Request Submission Process FlowIn order to submit a rescue request, driver is required to key in the vehicle number and select axlefrom a default 5-axle layout. Driver is able to select multiple axles if tyres broke down are belong todifferent axles. To cater for submitting request for both prime mover and trailer simultaneously,driver can provide a second set of vehicle number and axle input optionally.If the driver is authorised user, the submission of the rescue request will trigger the Web Service (KitLoong Backend System) to store. The rescue request data sent by the mobile application to the WebService consist of driver’s phone number, vehicle number(s), axle(s), GPS location and currenttimestamp. 5

Mobile App Development June 13th, 2017Please note that the axle data is the position of axle where tyre is belong to, it is not the position ofthe tyre in the configuration. For prime mover, there are axle 1 – 4; for trailer, axle 1 – 5 will be givenas options to be selected by driver.If the driver is non-authorised user, the submission of the rescue request will trigger the Web Service(Kit Loong Backend System) to store as a pending request. A push notification will then be sent byKit Loong Backend System to the driver’s supervisor to seek for his / her approval on the rescuerequest.At any one time, a driver can only have one ongoing rescue request. In order to submit a secondrequest, the first request must be case closed, which can be determined by:  Kit Loong Backend System has updated the status of the rescue request to Completed  Authorised user (driver / supervisor) has cancelled the rescue request 6

Mobile App Development June 13th, 2017Ongoing Rescue Updates Figure 4 – Process Flow of Driver’s Ongoing Rescue Updates DisplayIf there is currently an ongoing rescue request, driver will always see the screen containing full detailsand all updates of the ongoing rescue request after launching the mobile application.The rescue request details such as driver’s name, vehicle number, axle, request submission time,address and GPS location.The updates will be displayed in reverse chronological order. Updates of a rescue request consist ofapproval status from the supervisor, rescue request case status updates and so on. Figure 5 – Example of Rescue Request Status FlowFigure 5 demonstrates a rescue request status flow from beginning to end. Driver is expected to get apush notification for each status update. All push notifications are to be initiated by Kit LoongBackend System. 7

Mobile App Development June 13th, 2017Managing a Rescue Request Figure 6 – Driver Managing a Rescue RequestUnder the same rescue update screen, there are few actions that driver can perform with the ongoingrescue request:Cancel RequestAuthorised driver can cancel rescue request that has been submitted. The cancellation of the requestwill trigger the Web Service (Kit Loong Backend System). 8

Mobile App Development June 13th, 2017Withdraw Pending RequestNon-authorised driver cannot cancel but only withdraw rescue request that has been submitted andnot yet approved by the supervisor. The request withdrawal will trigger the Web Service (Kit LoongBackend System). A push notification will then be sent by Kit Loong Backend System to the supervisor.Based on the withdrawal request, supervisor can choose whether to proceed with cancelling therescue request.Update Current LocationConsidering that driver’s location may change after submitting the rescue request, option is given forthe driver to update the current location if necessary. The location update will trigger the Web Service(Kit Loong Backend System) to store. 9

Mobile App Development June 13th, 2017Rating of Rescue Service Figure 7 – Process Flow of Rescue Service RatingUpon completion of rescue process, driver will receive a final push notification from Kit Loong BackendSystem. After launching the mobile application, driver will be prompted to give rating on the overallrescue service experience.The rating range from 1 to 5 score. In the event of 1 score is rated by the driver, driver will be promptedto select a reason for giving low rating from a predefined list of reasons.The submission of the rating will trigger the Web Service (Kit Loong Backend System) to store. 10

Mobile App Development June 13th, 2017Supervisor ModuleUse Case Diagram Figure 8 – Supervisor Use Case DiagramFigure 8 illustrates all the actions that a supervisor can perform with the mobile application. Therequirements and details for each use case are explained in the following sections. 11

Mobile App Development June 13th, 2017Account Activation Figure 9 – Supervisor Account Activation Process FlowOn the first launch (first time use) of the mobile application, the application will display the currentphone number of the device. Supervisor is required to confirm the phone number before proceedingto the activation process.Activation of the phone number will trigger the Web Service (Kit Loong Backend System) toauthenticate/activate the phone number. Once it is authenticated/activated, mobile application statewill be updated and supervisor will be able to access the full features of the application. 12

Mobile App Development June 13th, 2017Pending and Ongoing Rescue Requests Figure 10 – Process Flow of Supervisor’s Pending and Ongoing Rescue Requests DisplayIf supervisor’s account has been activated, supervisor will see a list of pending and ongoing rescuerequests after launching the mobile application. For each rescue request, brief information will bedisplayed such as driver’s name, vehicle number and request submission time.For pending requests, supervisor can approval or reject directly under this screen.For ongoing requests, supervisor can tap to see the detailed information and all updates in anotherscreen that is similar to what driver sees for the single ongoing rescue request. 13

Mobile App Development June 13th, 2017Approval of Rescue Request Figure 11 – Rescue Request Approval Process FlowFrom the pending / ongoing rescue request screen, supervisor is able to approve or reject a pendingrescue request. The approval / rejection of the request will trigger the Web Service (Kit Loong BackendSystem). Regardless of approval or rejection, a push notification should be sent by Kit Loong BackendSystem to inform the driver. 14

Mobile App Development June 13th, 2017Cancellation of Rescue Request Figure 12 – Rescue Request Cancellation Process FlowFrom the pending / ongoing rescue requests screen, supervisor can tap in the see full details and allupdates about an ongoing rescue request.The rescue request details such as driver’s name, vehicle number, axle, request submission time,address and GPS location.Supervisor can choose to cancel the ongoing rescue request. The cancellation of the request willtrigger the Web Service (Kit Loong Backend System). A push notification will then be sent by Kit LoongBackend System to the driver to inform. 15

Mobile App Development June 13th, 2017System Development PrerequisitesFirebase Cloud MessagingA Firebase account must be provided by Kit Loong.All push notifications are made by Kit Loong Backend System only to the users’ mobile device andprocessed by the mobile application.To ensure that push notification is recognized and can be processed by the mobile application, KitLoong Backend System must send push notifications via Firebase Cloud Messaging (FCM) with dataformat agreed by Pro Group. Data format to be discussed.Types of Push NotificationsBelow are suggested types of push notifications to be made by Kit Loong Backend System.Pending rescue Description After non-authorised driver has submitted a rescue request, arequest Data Payload push notification is sent to supervisor to seek for approval Driver’s name, driver’s mobile number, vehicle number(s), axle(s), GPS location, full address, submission time, rescue request IDRequest status Description A push notification sent to driver and/or supervisor wheneverupdates Data Payload status of request is updated. Example of status updates: request has been approved / rejected, Mobile Service Provider on the way, request has been cancelled etc. Rescue request ID, new status, last updated timestampWithdraw Description After non-authorised driver has withdrawn a pending request,request Data Payload a push notification is sent to supervisor. Rescue request ID, request withdrawal timestampRescue rating Description After rescue process is done, a push notification is sent to Data Payload driver to ask for rating Rescue request ID, rescue completion timestamp 16

Mobile App Development June 13th, 2017Web Services RequirementsBelow are list of RESTful Web Services required by Pro Group:Authenticate Description To authenticate a user accountHTTP POST Parameter Mobile number Response Data User type: Whether this user is a Driver / Supervisor Authorized: Boolean, only applicable for driverStore authorised Description To store a rescue request from authorised driverrequest Parameter Driver’s mobile number, vehicle number(s), axle(s), GPS locationHTTP POST Response Data Boolean status and rescue request IDStore non- Description To store a rescue request from non-authorised driverauthorised request Parameter Driver’s mobile number, vehicle number(s), axle(s), GPS locationHTTP POST Response Data Boolean status and rescue request IDApprove / reject Description To approve or reject a pending rescue request made byrequest non-authorised driver Parameter Rescue request ID, supervisor’s mobile numberHTTP POST Response Data BooleanCancel authorised Description To cancel an authorised rescue requestrequest Parameter Rescue request ID, driver’s or supervisor’s mobile numberHTTP POST Response Data BooleanWithdraw non- Description To withdraw a pending rescue requestauthorised request Parameter Rescue request ID, driver’s mobile number Response Data BooleanHTTP POSTCancel non- Description To cancel a pending rescue requestauthorised request Parameter Rescue request ID, supervisor’s mobile number Response Data BooleanHTTP POSTUpdate request Description To update current location of a rescue requestGPS location Parameter Rescue request ID, GPS locationHTTP POST Response Data BooleanGet rating reasons Description To get list of rating reasonsHTTP POST Parameter - Response Data Reason ID, reason descriptionSubmit rescue Description To store a driver’s rating for rescue servicerating Parameter Rescue request ID, driver’s mobile number, rating input, rating reason (optional)HTTP POST Response Data Boolean 17

Mobile App Development June 13th, 2017TimelinePro Group estimates to take approximately 52 working days to complete the project, depending onwhen feedback is received at each milestone. Upon signing the proposal, Pro Group are prepared tostart work immediately. Phase Man DaysRequirement Gathering 2Requirement Sign-off 1UI Design 2Development 25Web Service Integration 4UAT, Rectification, UAT Sign-off 5Deployment, Deployment Guide, Source Code 3 42 TotalPricingBelow is the estimated budget based on the scope of services outlined earlier in this proposal.Description PriceRequirement Gathering and Sign-offUI Design RM 2,100.00Development RM 1,400.00Web Service Integration RM 17,500.00UAT, Rectification and UAT Sign-off RM 2,800.00Deployment, Deployment Guide, Source Code RM 3,500.00 RM 2,100.00 Sub Total RM 29,400.00 6% GST RM 1,764.00 TOTAL RM 31,164.00 18

Mobile App Development June 13th, 2017Terms & Conditions1. Hosting of the application is not included.2. Pro Sales & Marketing Consultancy Sdn Bhd is expected to complete the entire project within 42 man days upon approval of this proposal and official PO received.3. Project completion timeline subject to changes based on the below conditions:  Requirement changes  Web Services availability and stability from Entire Tyre Management Technology Sdn Bhd  Requirements sign-off date  The efficiency of receiving feedback at each milestone4. Changes divert from initial Requirement Sign-Off document are considered as CR (Change Request) or VO (Variation Order).5. CR and VO are subjected to new agreements from both parties Pro Sales & Marketing Consultancy Sdn Bhd and Entire Tyre Management Technology Sdn Bhd.6. Bug fixes and error corrections will be provided by Pro Sales & Marketing Consultancy Sdn Bhd as Free of Charge during the first 3 months from the UAT Sign-Off date.7. Pro Sales & Marketing Consultancy Sdn Bhd shall not be responsible for any application bugs or errors occur due to modifications made by Entire Tyre Management Technology Sdn Bhd to the application source code.8. No refund shall be issued in the result of project termination requested by Entire Tyre Management Technology Sdn Bhd.9. In the event of project termination, Entire Tyre Management Technology Sdn Bhd shall pay Pro Sales & Marketing Consultancy Sdn Bhd for the Services performed through the date of termination in the amount of a prorated portion of the fees due.10. By signing this proposal, Entire Tyre Management Technology Sdn Bhd agrees that any communal information is confidential and will not be shared with any third parties without permission from Pro Sales & Marketing Consultancy Sdn Bhd.Pro Sales & Marketing Consultancy Entire Tyre ManagementSdn Bhd Technology Sdn BhdApproved By: Approved By:Name: Andrew Sia Name:Designation: CEO Designation:Date: 13/6/2017 Date: 19


Like this book? You can publish your book online for free in a few minutes!
Create your own flipbook