ROADIE

Submitted by:
Names Registration No
Abdul Manan Khan 2018-UKT-006225
Saad Iqbal 2018-UKT-006239
Muhammad Anwar 2018-UKT-006242

Class:
BS SE (2018-22)

Supervised by:
Dr. Umair Khadim

Department of Software Engineering

Faculty of computing and engineering
 University of Kotli Azad Jammu and Kashmir
FINAL APPROVAL
It is certified that we have reviewed the project report prepared for “Roadie” and
it is our judgment that this project is of sufficient standard to warrant its acceptance
by the University of Kotli Azad Jammu and Kashmir for BS Software Engineering
as a partial fulfilment. This project is submitted by Abdul Manan Khan, registration
number 2018-UKT-006225, Saad Iqbal, registration number 2018-UKT-006239 and
Muhammad Anwar, registration number 2018-UKT-006242.
Committee

Supervisor
Mr. Umair Khadim
Lecturer
Department of Software Engineering Sign:_______________________
Faculty of Computing & Engineering
University of Kotli AJK

External Examiner

Dr. Muhammad Munwar Iqbal

Assistant Professor Sign:____________________
Department of Computer Science
University of Engineering and Technology (UET), Taxila,
Punjab Pakistan

Chairman
Mr. Umair Khadim
Lecturer
Department of Software Engineering Sign:_______________________
Faculty of Computing & Engineering
University of Kotli AJK

Dean
Prof. Dr. Ghulam Nabi
Faculty of Computing & Engineering Sign: ______________________
University of Kotli AJK
 DECLARATION
We declare that this system, neither as a whole nor as a part has been copied
from any other source. It is further declared that we have completed our project
entirely on the basis of our personal effort made under the sincere guidance of our
teachers. No portion of the work presented in this report has been submitted in
support of any application for any other degree or qualification of this or any other
university or institute of learning. If any part of this project and write up is proved to
be copied out or there is any duplication of code, then will be responsible for the
consequences.

Abdul Manan Khan: ______________

Saad Iqbal: ______________

Muhammad Anwar: ______________

 ABSTRACT
Our aim is to develop “Roadie" is a mobile based application system that will
serve as a ride service provider for everyday travellers. The idea is to pick up and
drop off the customer from and to their desired locations for the whole month after
they book ride only once a month. The report discusses, in detail, the problem area,
our proposed solution, target users, other such systems already installed and in use
followed by an in detail analysis and coverage of the methodology/architecture used,
milestones achieved and the future outlook of the project. This document presents the
design and implementation of a ride sharing application for a mobile environment. It
will enable users to share car rides in an efficient and simple way. Use of this system
should reduce significantly the number of private cars on the roads, providing
ecological, economical, and social benefits. The application is designed for "smart
phones", thus enabling implementation of the sharing in real time, from anywhere,
anytime. The application requires an algorithm for finding sub routes in a user-
defined path, according to the number of matched points along the path. This
application differs from the existing car sharing applications in several ways. The
article will describe both the system and the specific differences from other software.

iv
 ACKNOWLEDGEMENT
All the praise and glory to Allah, who has blessed us with the courage and
knowledge to achieve our goal. We can never thank Him enough for His countless
blessings upon us. Praise to Prophet Mohammad (S.A.W), who is and will always
be a source of guidance and knowledge for humanity as a whole.
For us, a mile stone of this nature would never have been possible to achieve
without the support of galaxy of some truly loving and kind people in our life. No
words can fully describe our feelings of respect and gratitude for our affectionate
parents, supporting sibling and friends, whose love, encouragement and prayers
invariably buoyed us up. Their concern, love and support can never be paid back.
We owe a lot of sincere gratitude to our respected supervisor Dr. Umair
Khadim, whose true guidance, positive criticism and sincere encouragement made
us to get to our destination. He became a source of inspiration for us and kept us
moving in the right direction towards our goal.

Abdul Manan Khan

Saad Iqbal
Muhammad Anwar

v
 PREFACE
This report presents a description of the analysis, design, implementation, and

testing of the "Roadie" developed as a ride service provider for everyday travellers.

These chapters include the steps involved in the study to develop; a brief description

of these chapters is given below:

Chapter 1: This chapter contains the introduction of the concerned organization and

the project

Chapter 2: This chapter contains the description of the requirements specification.

Chapter 3: This chapter is about system design.

Chapter 4: This chapter is about project management.

Chapter 5: This chapter is about implementation.

Chapter 6: This chapter is about system testing.

Chapter 7: This chapter is about Software Testing for the Measurements of Its

Correctness.

Chapter 8: This Chapter is about Conclusions, Limitations and Recommendations.

Chapter 9: This chapter is about Appendices and References.

vi
 TABLE OF CONTENTS
Final approval................................................................................................................ii
Declaration.....................................................................................................................ii
Abstract.........................................................................................................................iv
Acknowledgement..........................................................................................................v
Preface...........................................................................................................................vi
Chapter 1.......................................................................................................................1
1 Introduction.................................................................................................................1
1.1 Purpose.................................................................................................................1
1.2 How will it work...................................................................................................1
1.3 System Conception...............................................................................................1
1.3.1 Who is the application for?...................................................................................2
1.3.2 What problems will it solve?.................................................................................2
1.3.3 Where will it be used?...........................................................................................2
1.3.4 When is it needed?................................................................................................2
1.4 Software Process Model.......................................................................................2
Chapter 2.......................................................................................................................3
2 System Requirement Specification.............................................................................3
2.1 System Requirements Specification.......................................................................3
2.2 Functional Requirements......................................................................................3
2.3 Non-Functional Requirements..............................................................................4
2.3.1 Security Requirements..........................................................................................4
2.3.2 Software Quality Attributes..................................................................................5
2.3.3 Product Requirements...........................................................................................5
2.3.4 Organizational Requirements................................................................................5
2.3.5 External Requirements..........................................................................................6
2.4 System Features....................................................................................................6
2.4.1 User information...................................................................................................6
2.4.2 Response Sequences..............................................................................................7
2.4.3 System Architecture..............................................................................................7
2.4.4 System Evolution..................................................................................................7
2.5 Other Non-functional Requirements....................................................................7
2.6 Performance Requirements..................................................................................7

vii
 2.7 Safety Requirements.............................................................................................8
2.8 Security Requirements..........................................................................................8
2.9 Software Quality Attributes..................................................................................8
2.10 Business Rules....................................................................................................8
Chapter 3.......................................................................................................................9
3 System Design.............................................................................................................9
3.1 System Design......................................................................................................9
3.1.1 Class Model.........................................................................................................10
3.2 Class Diagram....................................................................................................10
3.3 Use Case Diagram..............................................................................................11
3.3.1 Login...................................................................................................................12
3.3.2 Logout.................................................................................................................12
3.3.3 Add order............................................................................................................13
3.3.4 Add car................................................................................................................14
3.3.5 Delete car............................................................................................................15
3.3.6 Notification.........................................................................................................16
3.4 Sequence Model.................................................................................................16
3.4.1 Scenarios.............................................................................................................17
3.4.2 Sequence Diagrams.............................................................................................17
3.4.3 Sequence Diagram for login................................................................................17
3.4.4 Sequence Diagram for Update records...............................................................18
3.4.5 Sequence Diagram for Log Out..........................................................................19
3.5 Activity Diagram................................................................................................19
3.5.1 Activity Diagram for Login................................................................................20
3.5.2 Activity Diagram for add Records......................................................................21
3.5.3 Activity Diagram for Registration......................................................................22
Chapter 4.....................................................................................................................23
4 Software Project Management..................................................................................23
4.1 Project Management Techniques.......................................................................23
4.2 Work Breakdown Structure for TSR..................................................................23
4.3 Gantt chart:.........................................................................................................23
4.3.1 Critical Path Method:..........................................................................................24
4.3.2 Activity on Node diagram...................................................................................25
4.3.3 Critical Path Method...........................................................................................25
viii
4.3.4 Paths....................................................................................................................25
4.3.5 Time Period:........................................................................................................25
4.4 Total Cost:..........................................................................................................26
4.5 Productivity........................................................................................................26
4.6 Resources we used..............................................................................................26
4.7 Hardware............................................................................................................26
4.8 Software..............................................................................................................27
Chapter 5.....................................................................................................................28
5 Project Implementation.............................................................................................28
5.1 Framework..........................................................................................................28
5.2 Hardware Requirements.....................................................................................28
5.3 Software Requirements......................................................................................29
Chapter 6.....................................................................................................................30
6 Software Testing.......................................................................................................30
6.1 Introduction........................................................................................................30
6.2 Psychology of Testing........................................................................................30
6.3 Testing Objective................................................................................................30
6.4 The Box Approach.............................................................................................30
6.4.1 White Box testing................................................................................................31
6.4.2 Black Box testing................................................................................................31
6.5 Levels of Testing................................................................................................32
6.6 Unit Testing........................................................................................................32
6.7 Integration Testing..............................................................................................32
6.8 System Testing...................................................................................................32
6.9 Alpha Testing.....................................................................................................33
6.10 Beta Testing......................................................................................................33
6.11 Acceptance Testing..........................................................................................33
6.12 Interface Testing...............................................................................................33
Chapter 7.....................................................................................................................34
7 Software Testing for the Measurements of Its Correctness......................................34
7.1 Testing................................................................................................................34
7.2 Development Testing..........................................................................................34
7.3 Unit Testing........................................................................................................35
7.4 Components Testing...........................................................................................35
ix
 7.5 System Testing...................................................................................................36
7.6 User Testing........................................................................................................36
7.7 Test Cases...........................................................................................................37
7.7.1 Test Case for Signup...........................................................................................37
7.7.2 Test Case for Login.............................................................................................38
7.7.3 Test case for Add, Update and Delete Record....................................................39
7.7.4 Test Case for Logout...........................................................................................39
Chapter 8.....................................................................................................................40
8 Conclusions, Limitations and Recommendations...............................................40
8.1 Conclusion..........................................................................................................40
8.2 Future Improvements..........................................................................................40
8.3 Limitations..........................................................................................................40
Chapter 9.....................................................................................................................41
9 Appendices and References......................................................................................41
9.1 Appendices.........................................................................................................41
9.2 Glossary..............................................................................................................41
9.3 References:.........................................................................................................41

x
 LIST OF FIGURES
Figure 1: Iterative Waterfall Process Model..................................................................2
Figure 2: Class Diagram of Roadie..............................................................................10
Figure 3: Use Case Diagram of Roadie........................................................................11
Figure 4: Sequence Diagram for Login........................................................................18
Figure 5: Sequence Diagram for Update Record.........................................................18
Figure 6: Sequence Diagram for logout.......................................................................19
Figure 7: Activity diagram for Login...........................................................................20
Figure 8: Activity Diagram for Add Records..............................................................21
Figure 9: Activity Diagram for Registration................................................................22
Figure 10: Gantt Chart.................................................................................................24
Figure 11: AON Network Diagram..............................................................................25
Figure 12: Critical Path Method...................................................................................25
Figure 13: White Box Testing......................................................................................31
Figure 14: Black Box Testing......................................................................................31

xi
 LISTS OF TABLES
Table 1: Use Case Description for User Login............................................................12
Table 2: Use Case Description for User Logout..........................................................12
Table 3: Use Case Description for add category..........................................................13
Table 4: Use Case Description for add car...................................................................14
Table 5: Delete Car......................................................................................................15
Table 6: Use Case Description for Notification...........................................................16
Table 7: Work Breakdown Structure...........................................................................23
Table 8: Network Table...............................................................................................24
Table 9: Hardware Requirement for Project................................................................28
Table 10: Software Requirements................................................................................29
Table 11: Test Case for Signup....................................................................................38
Table 12: Test Case for login.......................................................................................38
Table 13: Test case for Add, Update and Delete Record............................................39
Table 14: Test Case for Logout....................................................................................39
Table 15: Glossary.......................................................................................................41

xii
 Chapter 1
1 INTRODUCTION
This chapter describes the existing system and the proposed system in details.
What problems we were facing in the existing system, due to which we are going to
atomize our system, are described here? What functionality our system will provide,
is described here.

1.1 Purpose
The project is about ROADIE android app. The purpose of the project is to provide
an online services system to the users in their mobile phones. The system helps a lot
in business management and provides a convenient service in booking the cars.
Detailed listing and seamless online booking are the main features of the system for
easy usage. Customers can directly see the information about all the cars available.
With many advance vehicle rental software, user can also add some extra added
benefits and discounts to your customers.

1.2 How will it work

We are living in a modern Era where almost everything automated, but it is
not possible for everyone to afford automated system for a booking a car, the system
we are designing is less in price and affordable for everyone and can installed easily
in mobile phon.
Our project is mainly for the travellers. Moreover, people particularly the
newcomers to cities can also use the app for knowing the route and source to
destination cost by different transportation medium. Our system will cover all the
aspects of the existing manual system with some extra and advanced features
facilitating the targeted users.

1.3 System Conception

System conception deals with the genesis of an application. Initially some
person, who understands both business needs and technology, thinks of an idea for an
application. Developers must then explore the idea to understand the needs and devise
possible solutions. Most of the systems start as vague ideas that need more substance.
A good system concept must answer the following questions as our system does.

1
1.3.1 Who is the application for?
This application can be used for those who need affordable long distance ride.
That is to say, it is possible to reach a destination point faster or find a parking place .

1.3.2 What problems will it solve?

As this is app-based system that allows consumers to register and reserve
automobiles online while also allowing the firm to manage its car rental business
efficiently? To make the process of renting an automobile easier for consumers.

1.3.3 Where will it be used?

 This application can be used for those who need affordable long distance ride.
 That is to say, it is possible to reach a destination point faster or find a parking
place.
1.3.4 When is it needed?
Nowadays, there is Online Car Rental, which benefits users greatly. A rental
service is one where customers come to seek the rental of a rental unit. It is more
convenient than paying for the unit's ownership and maintenance. A car rental
company lends autos for a price for a few hours, a few days, or a week or more.

1.4 Software Process Model

2
 Software process model is an abstract representation of a software process, which
is a set of activities that leads to the production of a software product. Some of
the generic process models are waterfall model, evolutionary development and
component based software engineering. For this project we will follow iterative
waterfall process model, because of clear and unchanging business requirements as

shown in Figure 1.
Figure 1: Iterative Waterfall Process Model

Chapter 2
2 SYSTEM REQUIREMENT SPECIFICATION
2.1 System Requirements Specification
System requirements are more detailed descriptions of the software system’s
functions, services, and operational constraints. The system requirements document
(sometimes called a functional specification) should define exactly what is to be
implemented. It may be part of the contract between the system buyer and the
software developers.

2.2 Functional Requirements

These are statements of services the system should provide, how the system
should react to particular inputs, and how the system should behave in particular
situations. In some cases, the functional requirements may also explicitly state what
the system should not do. The functional requirements for a system describe what the
system should do.
This section describes the functional requirements of the system.
1. Login:
3
 Actors: user, driver and admin
Precondition: the user must be member of the system.

2. Logout:
Actors: user, driver and admin

3. Signup:
Actor: user and driver
Precondition: new user/ driver with new mail address is required.

4. Remind password:
Actor: user and driver
Precondition: the user/ driver must be a member of the system.

5. View user info:

Actor: user
Precondition: the user must be logged on to the system.

6. Update user info:

Actor: user
Precondition: the user must be logged on to the system.

7. View driver info:

Actor: driver
Precondition: the driver must be logged on to the system.

8. Update driver info:

Actor: driver
Precondition: the driver must be logged on to the system.

9. Payment:
Actor: user
Precondition: the user must be logged on to the system

10. Admin tool

Actor: admin
Precondition: the admin must be logged on to the system.
4
2.3 Non-Functional Requirements
Non-functional requirements are not directly concerned with the specific
services delivered by the system to its users. They may relate to emergent system
properties such as reliability, response time, usability and store occupancy.

Non-functional requirements, such as performance, security and availability

usually specify or constrain characteristics of a system as a whole. There are
following types of Non-functional requirements.

2.3.1 Security Requirements

A security requirement is a statement of needed security functionality that
ensures one of many different security properties of software is being satisfied.
Security requirements are derived from industry standards, applicable laws, and a
history of past vulnerabilities. No one can hack our system and control it.

2.3.2 Software Quality Attributes

A quality attribute, or a QA, is a measurable or testable property of a system
that is used to indicate how well the system satisfies the needs of its stakeholders. We
can do changes in our system according to need. We can work on it to make its
quality batter.

2.3.3 Product Requirements

These requirements specify or constrain the behaviour of the software.
Examples include performance requirements on how fast the system must execute and
how much memory it requires, reliability requirements that set out the acceptable
failure rate, security requirements, and usability requirements.

In our system minimal navigation through will make its performance better. It
is not an embedded system so memory is not a big issue for our system, as memory
has become very cheap now days. We are providing a user-friendly interface and our
system will be guiding the user at every step of performing some tasks. Our system
will be reliable as we are handling exceptions in our system. To deal security issues
we are using user name and password for security purposes.

5
2.3.4 Organizational Requirements
These requirements are broad system requirements derived from policies and
procedures in the customer’s and developer’s organization. Examples include
operational process requirements that define how the system will be used,
development process requirements that specify the programming language, the
development environment or process standards to be used, and environmental
requirements that specify the operating environment of the system.
For development we are using these tools:

Development Tools: Android Studio

Programming Language: Fire Base, CSS, Java & HTML (for App)

Arduino IDE: Originated from the IDE for the languages Processing and Wiring.
We are using Windows 10 as operating environment. Our app can be run on any
android operating system, because our app is attached with hardware system so it
cannot be hosted.
2.3.5 External Requirements
External Requirements are those Requirement elements that have been
connected to the current element using a Realization connector. By creating the
connector from the element to the Requirement, you create an expectation that the
element must implement the requirement as part of the system solution. It also
requirements specify hardware, software, or database elements with which a system or
component must interface.

2.4 System Features

Features are the “tools” you use within a system to complete a set of tasks or
actions. Functionality is how those features actually work to provide you with a
desired outcome. For example, a basic requirement for most boarding schools is the
ability to customise leave types. System Feature describe the system and how it will
function to help with a user’s task.

System Software include the following features.

High speed. System software must be as efficient as possible to provide an effective
platform for higher-level software in the computer system.
Hard to manipulate: It often requires the use of a programming language, which is
more difficult to use than a more intuitive user interface (UI).
6
Written in a low-level computer language: System software must be written in a
computer language the central processing unit (CPU) and other computer hardware
can read.
Close to the system: It connects directly to the hardware that enables the computer to
run.
Versatile: System software must communicate with both the specialized hardware it
runs on and the higher-level application software that is usually hardware-agnostic
and often has no direct connection to the hardware it runs on. System software also
must support other programs that depend on it as they evolve and change.

2.4.1 User information

The user must login or signup to the system for service confirmation with his
name, last name, CNIC, address, contact number, confirmation than proceed to
payment.

2.4.2 Response Sequences

The user can login or signup to the system after that the system will response to the
user for payment, confirmation of the service.

2.4.3 System Architecture

System architecture or systems architecture is the conceptual model that
defines the structure, behaviour, and more views of a system. An architecture
description is a formal description and representation of a system, organized in a way
that supports reasoning about the structures and behaviours of the system.

System architecture can comprise system components, the externally visible

properties of those components, the relationships (e.g. the behaviour) between them.
It can provide a plan from which products can be procured, and systems developed,
that will work together to implement the overall system. There have been efforts to
formalize languages to describe system architecture; collectively these are called
Architecture Description Languages (ADLs). [Blaha M, Rumbaugh J-2005]

2.4.4 System Evolution

This section describes the fundamental assumptions on which the system is
based, and any anticipated changes due to hardware evolution, changing user needs,
and so on. This section is useful for system designers as it may help them avoid

7
design decisions that would constrain likely future changes to the system.
[Sommerville-2009]

2.5 Other Non-functional Requirements

Non-functional requirements define system attributes such as security,
performance, safety. They serve as a constraints or restrictions on the design of the
system across the different backlogs.

2.6 Performance Requirements

The system must be interactive and the delays involved must be less. So, in
every action response of the system, there are no immediate delays. Performance
requirements define how well the software system accomplishes certain functions
under specific conditions. Examples include the software's speed of response,
throughput, execution time and storage capacity. The service levels comprising
performance requirements are often based on supporting end-user tasks

2.7 Safety Requirements

If there is extensive damage to a wide portion of the database due to
catastrophic failure, such as a disk crash, the recovery method restores a paste copy of
the database that was backed up to archival storage and reconstructs a more current
state by reapplying or reasoning the operations of committed transactions from the
backend-up log, up to time of failure.

2.8 Security Requirements

Security systems need database storage just like many other applications.
However, the special requirements of the security market mean that vendors must
choose their database partner carefully.

2.9 Software Quality Attributes

 Availability
 Maintainability
 Usability
 Correctness
 Reliability

8
2.10 Business Rules
For operating website, the user must familiar with web-based system and for
using android app user must have android operating system and should be familiar
with it. The admin can confirm user reserved service after checking user’s full details,
user can reserve services.

Chapter 3
3 SYSTEM DESIGN
3.1 System Design
Design is the first step in the development phase for any engineered product or
system. The designer’s goal is to produce a model or representation of a class that will
later be built. Beginning, once system requirement has been specified and analysed,
system design is the first of the three technical activities -design, code and test that is
required to build and verify software. This document details out the overall software
design.

The importance can be stated with a single word “Quality”. Design is the place
where quality is fostered in software development. Design provides us with
representations of software that can assess for quality. Design is the only way that we
can accurately translate a customer’s view into a finished software product or system.
Software design serves as a foundation for all the software engineering steps that
follow. Without a strong design, we risk building an unstable system that will be
difficult to test, one whose quality cannot be assessed until the last stage.

9
 During design, progressive refinement of data structure, program structure, and
procedural details are developed reviewed and documented. System design can be
viewed from either technical or project management perspective. From the technical
point of view, design is comprised of four activities – architectural design, data
structure design, interface design and procedural design.

The development team devise a high-level strategy, the system architecture, for
solving the application problem. They also establish policies that will serve as a
default for the subsequent, more detailed portions of design. The system designer
must decide what performance characteristics to optimize, choose a strategy of
attacking the problem, and make tentative resource allocations. For example, the
system designer might decide that changes to the workstation screen must be fast and
smooth, even when windows are moved or erased, and choose an appropriate
communications protocol and memory buffering strategy.

3.1.1 Class Model

The class diagram is the main building block of object oriented modelling. It is
used both for general conceptual modelling of the systematic of the application, and
for detailed modelling translating the models into programming code. Class diagrams
can also be used for data modelling. The classes in a class diagram represent both the
main objects, interaction in the application and classes to be programmed.
In the diagram, classes are represented with boxes which contain three parts.
• The upper part holds name of the class.
• The middle part contains the attributes of the class.
• The bottom part gives the methods or operations the class are take or
undertake.

After the identification of classes their attributes and the relationships among them
our class diagram is given above.

3.2 Class Diagram

10
 Class diagrams provide a graphic notation for modelling classes and their
relationships thereby describing possible objects. Class diagrams are useful both
abstract modelling and for designing actual programs. They are concise, easy to
understand, and work well in practice. We will use class diagrams throughout this
book to represent the structure of applications. Class diagrams are useful in many
stages of system design as shown in Figure 2.
Figure 2: Class Diagram of Roadie

Person
#firstName : string
#lastName : string
#gender : string Driver
#birthDate : Date
Message -license : string
#phone : int 1
-status : string
-body : string #email : string
-createdAt : Date * #password : string
-status1 : bool #signUpDate : int
-status2 : bool #token : string
+save() * #active : bool
+find() #profileImage : object Admin
+delete() #coverImage : object -lastLogin : int
+register() +Delete 0..1
+login() Account()
+viewAccount() Car
+searchAccount() -type : string
+deleteAccount() -model : int
-number : int
-rent : int
1 -seat : int
Customer
-nicNo : string -color : string
-address : string -status : string
Offer * *
-homePhone : int -image : object
-description : string +addCar()
-time : int +deleteCar()
+addOffer() 1 +viewCar()
+deleteOffer() JoinOffer
+viewOffer()
-reservedSeat : int *
+updateOffer()
-joinDate : int
*
-expense : int
1
+joinOffer()
Order
+cancelOffer()
-order_no : int
-bookingDate : Date
-locationTo : string
* -locationFrom : string
-goingTime : int
Comment 1 -quantity : int
-commentDis : string -amount : int
* *
-commDate : int -approved : bool
-driverStatus : bool *
+addComm()
Payment -offered : bool
+viewComm()
-mode : string -orderAt : int
-receiptNo : string +viewOrder()
-status : string +cacelOrder()
-amount : int +updateOrder()
-date : Date +approveOrder()
+addPay()
+viewPay()
+updatePay()

11
3.3 Use Case Diagram
A system involves a set of use cases and a set of actors. Each use case
represents a slice of the functionality the system provides. The set of use cases shows
the complete functionality of the system at some level of detail. Similarly, each actor
represents one kind of object for which the system can perform behaviour. The set of
actors represents the complete set of objects that the system can serve. Objects
accumulate behaviour from all the systems with which they interact as actors. This
system involves a set of use cases like make a login, add record, and detection as

shown in Figure 3.

12
 Figure 3: Use Case Diagram of Roadie
3.3.1 Login
This use case starts when an actor wishes to log into the System. The system
requests the actor to enter his/her details. The actor enters his/her name and password.
The system then validates the entered credentials and logs the actor into the system as
shown in Table 1.

Table 1: Use Case Description for User Login

Use Case Name Login

Summary Admin, driver and customer can login to his respective panels to
use his relative services.
Actor Administrator, driver and customer
Precondition The system is launched, and login pages are waiting to get login
details.
Post Condition After the successful login operation admin will be able to
navigate to his respective panels.
Description Administrator, driver and customer will provide email and
password so he can login in to their relative panels.
Exceptions Login validations: if user will provide wrong login information
Kashmir Tourist System will deny the access showing an error
message of invalid email or wrong password.

3.3.2 Logout
This use case starts when an actor wishes to log out of the System. The system
then performs the action of checking that which actor is wishing to logout from the
system by validating the credentials of that actor. The process is shown in Table 2.

Table 2: Use Case Description for User Logout

Use Case Name Logout

Administrator, driver and customer can logout to his respective
Summary
panels after using their relative services.
Actor Administrator, driver and customer
The system is launched, and administrator, driver and customer
Precondition
is having some RODIE System services form his respective
13
 panels.
After the successful logout operation admin, driver and customer
Post Condition will navigate to the home page of the system with general
services available for all.
Administrator, driver and customer will click on the “Logout”
Description button after completing their sessions; they’ll return the home
page of RODIE application.
Exit: if the administrator presses the exit or Alt+F4 before
Exceptions clicking on the “logout” button, system will be closed.

3.3.3 Add order

This use case starts when an actor wishes to add order into the System. The
actor enters his/her name and password. The system validates the entered name and
password and logs the actor into the system and then user placed the order as shown
in Table 3.
Table 3: Use case description for add category

Use Case Name Add order

Customer will login from the panel and then add a category basis
Summary
on the place type.
Actor Customer
The system will ask for login first, to enter home page and there
Precondition
should be add a category.
After adding a category, the system will be waiting for another
Post Condition category to be entered and also shown a message category added
successfully.
When customer login from his respective account they will go
Description the home page then select the Add order and then filling specific
fields and press the Add button to add order.
Wrong email or password: if the customer enters wrong
password or email the system will ask for valid email and
Exceptions
password.
Sing out: If customer press the log out button without adding

14
 category the system will return back to index form.
Back to Home: if the customer presses the back to home button
without adding category, system will return to home.

3.3.4 Add car

This use case starts when an actor wishes to add details into the System. The
system requests the actor to enter his/her name and password. The actor enters his/her
credentials. The system validates the entered name and password and logs the actor
into the system and then as shown in Table 4.

Table 4: Use case description for add car

Use Case Name Add car

Admin will login form the admin panel and then add a visiting
Summary place by selecting category with the title, description and images
etc.
Actor Admin
The system will ask for login first, to enter home page and there
Precondition
should be add a visiting place.
After adding a car, the system will be waiting for another
Post Condition visiting place item to be entered and also shown a message
category added successfully.
When admin login from his respective account they will go the
Description home page then select the Add car and then filling specific fields
and press the Add New Item button to add car.
Wrong email or password: if the admin enters wrong password
or email the system will ask for valid email and password.
Sing out: If admin press the log out button without adding place
Exceptions
the system will return back to index form.
Back to Home: if the admin presses the back to home button
without adding place, system will return to home.

15
3.3.5 Delete car
This use case starts when an actor wishes to log into the System. The system
requests that the actor enter his/her name and password. The actor enters his/her
credentials. The system validates the entered name and password and logs the actor
into the system and allows the actor to delete a car, as shown in Table 5.

Table 5: Delete car

Use Case Name Delete car

Admin will login form his respective panels and then he can
Summary
delete a car that submitted by him.

Actor Admin

The system will ask for login first, to enter home page and there

Precondition all visiting place will be display with an option to “Delete car”

for specific place that submitted by him.

Post Condition Message will be shown specific has been deleted successfully.

When admin login from his respective panel he will go the

Description home page then display the all places he can press the delete

button for delete a specific selected place.

Wrong email or password: if the admin enters wrong

password or email the system will ask for valid email and

password.

Canceled: if the admin presses the cancel button without

Exceptions deleting place the processing will be stopped.

Sing out: If admin presses the sign out button without deleting,

the system will return back to index form.

Back to Home: if the admin presses the back to home button

without deleting a place, system will return to home.

16
3.3.6 Notification
This use case starts when a person places an order for the cab, the person can
view and locate the cab with the notification bar of the device as shown in Table 6.

Table 6: Use case description for notification

Use Case Name Notification

User can view notification on place order detail with his
Summary
account. System will use the IP address to remember his name.
Actor Driver, customer
The system will not ask for login first to enter home page. User
Precondition can view a visiting place detail and then he will submit a
comment.
Post Condition Message will be shown comment has been submitted
successfully.
When user will see the visiting place at the visiting place page
then he can view all visiting places then open anyone place
Description
detail by clicking on view detail button to see detail of place the
he submit a comment on it.
Wrong email or password: if the admin enters a wrong
password or email the system will ask for valid email and
Exceptions
password. Sing out: If client/lawyer presses the sign out button
without comments, the system will return back to index form.
Back to Home: if the lawyer/client presses the back to home
button without comments, system will return to home.

3.4 Sequence Model

Sequence models are the machine learning models that input or output sequences of
data. Sequential data includes text streams, audio clips, video clips, time-series data
and etc. Recurrent Neural Networks (RNNs) is a popular algorithm used in sequence
models. The sequence model elaborates the themes of use cases. There are two kinds
of sequence models: scenarios and a more structured format called sequence
diagrams.

17
3.4.1 Scenarios
A scenario is a sequence of the events that occurs during one particular
execution of a system such as for a use case. The scope of a scenario can vary; it
may include all events in the system or it may include only those events impinging
on or generated by certain objects. A scenario can be the historical record of
executing an actual system or a thought experiment of executing a proposed
system. A scenario can be displayed as a list of text statements. A scenario contains
messages between objects as well as activities performed by objects. Each message
transmits information from one object to another.

3.4.2 Sequence Diagrams

A sequence diagram is a Unified Modeling Language (UML) diagram that
illustrates the sequence of messages between objects in an interaction. A sequence
diagram consists of a group of objects that are represented by lifelines, and the
messages that they exchange over time during the interaction. It is used primarily to
show the interactions between objects in the sequential order that those interactions
occur. Much like the class diagram, developers typically think sequence diagrams
were meant exclusively for them. A sequence diagram simply depicts interaction
between objects in a sequential order i.e. the order in which these interactions take
place. We can also use the terms event diagrams or event scenarios to refer to a
sequence diagram. It shows the participants in an interaction and the sequence of
message among them. A sequence diagram shows the interaction of a system with its
actor to perform all or part of a use case. Each use case requires one or more sequence
diagrams to describe its behaviour. Each sequence diagram shows a particular
behaviour sequence of the use case.

3.4.3 Sequence Diagram for login

A sequence diagram is a Unified Modelling Language (UML) diagram
consists of a group of objects that are represented by lifelines, and the messages that
they exchange over time during the interaction. It is used primarily to show the
interactions between objects in the sequential order that those interactions occur.
Much like the class diagram, developers typically think sequence diagrams were
meant exclusively for them. The Login sequence diagram shows the sequence of steps
required to login into the system. The system requests that the actor enter his/her

18
name and password. The actor enters his/her name and password. The system
validates the entered name and password and logs the actor into the system as shown
in Figure 4.

Figure 4: Sequence Diagram for Login

3.4.4 Sequence Diagram for Update records

The Update sequence diagram shows the sequence of steps required to update
data into the system. The system requests the actor to enter results. The actor enters
data. The system validates the data and update the information as shown in Figure 5.

Figure 5: Sequence Diagram for Update Record

19
3.4.5 Sequence Diagram for Log Out
The Logout sequence diagram shows the sequence of steps required to exit
from the system. The system requests that the actor enter his/her name and password.
The actor enters his/her name and password After that user will click on the log out
button they’ll be returned the Home Page of Roadie as shown in Figure 6.

Figure 6: Sequence Diagram for logout

3.5 Activity Diagram

Activity diagram is another important diagram in UML to describe dynamic
aspects of the system. Activity diagram is basically a flow chart to represent the flow
form one activity to another activity. The activity can be described as an operation of
the system. So, the control flow is drawn from one operation to another. Activity
diagrams represent workflows in a graphical way.

20
3.5.1 Activity Diagram for Login
An activity diagram shows the sequence of steps that make up a complete
complex process, such as an algorithm or workflow. An activity diagram shows flow
of control, similar to a sequence diagram, but focuses on operations rather than on
objects. Activity diagrams are most useful during the early stages of designing
algorithms and workflows as shown in Figure 7.

Figure 7: Activity diagram for Login

21
3.5.2 Activity Diagram for add Records
An activity diagram shows flow of control, similar to a sequence diagram, but
focuses on operations rather than on objects. Activity diagrams are most useful during
the early stages of designing algorithms and workflows. In this activity diagram user
add record into the system and system update the record as shown in Figure 8.

Figure 8: Activity Diagram for Add Records

22
3.5.3 Activity Diagram for Registration
An activity diagram shows the sequence of steps that make up a complete
complex process, such as an algorithm or workflow. An activity diagram shows flow
of control, similar to a sequence diagram, but focuses on operations rather than on
objects. Activity diagrams are most useful during the early stages of designing
algorithms and workflows. In this activity diagram user need to add details for
registration & then login into the system as shown in Figure 9.

Figure 9: Activity Diagram for Registration

23
 Chapter 4
4 SOFTWARE PROJECT MANAGEMENT
4.1 Project Management Techniques
Project management system helps your engineering team track every initiative. A
single system can manage every aspect of every project your engineering team is
executing. In Notion, all the project work lives side-by side deadlines and updates
saving you time bouncing between tools. Project management techniques involved
both of Gant Chart and Critical Path Methods. Both have different qualities and
importance which can be helpful in every project, these techniques are very helpful in
business purpose and many organizations. These techniques are,
 Gantt Chart
 Critical Path Method

4.2 Work Breakdown Structure for TSR

Work break down structure is that how we can work in our project. Basically
work breakdown structure helps us in our project and it is easy way too reached at our
target easily. The WBS for our project is given below in Table 7.

Table 7: Work Breakdown Structure

Level Activity
1 Idea
2 Research Work
3 SRS
4 Design Documentation
5 Progress Presentation
6 Implementation & Testing

4.3 Gantt chart:

A chart in which a series of horizontal lines shows the amount of work done or
production completed in certain periods of time in relation to the amount planned for
those periods. It is a visual description of a project's timeline. The chart shows the
start and end dates of a project's components, such as resources and planning. If you

24
are involved in a project, it is recommended to use a Gantt chart to help organize the
various tasks within the project. Roadie Gantt chart are shown in the Figure 10.

Figure 10: Gantt chart

4.3.1 Critical Path Method:
The critical path method (CPM) is a technique where you identify tasks that
are necessary for project completion and determine scheduling flexibilities. A critical
path in project management is the longest sequence of activities that must be finished
on time in order for the entire project to be complete. The critical path method (CPM)
is a technique that's used by project managers to create a project schedule and
estimate the total duration of a project. Critical Path Method for Roadie have activity,
description, immediate predecessor and activity of the project as shown in Table 8.

Table 8: Network Table

Activity Description Immediate Activity Time,

Predecessor Weeks
A Generation of Idea - 3 Weeks
B Research and related work- A 5 Weeks
study
C Making SRS B 4 Weeks
D Design Phase documentation C 5 Weeks
E Presentation of the Design B, C 2 Week
phase
F Implementation and Testing E 2 weeks

25
4.3.2 Activity on Node diagram
We can see how we can draw activity on node, that how the activity is drawn
on node from start to the point ‘F’ as shown in Figure 11.

Figure 11: AON Network Diagram

4.3.3 Critical Path Method
The Critical path method is that who is the largest of path in the project. The
critical path method for our project is given below Figure 13.

Figure 12: Critical Path Method

4.3.4 Paths
Two paths we can obtain in critical path method is given below,
A B C D E F = 35 Weeks
A B C E F = 30 Weeks

So ABCDEF is a critical path for this project.

4.3.5 Time Period:

This project will take 30 weeks to complete on normal.

26
4.4 Total Cost:
To find the total cost and effort involved we use the COCOMO model in this
project. As our TSR project contains about (2.5) KLOC, we will use the Organic
Mode.

Effort (E) = a x
(Size)b

Where a = 2.4, b
= 1.05 So,

Effort = 2.4 x (2.5) x1.05

E = 6.3 Staff Months
Development Time = 2.5 x (E) x 0.38

TDEV = 2.5 x (6.3) x 0.38

TDEV =4.5

TDEV = 5 months

4.5 Productivity
Productivity= Size / Effort
Productivity = 2.5 / 6.3 =
0.3968 Productivity = 0.4
LOC/Staff-month

Staff = Effort / TDEV

Staff = 6.3 / 5

Staff = 1.26 Staff members on average

4.6 Resources we used

The resources that we use in our project which included both the software and
hardware is given below.

4.7 Hardware
 Android Mobile
 Internet
27
4.8 Software
 Internet
 Android Studio
 HTML & CSS

28
 Chapter 5
5 PROJECT IMPLEMENTATION
We use Html, CSS, Firebase & Android Studio to do all the necessary tasks
and operations that are required to achieve the proposed solution of our project. We
are using Html & Firebase to develop application. By using this language, we are
doing interact with modules and implement other different modules.

5.1 Framework
The Android Framework is the entire stack of stuff that makes up the OS. This
is the underlying Native libraries that are not directly accessible, the layer above that
that you actually interact with and the code that developers write to run on the system.
The Android Framework is the entire stack of stuff that makes up the OS. This is the
underlying Native libraries that are not directly accessible, the layer above that that
you actually interact with and the code that developers write to run on the system. it
comprises of five levels, which are the Linux kernel, Libraries, Application
framework, Android runtime, and System applications.

5.2 Hardware Requirements

The hardware requirements are the requirements of a hardware device. Most
hardware only has operating system requirements or compatibility. These
requirements include the minimum processor speed, memory, and disk space required
to install Windows. In almost all cases, you will want to make sure that your hardware
exceeds these requirements to provide adequate performance for the services and
applications running on the server. For example, a printer may be compatible with
Windows XP but not compatible with newer versions of Windows like Windows 10,
Linux, or the Apple macOS. System requirements are the most effective way of
meeting the user needs and reducing the cost of implementation. System requirements
could cause a company to save a lot of money and time, and also can cause a
company to waste money and time as shown in Table 9.

Table 9: Hardware Requirement for project

Laptop For designing and developing applications, we need a laptop having

at least 4 gigabytes of RAM, 250 gigabytes HDD.

29
5.3 Software Requirements
A software requirements specification (SRS) is a document that describes what
the software will do and how it will be expected to perform. It also describes the
functionality the product needs to fulfil all stakeholders (business, users) needs. The
software requirements are description of features and functionalities of the target
system. Requirements convey the expectations of users from the software product.
The requirements can be obvious or hidden, known or unknown, expected or
unexpected from client's point of view as shown in Table 10.

Table 10: Software Requirements

Software Software Android studio.

Language 1: Java
2:Kotlin
3:XML
4:Groovy

30
 Chapter 6
6 SOFTWARE TESTING
6.1 Introduction
Software testing is a critical element of software quality assurance and
represents the ultimate review of specification, design and coding. In fact, testing is
the one step in the software engineering process that could be viewed as destructive
rather than constructive. As a secondary benefit, testing demonstrates that software
functions appear to be working according to the specification. Testing provides a
good indication of software reliability and some indication of software quality as a
whole. Testing cannot show the absence of defects, it can only show that software
defects are present finally we arrive at system testing and we tried our best to test
each individual module and also as an integrated module (as a whole) with sufficient
data that may an organization have, fulfilling the objective of our “Roadie”.

6.2 Psychology of Testing

The aim of testing is often to demonstrate that a program works by showing
that it has no errors. The basic purpose of testing phase is to detect the errors that
may be present in the program. Hence one should not start testing with the intent of
showing that a program works, but the intent should be to show that a program
doesn’t work. Testing is the process of executing a program with the intent of finding
errors.

6.3 Testing Objective

Objective of testing is to find maximum errors in the software. So, a good testing
strategy is the one with high potential of finding errors and bugs.
 Testing is a process of executing a program with the intent of finding an error.
 A successful test is one that uncovers an as yet undiscovered error.
 A good test case is one that has a high probability of finding error, if it exists.
 The tests are inadequate to detect possibly present errors.
 The software more or less confirms to the quality and reliable standards.

31
6.4 The Box Approach
Traditionally software testing methods are divided into white- and black-box
testing. These two approaches describe the point of view of test designer.

6.4.1 White Box testing

White-box testing, also known as clear box testing, and glass box testing
which tests internal workings of a program, instead of the functionality. In white-box
testing detailed internal perspective of the system, as well as programming skills, are
used to design test cases. I tested step wise every piece of code, taking care that
every statement in the code is executed at least once as shown in Figure 13.

Figure 13: White Box Testing

6.4.2 Black Box testing
Black-box testing treats the software as a "black box", examining
functionality without any knowledge of internal software workings. The tester is only
aware of what the software is supposed to do, not how it does it, tester only knows
the input and output and nothing more as shown in Figure 14.

32
 Figure 14: Black Box Testing

6.5 Levels of Testing

In order to uncover the errors, present in different phases we have the concept of
levels of testing. The basic levels of testing are as shown below
 Unit Testing
 Acceptance Testing
 System Testing
 Integration Testing

6.6 Unit Testing

Unit testing focuses verification effort on the smallest unit of software i.e. the
module. Using the detailed design and the process specifications testing is done to
uncover errors within the boundary of the module. All modules must be successful in
the unit test before the start of the integration testing begins. In this application we
test the programs up as system. Unit testing is first done on modules, independent of
one another to locate errors. This enables to detect errors.
All components of our project were tested with driven programs. Even each
function was tested individually using the test cases which are described at the end of
chapter.

33
6.7 Integration Testing
After the unit testing, we have to perform integration testing. The goal here is
to see if modules can be integrated properly, the emphasis being on testing interfaces
between modules. This testing activity can be considered as testing the design and
hence the emphasis on testing module interactions.
In this project integrating all the modules forms the main system. When
integrating all the modules we have checked whether the integration effects working
of any of the services by giving different combinations of inputs. All modules were
collected and integrated to each other and results of each test were up to the mark.

6.8 System Testing

After testing each module and getting the expected results, here the modules are
integrated to make sure that the application is well supporting its features. As a
standalone application, its results are according to requirements, as expected. The
application runs smoothly when executed.
 Application is reliable and less prone to crash.
 Application is capable enough to meet all the requirements of users.
 The application is easy to maintain.
 The application is fast and takes less memory space.
 The application is easily usable by the intended user.
 Application is easy to access when needed by user.

6.9 Alpha Testing

Alpha testing is specially used by product development organizations.
Developers observe the users and note problems. Alpha testing is testing of an
application when development is about to complete. Minor design changes can still
be made as a result of alpha testing.
During alpha testing of our project we find following minor errors and solve them
such as,
 Broken links
 Spelling mistakes

34
6.10 Beta Testing
Beta Testing is conducted at the client’s place i.e. outside the organization. In
Beta testing, developer is not present while testing as it is tested at client’s side. Here,
customer records all the errors and other issues encountered during this testing and
reports to the developer.

6.11 Acceptance Testing

Acceptance Test is performed with realistic data of the client to demonstrate
that the software is working satisfactorily. Testing here is focused on external
behaviour of the system, the internal logic of program is not emphasized.

6.12 Interface Testing

The system has been tested at interface level. The interface is tested to make
sure that the form, menus, text boxes and buttons are operational and everything is
displayed according to the requirement.

Chapter 7
7 SOFTWARE TESTING FOR THE MEASUREMENTS
OF ITS CORRECTNESS
7.1 Testing
Testing is intended to show that a program does what it is intended to do and
to discover program defects before it is put into use. When you test system, you
execute a program using artificial data. You check the results of the test run for errors,
anomalies, or information about the programs non-functional attributes.
The testing process has two distinct goals:
To demonstrate the developer and the customer that the system meets its
requirements. For custom software this means that there should be at least one test for
every requirement in the requirements document. For generic software products, it
means that there should be tests for all the system features, plus combination of these
features, that will be incorporated in the product release.

35
 To discover situation in which the behaviour of the system is incorrect,
undesirable, or does not conform to its specification. There are consequences of
system defects. Defects testing is concerned with rooting out undesirable system
behaviour such as system crashes, unwanted interactions with other systems, incorrect
computations and data corruption.

7.2 Development Testing

Development testing includes all testing activities that are carried out by the
team developing the system. The tester of the software is usually the programmer who
developed that software, although this is not always the case. Some development
processes use programmer/tester pairs (Cusamano and Selby, 1998) where each
programmer has an associated tester who develops tests and assists with the testing
process. For critical systems, a more formal process may be used, with a separate
testing group within the development team. They are responsible for developing tests
and maintaining detailed records of test results.
During development, testing may be carried out at three levels of granularity:
• Unit testing, where individual program units or object classes are tested. Unit
testing should focus on testing the functionality of objects or methods.
• Component testing, where several individual units are integrated to create
composite components. Component testing should focus on testing component
interfaces.
System testing, where some or all of the components in a system are integrated and
the system is tested as a whole. System testing should focus on testing component
interactions.
Development testing is primarily a defect testing process, where the aim of
testing is to discover bugs in the software. It is therefore usually interleaved with
debugging the process of locating problems with the code and changing the program
to fix these problems.

7.3 Unit Testing

Unit testing is the process of testing program components, such as methods or
object classes. Individual functions or methods are the simplest type of component.
Your tests should be calls to these routines with different input parameters.

36
When you are testing object classes, you should design your tests to provide
coverage of all of the features of the object. This means that you should:
• Test all operations associated with the object;
• Set and check the value of all attributes associated with the object;
• Put the object into all possible states. This means that you should simulate all
events that cause a state change.

7.4 Components Testing

Software components are often composite components that are made up of
several interacting objects. For example, in the weather station system, the
reconfiguration component includes objects that deal with each aspect of the
reconfiguration. You access the functionality of these objects through the defined
component interface. Testing composite components should therefore focus on
showing that the component interface behaves according to its specification. You can
assume that unit tests on the individual objects within the component have been
completed.

7.5 System Testing

System testing during development involves integrating components to create
a version of the system and then testing the integrated system. System testing checks
that components are compatible, interact correctly and transfer the right data at the
right time across their interfaces. It obviously overlaps with component testing but
there are two important differences:
During system testing, reusable components that have been separately
developed and off-the-shelf systems may be integrated with newly developed
components. The complete system is then tested.
Components developed by different team members or groups may be
integrated at this stage. System testing is a collective rather than an individual
process. In some companies, system testing may involve a separate testing team with
no involvement from designers and programmers.

7.6 User Testing

User or customer testing is a stage in the testing process in which users or
customers provide input and advice on system testing. This may involve formally

37
testing a system that has been commissioned from an external supplier, or could be an
informal process where users experiment with a new software product to see if they
like it and that it does what they need. User testing is essential, even when
comprehensive system and release testing have been carried out. The reason for this
is that influences from the user’s working environment have a major effect on the
reliability, performance, usability, and robustness of a system.
It is practically impossible for a system developer to replicate the system’s
working environment, as tests in the developer’s environment are inevitably artificial.
For example, a system that is intended for use in a hospital is used in a clinical
environment where other things are going on, such as patient emergencies,
conversations with relatives, etc. These all affect the use of a system, but developers
cannot include them in their testing environment.
In practice, there are three different types of user testing:
• Alpha testing, where users of the software work with the development team to
test the software at the developer’s site.
• Beta testing, where a release of the software is made available to users to
allow them to experiment and to raise problems that they discover with the
system developers.
• Acceptance testing, where customers test a system to decide whether or not it is
ready to be accepted from the system developers and deployed in the customer
environment.

7.7 Test Cases

A test case is a singular set of actions or instructions for a tester to perform
that validates a specific aspect of a product or application functionality. If the test
fails, the result might be a software defect that the organization can triage. Testing is
expensive and time consuming, so it is important that you choose effective unit test
cases. Effectiveness, in this case, means two things:

The test cases should show that, when used as expected, the component
that you are testing does what it is supposed to do. If there are defects in the
component, these should be revealed by test cases. You should therefore write two
kinds of test case. The first of these should reflect normal operation of a program and
should show that the component works. For example, if you are testing a component

38
that creates and initializes a new patient record, then your test case should show that
the record exists in a database and that its fields have been set as specified. The
other kind of test case should be based on testing experience of where common
problems arise. It should use abnormal inputs to check that these are properly
processed and do not crash the component. [Sommerville-2009]

Test cases are built around specifications and requirements, i.e., what the
application is supposed to do. Test cases are generally derived from external
descriptions of the software including specification specifications requirements and
design parameters. The test designer determines input, output and possible flow of
events.

7.7.1 Test Case for Signup

The Sign Up test case test the ask the User to sign up first and then login to
become a Registered User. This allows the User to gain access to the system features
as shown in Table 11.
Table 11: Test Case for Signup

ID 01
Name Signup
Brief Description Used to sign-up to the system
Expected Input Signup name, Email and password
Expected flow of 1. Enter Name 2. Enter Email 3.Enter Password 4.Press
events Sign-up button.
Alternate flow of 1. Invalid Information added, or Email already exist 2.
events Error message displayed to admin.
Pre-Condition None
Post-Condition signed in
Actor Admin
Status Pass

7.7.2 Test Case for Login

This login test case tests when an actor wishes to log into the System. The
system requests that the actor enter his/her name and password. The actor enters

39
his/her credentials. The system validates the entered name and password and logs the
actor into the system as shown Table 12.

Table 12: Test case for login

ID 02
Name Login
Brief Description Used to login to the system
Expected Input Login Email password
Expected flow of events 1. Enter Email 2. Enter password 3.press ”Login”
Alternate flow of events 1. Invalid login Email or password 2. Error
message displayed to admin.
Pre-Condition None
Post-Condition Logged in
Actor Admin
Status Pass
7.7.3 Test case for Add, Update and Delete Record
The Add, update or delete record test case the User to view the final results.
When the User accesses the system feature that enables to create an account by
entering information that is maintained in the record as shown in Table 13.

Table 13: Test case for Add, Update and Delete Record

ID 03
Name Add, Update and Delete Record
Brief Description Admin will add, update and delete record from the database.
Expected Input Add, Update and Delete Record
Expected flow of Admin will add, update and delete the record, System will
events store it in database.
Pre-Condition Must login
Post-condition Record will be added, updated and deleted successfully
Actor Admin
Status Pass

40
7.7.4 Test Case for Logout
The Logout test case tests the User to logout of the system after using their
relative services. User will click on the log out button after completing their sessions;
they’ll be returned the Home Page of Roadie as shown in Table 14.

Table 14: Test case for Logout

ID 06
Name Logout
Brief description Admin
Expected flow of events Admin logout of FDR by clicking Logout button,
System will take the user to logout page.
Pre-condition Must login
Actor Admin
Status Pass

Chapter 8
8 CONCLUSIONS, LIMITATIONS AND
RECOMMENDATIONS
8.1 Conclusion
Our aim is to develop “Roadie" is a mobile based application system that will
serve as a ride service provider for everyday travellers. The idea is to pick up and
drop off the customer from and to their desired locations for the whole month after
they book ride only once a month. The chosen platform is Android, which will work
in assistance with Google Maps API to make the app location aware. The report
discusses, in detail, the problem area, our proposed solution, target users, other such
systems already installed and in use followed by an in detail analysis and coverage of
the methodology/architecture used, milestones achieved and the future outlook of the
project.

8.2 Future Improvements

In recent years with the help of mobile phones, we can perform many
functions. In comparison to previous experiences, when every activity related to the

41
vehicle rental business was restricted to a physical place alone, the car rental industry
has emerged with new delicacies. Even if the physical location has not been
completely eliminated, the internet's power has altered the nature of functions and
how these tasks are accomplished. Customers may now book vehicles online, rent
automobiles online, and have the car delivered to their home if they are a registered
member, or they can travel to the office to pick up the car.

8.3 Limitations
 Limited to short distance
 Complex installation.
 Cost effective

Chapter 9
9 APPENDICES AND REFERENCES
9.1 Appendices
These should provide detailed, specific information that is related to the
application being developed; for example, hardware and database descriptions.
Hardware requirements define the minimal and optimal configurations for the system.
Database requirements define the logical organization of the data used by the system
and the relationships between data. [Sommerville-2009].

9.2 Glossary
An alphabetical list of words relating to a specific subject, text, or dialect, with
explanations a brief dictionary. It is a list of some of the words found in the book and
what they mean. It is found at the end of a book. A glossary sometimes includes
pictures that explain some of the words as shown in Table 15.

Table 15: Glossary

42
 IEEE Institute of Electrical and Electronics Engineering

SRS Software requirements specification

SDLC Software development life cycle

GPS Global positioning system

ROM Read Only Memory

RAM Random Access Memory

GB Giga Byte

9.3 References:
[1]Sommerville-2009] Sommerville I. (2009). Software Engineering. United States
of America. Boston Massachusetts. Pearson Education.

[2] Balaha M, Rumbaugh J-2005] Balaha M, Rumbaugh J. (2005). Object Oriented

Modelling and Design with UML 2.0: UML2. State of India. Noida.Dorling
Kindersley (India) Pvt. Ltd.

[3] http://en.wikipedia.org/wiki/systemsarchitectures

[4] https://www.youtube.com/watc?v=hN9xemJYwos

[5] http://www.omg.org/spec/UML/2.0/

43