2|P ag e

Table of Contents

1. Confidential Information ................................................................................................................... 3

2. Our Understanding ............................................................................................................................ 4
2.1. Requirements understanding .................................................................................................... 4
2.2. Queries/ Assumptions .............................................................................................................. 5
5. Proposed Solution ............................................................................................................................. 6
a. Proposed Technology & Framework ............................................................................................ 6
b. Proposed Application Architecture............................................................................................... 6
c. Realization of the architecture (MVC).......................................................................................... 7
d. Realization of the architecture (MVVM) .................................................................................... 10
e. Application Architecture ............................................................................................................ 12
f. Application Architecture – iOS .................................................................................................. 13
g. Application Architecture and Process – Android ........................................................................ 18
h. Software Requirements .............................................................................................................. 20
7. Budget ............................................................................................................................................ 23
a. Effort Estimation ....................................................................................................................... 23
b. Budget ....................................................................................................................................... 28
c. Terms & Conditions .................................................................................................................. 28
8. Project Management & Methodology .............................................................................................. 29
a. Company Profile........................................................................................................................ 29
b. smartData’s Methodology .......................................................................................................... 29
c. Assumptions .............................................................................................................................. 31
d. Change Management ................................................................................................................. 32

Project Name Copyrights Reserved 1996-2019

3|P ag e

1. Confidential Information
This Response to RFP is confidential to smartData Enterprises and the client. This document contains
information and data that smartData considers confidential and proprietary (“Confidential
Information”).

Confidential Information includes, but is not limited to, the following:

Corporate and Infrastructure information about smartData
smartData’ project management and quality processes
Project experiences provided to illustrate smartData capability

Any disclosure of Confidential Information to, or use of it by a third party (i.e., a party other than
client), will be damaging to smartData. Ownership of all Confidential Information, no matter in
what media it resides on, remains with smartData.
Confidential Information in this document shall not be disclosed outside the buyer’s response
evaluators and shall not be duplicated, used, or disclosed – in whole or in part – for any purpose
other than to evaluate this informational package without specific written permission of
smartData Enterprises.

Project Name Copyrights Reserved 1996-2019

4|P ag e

2. Our Understanding
2.1. Requirements understanding
The objective of the application is to provide a platform to customers to find truck-owners to
transport their goods. This platform will help customer get estimates to transport their goods
on the basis of location, pickup time, distance, goods and type of truck. All of this will be
done through kiosk where customers will order their transport in few clicks.

Project Name Copyrights Reserved 1996-2019

5|P ag e

2.2. Queries/ Assumptions

1. We are assuming that as the current web app is built in PHP so I am assuming that
backend will be made in PHP and user app in Android. Please share your thoughts.

2. How are truck drivers going to verify the information about the items that they are going
to ship/move?

3. Can you provide more information about scanning the ticket? How will it be generated?
Or the ticket is just an ID that is generated when the customer uploads the description on
the kiosk and that information will go in the backend.

4. As the default pickup address is going to be kiosk location, will the users have option to
change the pickup address. Or will they have to bring their stuff to the pickup location.

Project Name Copyrights Reserved 1996-2019

6|P ag e

5. Proposed Solution
a. Proposed Technology & Framework
Web based applications can be built on different frameworks such as .NET and Open source.
The parameters, which govern choice of framework, are numerous such as strategic
directions, technology standards or resource availability. smartData has experience and the
capability to provide solutions on both competing technologies.
smartData proposes to architect and develop this application using PHP7. Proposed site
will be structured, developed and enhanced using PHP7 MVC based framework structure.
The various third party services that needs to be provided by client to development team for
implementation purpose includes following:

b. Proposed Application Architecture

PHP is an established server-side scripting language that is very similar in syntax to C
languages for creating dynamic web pages. As a language that has been designed
expressly for the Web, it brings many features that commercial entities are looking for:
• Exceptionally short learning curve
• Quick development time
• Very high performance
PHP supports all major platforms (UNIX, Windows, MAC and even mainframes), and
features native support for most popular databases. All these factors make it a very good
choice for Web development. The fact that PHP was designed specifically for Web
development gives it an edge as a development tool, as Intranet Design Magazine explains:
"PHP was built with the needs of Web developers in mind... Unlike other cumbersome,
overhead-laden approaches, PHP is lightweight and focused on the Web - where it can solve
complex problem scenarios quicker and more easily than comparable technologies."
Although originally designed to run under Linux using the Apache Web server, it has been
ported to work using virtually every operating system and any standards-compliant Web
server software. From this it can be derived three of the primary advantages of PHP.
• Firstly, it is cross platform technology and consequently PHP applications can be
very portable – depending, of course, upon any additional components they are built
to incorporate, such as vendor specific databases etc. This portability incurs an
additional benefit by virtue of the fact that most Web hosting providers support PHP,
making it fairly easy to change hosts if necessary.
• Secondly, because PHP bears so much resemblance to C programming languages, it
is very easily picked up by developers familiar with this syntax – one that is shared by
Java, JavaScript and Perl, amongst others.

Project Name Copyrights Reserved 1996-2019

7|P ag e

• Thirdly, being open source, PHP is constantly evolving and, more importantly, bug
fixes are being regularly implemented to core libraries, which are freely available.

In addition to these benefits, there is certain programming requirement that makes PHP an
appealing choice for developers. Firstly, there are built-in libraries for the direct creation and
manipulation of image and PDF documents. This means, for example, that if an application
calls for dynamically-created menu images with anti-aliased text, or the exporting of pages to
Acrobat format, PHP may be the ideal technology to do it. Although these features are
theoretically available to competing technologies, they usually require the installation of third
party custom components to do so. Other known benefits are: -

• PHP 7 is often termed PHPNG (PHP – Next Gen) taking the performance of code to a
whole new level.
• Hosting is easy for PHP 7 applications.
• Modular programming approach is adopted by PHP 7 i.e. at any time in future; client
can easily add new modules in website thus Lesser Lines of Code is required.
• Supports Object Oriented Programming concept (Constructors, Destructors, Abstract
classes, Interfaces, Public, protected, and private properties and methods can easily be
created in PHP 7)
• Open Source, Supports MVC architecture and XML extensions are also supported
• Implementation of Ajax is also applicable
• Also supports SOAP, a key component of fast-growing web services field

c. Realization of the architecture (MVC)

MVC is architectural pattern used in software engineering. In complex computer applications
that present lots of data to user, one often wishes to separate data (model) and user interface
(view) concerns, so that changes to user interface do not impact data handling, and that data
can be reorganized without changing user interface. Model-view-controller solves this
problem by decoupling data access and business logic from data presentation and user
interaction, by introducing an intermediate component: the controller. MVC paradigm is a
way of breaking an application, or even just a piece of an application's interface, into three
parts: model, view, and controller. MVC was originally developed to map traditional input,
processing, output roles into GUI realm.

Model, View, Controller (MVC) structure is the best design pattern for architecting web
applications. MVC architecture separates web application into three primary layers. Model
layers abstracts a domain-specific data model and interacts with data persistence layer on its

Project Name Copyrights Reserved 1996-2019

8|P ag e

behalf (usually a database but could also be XML or text files). Controller interacts with user
through an interface (e.g. a webpage). Controller receives information or requests from user,
routes these to appropriate place in application and returns application’s response to the user.
View layer adds presentation templates (e.g. styles, themes, etc.) to data that comes from
model layer, before it is sent back to the user interface by Controller.

Model: Model is part of component that encapsulates application's data. It will often provide
routines to manage and manipulate this data in meaningful way in addition to routines that
retrieve data from model. In our case, model will contain methods to add, remove and update
information related to content in database. It will also contain methods to retrieve list of content
from database.

View: View is part of component that is used to render data from model in manner that is
suitable for interaction. For web-based application, view would generally be an HTML page that
is returned to data. View pulls data from model (which is passed to it from controller) and feeds
data into template which is populated and presented to user. View does not cause data to be
modified in any way; it only displays data retrieved from model.

Controller: Controller is responsible for responding to user actions. In case of web application,
user action is page request. Controller will determine what request is being made by user and
respond appropriately by triggering model to manipulate data appropriately and passing model
into view. Controller does not display data in model; it only triggers methods in model which
modify data.

MVC architectures improve development, scalability and on-going maintenance of web

applications by dividing their critical components into separate layers that can enhance or
exchanged without affecting other layers. They follow software engineering paradigm of
separating data persistence from application logic from presentation. Main distinction being
that web applications require ability to configure custom data models specific to domain of
application. These data models must support basic one-to-many and many-to-many type
relationships between objects, something that all MVC frameworks do very well.

Project Name Copyrights Reserved 1996-2019

9|P ag e

The MVC application type architecture has the following benefits:

Clean separation of roles and responsibilities of individual programs resulting in a modularly

built application.

Development teams can engage in parallel activities for developing programs of their domain.
For example UI developers, Business logic developers and control program developers can work
independently.

Most importantly when these applications are deployed, different program groups belonging to
Model, View and Controller will use different type of server resources and no server resource
will over load results in good performance and scalability.

Project Name Copyrights Reserved 1996-2019

10 | P a g e

The above points clarify that MEAN is suitable for writing small to medium-sized to large
web based applications without writing big line of codes and elegance of JavaScript makes
application extensible, robust and scalable, which is always primary requirement while
development of an application.

d. Realization of the architecture (MVVM)

MVVM is one of the architectural patterns which enhances separation of concerns, it allows
separating the user interface logic from the business (or the back-end) logic. Its target (with other
MVC patterns goal) is to achieve the following principle “Keeping UI code simple and free of
app logic in order to make it easier to manage”.

MVVM has mainly the following layers:

Model
Model represents the data and business logic of the app. One of the recommended implementation
strategies of this layer, is to expose its data through observables to be decoupled completely from
ViewModel or any other observer/consumer (This will be illustrated in our MVVM sample app
below).

ViewModel
ViewModel interacts with model and also prepares observable(s) that can be observed by a View.
ViewModel can optionally provide hooks for the view to pass events to the model.
One of the important implementation strategies of this layer is to decouple it from the View, i.e.,
ViewModel should not be aware about the view who is interacting with.

View
Finally, the view role in this pattern is to observe (or subscribe to) a ViewModel observable to get
data in order to update UI elements accordingly.

The following diagram shows MVVM components and basic interactions.

Project Name Copyrights Reserved 1996-2019

11 | P a g e

LiveData
As said above, LiveData is one of the newly introduced architecture
components. LiveData is an observable data holder. This allows the components in your
app to be able to observe LiveData objects for changes without creating explicit and rigid
dependency paths between them. This decouples completely the LiveData object producer
from the LiveData object consumer.

Adding to this, there is also a great benefit in LiveData, LiveData respects the lifecycle
state of your app components (activities, fragments, services) and handles object life cycle
management which ensures that LiveData objects do not leak.
As per Google Docs, if you are already using a library like Rx or Agera, you can continue
using them instead of LiveData. But in this case, it is your responsibility to handle object
allocation and de-allocation per Android components life cycle.

Since LiveData respects Android Lifecycle, this means it will not invoke its observer
callback unless the LiveData host (activity or fragment) is in an active state
(received onStart () but did not receive onStop () for example). Adding to this, LiveData
will also automatically remove the observer when the its host receives onDestroy ().

ViewModel
ViewModel is also one of the newly introduced architecture components. Architecture
components provide a new class called ViewModel, which is responsible for preparing the
data for the UI/View.

ViewModel gives you a good base class for your MVVM ViewModel layer
since ViewModel (and its children AndroidViewModel)’s extending classes are
automatically having their holding data retained during configuration changes. This means

Project Name Copyrights Reserved 1996-2019

12 | P a g e

that after configuration changes, this ViewModel holded data is immediately available to
the next activity or fragment instance.

The following diagram shows the life cycle of ViewModel component.

Important Guiding Principles for MVVM Implementation

Now, it is important to highlight some of the important guiding principles for MVVM
implementation:

As shown in the sample, ViewModels do not and must not reference Views directly because if
this is done, ViewModels can outlive the View’s lifecycle and memory leakage can happen.

Model and ViewModel are recommended to expose their data using LiveData since LiveData
respects the lifecycle state of app components (activities, fragments, services) and handles object
life cycle management which ensures that LiveData objects do not leak.

e. Application Architecture
The Application architecture for proposed system will be based on MVVM (MVC on
request) Design pattern using PHP based on advantages presented in section 4.2. Proposed
solution with modular and multi-tiered component based architecture will use Linux,
Apache, MySQL, and PHP 5, which will ensure that system will be customizable, robust and
scalable. Being compatible with most of databases and its ability to be used across multiple

Project Name Copyrights Reserved 1996-2019

13 | P a g e

platforms makes it perfect choice from technical point of view. Due to its excellent execution
speed their preferred choices for scripting language resulting in faster interactions. Last but
not least there is no denying with respect to cost advantage it brings in along with technical
advantages we have touched upon above briefly. No user licensing fees with minimal
maintenance fees along with some of free available components via PHP developer
community forums makes it a WIN-WIN for both development team as well as owner of
proposed developed product. The overall application will follow this simple but robust
recommended plan. It depicts technical application architecture for proposed system. The
client tier consists of Web Browser running on Windows system. The browser tier contains
HTML and runs JavaScript for user input validations.

f. Application Architecture – iOS

Applications architecture is designed keeping in view the pattern provided by MVC

In September 2014 apple announced the 1.0 version of the Swift language and gradually
increased its version to make it more stable with time. It is currently operating with version 4.0.
Definitely with more features it took an edge over Objective C and becoming the first priority of
developers to use it as the main central language for the software. Swift is light weight language
that follow the concept of scripting based language and here it took the edge over Objective C.

Swift is 70% faster as compared to Objective-C and that’s the reason all major platforms
are shifting their apps from Objective C to Swift. And swift is 12x effective than Objective
C so improving the performance of software.

SmartData follows the policy of quick adaptability so we are working on this language since
launch of XCode 6.0 to support our customers with best and updated technology. Various
successful applications are developed by organization that includes different examples using
swift and its updated versions.
Other features that Swift provides over Objective C are:

1. Interactive Playground: Swift provides interactive playground to look at the effect of code
so user can experiment small things to create best algorithms quickly. It uses WYSIWYG editor
for this feature which gives results side by side as you write any code.

2. Declaration and Syntaxes: More simplified syntaxes are provided by Apple in this language
as it does not need instance variable. That is why swift is also considered as the language where
“everything is an object.” It uses three kinds of objects:
Class
Struct
Enum

Project Name Copyrights Reserved 1996-2019

14 | P a g e

3. Features like:
a. Tuples : An ordered group of values. Very useful when need to pass more than
one value.
b. Generics: Get rid of type casts. It provides a way to defer the definition of type.
It’s pretty simple to use.

4. Objective-C Interoperability: You can create an entirely new application with Swift today,
or begin using Swift code to implement new features and functionality in your app. Swift code
co-exists alongside your existing Objective-C files in the same project, with full access to your
Objective-C API, making it easy to adopt.

5. Designed for Safety: Swift eliminates entire classes of unsafe code. Variables are always
initialized before use, arrays and integers are checked for overflow, and memory is managed
automatically. Syntax is tuned to make it easy to define your intent — for example, simple three-
character keywords define a variable (var) or constant (let).
Another safety feature is that by default Swift objects can never be nil. In fact, the Swift
compiler will stop you from trying to make or use a nil object with a compile-time error. This
makes writing code much cleaner and safer, and prevents a huge category of runtime crashes in
your apps. However, there are cases where nil is valid and appropriate. For these situations Swift
has an innovative feature known as optionals. An optional may contain nil, but Swift syntax
forces you to safely deal with it using the ?syntax to indicate to the compiler you understand the
behavior and will handle it safely.

Architecture of swift: Swift works with combination of the MVVM and MVC pattern. How?

Swift support direct access to property or the variable by its different behavior called as
“Property Observers”. Its property can behave differently depending upon the situation like run
time calculation for getters, accessing new values with setters and provide access when value is
changed or when value is about to change. Also it gives access for the initialization of any object
example the usage of lazy functionality for variable.
So as soon as we observe any value or change the same can be passed to view to change it
directly without the interference of controller. This make it adapt the property of MVVM by
changing directly to view as soon as modal is changed. Also support of reactive swift makes it
completely involve as MVVM.
Also language work in MVC pattern that is commonly known to all the developers is very old
pattern for different languages. This feature also helps developer to easily understand and known
towards swift. MVC allow controller as interface between Modal and the View so easy to
manage code using categories.
With combination of these design patter, Swift created a new architecture known as MVC-RS.
RS refer to as Router and storage respectively. So two layers make it more advance and more
powerful.

How it really works:

Reusability: Swift is reusable on all the Apple platforms, iOS, macOS, watchOS and tvOS but
also on Linux and someday, on Windows and android.

Project Name Copyrights Reserved 1996-2019

15 | P a g e

Reusing the View layer is different from reusing some common piece of code, because Views
are tightly coupled to the platforms they are running on. That makes sense, you are not rendering
the same kind of UI and you are not allowing the same kind of user interactions on a watch,
phone, tablet, computer or tv. If you have written a View layer on macOS, you have used AppKit
and so, your layer will be reusable only where AppKit is available, which means only on macOS.
The Model layer doesn’t have such constraints as the View, so you should be able to reuse your
Models on all the platforms where the language is available
Storage: The Storage layer will simply go between your Persistence and your Model and it will
have 2 tasks:
Talking to the Persistence
Converting raw data from the Persistence into entities of your Model

Router: The Router is a layer that goes ‘above’. It knows your Storage, your Model and your
Controller layers, and it has 3 tasks:
Communication with the Storage
Coordination of the Controllers
Management of the chrome

Communication with the Storage: The Router being in charge of the communication with the
Persistence, through the Storage, means also that the Controller layer has no longer any link with
the Persistence. Your Controllers won’t ever again ask for data; it is always the Router that will
give data to the Controllers. So it’ll be Dependency Injection all the way for the Controller layer.
First, the Router knows that asking data to the Storage is asynchronous, so it’ll start by showing
a loading screen to the user. Once the call is complete, there is several scenarios:
An error occurred, the Router will be responsible to show an appropriate error view. The result is
empty; the Router will be responsible to show an appropriate ‘empty’ view. You have actual

Project Name Copyrights Reserved 1996-2019

16 | P a g e

data, the Router will instantiate the appropriate Controller with that data and show that
Controller.
The 4 states (loading, error, empty, loaded) we saw previously are now managed by the Router.

Advantages of MVC-RS
Reuse your Models on every platform
Deep linking can easily be implemented
Controllers are now very light and very dumb, they do what they have to do and that’s all, no
extra work, no extra knowledge

Applications architecture is designed keeping in view the pattern provided by MVC

(Modal View Controller). User Interface is designed strictly according to
Apple's Human Interface guidelines. Backward compatibility across different iOS
versions is maintained by weak linking new frameworks. For databases programming
we use SqliteCoredata frameworks. Following flow chart explains the
customized framework followed at smartData to create apps on IOS.

Project Name Copyrights Reserved 1996-2019

17 | P a g e

The development of the proposed App would take in consideration the following iOS
elements:

iOS SDK: This is a software development kit developed and distributed by Apple. It is used to
develop iOS application that can be run on Apple devices including iPhone and iPad.

iOS Simulator: It is a testing engine used by developers for running, testing and debugging the
application for finding any bugs and issues before sending any release. Simulator allows
developers to simulate iPhone or iPad environment on their Mac Systems.

Instruments: Instruments are used to collect and analyze the data in real- time related to the
performance of the developed application. This is specifically used to check for any memory
leakage and for optimizing the application for better performance.

Interface Builder: Interface builder provides a graphical interface to the developers through
which they can design the application screen using drag and drop functionality.

Project Name Copyrights Reserved 1996-2019

18 | P a g e

g. Application Architecture and Process – Android

Android Architecture Components (AAC) is a new collection of libraries that contains the
lifecycle-aware components, which helps you design a robust, testable, and maintainable app. We
will be combining the MVVM(Binder) pattern and the Android Architecture Components (ACC).

View: The view is responsible for defining the structure, layout, and appearance of what the user
sees on the screen. It uses Data binding to bind the data with the layout file. This part is extracted
from the activity/fragment to make it easier to change the view or apply A/B testing. The view
shouldn’t hold any reference to the activity/fragment and it should expose the UI events (e.g. click
events) through an event listener to the activity/fragment. We’ll be using Kotlin Android
Extensions or Butter Knife.

Activity/Fragment: It is responsible for observing the ViewModel, keeping the UI up-to-date

(through the View) and it also forwards the user actions back to the ViewModel. It shouldn’t have
any reference to layout file (e.g. by using findViewById), instead, the activity inflates the View as
its content and implements view’s event listeners.

ViewModel: It is responsible for preparing and keeping the data for the UI. It uses LiveData to
keep the data and it survives the configuration changes. ViewModels are like gateway for the UI
components. The UI components (Activity/Fragment) use ViewModels to communicate with the
rest of the application.

LiveData: LiveData is a data holder class that keeps a value and allows this value to be observed.
Unlike a regular observable (e.g. RxJava), LiveData respects the lifecycle of app components,
such that the Observer can specify a Lifecycle in which it should observe.

Repository: Repository is responsible for the complete data model for the app, it provides simple
data modification and retrieval APIs and it is responsible for fetching, syncing and persisting from
different data sources.

Data Source: API to the data sources, such as Retrofit, Room and external contentProviders for
the OS.

For developing the proposed app for Android platform we will be using the below
mentioned resources:

Project Name Copyrights Reserved 1996-2019

19 | P a g e

Android Studio: It was announced on May 16, 2013 at the Google I/O conference. It is the
official integrated development environment (IDE) for Google's Android operating system, built
on JetBrains' IntelliJ IDEA software and designed specifically for Android development
available on Windows, macOS and Linux based OS. It is a replacement for the Eclipse Android
Development Tools(ADT) as primary IDE for native Android application development.

Android SDK: It is a software development kit provided by Google that allows developers to
create Native application for Android platforms. All the applications are written in Java
programming language and runs on Dalvik virtual machine.

Android Emulator (emulator) / 3rd party plugins (Genymotion / BlueStacks): These are
Emulator tools that allows developers to simulate Android device on their machines and allow
them to test the application.

Communication flow of an android application

Project Name Copyrights Reserved 1996-2019

20 | P a g e

h. Software Requirements

6. Type Name
Server * Linux/ Windows Server 2016

Web Server ** Apache/ IIS 10.0

Database *** MySQL

Scripting Language PHP 7

Framework CakePHP 3/Laravel (MVC based Framework)

Compatible Browsers IE10+, Safari (Mac – 11.1 and Windows – 5.1.7), Firefox
(Version 60.0.2), Edge (Version 42.17134) and Google
Chrome

Project Name Copyrights Reserved 1996-2019

21 | P a g e

Note:

Note:
* Server is operating system of server where web server and (or) database will be installed.
** Web Server is the server which hosts the application.
*** Database will be hosted on server

iOS Development:
(1) Note: iOS does not forcefully restart background services.

(2) App will be developed to the specific iOS device (iPhone or iPad or iPad
Mini) as per the requirements and specifications for the device. In case no
specific device details are specified the app will be made to support default
devices and versions.

iOS Development

Type Name
We will be testing the iOS app Cocoa (MVC pattern)
over below mentioned Apple
Devices Framework
Device Compatibility iPhone/ iPad or both [as per request]

iOS Version As per Client requirement (default latest version – 11.4)

[ Xcode 9.4, Swift 4.1, IOS 10.0 and above ]

Testing on Devices (iPhone):

Manufacture Mobile Categories Name iOS

Phone iPhone X 11.4.x
Phone iPhone 8+ 9.4
Xcode 11.2.x
Phone iPhone6+ 11.4.x
Apple Phone iPhoneSwift
5 4.1 11.4.x
IPad iOS 10.0
IPad 6 and above 11.2.x
IPad Air 11.1.x
IPad Air 2 11.1.x
IPad IPad 3 11.1.x

Android Development
Xcode 9.4 Swift 4.1 iOS 10.0 and above

Project Name Copyrights Reserved 1996-2019

22 | P a g e

Type Name
Language Android (Java) or Android (Kotlin) [as per request]

Framework MVVM pattern or MVC pattern [as per request]

Compatibility Android phones and Tablets [as per request]

Android Version As per Client Requirement (Default - Android 4.0 -

Oreo)

Testing on Devices (Android):

Mobile Android
Manufacture Category Name Version Resolution
Phone Note 5 7.0 2560 x 1440
Phone J2 5.1.1 540 x 960
Samsung Phone Note2 4.4.2 720 x 1280
Phone S3 4.1.2 720 x 1280
Tablet Note 800 (10.1) 4.1.2 800 x 1280
LG Phone LG Optimus 4.4.2 768 x 1280
HTC Phone Sensation 4.0.3 540 x 960
Phone Nexus 5X 8.1.0 1920 x 1080
Google nexus Phone Nexus 5 6.0 1920 x 1080
Phone Nexus S 4.1.2 480 x 800
Motorola Phone G4 Plus 7.0 320 x 480

Please Note: The features of application are developed taking raw android into consideration.
Due to customizable nature of Android OS, it is possible that some features of the application
developed may vary from device to device, wherever device manufacturer makes
customization specific to their brand.

Project Name Copyrights Reserved 1996-2019

23 | P a g e

7. Budget
a. Effort Estimation
This section describes the indicative smartData’s effort estimate to deliver the
Development Phase of this engagement. All effort is in “person hours” unit of measure

Functional Requirements Hours

Platform Development
Project Setup & Analysis 45
Design wireframes and Mock-ups
Application Architecture setup
Side bar setup for internal navigation
Defining basic concepts of application flow and screen navigations
(Including app design and wireframes including Android
standards)

Customer Application Interface

KIOSK - Public Screen 2
Splash Screen - can be an animation, a video, a series of graphics,
or a static image.
Welcome Screen

Aggregation 34
Kiosk location will be default pickup location
Ability to enter drop off location manually
Display in map - Google Map integration
Auto suggest location - Google API integration
a. Provide details - Door to Door or In house delivery
b. In case of in-house delivery
- Select the floor
- If there is elevator in the building
Select the number of helpers
Select Proposition of items
Select the number of items from the drop down menu
Select whether the item is fragile
For the selection of vehicle an algorithm will be created of us that
will recommend vehicle on the basis of information that customer
has provided

Select date and time for helpers arrival ( Calendar API integration )

Project Name Copyrights Reserved 1996-2019

24 | P a g e

Summary and Final confirmation

User will add mobile number for verification by OTP
SMS gateway interaction Twillio or any other

Payment 22
Payment with physical terminal
Payment gateway integration

Ability to print receipt via kiosk printer ( Printer Integration)

Ability to send receipt via SMS

ADMIN - Web Interface

System Analysis and Design 10

Database Setup and normalization
Creation of design for admin panel
Creation of inner pages/forms etc.

Login 2

Dashboard 8
View count of active booking
-Graphical view
- number of active clients
- number of active Clients
- Notifications/Alerts
Numbers of orders by kiosk

Users Management 8
Manage Drivers
List of Drivers
Add/Edit/Delete Drivers

Manage Kiosk 6
List of kiosk and their locations
Set up the default address
List of orders through each kiosk

Project Name Copyrights Reserved 1996-2019

25 | P a g e

Matching 16
Request will go to the admin/service owner based on location and
availability. Then the admin will assign requested vehicle to the
client.

Orders Management 8
Confirm an Order
Ability to view the upcoming/ongoing/completed pickup with
booking ID, date and time of pickup.
Status of past orders (completed/cancelled)
Details of orders(pickup and drop off location, driver profile pic,
detail of pickup will be displayed.)
Cancel an ongoing/upcoming order

Price Management 6
Price list per area
Price of helpers
Update Price per area
Update price of helpers
Update price of door to door/In-house/Floor delivery

Content Management System 8

Add /Edit/ delete/active/ de-active content pages

Admin profile Setting 10

Profile update API
Change Password API
Logout API

SYSTEM INTEGRATION & TESTING

Server Setup (Technology) 8

Server setup for Android tech stack
nginx configuration changes if required

System Integration & Testing 8

System integration & testing
Bugs posting and fixing

Project Name Copyrights Reserved 1996-2019

26 | P a g e

Total Hours for Kiosk + Admin 201

Functional Requirements

Driver Application

1 Project Setup & Analysis

Initial project Setup 45
Design wireframes and Mock-ups
Application Architecture setup
Side menu setup for internal navigation
Defining basic concepts of application flow and screen navigations

Sign up & login 16

Sign up: Ability to sign up via mobile number where driver will
enter his/her valid mobile number in proper number format.
Account Verification: On sign up with mobile number an OTP will
be sent along with the resend OTP option.
Account Activation: Once the driver’s phone number is
successfully verified, details like Name and Vehicle Type need to
be filled by the Driver.
Service-related details: Ability to upload relevant documents for
approval from service owner.

Login: Ability to login with mobile number. System will check if

number exists in the system. In case the phone number does not
exist in the system, the driver will be asked to Sign up.

Aggregation 12
Ability to receive pickup requests.
Ability to view pickup details. When the driver taps on the
booking card, it will show the complete details of pickup including
booking name, customer name, , icon to get directions to pick
up/drop off location.
Ability to accept/reject the pickup request.
Ability to provide reason for rejection.

Project Name Copyrights Reserved 1996-2019

27 | P a g e

Notification 12
1. Ability to get push notifications:
A. New pickup request

Payments 4
1. Ability to view earnings via the platform.

Navigation 24
1. Ability to get directions to the pickup and drop off location.
Driver will be directed to Google Maps app on their phone to
navigate to pick up/drop off location.

Review 4
1. Ability to give a 5-star rating and feedback to the customer
once the ride is completed

Others (Side Menu) 16

Profile:
A. View Profile: Ability to view profile. Profile parameters: first
name, email, phone, Profile picture.

B. Edit Profile: Ability to edit the profile so the driver can keep the
profile updated in the application. In case of editing email or
phone number, email verification or OTP verification will be done.

Bookings: Ability to view the past bookings with booking ID, date,
time of ride, customer name in card view, status of pickup. On
clicking the card, additional ride details such as details
ofpickup/drop off address.

Sign Out: Ability to sign out of the application.

Testing and deployment 12

Unit testing
Application deployment on Store

Hours 145

Total Hours ( IOS + ANDROID ) 245

Project Name Copyrights Reserved 1996-2019

28 | P a g e

b. Budget
smartData will execute the development phase of the project in Upwork hourly mode
following a fixed number of 446 hours at hourly rate of $14 for android/IOS and
hourly rate of $12 for PHP for the functionalities as mentioned in section $ and
mutually agreed in the proposal will be implemented for the application. Customer
shall not be charged beyond the number of hours and $ 6048 quoted here. In case,
during the project development phase, customer comes up with new features, not
being part of the effort shown in above section as mentioned above the same would
be treated as the change request after discussing/explaining and seeking consent from
the customer and they will be processed as per the clause defined in the proposal.

c. Terms & Conditions

Invoices will be weekly basis via XX mode. The payment will be based on the work done by the
team.

This proposal is valid for acceptance for 30 days from the date of submission.

Lead-time to start the project is 2 weeks from date of proposal acceptance and 1 week from time
of award of project and payment of advance.

Project Name Copyrights Reserved 1996-2019

29 | P a g e

8. Project Management & Methodology

a. Company Profile
smartData Enterprises is a CMMI 3 – (accreditation for software process improvement
standards) IT consulting and a contract services provider, providing end-to-end consulting
for global clients. smartData has partnered with several Startups, SME’s and Fortune 500
companies, in building their next generation digital information infrastructure for competitive
advantage. The smartData portfolio of services includes Healthcare services, Business
automation, Digital Enterprise, IT Services and E-strategy consulting. Our solutions focus
on addressing market and technology challenges for customers across multiple industries.
The offshore model of the company leverages talent and infrastructure to provide high
quality, rapid time-to-market solution using scrum methodology and empirical software
development processes, as a result we have 2000+ satisfied customers, 500 published apps on
itunes and Google play store, Microsoft partnership and Certificate of Status (State of
California).
smartData has 3 development offices in India (located at Mohali (Head Quarter), Nagpur
and Dehradun) along with business development offices in New York, USA and Sydney,
Australia. smartData has team of app. 850 developers, designers, QA and other associated
technologies senior resource pool. Major teams include 350+ Microsoft, 250+ OpenSource
(MEAN, PHP, MERN, Python etc.) along with 150+ mobility (Native iOS & Android,
Hybrid) resources. Beside these dedicated team of UI/UX developers, designers, QA/QC
along with new technology/R&D team are also available.

b. smartData’s Methodology
Our methodology follows Scrum, the agile process with an iterative and rapid incremental
development approach, where each set of features is fully operational after a short cycle.

Step 1: Product vision and the scope is defined in terms of short user stories comprising of
the product backlog items. Product owner defines, prioritize and presents the ready backlog
to Scrum master and the team. Master sprint plan is prepared with 1 week sprints.

Step 2: Sprint backlog is the list of work that the development team addresses during the
sprint, the list is derived by the scrum team progressively selecting the backlog items in
priority order, core features are at the top (developed first) followed by the non-essential.

Project Name Copyrights Reserved 1996-2019

30 | P a g e

Step 3: Sprints are initiated with daily standup meetings, team presents backlogs that are
done, impediments are identified and removed by cross functional collaboration. Continuous
retrospection is done by the scrum master, and the team identifies, the top process
improvements. Inspect and Adapt cycle is followed. Github is used for code repository and
source revision, ACE project management tool is used for day to day progress and tracking.

Step 4: Scrum master does the product backlog management, clearly communicates vision,
goals and product backlog items to the team, facilitate scrum event (release planning)
facilitates daily standups, sprint planning and impediments removal. Estimate is done in
terms of the story size and not time, they are done by the people who are going to do the

Project Name Copyrights Reserved 1996-2019

31 | P a g e

work, 10% of the sprint time is allocated to the product owner, and continuous estimates are
done during the project and not all upfront. The desired product with user feedback is
developed rapidly with quick turnaround time and minimal cost. Any new functionality to be
added or a change, required in functionality that may result in change of work flow is
considered a change request for which the process mentioned under section 5.4 is followed.

c. Assumptions
We are providing the estimates only for the application development as per the requirements
provided.
The scope will be contained to line items mentioned in section 2.2 and 2.3 of the proposal. While
creating proposal, it has been assumed that requirements given by client forms complete scope of
application. Any requirement, not explicitly mentioned in this document, do not form part of
these estimates. For any changes required in application, it will be considered as change request
and proper estimates (in man hrs.) of changes will be provided by smartData.
Client shall provide all third party software, hardware components, images/content or any
material needed for project. This includes hosting details, hardware environment etc. Cost of all
these components/images/content if any, will be borne by client and does not form part of
proposed estimated cost in development cost section 4.1
smartData will be responsible for the development of the software alone and can only
recommend the Hosting service provider. The hosting service will be a client decision. Any new
requirement or changes in server settings recommended by smartData developers will be
provided by client. Any delay in the project delivery due to this will NOT be smartData’s
responsibility.
Client shall regularly participate in the weekly sprint meetings and provide acceptance of the
sprints within a week’s time, if not then it will be considered as accepted. Client will provide all
requirement details by first week after awarding the project.
Deployment
smartData development team will provide prerequisite for proper functioning of the software to
the customer prior to live deployment process
Customer shall be responsible for the purchase and configuration of the deployment environment
as suggested by the team
smartData shall ensure that the software works exactly as verified by the customer in smartData's
staging environment.
smartData shall not be responsible for any loss of data, hacking or any other malicious attempts
made on server once the application is made live.
smartData can provide a paid support for any server related issues and configurations, charged
hourly which will be separate from the development work

Project Name Copyrights Reserved 1996-2019

32 | P a g e

In cases where the team members are continuously updating the live environment due to customer
needs and/or end user requirements, smartData will update the customer about the process of
securing the code and database, decision to implement the process will be taken by the customer,
smartData shall bear no responsibility in case of any loss of data.

d. Change Management
Change Management is an integral portion of smartData Quality Management System
(QMS). Processes that govern change management activities are described in these clauses
in smartData QMS. Project-specific change management processes are tailored from this
organizational standard software process and represented in operational software process for
project. Tailoring takes into account, amongst other factors, nature of workflow, client-
communication channels, the routing of work packets, location of development, and
associated technology.

Typically, changes are received through Change Requests (CR) and log ged in Change
Register. An impact analysis is done on change requests to identify depth of changes on
software components. The result translates into a change introduction strategy that would

Project Name Copyrights Reserved 1996-2019

33 | P a g e

involve scope of change, methods involved in establishing change, type and extent of testing
required and other parameters.

--------------- End of Document ---------------

Project Name Copyrights Reserved 1996-2019