0% found this document useful (0 votes)
196 views50 pages

Parkey Project 2019: Brikelda Liçaj Elisa Pashku Sara Mboqe Xhemal Kodragjini

The document provides an overview of the ParKey project, which aims to create a network between drivers to help reduce parking problems in major cities. It does this through an AI parking assistant named Vinny, which coordinates and guides drivers to alternative parking options using voice recognition. The document outlines the problem statement, proposed solution, novelty, and responsibility levels of the project members. It also provides details on the requirements analysis, planning, implementation, and testing phases of the project.

Uploaded by

elisa
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
196 views50 pages

Parkey Project 2019: Brikelda Liçaj Elisa Pashku Sara Mboqe Xhemal Kodragjini

The document provides an overview of the ParKey project, which aims to create a network between drivers to help reduce parking problems in major cities. It does this through an AI parking assistant named Vinny, which coordinates and guides drivers to alternative parking options using voice recognition. The document outlines the problem statement, proposed solution, novelty, and responsibility levels of the project members. It also provides details on the requirements analysis, planning, implementation, and testing phases of the project.

Uploaded by

elisa
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 50

ParKey Project

2019

Brikelda Liçaj
Elisa Pashku
Sara Mboqe
Xhemal Kodragjini
2

TABLE OF CONTENTS
Table of Figures ................................................................................................................................................. 3
Glossary of Terms .............................................................................................................................................. 5
1. INTRODUCTION ..................................................................................................................................... 6

1.1 PROBLEM STATEMENT ................................................................................................................................... 6


1.2 PROPOSED SOLUTION ..................................................................................................................................... 6
1.3 NOVELTY ..................................................................................................................................................... 6
1.4 RESPONSIBILITY LEVELS ................................................................................................................................ 7

2. REQUIREMENTS ANALYSIS .................................................................................................................. 8

2.1 MARKET REQUIREMENTS ............................................................................................................................... 8


2.2 SYSTEM REQUIREMENTS ................................................................................................................................. 8
2.3 USER INTERFACE (CUSTOMER-DESIGNED) ...................................................................................................... 10
2.4 STAKEHOLDERS .......................................................................................................................................... 11
2.5 KICK-OFF MEETING ...................................................................................................................................... 12
2.6 BUSINESS CASE ........................................................................................................................................... 13

3. PLANNING ............................................................................................................................................. 15

3.1 PLANNING KICK-OFF MEETING ...................................................................................................................... 15


3.2 UML DIAGRAM .......................................................................................................................................... 16
3.2.1 Activity Diagram ................................................................................................................................ 16
3.2.2 State Diagram .................................................................................................................................... 17
3.2.3 Sequence Diagram .................................................................................................................................. 18

4. IMPLEMENTATION .............................................................................................................................. 21

4.1 PRE-CODING ESSENTIALS (REQUIREMENTS) ................................................................................................... 22


4.2 DATABASE DESCRIPTION .............................................................................................................................. 24
4.3 SYSTEM CODE ............................................................................................................................................. 26

5. TESTING ................................................................................................................................................ 36
3

Table of Figures
Figure 1. Client Interface request ............................................................................................... 10
Figure 2. Activity Diagram ....................................................................................................... 16
Figure 3. State Diagram ............................................................................................................ 17
Figure 4. Sequence Diagram...................................................................................................... 18
Figure 5. Sequence Diagram...................................................................................................... 19
Figure 6. Sequence Diagram...................................................................................................... 20
Figure 7. ER MODEL .............................................................................................................. 24
Figure 8. ER MODEL 2 ............................................................................................................ 25
Figure 9. App design ................................................................................................................ 34
Figure 10. Class Diagram .......................................................................................................... 35
Figure 11 Unit testing ............................................................................................................... 37
4

Table 1 Responsibilities ........................................................................................................................... 7


Table 2 Functional Requirements ............................................................................................................ 8
Table 3 Non-functional requirements ...................................................................................................... 9
Table 4 Stakeholders .............................................................................................................................. 11
5

Glossary of Terms

Application (App): a software program designed to perform specific functions for a user.

Coupon: a ticket or document that can be redeemed for a financial discount or rebate when purchasing

a product.

Customer: a person or organization that buys goods or services from a store or business. It this report,

the customer is the person using the application.

Customer account: a user account to access the application as a consumer that allows them to reserve

parking spots and use the features of the system.

Database: a structured set of data stored on the ParKey network, certain parts of which are accessible

to certain user accounts.

QR Code: is the trademark for a type of matrix barcode (or two-dimensional barcode. In this report,

the QR code is used for customers to confirm having received the coupon)

Rating: A position or standing of something, such as the popularity of drivers or businesses.

User interface: the visual aspect of the android application on the user’s phone that allows user

interaction with the system.


6

1. INTRODUCTION
1.1 Problem Statement
More and more the traffic is increasing in our city, creating chaos, air and acoustic pollution, and
citizen frustration. Furthermore, parking areas are limited. There is no structure or entity to organize
the placement of vehicles in parking spots.

1.2 Proposed Solution


ParKey solves finding parking in cities, by reducing the time, fuel and stress it takes users to find
parking on their own. It improves the current way of doing things by creating a drivers’ network to
improve traffic efficiency.

1.3 Novelty
ParKey aims to create a network of connected mobility between drivers to reduce the parking problems
in major cities. Using an AI Parking Assistant, Vinny, the intermediate coordinator between
anonymous drivers, Vinny coordinates and guides drivers through voice recognition to alternative
parking options with the all-in-one access to finding parking availability in the cities. ParKey
introduces a unique GPS Navigational experience, redirecting a driver’s focus on safety, traffic
efficiency and organized correlations engaging drivers in a stress-free parking experience.
7

1.4 Responsibility levels

No. Member Responsibilities

Business Case
User interface
State diagram
1 Brikelda Licaj
Database description & ER Model 1
Unit Testing
List of Prioritized Risks
Stakeholders
Sequence diagram – searching
Pre-coding essentials
2 Elisa Pashku
System code
Acceptance Testing
Lessons Learnt Report
Requirements analysis
Kick-off meetings
Activity diagram
3 Sara Mboqe
Sequence diagram – login
Integration Testing
Class diagram
Introduction
Sequence diagram – parking in/out
Project presentation
4 Xhemal Kodragjini
ER Model 2
Design elements of the app
Testing Design & Conclusion

Table 1 Responsibilities
8

2. REQUIREMENTS ANALYSIS

2.1 Market Requirements


The market needs a solution to reduce the traffic so that the citizens feel less stressed and frustrated.
Drivers have always been looking for an organized and structured system of parking areas.

2.2 System requirements

Identifier Priority Requirement


REQ-1 5 The application shall allow users to log in.
The application allows users to search for free parking
REQ-2 5
spots.
The application will rate the users based on app usage
REQ-3 3
frequency.
The application should access the GPS location of the
REQ-4 5
user.
The application should offer options for other parking
REQ-5 3
spots, not near to the driver location.
The application must classify the parking areas, based on
REQ-6 2
their distance from the driver.
The application shall allow the user to park out, in order
REQ-7 4
to free spaces.
The application should update the database every time a
REQ-8 5
parking spot is picked or freed.

Table 2 Functional Requirements


9

Identifier Priority Requirement


The application should have a high mean time between
REQ-9 5 failure and high meant time to recovery to ensure
reliability.
REQ-10 4 The application should be intuitive and easy to use.
REQ-11 3 The voice of Vinny should be clear and pleasant.
The application should look aesthetically pleasing and
REQ-12 2
modern
The application should have minimal transitions from
REQ-13 4
each screen/action.
The application should be designed to handle an
REQ-14 3 overestimated number of users for consistent throughput
and availability.
The application should be designed to make updates and
REQ-15 2
fixes easy to implement

Table 3 Non-functional requirements


10

2.3 User Interface (Customer-designed)

Figure 1. Client Interface request

Customer:

1. This is the first page that appears when I open the app. There is the logo of ParKey and the
version of the app.
2. In the second page I can read all the legal information, permissions, conditions and accept
them.
3. Here I can see the map with all the necessary details, including the option to park in or park
out. There is also an Options tab.
4. When I press Park in / Park out, this page appears. I login with my personal ID or password.
Other people who are using the app for the first time can register by clicking Sign Up. You can
use Facebook or Google + to login also.
11

2.4 Stakeholders

Name Position Internal/ Project Role Contact Information


External
Users of the -drivers I A person who will use our Contacted through
software software to find free social media and other
parking spaces methods of digital and
traditional marketing
government -planning E -Provide authorization for Direct meetings in the
officers, this project municipality
-transport -Provide different
planners documents (ex. maps or
statistics)
developers of -software I -Plan the technical steps Constant meetings
the software developers, and features of the project during the production
-programmers, -Code the software of the software
-graphic -Design the foreground of
designers the software to be as user-
friendly as possible
the company I -Fund the project and Will be contacted
provide specifications or mostly at the first phase
desired features for the when we will get the
final product requirements, but also
-Receive monetary profits during the process of
at the end production
non-users -pedestrians, E -Support the product and Will get the feedback
living in the -cyclists, get indirect benefits through forms,
city -public questionnaires etc.
transport users
competitors other E -After analysing their Find information
companies products, we can use their online from their
offering the good sides and not follow websites
same service their bad aspects
third parties -Google Earth E They will contribute with Will be contacted
-shops which their services through social media
will provide and direct meetings
their services
for the coupons
Table 4 Stakeholders
12

2.5 Kick-off meeting

Meeting Objective: Get the project off to a great start by introducing key stakeholders, reviewing
project goals, and discussing future plans

Agenda:

• Introductions of attendees

• Background of project

• Review of project-related documents (i.e. business case, project charter)

• Discussion of project organizational structure

• Discussion of project scope, time, and cost goals

• Discussion of other important topics

• List of action items from meeting

Short description:

The attendees were introduced to the project. Issues and restrictions of the app were discussed, tasks
were given to the members of the team.

The date and time of next meeting was scheduled.

Tasks

Action Item Assigned To Due Date

Market Research Brikelda Licaj 25.03.2019

Marketing Strategy Sara Mboqe 25.03.2019

Business Model Elisa Pashku 25.03.2019

Xhemal Kodragjini

Date and time of next meeting: 26.03.2019


13

2.6 Business Case

1.0 Introduction/ Background


The problem encountered by drivers in very populated cities, such as Tirana, is to find a free parking
spot for their vehicles.

2.0 Business Objective


Parkey aims to create a network of drivers to facilitate the process of parking in Tirana, in a
navigational experience that coordinates the drivers and a voice-recognition tool that directs them to the
nearest parking spot in town.

3.0 Current Situation and Problem/Opportunity Statement


A major issue in Tirana, but also other metropole cities, is the parking process. Drivers spend around
10-25 minutes on finding a free parking spot. They express their frustration by mentioning that they are
thinking of using other transport means.
There is a need in this city to coordinate the parking areas and make drivers feel safe about their cars.
ParKey is the key to finding parking.

4.0 Critical Assumption and Constraints


- app deployment for making it accessible to large number of users
- users might perceive a lack of differentiation from other parking apps
- competition from other parking apps which are currently being used such as ParkMe

5.0 Analysis of Option and Recommendation


#1 Finding a parking spot by swapping with anonymous drivers and receiving rewards in exchange

#2 Anonymous drivers collaborating


#3 Parking regulation information provided in every language

6.0 Preliminary Project Requirements


AI System
Navigation systems
Mobile app development (IOS & Android)

7.0 Budget Estimate and Financial Analysis


Funding possibilities: Crowdfunding, Business Angels, Venture Capitalists
Capital: 100.000 USD for first year
14

8.0 Schedule Estimate


3 months of app development process
1 month of testing
3 weeks of online marketing of the product

9.0 Potential Risks


- competition worldwide
- low usage of smart devices from drivers
- complex project, requires advanced knowledge in programming, advanced technical skills
10.0 Exhibits
Exhibit A: Financial Analysis
15

3. PLANNING
3.1 Planning Kick-off meeting
Meeting Objective: Discuss the elements that will be included in the planning phase of the project and
divide the tasks for each member.

Agenda:

• Attendance list

• Discussion on the previous work done

• Short introduction of the objectives of the meeting

• Brainstorming of ideas

• Tasks division

Short description:

The attendees were introduced to the topic of the meeting and points to be discussed. An evaluation of
the quality of the previous assignments was made and potential improvements for the future were
discussed. Moreover, attendees had the opportunity to discuss regarding the current phase, new
assignments were given to the members, the brainstormed were structured and represented using UML
diagrams.

Tasks

Action Item Assigned To Due Date

State diagram Brikelda Licaj 15.04.2019

Sequence diagram – login Sara Mboqe 15.04.2019

Sequence diagram – searching Elisa Pashku 15.04.2019

Sequence diagram – parking in/out Xhemal Kodragjini 15.04.2019

Date and time of next meeting: 15.04.2019


16

3.2 UML Diagram


3.2.1 Activity Diagram

Figure 2. Activity Diagram

First, the user opens the application after installation. He has two possibilities 1) to accept terms and
conditions for the privacy and goes to the profile of the application 2) does not accept them and closes
the application. After doing this he goes to the profile and can create an account if he doesn’t have it or
log in if he has one. After login he enters in a new step where all possibilities of doing something with
the application are in parallel and aren’t dependent from each other. Then after he reach the destination
he closes the application.
17

3.2.2 State Diagram

Figure 3. State Diagram

First, the user opens the application in order to register. After being registered (filling in all the
required information), he/she logs in with the username and password.
Now the user can see the dashboard which provides information about the free parking spots within the
area, discounts and offered coupons. Moreover, the user can park in (find a free parking spot and
occupy it). After some time, the user can park out, meaning that the spot will become available again
for another user.
18

3.2.3 Sequence Diagram

Figure 4. Sequence Diagram

This is the sequence diagram for the log in process. The objects are: the user, the application and the
database. The person enters their credentials (username and password). If the username and password
are correct (it is checked on the database), the user can use the application and its features.
If the credentials are not correct (mistyping, null, or not registered), the user is required to try again.
19

Figure 5. Sequence Diagram

This sequence diagram represents the searching process where the objects are the same (user,
application, database). The user has to type their username and password which has to be verified on
the database if there is a match. If the user is registered, he/she can write the address, request a parking
space and automatically the database updates itself (meaning the space is reserved on the database).
If the user is not registered, an alert dialog pops up and suggests the user to register.
20

Figure 6. Sequence Diagram

The last sequence diagram is for the park-out with respective objects: the user, the application and the
database. After finishing, the user requests to park out. The application sends him/her a confirmation
message and automatically updates the database (the spot is freed and added to free spaces). Moreover,
the application informs the user for the bonus he/she earned and the bonus is recorded on the database.
21

4. IMPLEMENTATION

Kick-Off Meeting

Meeting Objective: Discuss the elements that will be included in the implementation phase of the
project and divide the tasks for each member.

Agenda:

• Attendance list

• Discussion on the previous work done

• Short introduction of the objectives of the meeting

• Brainstorming of ideas

• Tasks division

Short description:

The attendees were introduced to the topic of the meeting and points to be discussed. An evaluation of
the quality of the previous assignments was made and potential improvements for the future were
discussed. Moreover, attendees had the opportunity to discuss regarding the current phase, new
assignments were given to the members.

Tasks

Action Item Assigned To Due Date

Database description Brikelda Licaj 10.05.2019

Meeting report Sara Mboqe 10.05.2019

System code Elisa Pashku 10.05.2019

ER Model 1 and 2 Xhemal Kodragjini 10.05.2019

Date and time of next meeting: 10.05.2019


22

4.1 Pre-Coding Essentials (Requirements)

Admin:
• Login: The system is under supervision of admin who manages the bookings made.
• Add Slots: Admin adds Parking slots with all its information.
• View Feedback: The admin can view all the feedbacks sent by the users.
• View Users: The admin can see all the users registered into the system.
• View Booking: The system will give all the booking information against start and end dates as
inputs.

User:
• User login/registration: Users have to first register themselves to login into the system.
• Parking availability check: User can click on spaces to view the availability. If the space is
already booked it will be marked red and the available ones will be seen in white color.
• Parking cancellation: User may even cancel their bookings by login into the system anytime.
• Profile: The system will show all the user details, wallet balance and valid bookings.
• Feedback: The system has a feedback form, where user can provide feedback into the system.

User side functionality:


• Book parking space
• Cancellation
• Feedback
• Recharge Account

Admin side functionality:


• Administers parking booked
• Add new parking Slots
• View User Data
• Feedback view and reply

Software Requirements:
• Windows 7 / 10
• SQL 2017
23

• Visual Studio 2017


• Android Studio

Advantages:
• Users can get learn about parking areas for particular locations.
• It saves user time in search of parking space available in such a long parking area.
• The system provides a graphical view of the parking spaces.
• User can pay online on the spot and confirm their space.
• It excludes the need of human efforts for managing parking spaces.
• The system generates online bill for requested time and even sends an email.
• Cost-effective.

Disadvantages:
• It requires an internet connection.
• It requires large database.

Applications:
• The project can be implemented in commercial areas for employee parking.
• It can be utilized by companies and organizations (hospitals, schools, colleges) to automate
their parking system.
• The system can also be used in public places for public parking like in malls, station, and so on.
24

4.2 Database description


For our application we need to use a database in order to log every activity of our users and to save
data. The database that we have chosen is MySQL. Since the application contains sensitive
information, such as number of parking spots or drivers’ activities, MySQL is the best option when it
comes to data security and reliability. Also it optimizes the performance of the application, reducing
system latency or crashes.

Figure 7. ER MODEL
25

Figure 8. ER MODEL 2
26

4.3 System Code


Since the application will be used in mobile devices, we are going to develop it using Android platform
and Java programming language. Java is well-known for its features and the ability to solve complex
problems in an easier way, comparing it to other available programming languages. Moreover, being
present in the industry for more than 20 years, Java offers a high-performance experience for both
developers and users.

In this section, we explain the creation of registration/login form for the app.

Login
The first layout contains a background image (imageView), a textView for the name of the app, two
labels for the username and password, two editTexts for hinting the user to insert their credentials and
a login button. Moreover, there is a checkbox which allows the user to save the credentials. By
checking the box, the app will save the credentials using cookies and will not need to insert them
manually everytime he/she uses the app.

The respective login activity will contain:

- The declaration of all views of login layout

- The statements where the view is matched with its ID (findViewById)

- The onCreate() method

- The setOnClickListener() method,which will represent the logic happening on the background when
the user clicks the login button. When clicking the button, another method will be called, which will
search on the database if there already exists a user with the credentials inserted
If the credentials exist on the database, the user will successfully login and another layout will appear.
If the credentials do not exist, an alertDialog will appear, notifying the user to register by clicking the
register icon.
If the username and password do not match, an error will occur, notifying the user to reenter his
password.
27

Registration
This layout will contain an image in background, a textView as a welcoming message and 5 editTexts
for the information that first-time users must provide in order to register. Also, for legal purposes, the
users must accept the privacy policy and terms&conditions, which will be created using checkboxes.
At the end, there is a button for completing the registration process.

The registration activity will contain:

- The declaration of all views of login layout

- The statements where the view is matched with its ID (findViewById)

- The onCreate() method

- The setOnClickListener() method,which will represent the logic happening on the background when
the user clicks the register button. When clicking the button, the entered data will be saved in the
database. Prior to registering, the user must accept the terms & conditions and privacy policy. When
the register button is clicked, the login activity will appear.

Code for the Login section (LoginActivity.java)

package com.sourcey.materiallogindemo;

import android.app.ProgressDialog;
import android.os.Bundle;
import android.support.v7.app.AppCompatActivity;
import android.util.Log;

import android.content.Intent;
import android.view.View;
import android.widget.Button;
import android.widget.EditText;
28

import android.widget.TextView;
import android.widget.Toast;

import butterknife.ButterKnife;
import butterknife.InjectView;

public class LoginActivity extends AppCompatActivity {


private static final String TAG = "LoginActivity";
private static final int REQUEST_SIGNUP = 0;

@InjectView(R.id.input_email) EditText _emailText;


@InjectView(R.id.input_password) EditText _passwordText;
@InjectView(R.id.btn_login) Button _loginButton;
@InjectView(R.id.link_signup) TextView _signupLink;

@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_login);
ButterKnife.inject(this);

_loginButton.setOnClickListener(new View.OnClickListener() {

@Override
public void onClick(View v) {
login();
}
});

_signupLink.setOnClickListener(new View.OnClickListener() {

@Override
public void onClick(View v) {
// Start the Signup activity
29

Intent intent = new Intent(getApplicationContext(), SignupActivity.class);


startActivityForResult(intent, REQUEST_SIGNUP);
}
});
}

public void login() {


Log.d(TAG, "Login");

if (!validate()) {
onLoginFailed();
return;
}

_loginButton.setEnabled(false);

final ProgressDialog progressDialog = new ProgressDialog(LoginActivity.this,


R.style.AppTheme_Dark_Dialog);
progressDialog.setIndeterminate(true);
progressDialog.setMessage("Authenticating...");
progressDialog.show();

String email = _emailText.getText().toString();


String password = _passwordText.getText().toString();

new android.os.Handler().postDelayed(
new Runnable() {
public void run() {
// On complete call either onLoginSuccess or onLoginFailed
onLoginSuccess();
// onLoginFailed();
progressDialog.dismiss();
30

}
}, 3000);
}

@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
if (requestCode == REQUEST_SIGNUP) {
if (resultCode == RESULT_OK) {

// TODO: Implement successful signup logic here


// By default we just finish the Activity and log them in automatically
this.finish();
}
}
}

@Override
public void onBackPressed() {
// disable going back to the MainActivity
moveTaskToBack(true);
}

public void onLoginSuccess() {


_loginButton.setEnabled(true);
finish();
}

public void onLoginFailed() {


Toast.makeText(getBaseContext(), "Login failed", Toast.LENGTH_LONG).show();

_loginButton.setEnabled(true);
}
31

public boolean validate() {


boolean valid = true;

String email = _emailText.getText().toString();


String password = _passwordText.getText().toString();

if (email.isEmpty() || !android.util.Patterns.EMAIL_ADDRESS.matcher(email).matches()) {
_emailText.setError("enter a valid email address");
valid = false;
} else {
_emailText.setError(null);
}

if (password.isEmpty() || password.length() < 4 || password.length() > 10) {


_passwordText.setError("between 4 and 10 alphanumeric characters");
valid = false;
} else {
_passwordText.setError(null);
}

return valid;
}
}

res/layout/activity_login.xml

<?xml version="1.0" encoding="utf-8"?>


<ScrollView xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:fitsSystemWindows="true">
32

<LinearLayout
android:orientation="vertical"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:paddingTop="56dp"
android:paddingLeft="24dp"
android:paddingRight="24dp">

<ImageView android:src="@drawable/parkeyLogo"
android:layout_width="wrap_content"
android:layout_height="72dp"
android:layout_marginBottom="24dp"
android:layout_gravity="center_horizontal" />

<!-- Email Label -->


<android.support.design.widget.TextInputLayout
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_marginTop="8dp"
android:layout_marginBottom="8dp">
<EditText android:id="@+id/input_email"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:inputType="textEmailAddress"
android:hint="Email" />
</android.support.design.widget.TextInputLayout>

<!-- Password Label -->


<android.support.design.widget.TextInputLayout
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_marginTop="8dp"
android:layout_marginBottom="8dp">
<EditText android:id="@+id/input_password"
33

android:layout_width="match_parent"
android:layout_height="wrap_content"
android:inputType="textPassword"
android:hint="Password"/>
</android.support.design.widget.TextInputLayout>

<android.support.v7.widget.AppCompatButton
android:id="@+id/btn_login"
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:layout_marginTop="24dp"
android:layout_marginBottom="24dp"
android:padding="12dp"
android:text="Login"/>

<TextView android:id="@+id/link_signup"
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:layout_marginBottom="24dp"
android:text="No account yet? Create one"
android:gravity="center"
android:textSize="16dip"/>

</LinearLayout>
</ScrollView>
34

Design elements of the application

• The theme chosen for the design will be dark, taking into consideration the fact that drivers will

use the app in light environments.

• The colors of pin points are pulsing and bright to emphasize and make a contrast so that drivers

can find the spots quickly and easily.

• The current location is displayed in light blue and the position of the destination in yellow.

• There are two buttons for parking in and out, in round blue colors. Also, there is a voice

recognition button which helps the driver find the spot.

LOGO

• For the logo, we have chosen blue and white colors.

• At the bottom of the serif of P letter there are scratches that symbolize the marks left by cars.

• In background, there are two quarter circles in blue, symbolizing the wheels of cars.

Figure 9. App design


35

Class diagram

Figure 10. Class Diagram


36

5. TESTING
Kick-Off Meeting

Meeting Objective: Discuss the elements that will be included in the testing phase of the project and
divide the tasks for each member.

Agenda:

• Attendance list

• Discussion on the previous work done

• Short introduction of the objectives of the meeting

• Brainstorming of ideas

• Tasks division

Short description:

The attendees were introduced to the topic of the meeting and points to be discussed. An evaluation of
the quality of the previous assignments was made and potential improvements for the future were
discussed. Moreover, attendees had the opportunity to discuss regarding the current phase, new
assignments were given to the members.

Tasks

Action Item Assigned To Due Date

Unit Testing Brikelda Licaj 02.06.2019

List of Prioritized Risks

Integration Testing Sara Mboqe 02.06.2019

Acceptance Testing Elisa Pashku 02.06.2019

Lessons Learnt Report

Testing Design & Conclusion Xhemal Kodragjini 02.06.2019

Date and time of next meeting: 02.06.2019


37

5.1. Unit testing

The primary goal of unit testing is to take the smallest piece of testable software in the application,
isolate it from the remainder of the code, and determine whether it behaves exactly as you expect. Each
unit is tested separately before integrating them into modules to test the interfaces between modules.
Unit testing has proven its value in that a large percentage of defects are identified during its use. Since
we are writing codes using Java we choose to use Arquillian, a Java Unit Testing Framework. As we
identify each class in the component is extensively tested using Arquillian.

Figure 11 Unit testing

Intro to Arquillian
Arquillian is a highly innovative and extendible testing platform for JVM that allows developers to
easily create automated integration, functional and acceptance tests for Java. Arquillian allows you to
run test in the run-time so you don’t have to manage the run-time from the test (or the build).
Arquillian can be used to manage the life cycle of the container (or containers),bundling test cases,
dependent classes and resources. It is also capable of deploying archive into containers and execute
tests in the containers and capture results and create reports.
Arquillian integrates with familiar testing frameworks such as JUnit 4, TestNG 5 and allows tests to be
launched using existing IDE, and because of its modular design it is capable of running Ant and Maven
test plugins.
38

In writing the tests before we wrote the class, we have been forced to do a few things. First of all, we
had to invent the class’s public API before anything else. It’s worth noting that in Unit Testing and
TDD, it is virtually pointless to test private methods (what’s called “Testing State”) since we’re rarely
interested in how the code does something as opposed to what the expected end result should be (focus
on results, not intermediate state). In a lot of code the result will remain the same, but the working code
will evolve over time due to refactoring, new Arquillian functionality, or system dependent
requirements – so testing all this stuff only forces us to constantly rewrite our tests. Once we get down
to actual coding, we have all this design work already done and a set of tests which will continually
verify the new code we write.
39

5.2. Integration testing

Integration testing is a logical extension of unit testing. In its simplest form, two units that have already
been tested are combined into a component and the interface between them is tested. A component, in
this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units
are combined into components, which are in turn aggregated into even larger parts of the program. The
idea is to test combinations of pieces and eventually expand the process to test your modules with
those of other groups. Eventually all the modules making up a process are tested together. Beyond that,
if the program is composed of more than one process, they should be tested in pairs rather than all at
once. Integration testing identifies problems that occur when units are combined. By using a test plan
that requires you to test each unit and ensure the viability of each before combining units, you know
that any errors discovered when combining units are likely related to the interface between units. This
method reduces the number of possibilities to a far simpler level of analysis.

You can do integration testing in a variety of ways and we have chosen the Umbrella approach:

The umbrella approach requires testing along functional data and control-flow paths. First, the
inputs for functions are integrated in the bottom-up pattern discussed above. The outputs for each
function are then integrated in the top-down manner. The primary advantage of this approach is the
degree of support for early release of limited functionality. It also helps minimize the need for stubs
and drivers. We have chosen this model as the functional issues can be detected early and also as our
project requires maintenance, the regression testing scenario would not be a overhead for following
this pattern in testing.

CODE COVERAGE:

Code coverage is a measure used in software testing. It describes the degree to which the source code
of a program has been tested. We have used XDEBUG Extension and it gives us the function coverage
statistics as well as statement coverage statistics .We have observed that the function coverage was
100%, however statement coverage was 60% as many branches would never be executed with any
piece of testing.
40

Login section

Test covers : Graphical User Interface


Assumption: The application is showing the correct screen.

Integration Testing
Steps:
• Register by entering all the required information
• Click the register button

• →If the login section appears, login with your credentials.

Expected: Login screen appears after the customer registers

Fails if:

• After registering, the logo screen appears


• After clicking the register button, the user is required to reenter his data (information that is
required for the registration part)
41

Parking in

Test covers : Graphical User Interface


Assumption: The application is showing the correct screen.

Integration Testing
Steps:
• Search for the parking area you want to park in.
• Choose the parking block and spot.
• Click “Park in”

Expected: User has successfully parked in.

Fails if:

• In the moment that the user is choosing the block and spot, another user parks in.
• The place is not free, but this is not updated in the system.
42

Bonus points and coupons

Test covers : Graphical User Interface

Assumption: The application is showing the correct screen.

Integration Testing

Steps:
• Go to the “Bonus” menu in the app
• Click on the “Get a coupon” button
• Wait for the page to load the discount you have received.

Expected: User receives the coupon and discount from one of the partner companies.

Fails if:

• Waiting for the page to load takes long.


• After clicking the button, no discount appears.
43

5.3. Acceptance testing

Acceptance tests are created from user stories. During iteration the user stories selected during the
iteration planning meeting will be translated into acceptance tests. A story can have one or many
acceptance tests, whatever it takes to ensure the functionality works. Acceptance tests are black box
system tests. Each acceptance test represents some expected result from the system. Customers are
responsible for verifying the correctness of the acceptance tests and reviewing test scores to decide
which failed tests are of highest priority. Acceptance tests are also used as regression tests prior to a
production release.

Acceptance Test case 1

ATC1.01- Create a profile of a user who is not in the system. (Pass)

ATC1.02- Create a profile of a user who is already in the system. (Fail)

Acceptance Test case 2

ATC2.01- Update the personal information of a user. (Pass)

Acceptance Test case 3

ATC3.01- Access the user profile who is not currently logged in. (Fail)

ATC.02- User accesses his own profile. (Pass)

ATC3.03- The system logs out after being idle for 10 minutes. (Pass)

ATC3.04- The user enters the system after 3 consecutive failed attempts to login. (Fail)

ATC3.05 The user retrieves his password by answering the secret question (Pass)

ATC3.06- The user deletes his profile. (Pass)

ATC3.07- The user tries to login with a wrong user id or password. (Fail)
44

Acceptance Test case 4

ATC4.01-The system displays the list of all the user ID and password when the administrator

logs in (Pass)

ATC4.02-The system does not show any user ID and password when the administrator logs in

(Fail)
45

Below are the design of the test cases as per required by out project. These are the basic test

cases. We need to check thoroughly that all the test cases are working properly, the screens are

displayed in a proper format and there is no discrepancy in displayed graphs. We also need to

check the code thoroughly for the correctness of algorithm and control flows.

1. Test ID : TC1_Login

Assumption: the user is at login screen.

Input requirement Expected output Pass/Fail Comments

Pass if the user is able This is to test that the


Valid userId, system allow valid user
Login successfully to login and sees the
Password to enter the app
home screen

Display error Pass if the user is This test is to determine


Invalid UserId, message unable to see the that invalid user should
password "Invalid userId/ home screen not enter the app
Password"

2. Test ID : TC2_Register

Assumption: the user is at login screen.

Input requirement Expected output Pass/Fail Comments

This is to test that the


Pass if the user is able system allow only
the user enters a
Register successfully to register his UserId unique user in the
userId which is
password. system with the unique
unique
userID

Display error This is to test that the


message Pass if the user is system does not allow
the user enters a
"User Id already unable to create a two user with the same
userId which is
exist. Please choose userId userID
preexisting
another ID"
46

Lessons Learned Report

1. Did the project meet scope, time, and cost goals?

We did meet the scope and time goal, but the cost exceeded a bit. We actually exceeded scope goals by

having more people install and use our app compared to our user’s goal.

2. What was the success criteria listed in the project scope statement?

Our group has stated that the project will be a success if the parking app will be developed on time

providing all the features, and 50 users will install and use it within the first week of launching.

3. Reflect on whether or not you met the project success criteria.

The parking app was developed on time, but one feature was not developed as we had planned. We had

to rethink and evaluate again the gender of the virtual assistant, and for clarity purposes, we chose to

create Vinny with a male voice.

Furthermore, the number of installment far exceeded our expectations.

4. In terms of managing the project, what were the main lessons your team learned?

Having good communicational and organizational was a key factor to the success of our app. Writing

reports and keeping notes were two other important factors which made Parkey a full-option parking

app. Using ready dynamic libraries, helped us design the layout of the app easily. It was extremely

helpful to take time to develop and follow a team contract for the project team and to focus on
47

developing good partnerships with suppliers. Everyone was very supportive of each other.

Creativity and innovation are infectious: Many creative and innovative ideas were used on this project.

5. Describe one example of what went right on this project.

We were a little bit skeptical about the team spirit but actually everything went great and our

discussions were really productive. Moreover, we are really proud of the design of the app.

6. Describe one example of what went wrong on this project.

We had some difficulty integrating Google Maps inside the app. Google Maps needed constant

updates.

7. What will you do differently on the next project based on your experience working on this

project?

For future projects, it would be better not to underestimate the number of people who will take interest

and use our products. We should have more faith in our output as long as we put all our effort on the

project.
48

List of Prioritized Risks for ParKey

Ranking Potential Risk

No agreement between us and Google for the integration of Google Maps in


1
our system

2 In Albania there is a limited space for public and free parking.

3 The app will not be developed on time

We need to create a network of partners in order to offer coupons and


4
discounts for our users

5 The app should provide new exciting features

6 Loss or denigration of data saved on the database

Since there will be a lot of data to be processed, there might be cases of


7
connection loss between the app and the server
49

CONCLUSION

As a first draft, this prototype was focusing on usability for users with limited technical experience.

The prototype aimed at simplifying the process of finding parking spots. The draft features a “login”

option which enables the user to use the main features of the app. The design for this application is

aimed at providing the user with detailed information, which would aid them to make a choice of

where to park based on their needs and level of convenience; however, this may add too much

cognitive load.

The cognitive process of finding a car parking space and parking needs to be reduced in order to

enhance the efficiency of use for the user. For a novice user the process might be technically

challenging, equally an experienced mobile application user might find the interaction.

The next step is to provide a “voice” experience, by making the user communicate with a Virtual

Assistant, called Vinny, which will guide the user to the destination.
50

REFERENCES

Pressman, R. S. (n.d.). Software Engineering: A Practitioner's Approach.

TiranaParking. (n.d.). Retrieved from http://tiranaparking.al/

Best Parking Apps. (n.d.). Retrieved from https://www.moneyunder30.com/best-parking-app

UML tutorials. (n.d.). Retrieved from https://www.tutorialspoint.com/uml/

Study of Parking Patterns for Different Parking Facilities. (october 2014 - march 2015). International Journal of

Civil and Structural Engineering Research,35-39. Retrieved from

https://www.researchgate.net/publication/272680565_Study_of_Parking_Patterns_for_Different_Parking_Facilities.

Android Application Development for dummies(2nd ed.). (n.d.).

P. N., & J. K. (n.d.). Learning Java(3rd ed.).

Database. (n.d.). Retrieved from https://searchsqlserver.techtarget.com/definition/database

Color map. (n.d.). Retrieved from https://matplotlib.org/users/colormaps.html

You might also like