Let’s Share

Taqdees Habib
(15-Arid- 1405)
Abdul Moiz
(15-Arid-1295)

Supervised by

Mr. Saif-Ur-Rehman

UNIVERSITY INSTITUTE OF INFORMATION TECHNOLOGY

PMAS ARID AGRICULTURE UNIVERSITY
RAWALPINDI
2019
 Let’s Share

By

Taqdees Habib

(15-Arid- 1405)

Abdul Moiz

(15-Arid-1295)

Supervised by

Mr. Saif ur Rehman

A PROJECT SUBMITTED IN PARTIAL FULFILLMENT OF THE

REQUIREMENTS OF THE DEGREE OF

BACHELOR OF SCIENCE IN INFORMATION TECHNOLOGY

(BSIT)

UNIVERSITY INSTITUTE OF INFORMATION TECHNOLOGY

PMAS ARID AGRICULTURE UNIVERSITY
RAWALPINDI
2019

II
Dedicated to our beloved parents and to all those, whose
prayers paved the way of our success.

III
 PROJECT IN BRIEF

Project Title: Let’s Share

Organization: University Institute of Information Technology

Undertaken By: Taqdees Habib (15-Arid- 1405)

Abdul Moiz (15-Arid-1295)

Supervised by: Saif-Ur-Rehman

Date Started: 22nd Nov, 2018

Date Completed: 10/7/2019

Technology Used: Visual Studio .Net Framework, Firease, Android Studio

Operating System: Windows 8.1

System Used: CORE i5, 500 GB HDD, 8 GB RAM

IV
 ACKNOWLEDGMENT

ALLAH the almighty gave us the strength to work to complete this project on time and
with the best possible quality and our family and friends who supported us in every step
of life and mostly the past two years of university life.

We would like to thank and sincerely acknowledge the help of our supervisor Mr. Saif
Ur Rehman whose complete guidance, support and encouragement gave us a real
motivation in doing this project.

We would like to thank all the volunteers who helped us out while testing of this
application.

Lastly, we would like to thank all the faculty members of UIIT department for their
help, time, and support that was gladly given to us on the time of need.

Taqdees Habib

(15-ARID-1405)

Abdul Moiz

(15-ARID-1295)

V
 DECLARATION

We hereby declare that this project, neither whole or as a part has been copied out from
any source. It is further declared that we have developed this project and accompanied
report entirely on the basis of our personal efforts. If any part of this project is proved
to be copied out from any source or found to be reproduction of some other. We will
stand by the consequences. No Portion of the work presented has been submitted of any
application for any other degree or qualification of this or any other university or
institute of learning.

Taqdees Habib
(15-Arid- 1405)/ BSIT

Abdul Moiz
(15-Arid-1295)/ BSIT

VI
 CERTIFICATION

It is certified that the contents and form of the project entitled “Lets Share”
submitted by “Let’s Share” submitted by Taqdees Habib (15-Arid-1405) Abdul
Moiz(15-Arid-1295) has been found satisfactory for the requirements of

PMAS – Arid Agriculture University, Rawalpindi

For the award of the degree of

BACHELOR OF SCIENCE IN INFORMATION TECHNOLOGY (BSIT)

Supervisor: _______________________
Mr. Saif-Ur-Rehman

Examiner 1: _______________________
Dr. Saleem Iqbal

Examiner 2: _______________________
Ms. Sidra Tahir

Dated: 01/08/2019

Director: ________________________

Prof. Dr. Mobushir Raiz Khan

VII
 ABSTRACT

Traveling in Pakistan is not as easy as it must be, especially for women who have to
face a lot of trouble while traveling in public transport. Because of the poor
infrastructure of public transportation in the country, this is one industry that requires a
lot of attention. Working women and university girls have a face a lot of difficulty in
order find a suitable and trustworthy driver. With Let’s Share, girls and working
women can have access to affordable transportation with no fear and difficulty. This
system is a web and android based system that is designed only for the women. Women
can register both as customer of drivers. The software is designed and developed using
various development tools, technologies, and programming languages.

VIII
 TABLE OF CONTENTS

PROJECT IN BRIEF………………………………………………………………..…...IV

ACKNOWLEDGMENT………………………………………………………………..…V

DECLARATION……………………………………………………………………….....VI

CERTIFICATION…………………………………………………………………….....VII

ABSTRACT….……………………………………………………………………….....VIII

Chapter 1……………………………………………………………………................…….1

INTRODUCTION………………………………………………………………………….1

1.1. PROJECT OVERVIEW..........................................................................................1

1.2. PROJECT AIMS.....................................................................................................1

1.3. PROJECT OBJECTIVES.......................................................................................2

1.4. SCOPE OF THE PROJECT...................................................................................3

1.5. PROBLEM STATEMENT .....................................................................................3

1.6. PERPOSED SYSTEM COMPONENT .................................................................3

1.7. METHODOLOGY AND SOFTWARE LIFE CYCLE FOR THIS PROJECT .....4

1.8. DEVELOPMENT REQURIMENTS .....................................................................5

Chapter 2……………………………………………………………………................……6

REQUIREMENT ANALYSIS……………………………………………………….........6

2.1. SOFTWARE REQURIMENTS SPECIFICATION (SRS) ....................................6

2.2. FUNCTIONAL REQURIMENTS .........................................................................6

2.2.1 Interactivity with System ......................................................................................6

2.2.2 The User’s .............................................................................................................6

2.2.3 Database ................................................................................................................7

IX
 2.2.4 Profile Management ..............................................................................................7

2.2.5 User Activity Tracking ..........................................................................................7

2.2.6 User Content Checking .........................................................................................8

2.2.7 Account Creation and Dissolution ........................................................................8

2.2.8 Find and Add Route ..............................................................................................8

2.2.9 Multiple Users .......................................................................................................8

2.3. NON-FUNCTIONAL REQUIREMENT ...............................................................8

2.3.1 Usability ................................................................................................................8

2.3.2 Reliability ..............................................................................................................9

2.3.3 Integrity .................................................................................................................9

2.3.4 Performance ..........................................................................................................9

2.3.5 Supportability ........................................................................................................9

Chapter 3……………………………………………………………………................…..10

DESIGN AND ARCHITECTURE....................................................................................10

3.1. USE CASES .........................................................................................................10

3.2. ERD ......................................................................................................................28

3.3 CLASS DIAGRAM .............................................................................................29

3.4 SEQUENCE DIAGRAM .....................................................................................30

3.4.1 Registration .........................................................................................................30

3.4.2 Login ...................................................................................................................31

3.4.3 Update Account ...................................................................................................32

3.4.4 Delete Account ....................................................................................................33

3.4.5Delete User ...........................................................................................................33

3.4.6 Connection between driver and passenger ..........................................................34

3.4.7 Logout .................................................................................................................35

X
 3.5 ACTIVITY DIAGRAM .......................................................................................36

3.5.1 Register and login ...............................................................................................36

3.5.2 Delete Account ....................................................................................................37

3.5.3 Delete User ..........................................................................................................37

3.5.4 Overall communication and network between Driver and Passenger ................38

3.5.5 Logout .................................................................................................................39

3.6 COMPONENT DIAGRAM .................................................................................40

3.7 DEPLOYMENT DIAGRAM...............................................................................41

3.8 CHAPTER SUMMARY ......................................................................................41

Chapter 4……………………………………………………………………..................…42

PROJECT MANAGEMENT.............................................................................................42

4.1. MILESTONES .....................................................................................................42

4.2. PROJECT CLOSEOUT REPORT .......................................................................44

4.3. PROJECT DELIVERABLE ................................................................................44

4.4. PROJECT RESOURCE .......................................................................................44

4.5. RISK MANAGEMENT .......................................................................................44

4.5.1 Introduction to risk management ........................................................................44

4.5.2 Purpose ................................................................................................................44

4.5.3 Risk Management Responsibilities .....................................................................45

4.5.4 Risk Analysis .......................................................................................................45

Chapter 5..............................................................................................................................47

IMPLEMENTATION.........................................................................................................47

5.1. PROGRAMMING LANGUAGE ........................................................................47

5.2. FRAMEWORK ....................................................................................................48

XI
 5.3. SYSTEM REQUIREMENTS ..............................................................................47

5.4. CHAPTER SUMMARY ......................................................................................48

Chapter 6……………………………………………………………………................…..49

SOFTWARE TESTING.....................................................................................................49

6.1. DERIVING TEST ................................................................................................49

6.2. TEST ENVIRONMENT ......................................................................................49

6.3. SOFTWARE.........................................................................................................49

6.4. HARDWARE .......................................................................................................49

6.5. TESTING IDENTIFICATION ............................................................................50

6.6. TEST PROCEDURE ...........................................................................................50

6.6.1 Unit Testing .........................................................................................................50

6.6.2 Integrate Testing ..................................................................................................51

6.6.3 System Testing ....................................................................................................51

6.6.4 Performance Testing ............................................................................................51

6.7 TEST CASES .......................................................................................................52

6.7.1 TEST CASE 1 .....................................................................................................52

6.8. CHAPTER SUMMARY ......................................................................................55

Chapter 7..............................................................................................................................56

CONCLUSION AND FUTURE WORK..........................................................................56

7.1. DISCUSSION ......................................................................................................56

7.2. CONCLUSION ....................................................................................................57

7.3. LIMITATION .......................................................................................................57

XII
 List of Figures

Figure 1.1: Project Aims ........................................................................................................2

Figure 3.1: Use Case Diagram .............................................................................................10
Figure 3.2: ERD Diagram ....................................................................................................28
Figure 3.3: Class Diagram ...................................................................................................29
Figure 3.4: Sequence Diagram Registration ........................................................................30
Figure 3.5: Sequence Diagram Login ..................................................................................31
Figure 3.6: Sequence Diagram Update Account ..................................................................32
Figure 3.7: Sequence Diagram Delete Account ...................................................................33
Figure 3.8: Sequence Diagram Delete User .........................................................................33
Figure 3.9: Sequence Diagram Connection .........................................................................34
Figure 3.10: Sequence Diagram Logout ..............................................................................35
Figure 3.11: Activity Diagram Register ...............................................................................36
Figure 3.12: Activity Diagram Delete Account ...................................................................37
Figure 3.13: Activity Diagram Delete User .........................................................................37
Figure 3.14: Activity Diagram Communication ..................................................................38
Figure 3.15: Activity Diagram Logout.................................................................................39
Figure 3.16: Component Diagram .......................................................................................40
Figure 3.17: Deployment Diagram ......................................................................................41

XIII
 List of Tables

Table 3.1: Admin Login .......................................................................................................11

Table 3.2: Passenger Login ..................................................................................................12
Table 3.3: Driver Login........................................................ Error! Bookmark not defined.
Table 3.4: Delete User.......................................................... Error! Bookmark not defined.
Table 3.5: View User ........................................................... Error! Bookmark not defined.
Table 3.6: Admin Sign-out................................................... Error! Bookmark not defined.
Table 3.7: Chat Table ........................................................... Error! Bookmark not defined.
Table 3.8: User Login .......................................................... Error! Bookmark not defined.
Table 3.9: Update Profile: .................................................... Error! Bookmark not defined.
Table 3.10: Driver Profile .................................................... Error! Bookmark not defined.
Table 3.11: Update Contact .................................................................................................21
Table 3.12: View Inbox........................................................................................................22
Table 3.13: Ride History ...................................................... Error! Bookmark not defined.
Table 3.14: Delete Account.................................................. Error! Bookmark not defined.
Table 3.15: Search Ride ....................................................... Error! Bookmark not defined.
Table 3.16: Accept Ride ....................................................... Error! Bookmark not defined.
Table 3.17: Share Ride ......................................................... Error! Bookmark not defined.
Table 4.1: Project Milestones ...............................................................................................42
Table 4.2: Project Closeout Reports .................................... Error! Bookmark not defined.
Table 4.3: Project Deliverables ............................................ Error! Bookmark not defined.
Table 4.4:Project Resources ................................................. Error! Bookmark not defined.
Table 4.5: Risk Analysis ...................................................... Error! Bookmark not defined.
Table 4.6: Risk Response ..................................................... Error! Bookmark not defined.
Table 5.1: System Requirements.......................................... Error! Bookmark not defined.
Table 6.1: HardwareRequirements....................................... Error! Bookmark not defined.
Table 6.2: Test Case 1 ..........................................................................................................52
Table 6.3: Test Case II .........................................................................................................53
Table 6.4: Test Case III ........................................................................................................53
Table 6.5: Test Case IV ........................................................................................................54
Table 6.6: Test Case V ......................................................... Error! Bookmark not defined.
Table 6.7: Test Case VI........................................................................................................55

XIV
 Chapter 1

INTRODUCTION

1.1. PROJECT OVERVIEW

Girls that are working or start workings in offices and girls that is studying or starts
studying in university and colleges, convince is one of the main issue for them. To
find secure taxi or van and their parents are also very worried due to security of
their young girls; parents of kids are also very worried because of present condition
of Pakistan’s security and not able to trust anyone easily. So they don’t want to
send their kids with van or taxi drivers. In response to this problem, this ride-
sharing application will have solutions of all problems. Security problem will be
solved due to female drivers. And parents of kids and young girls will easily trust
and be confident to send them with female delivers.
Project will have two portals i.e. web and android app. Driver and passenger both
will have the permission to register or use both portals.
Girls that are using their own convince on daily bases to go offices, universities etc
will work as a driver in it. Driver will give their information like name, address,
contact no., their route and timings and destination, and it will store on database.
And passengers are the girls that are working or start workings in offices and girls
that is studying or starts studying in university and colleges; convince is one of the
main issue for them to solve this issue we are going to design this app. Girls who
want convince will search for its suitable driver girl schedule and contact it through
app and will set the time. And payment can be on daily bases, on weekly or on
monthly.
Payment will be divided between driver and company on the bases of satisfactory
percentage.
It will Secure, One tap solution and the biggest advantage; Extra income without
over time.

1.2. PROJECT AIMS

We want to resolve the female transport security issues.

My aim in this project is to map, to develop, to design, to track, to generate, to theories
to build a complete safe and secure app for female to travel from one point to another
easily.

Project Aims:

"You aim to accomplish a goal in order to achieve your objective"

It will only for females to Secure.

travel safely with female
drivers from one place to One tap solution.
another Extra income without over time.

Figure
Figure 1.1 Project
1: Project AimsAims

1.3. PROJECT OBJECTIVES

 Specific –It is specific for female passengers as well as drivers will also
female.
 Measureable – It will be definitely safe for females.
 Achievable – We want a safe and secure ride for females and also provide a
chance to earn without overtime.
 Realistic – We are practically able to do what we wish to do. Factors to
consider include: time; expense; skills; access to sensitive information;
participant’s consent; etc. We will consume them in an efficient way to
complete our project.

2
  Time constrained – It will take 7-8 months to complete.

1.4. SCOPE OF THE PROJECT

We are facilitating female workers and students for security purpose and also get an
extra income without overtime.

1.5. PROBLEM STATEMENT

Part A- the ideal: Girls that are working or start workings in offices and girls that is
studying or starts studying in university and colleges, convince is one of the main issue
for them.

Part B - the reality: To find secure taxi or van and their parents are also very worried
due to security of their young girls; parents of kids are also very worried because of
present condition of Pakistan’s security and not able to trust anyone easily. So they
don’t want to send their kids with van or taxi drivers.

Part C- the consequences: In response to this problem, this ride-sharing application

will have solutions of all problems. Security problem will be solved due to female
drivers. And parents of kids and young girls will easily trust and be confident to send
them with female delivers.

1.6. PERPOSED SYSTEM COMPONENT

Project is basically based on different components or deliverables. Main advantage of

dividing the project into components attains reusability.

Components/Modules of this project are as follows:

Module 1: Admin panel

Admin will give the initial right to the user, also has access to remove any user account
from the system. Admin can also employ new policies and constraints.

 Add/remove any user from its list.

 Check the overall activities of the user.

3
  Apply new polices.

Module 2: Automatic revokes authorization

User manages the privacy based on activities of other users on his uploaded content. If
a user doesn’t interact with other user her rights will be revoked. When the rides are
completed or when dissolution time meets communication will be deleted. Privacy
settings will also be revoked based on users communication history. If the user is
inactive with a certain team member for specific time period, she will be able to change
the privacy settings.

Module 3: Search

Allows user to search a specific route rider/provider, colleague or friend for whom she
wants to provide the facility of Let’s Share. User will be able to add multiple riders at
the same time and same route. User will be also able to change the route according her
routine.

Module 4: Communication history

User can check its activity log. Admin can view the communication history of the user.

Module 5: Privacy settings

 User will define privacy settings.

 Setting will be according to communication history, assigned tasks and type.

1.7. METHODOLOGY AND SOFTWARE LIFE CYCLE FOR THIS

PROJECT

For the development of our project the software methodology that we would be using
will be the “agile approach.” We have chosen this methodology as it will allow us to
add more functions and modules to the project later if needed. Therefore, the agile
approach will provide us with flexibility in our project for adding more functionality
later and with the use of it we will also not need to repeat the whole process of adding a
function during its development.

4
1.8. DEVELOPMENT REQURIMENTS

 C# Language:
There are many reasons why we chose C# for our project. It is a modern
programming language, widely spread, used by millions of programmers around the
entire world. At the same time C# is a very simple and easy to learn (unlike C and
C++). It is natural to start with a language that is suitable for beginners while still
widely used in the industry by many large companies, making it one of the most
popular programming languages nowadays.

 DOT NET Framework:

The C# language is not distributed as a standalone product – it is a part of the
Microsoft .NET Framework platform (pronounced "Microsoft dot net framework").
.NET Framework generally consists of an environment for the development and
execution of programs, written in C# or some other language, compatible with
.NET (like VB.NET, Managed C++, J# or F#). It consists of:
o The .NET programming languages (C#, VB.NET and others).
o An environment for the execution of managed code (CLR), which executes
C# programs in a controlled manner.
o A set of development tools, such as the csc compiler, which turns C#
programs into intermediate code (called MSIL) that the CLR can
understand.
o A set of standard libraries, like ADO.NET, which allow access to databases
(such as MS SQL Server or MySQL) and WCF which connects applications
through standard communication frameworks and protocols like HTTP,
REST, JSON, SOAP and TCP sockets.

 Android:
o Developers choose to develop for Android in order to reach the majority
of mobile device users.
o It helps to develop apps efficiently. It provides rich development
architecture. It can distribute app in many different ways such as a Google
Play.

5
 Chapter 2

REQUIREMENT ANALYSIS

2.1. SOFTWARE REQURIMENTS SPECIFICATION (SRS)

A software requirement specification minimizes the time and effort required by

developers to achieve desired goals and also minimizes the development cost. A good
SRS defines how an application will interact with system hardware, other programs and
human users in a wide variety of real-world situations. Parameters such as operating
speed, response time, availability, portability, maintainability, security and speed of
recovery from adverse events are evaluated.

2.2. FUNCTIONAL REQURIMENTS

Functional requirements are those requirements that define the functionality of the
project. In other words functional requirements are basically how the system works for
the users.

System features are described in detail as follows.

2.2.1 Interactivity with System

Graphical User Interface (GUI) is the most integral part of any system because user
what thinks is what he/she wants to see. GUI is the first key thing that user will stay on
application we have built, because any user first see then think. So our user interface
should very attractive and interactive too.
Nowadays, almost every application is responsive because user wants it on his/her
smart phone and tablet PC as well. So there is a requirement that application should be
responsive and very flexible for all kind of devices.
For this we used Android and other techniques to fulfil this requirement.

2.2.2 The User’s

User in this application has different privileges to access the application. In the Let’s
Share APP, there are two main parties are involved: the “Drivers” and the

6
“passengers”. On one hand there are users which are only using this app for making
extra income and safe ride purposes. On the other hand there are also some users which
are maintaining and managing this application.
User can communicate with each other, send and receive messages, manage her own
profile, share views and emotions, share comment like/dislike ride activity, view her
activity log.
Admin will maintain and manage the application, and will be able to see content of
user, can see conversation between user and driver can see activity log of rider and
provider, can delete users.

2.2.3 Database
Fully functional database is required for every single record over social network, i.e.
user personal information, driver personal information, notifications, route log, ride
logs, user’s/driver’s profile information, estimated cost of ride.

2.2.4 Profile Management

A user profile is a visual display of personal data associated with a specific user. A
profile refers therefore to the explicit digital representation of a person's identity.

There is a requirement of a well-structured and well managed user profile that she can
share all over the world. User profile does not only refer to its personal information.
But there is one more thing which is attached with this, is Privacy Settings. User can set
her general privacy setting that means who and how user’s uploaded content can be
seen by other users over the network.

There are two types of privacy settings, General Privacy Settings for all contents and
Ride Privacy Settings for single ride content.

2.2.5 User Activity Tracking

The core feature of this application is tracking out the activity of the user. By keeping
the track of user activity we can make user well bounded with our application. A
notification must be generated if the user isn’t involved in any activity, for a specific
long time period.

7
2.2.6 User Content Checking
User ride content must be seen and checked to ensure that the user over ride isn’t act
anything which is morally, culturally, religiously, or behaviourally explicit.

2.2.7 Account Creation and Dissolution

User can create its own account for which she is required as rider or provider. Account
needed to enter some details like, name and purpose of the account, email, phone
number etc. if a group is made for shorter period of time like a working women or
student make an account to ride or as provider but her session become closed. So by the
end of time the account becomes useless and all the data stays there forever. To
overcome this situation user should enter pre-defined time for the group.

2.2.8 Find and Add Route

Users should be able to find the route which she required and she also able to change
the route according to her routine as a provider.

2.2.9 Multiple Users

Provider should be able to add the multiple riders on same route and same time.

2.3. NON-FUNCTIONAL REQUIREMENT

Non-functional requirements are those requirements that don’t define the actual
working of the system. Non-functional requirements are used to judge and evaluate the
quality of the system. Non-functional requirements cover all the remaining
requirements which are not covered by the functional requirements. They specify
criteria that judge the operation of a system, rather than specific behaviours. Non-
functional requirements in our project are following

2.3.1 Usability
Usability is a quality attribute used to assess how easy the interface is to use. Usability
is ease of use. It tells how user friendly the interface is.

8
It includes memory-ability, learn-ability, and satisfaction. Our software interface has all
the above qualities. Any kind of user, whether he/she is a novice user or technical user
they can easily understand the interface.

The system will be design in such a way that it will be easy understandable by the
users. It is a web based project so it can be accessible only if a user has an internet
connection

2.3.2 Reliability
Reliability is how much the system is consistent in different platforms. The ability of an
apparatus machine, or system to consistently perform its intended or required function
or mission, on demands and without degradation or failure.

2.3.3 Integrity
An integral system is one which is more absorbing and is more precise in nature. When
it comes to replace the human a system should be as precise as possible with
approximately 0% of tolerances.

2.3.4 Performance
Our system’s response time will minimum and it will be dependent on the speed of
internet connection.

2.3.5 Supportability
System will be supported on all browsers. The system will also be supported by mobile
browsers.

9
 Chapter 3

DESIGN AND ARCHITECTURE

3.1. USE CASES

Figure 3.1: Use Case Diagram

10
3.2. USE CASES (Fully Dressed)

Table 3.1 Admin Login

Use Case ID: UC-1.1.1

Use Case
Name: Admin Login

Actors: Admin

Description: Admin Logins to perform several operations

Trigger: Click Admin Tab on the home screen.

Preconditions: Administrator must be authorized

Post
conditions: Admin Logged in Successfully.

Normal Flow: 1. Click Admin Button

2. Enter email
3. Enter Password
4. Click login button
Alternative
Flows: None

Exceptions: In step 2 and 3 of the normal flow if admin enters wrong details system
generates error messages and ask admin to re-enter password/username.

Includes: None

Special
Requirements: 1. Security
2. Reliability
Assumptions: Admin must be registered to the system

11
 Table 3.2 Passenger login
Use Case ID: UC-1.1.3

Use Case Name: Passenger login

Actors: Passenger

Description: It will help in adding new passenger to Application.

Trigger: Click Register As A Passenger button.

Preconditions: Passenger doesn’t have account.

Post conditions: Passenger added successfully

Normal Flow: 1. Click Register As A Passenger button

2. Select picture
3. Enter name
4. Enter CICN
5. Enter email
6. Enter route
7. Enter Password
8. Confirm Password and Click register button
Alternative Flows: None

Exceptions: If user already exists system displays error message

Includes: Uc-1.1.1

Special Requirements: 1. Security

2. Reliability
Assumptions: None

12
 Table 3.3 Driver login

Use Case ID: UC-1.1.3

Use Case Name: Add Driver

Actors: Driver

Description: It will help in adding new Driver to Application.

Trigger: Click Register As A Driver button.

Preconditions: Driver doesn’t have account.

Post conditions: Driver added successfully

Normal Flow: 1. Click Register As A Driver button

2. Select Picture
3. Enter name
4. Enter CICN
5. Enter email
6. Enter Password
7. Confirm Password and Click register button
Alternative Flows: None

Exceptions: If user already exists system displays error message

Includes: Uc-1.1.1

Special Requirements: Security

Reliability

Assumptions: None

Notes and Issues: None

13
 Table 3.4 Delete User (Driver/Passenger)
Use Case ID: UC-1.1.5

Use Case Name: Delete User

Actors: Admin

Description: It will help in deleting user from Application.

Trigger: Click on delete user button

Preconditions: Admin must be logged in

Post conditions: User deleted successfully

Normal Flow: 1. Click delete user button

2. Select the user to delete from list
3. Click delete button
Alternative Flows: None

Exceptions: None

Includes: UC-1.1.1

Special Requirements: Reliability

Assumptions: None

Notes and Issues: None

14
 Table 3.5 View User profile
Use Case ID: UC-1.1.6

Use Case Name: View User profile

Actors: Admin

Description: Admin can view any user’s profile

Trigger: Click View user’s profile button

Preconditions: Admin must be logged in

Post conditions: Admin view user’s profile successfully

Normal Flow: 1. Click view user profile button

2. Select user from list
3. Click view profile button
Alternative Flows: None

Exceptions: User temporarily deactivated

Includes: UC-1.1.1

Special Requirements: 1. Efficiency

2. Reliability
3. Security
Assumptions: None

Notes and Issues: None

15
 Table 3.6 Admin Sign-out
Use Case ID: UC-1.1.7

Use Case Name: Sign-out

Actors: Admin

Description: Admin will sign-out from system

Trigger: Click sign-out button

Preconditions: Admin must be logged in

Post conditions: Admin Sign-outs Successfully

Normal Flow: 1. Click Sign-out button

2. Click Confirm Button
Alternative Flows: None

Exceptions: None

Includes: Uc-1.1.1

Special Requirements: 1. Efficiency

2. Security
Assumptions: None

Notes and Issues: None

16
 Table 3.7 Communicate with Drivers
Use Case ID: UC-1.2.3

Use Case Name: Communicate with Drivers

Actors: Admin

Description: Admin will communicate with Drivers

Trigger: Click on Contact button

Preconditions: Admin must be logged-in and a driver to which Admin wants

to communicate

Post conditions: Contact Successfully

Normal Flow: 1. Click on Driver

2. Select the way to communicate
3. Then Communicate
Alternative Flows: None

Exceptions: Communication failed

Includes: UC-1.1.3

Special Requirements: 1. Usability

2. Security

Assumptions: None

Notes and Issues: None

17
 Table 3.8 User login
Use Case ID: UC-1.3.1

Use Case Name: User login

Actors: Passengers, Drivers

Description: User will login into the system

Trigger: Click Login on the home screen

Preconditions:
User is authorized by the system
Post conditions: User logged-in successfully

Normal Flow: 1. Enter email

2. Enter Password
3. Click login button
Alternative Flows: None

Exceptions: User not exists in the system

Includes: None

Special Requirements: 1. Security

2. Reliability
Assumptions: None

Notes and Issues: None

18
 Table 3.9 Update Profile
Use Case ID: UC-1.3.2

Use Case Name: Update Profile

Actors: Admin, Passengers, Driver

Description: User can update her profile

Trigger: Click Update profile button

Preconditions:
User must be Logged-In
Post conditions: User Successfully enters the profile update screen

Normal Flow: 1. Click update profile button

2. Then update information which you want to update
3. And save
Alternative Flows: None

Exceptions: None

Includes: UC-1.3.1

Special Requirements: 1. Security

2. Usability
Assumptions: User knows how to update profile

Notes and Issues: None

19
 Table 3.10 Driver add picture
Use Case ID: UC-1.3.3

Use Case Name: Driver add picture

Actors: Driver

Description: Driver can add and her profile picture

Trigger: Click the picture button

Preconditions:
Driver must be logged-in
Post conditions: Picture added or changed successfully

Normal Flow: 1. Click on the picture

2. Select the picture
3. Select categories to whom picture is visible
4. Click save button
Alternative Flows: None

Exceptions: Driver adds the picture which is of very low resolution

Includes: UC-1.3.2

Special Requirements: 1. Usability

2. Security
Assumptions: None

Notes and Issues: None

20
 Table 3.11 Update Contact Information
Use Case ID: UC-1.3.4

Use Case Name: Update Contact Information

Actors: Passengers, Drivers

Description: User updates her contact information

Trigger: Click the Update Contact Information button

Preconditions:
User must be logged-in
Post conditions: Contact information Updated successfully

Normal Flow: 1. Click on Update Contact Information button

2. Enter phone number
3. Enter address
4. Click save button
Alternative Flows: None

Exceptions: User enters incorrect format or exceeds the phone number digits
limit

Includes: UC-1.3.2

Special Requirements: 1. Usability

2. Security
Assumptions: None

Notes and Issues: None

21
 Table 3.12 View Inbox messages
Use Case ID: UC-1.3.5

Use Case Name: View Inbox messages

Actors: Passengers, Drivers

Description: User can view her messages in inbox after she books her ride

Trigger: Click the inbox button

Preconditions:
User must be logged-in
Post conditions: User successfully view messages in her inbox

Normal Flow: 1. Click the inbox button

2. See the messages from driver
3. Drivers Sees the messages from passenger
4. And reply it
Alternative Flows: None

Exceptions: Message corrupted

Includes: UC-1.3.1

Special Requirements: 1. Usability

2. Security
3. Efficiency
Assumptions: None

Notes and Issues: None

22
 Table 3.13 View ride history
Use Case ID: UC-1.3.7

Use Case Name: View ride history

Actors: Passenger

Description: Passenger can view her previous rides

Trigger: Click the previous rides history button

Preconditions:
Passenger must be logged-in and successfully see her rides
Post conditions: Passenger successfully view the selected task history

Normal Flow: 1. Click the task history button

2. Select the task
3. Click view button
Alternative Flows: None

Exceptions: Passenger may not have ride history

Includes: UC-1.1.3

Special Requirements: 1. Usability

2. Security
Assumptions: None

Notes and Issues: None

23
 Table 3.14 Delete own account
Use Case ID: UC-1.3.8

Use Case Name: Delete account

Actors: Passenger, Driver

Description: User can delete her friend whenever she want

Trigger: Click Delete account button

Preconditions: User must be logged-in

Post conditions: Account deleted successful

Normal Flow: 1. Click the delete account button

2. Select Yes
Alternative Flows: None

Exceptions: None

Includes: UC-1.3.1

Special Requirements: 1. Usability

2. Security
3. Reliability
Assumptions: None

Notes and Issues: None

24
 Table 3.15 Search Ride
Use Case ID: UC-1.3.12

Use Case Name: Search ride

Actors: Passenger

Description: Passenger find ride according to the available cars

Trigger: Click Find ride button

Preconditions:
User must be logged-in
Post conditions: Ride found successfully

Normal Flow: 1. Click Find ride button

2. Available driver can accept ride
3. Communicate with driver
4. When driver reached, ride start.
Alternative Flows: None

Exceptions: Find no ride nearby

Includes: UC-1.3.1

Special Requirements: 1. Usability

2. Security
3. Reliability
Assumptions: None

Notes and Issues: None

25
 Table 3.16 Accept Ride
Use Case ID: UC-1.4.1

Use Case Name: Accept ride

Actors: Driver

Description: Driver accept ride of nearby passenger

Trigger: Click Accept ride button

Preconditions:
Driver must be logged-in
Post conditions: User successfully found the searched name

Normal Flow: 1. Ride request appears on screen

2. Accept ride of nearby passenger
3. Communicate with passenger to go the on a ride location
4. Go to the location pick passenger
5. Click start ride button
Alternative Flows: None

Exceptions: No ride request

Location of passenger is faraway

Includes: UC-1.3.1

Special Requirements: 1. Usability

2. Security
3. Reliability
Assumptions: None

Notes and Issues: None

26
 Table 3.17 Share Ride
Use Case ID: UC-1.4.1

Use Case Name: Share ride

Actors: Passenger

Description: Passenger can share its ride with any family member or friend.

Trigger: Click share ride button

Preconditions:
User must be logged-in
Post conditions: User successfully found the searched name

Normal Flow: 1. Click share ride button

2. Select the contact with whom want to share your
ride
3. Click on the share button
4. Ride shared

Alternative Flows: None

Exceptions: Sharing fail

No network

Includes: UC-1.3.1

Special Requirements: 5. Usability

6. Security
7. Reliability
Assumptions: None

Notes and Issues: None

27
3.2. ERD

Figure 2.2:ERD Diagram

28
3.3 CLASS DIAGRAM

Figure 3.3: Class Diagram

29
3.4 SEQUENCE DIAGRAM
Registration

Figure 3.4: Sequence Diagram Registration

30
Login

Figure 3.5: Sequence Diagram Login

31
Update Account

Figure 3.6: Sequence Diagram Update Account

32
Delete Account

Figure 3.7: Sequence Diagram Delete Account

Delete User

Figure 3.8: Sequence Diagram Delete User

33
Connection between driver and passenger

Figure 3.9: Sequence Diagram Connection

34
Logout

Figure 3.10: Sequence Diagram Login

35
3.5 ACTIVITY DIAGRAM

Register and login

Figure 3.11: Activity Diagram Register

36
Delete Account

Figure 3.12: Activity Diagram Delete Account

Delete User

Figure 3.13:Activity Diagram Delete User

37
Overall communication and network between Driver and Passenger

Figure 3.14:Activity Diagram Communication

38
Logout

Figure 3.15: Activity Diagram Logout

39
3.6 COMPONENT DIAGRAM

Figure 3.16: Component Diagram

40
3.7 DEPLOYMENT DIAGRAM

Figure 3.17: Deployment Diagram

3.8 CHAPTER SUMMARY

This chapter includes the design of the project its use cases, class diagram, activities
and sequences of the project modules of the project are designed and their flow is
designed in term of class, activity, sequence, use case and other diagrams.

41
 Chapter 4

PROJECT MANAGEMENT

4.1. MILESTONES

A project a milestone is a predictable state where a formal report of progress is

presented to management (supervisor).The project entitled as “Education Guide” is
divided into many milestones for the ease of achieving of the project within the time
limits. The project milestones are presented below:

Table 4.1: Project Milestones

Project Milestones Target Date

(DD/MM/YYYY)

Project start 1/1/2019

GUI 15/2/2019

Coding 20/5/2019

Admin Panel 15/6/2019

Documentation 27/3/2019

Documentation evaluation 28/4/2019

Complete working web system 22/6/2019

Testing 27/6/2019

Final Evaluation 09/7/2019

42
 Table 4.2: Project Closeout Reports

Title Activity Centric Social Network

Completed By Taqdees Habib
Abdul Moeez
Supervised By Sir Saif-Ur-Rehman
Examined By Ma’am Sidra and Sir Saleem Iqbal

Table 4.3: Project Deliverables

Deliverable Date Contingencies or conditions

Proposal Nov,2018

Requirement Dec,2019 Must meet requirement

Specification

Design 15 Jan,2019

Development 1 March,2019

Testing 30 May,2019 Testing properly

Code Review 30 Jun,2019

Complete 13Jul,2019 Document must meet Customer

Documentation Requirement

Complete Project 13 Jul,2019 Project should be in complete

running form, with its all modules
running perfectly.

43
 Table 4.4:Project Resources

Resource Person or Organization

(Describe or name the resource used) Who Received Resource

Project Team
Taqdees Habib UIIT
Abdul Moeez UIIT

Facilities
HP core i5 UIIT

Internet Service UIIT

Software Tools

Android Studio UIIT

Visual Studio 2015 UIIT

Fire Base Console UIIT

4.2. RISK MANAGEMENT

4.5.1 Introduction to risk management

Risk management ensures that developers identify and understand the risks which can
occur in their way. It also guarantees that developers should identify the ways to tackle
those risks. A project management plan is a type of document that a developer prepares
to foresee risks, estimate the schedule and prepare a solution for these future risks.
Good risk management should be as simple as answering these questions.

 What can go wrong?

 What will we do when anything wrong will happen?

4.5.2Purpose
The purpose of risk management is to identify potential problems before they occur so
that risk-handling activities may be planned and invoked as needed across the life of
the product or project to mitigate adverse impacts on achieving objectives. Risk
management is a continuous, forward-looking process that is an important part of
business and technical management processes. Risk management should address issues

44
that could endanger achievement of critical objectives. A continuous risk management
approach is applied to effectively anticipate and mitigate the risks that have critical
impact on the project. Effective risk management includes early and aggressive risk
identification through the collaboration and involvement of relevant stakeholders.
Strong leadership across all relevant stakeholders is needed to establish an environment
for the free and open disclosure and discussion of risk. Although technical issues are a
primary concern both early on and throughout all project phases, risk management must
consider both internal and external sources for cost, schedule, and technical risk. Early
and aggressive detection of risk is important because it is typically easier, less costly,
and less disruptive to make changes and correct work efforts during the earlier, rather
than the later, phases of the project.

4.5.3Risk Management Responsibilities

The roles and responsibilities of the risk management are

 Identification of risks before it occur

 Setting policy for risk management
 Building a risk aware culture within the organization
 Establishing internal risk policy and culture
 Designing and reviewing process for risk management
 Coordinating the various functional activities which advise on risk
management issues

Developing risk response processes including contingencies plan and preparing reports
on risk.

4.5.4 Risk Analysis

As before turnover the product a complete risk analysis is needed. In our product, we
have Technology, Organizational, Requirement and Estimation Risk. Technology Risk
may invoke as our system is not very good structured or strong to meet the changes.
Organizational risk occurs when the resources are very limited. Requirement risk can

45
also occur because as we are progressing in our project we are exposing new
requirements as well. Estimation risk can also occur as we have to work very hard for
meeting the deadline.

Table 4.5: Risk Analysis

Risk Name Probability Impact Level Impact

Risk
Of Description
#
Occurrence
Unavailability of Low No Internet The application
R#1
Internet Connection Connection won’t start
without internet
Connection
Data Duplication Moderate LAN is down Maintain the
R#2
Proper Module
More Requests Moderate Server Will be Recover the
R#3
Down System Within
Short Time

Table 4.6: Risk Response

Risk Risk Responsible

Priority Number Risk Name Person Mitigation Action(s)
1 RSK-01 Code Changes Supervisor White Box testing

2 RSK-02 Time Supervisor Deliver project on time

Scheduling with quality.

3 RSK-03 Design Supervisor User friendly layout.

changes

4 RSK-04 Requirements Supervisor Enhance the quality of

enhancements project.

46
 Chapter 5

IMPLEMENTATION

5.1. PROGRAMMING LANGUAGE

Android is a mobile operating system developed by Google. It is based on a

modified version of the Linux kernel and other open source software, and is
designed primarily for touchscreen mobile devices such as smartphones and tablets.
In addition, Google has developed Android TV for televisions, Android Autofor
cars, and Wear OS for wrist watches, each with a specialized user interface.
Variants of Android are also used on game consoles, digital cameras, PCs and other
electronics.

Initially developed by Android Inc., which Google bought in 2005, Android was
unveiled in 2007, with the first commercial Android device launched in September
2008. The current stable version is Android 9 "Pie", released in August 2018.
Google released the first beta of the next release, Android Q, on Pixel phones in
March 2019. The core Android source code is known as Android Open Source
Project (AOSP), which is primarily licensed under the Apache License.

Android is also associated with a suite of proprietary software developed by

Google, called Google Mobile Services (GMS), that frequently comes pre-installed
on devices. This includes core apps such as Gmail, the application store/digital
distribution platform Google Play and associated Google Play Services
development platform, and usually includes the Google Chrome web browser
and Google Search app. These apps are licensed by manufacturers of Android
devices certified under standards imposed by Google, but AOSP has been used as
the basis of competing Android ecosystems such as Amazon.com's Fire OS, which
use their own equivalents to Google Mobile Services.

Android has been the best-selling OS worldwide on smartphones since 2011 and on
tablets since 2013. As of May 2017, it has over two billion monthly active users, the
largest installed base of any operating system, and as of December 2018,
the Google Play store features over 2.6 million apps.

47
 5.2. FRAMEWORK

The android framework is the set of API's that allow developers to quickly and
easily write apps for android phones. It consists of tools for designing UIs like
buttons, text fields, image panes, and system tools like intents (for starting other
apps/activities or opening files), phone controls, media players, ect. Essentially an
android app consists of Activities (programs that the user interacts with), services
(programs that run in the background or provide some function to other apps), and
broadcast receivers (programs that catch information important to your app).

Table 5.1: System Requirements

Processor Not Specified

Installed Memory(RAM) Minimum 512 MBs.

Available Hard Disk Space Not Specified

Operating System Windows, or MAC

CD-ROM Drive or DVD Not Required

Displays Any devices i.e, laptop, mobile phones etc

Environment Web Browser i.e, Internet Explorer 10, Google

Chrome, Mozila Firefox

Pointing Device Mouse is required for PC users

Internet A good internet connection

5.4. CHAPTER SUMMARY

This chapter includes the design of the project its use cases, class diagram, activity and
sequences of the project modules of the project are designed and their flow is designed
in term of class, activity sequence use case and other diagrams.

48
 Chapter 6
SOFTWARE TESTING

6.1. DERIVING TEST

After completion of each phase verification was done. To verify the requirements, the
completed phase was fully tested. Against the requirements all the units were found to
be completely satisfactory. As the system should be verified at each stage of the
software process using documents produced during the previous stage therefore we
started verification with requirements reviews and continued through design and code
reviews to product testing. This is an activity to verify whether we have built the
system right or not in the development life cycle.

6.2. TEST ENVIRONMENT

The following elements are required to support the overall testing effort at all levels.
The “Activity-Centric Social Networks” is tested at university lab with the required
hardware and software requirement.

6.3. SOFTWARE

 OS windows 8 and upwords

 Android Studio
 Visual Studio
 Microsoft word 2010(for documentation)

6.4. HARDWARE

Table 6.1 Hardware Requirement

Server Client

Core I5 Core I5

RAM 4GB RAM 4GB

Local Area Network Local Area Network

49
6.5. TESTING IDENTIFICATION

A specific test is planned for every test level to test all system components. The test
procedure is designed in detailed so that the system meets all user requirements.

The system can be divided into following modules:

 Registration Users
 Login Users
 Uploading Pictures
 Booking Ride
 Accepting/ Rejecting Ride

6.6. TEST PROCEDURE

The following testing is done:

6.6.1 Unit Testing

The goal of unit testing is to separate each part of program and show that the individual
parts are correct. Unit testing provides a strict, written contract the piece of code must
satisfy. As a result, it affords several benefits. Unit testing allows the programmer to
refractor code at a later date, and make sure the module still works correctly. This
provides the encouragement to programmer to make changes to the code. Unit testing
will be done for the following units:

6.6.2 Make Connections

Testing this unit ensure that the application is successful connected to every module
and properly connected to perform the task in case valid connection information is
provided.

6.6.1.2 Registration
Testing of this unit will ensure that the rivers and passengers can successfully create
their profile to use the application.

50
6.6.1.3 Login
Testing of this unit will ensure that the driver and passengers can successfully login
to their accounts.

6.6.1.4 Book Ride

Testing of this unit will ensure that the passenger can successfully find the driver of
her route and book her ride.

6.6.1.5 Accept/Cancel request

Testing of this unit will ensure that the driver receives notification from passenger
and can accept or cancel request according to her own route.

6.6.2 Integrate Testing

Integration testing is the phase in software testing in which individual software
modules are combined and tested as a group. It occurs after unit testing and before
system testing. The test conducted to ensure that the components are integrated to
perform together.

 Integrate Login module and tested.

 Integration and testing of when content is added, removed, or update in area are
update successfully.
 Integration and testing of profile management module.
 Integration and testing of group creation module follows with add group member
to group and setting group dissolution date.
 Testing of application over different hardware
 Testing of application over different web browsers.

6.6.3 System Testing

System testing involves the set of tests that the entire system performs according to
specification. Every module of this system is functional and well connected.

6.6.4 Performance Testing

Performance testing can be applied to understand the application’s scalability and
stability.

51
6.7. TEST CASES

Test cases involve the set of steps, conditions and inputs which can be used while
performing the testing tasks. The main intent of this activity is to ensure whether the
software passes or fails in terms of its functionality and other aspects.

There are many types of test cases like: functional, negative, error, logical test cases,
physical test cases, UI test cases etc. A test is prepared for each test that needs to be
performed. The test cases result in the development of test reports, which will be used
for test output analysis.

Below are some of the test cases to verify the system functional abilities.

6.7.1 TEST CASE 1

Table 6.2 Test Case 1

Tested By: Abdul Moiz

Test Type: Unit Testing
Test Case Number: Test1
Test Case Name: Registration to application
Test Case Description: This test verifies that the user is registering
to the application with all required personal
data
Items To Be Tested
1. Personal data
2. Complete information
3. Password field
Specifications
Input Expected Output/Result
1. Specific username and password 1. Successfully registered message will
are given for registration. be displayed.

Procedural Step
1. Enter the required values
2. Click on the Register button

52
 Table 6.3 Test Case II

Tested By: Taqdees Habib

Test Type: Unit Testing
Test Case Number: Test2
Test Case Name: Login application
Test Case Description: This test verifies that the user is connected
properly to application.
Items To Be Tested
1. Connection of user to application
2. Login to application
3. User name and password fields
Specifications
Input Expected Output/Result
1. Tab to open the application on the 1. Application will show the user name
android phone and password fields.
2. Tab on log in button 2. Client login to app. To make changes.
Procedural Step
1. Open the android client application and log in through it.

Table 6.4: Test Case III

Tested By: Muhammad Adil

Test Type: Unit Testing
Test Case Number: Test3
Test Case Name: Profile Management
Test Case Description: This test verifies that the user can update
profile successfully.
Items To Be Tested
1. Connection of application.
2. Log in to application.
Specifications
Input Expected Output/Result
1. Click on timeline button. 1. User data entered to Database.
2. Fill the provided forms. 2. Message for update displayed.
Procedural Step
1. Open the application URL.

53
 Table 6.5 Test Case IV

Tested By: Taqdees Habib

Test Type: Unit Testing
Test Case Number: Test4
Test Case Name: Registered drivers Found
Test Case Description: This test verifies that the all registered
drivers can successfully show on map of
Passenger.
Items To Be Tested
1. Connection to application.
2. Log in to application.
Specifications
Input Expected Output/Result
1. Login to account and go to book a
ride button.
2. Click Find Drivers button. 1. Drivers shown successfully.
Procedural Step
1. Open the application URL.

Table 6.6: Test Case V

Tested By: Abdul Moiz

Test Type: Unit Testing
Test Case Number: Test5
Test Case Name: Accept or reject ride.
Test Case Description: This test verifies that the driver can Accept
or Cancel the ride successfully.
Items To Be Tested
1. Connection to application.
2. Log in to application.
3. Receive notification successfully.
Specifications
Input Expected Output/Result
1. Login to account. 1. Request receive.
2. Go on her dashboard. 2. Able to accept or cancel the
passenger’s request.
Procedural Step
1. Open the application URL.

54
 Table 6.7: Test Case VI

Tested By: Taqdees Habib

Test Type: Unit Testing
Test Case Number: Test6
Test Case Name: Passenger make request.
Test Case Description: Passenger is able to select and send ride
request to her suitable driver.
Items To Be Tested
1. Login to application.
2. Open Dashboard and driver.
Specifications
Input Expected Output/Result
1. Click to request a ride button after 1. Request sended successfully.
finding suitable driver.
Procedural Step
1. Request done.

6.8. CHAPTER SUMMARY

This chapter is about the testing the different phases of the project. We are applying the
known and unknown internal structure, design and implementation. We make a strong
testing by using the different testing processes like Unit testing, Integrated testing,
System testing etc.

55
 Chapter 7

CONCLUSION AND FUTURE WORK

7.1. DISCUSSION

There are so many application of pick and drop services and some ride sharing
applications are also online in foreign countries but there is no such ride sharing
application that is only for females. So we made a ride sharing application that is only
for females for their safety.

Girls that are working or start workings in offices and girls that is studying or starts
studying in university and colleges, convince is one of the main issue for them. To find
secure taxi or van and their parents are also very worried due to security of their young
girls; parents of kids are also very worried because of present condition of Pakistan’s
security and not able to trust anyone easily. So they don’t want to send their kids with
van or taxi drivers. In response to this problem, this ride-sharing application will have
solutions of all problems. Security problem will be solved due to female drivers. And
parents of kids and young girls will easily trust and be confident to send them with
female delivers.
Project will have two portals i.e. web and android app. Driver and passenger both will
have the permission to register or use both portals.
Girls that are using their own convince on daily bases to go offices, universities etc will
work as a driver in it. Driver will give their information like name, address, contact no.,
their route and timings and destination, and it will store on database. And passengers
are the girls that are working or start workings in offices and girls that is studying or
starts studying in university and colleges; convince is one of the main issue for them to
solve this issue we are going to design this app. Girls who want convince will search
for its suitable driver girl schedule and contact it through app and will set the time. And
payment can be on daily bases, on weekly or on monthly.
Payment will be divided between driver and company on the bases of satisfactory
percentage.
It will Secure, One tap solution and the biggest advantage; Extra income without over
time.

56
7.2. CONCLUSION

This document provides the complete information about the “Let’s share
Application” with the all details about its structure, interfaces, and some bit of
code.

7.3. LIMITATION

This system is limited to the core functionality which is discussed in detail all structure.
But the system can be taken to the higher level to make it complete and accurate
according to the demand of complete security for females.

57
 Chapter 8
SCREENSHOTS

58
59
60
61
62
63
64
65
66