0% found this document useful (0 votes)
2 views5 pages

Research Project 20036

Uploaded by

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

Research Project 20036

Uploaded by

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

Research project topic Fake Phone Verification

Through supply Chain

Author SONGA SHEMA Kevin

Faculty Information technology

Department Networks & Communication


Systems

ID 20036

Email Songakevin9@gmail.com

Phone number +250785937023


1. BACKGROUND
Counterfeit mobile phone producers imitate all facets of a branded phone‘s appearance to
make their products appear genuine .The phone ‘s cover and screen, the printed logos and
branding and included accessories can all be duplicated which makes it a problem to
know whether the phone is fake or genuine. It is always preferable to buy a phone through a
registered retailer or reseller who can vouch for a phone’s authenticity or you can do a little
research before purchasing a new phone which include gathering information like phone’s
specific model number, available colors, features, software version of the phone and warrant
offered for the product.
2. DESCRIPTION OF THE CURRENT SYSTEM:
Mostly a genuine mobile phone has a serial number to register it to a carrier network. The
serial number used is called IMEI (International Mobile Equipment Identify). The IMEI
number is the one used to check the legitimacy of a phone. Usually counterfeit models don’t
have an IMEI number or have a fake one. If you want to buy a phone you have to find the
IMEI number on the product packaging under the phone’s battery or by pressing *#06# on
the phone .
There are some issues with this manual system below:

 Using this current system you can’t check the manufacturing history of the product which
means you can’t know where, when it was manufactured and who bought it first.
 You can’t know if the product was not stolen.
 There is no current way a customer can geographically locate his phone when it is stolen
without going to RIB

3. PROBLEM SOLUTION

The solution for the problem involves a simple QR code based on identification that can help
the consumer and the company salesman to scan and identify genuineness by using a
smartphone. The manufacturing company will print unique QR codes on labels for their
products and products packages. This QR code will contain information about the specific
product which will include the product name, model number, factory of manufacture, date of
manufacture. This code will be displayed on the outer part of the product so that it can be
accessed easily for scanning by the customer or suppliers. The system will hold the product
details along with history of transactions to enable tracking of the product along supply
chain. Also the system will provide a way to geographically locate his phone when it is
stolen.
4. OBJECTIVE OF THE PROJECT

The main objective of this project fake phone verification system through supply chain is to
develop a system that will give a customer the phone‘s information before purchasing it in
order to avoid buying fake phones and for the customer to track the phone when theft occurs.

4.1. SPECIFIC OBJECTIVES

 To design and implement a web-based fake phone verification system that uses QR
code for protecting and storing phone information.
 The system will be having an Administrator whose role is to add manufacturing
companies.
 The manufacturing company will add all manufactured phones with their respective
QR code
 The customer will scan the phone’s QR code before buying it.
 The customer will check phone’s manufacturing information and will be provided a
pro forma invoice before the purchase of the phone.
 The customer will be given a way of geographically locate his phone.

5. REQUIREMENTS

5.1. Functional Requirements


The system should meet the following Functionalities:
 Ability of the system to produce a QR code for each phone.
 Ability of the administrator to add manufacturing company.
 Ability of the manufacturing company to add phones.
 Ability of the customer to be scan QR code of the phone.
 Ability of the system to provide a pro forma invoice to the customer or supplier.
 Ability of the system to provide information of the scanned phone to the customer.
 Ability of the system to provide an option to the customer for geographically locate his
phone.
5.2. Non-Functional Requirements
• For the administrator to access the system he must enter on the login panel
the valid username and password. After the system will authenticate to check if the
credentials are true.

• The system should keep the distribution chain of all phones from the manufactures
to the supplier till it reaches to the consumers.

• Availability:
The system hall have high availability, the system shall have downtime at
most 3 hours/month
• Usability
The system shall provide an easy-to-use graphical interface
The web interface should be intuitive and easily navigable Users should be
able to understand the menu and options provided by the system.
• Privacy: the system should be able to protect product’s information. The
information should only be accessed by scanning the QR code on the product.

• Operational: the system should be able to run to any operating system.

6. TOOLS and TECHNOLOGIES


Programming languages: PHP (laravel framework), java script, CSS, HTML.
DBMS: MySQL-server 5
IDE & Text editor: NETBEANS IDE 8.2, Brackets.
Tools of designing: Star UML, Visual Paradigm.
Operating system: windows 10.
7. WORK BREAKDOWN STRUCTURE
Work Breakdown Structure
Task ID Task Name Duration Dependency Status
1 Project plan 1Month Open
2 Requirement analysis 5 weeks Open
2.1 Make interviews 4days Open
2.2 Review existing System 1week Open
2.3 Document requirement 7days Open
2.4 Document review 1week Open
2.5 Validation 1week Open
3 System Design 1week Open
3.1 Architecture 1day Open
3.2 Database design 3days Open
3.3 UI design 2days Open
3.4 Program design 1day Open
4 System Implementation 2months Open
4.1 Coding 7days Open
4.2 Integration/quality assurance 7days Open
5 Testing 2weeks Open
5.1 System testing 1week Open
5.2 User Acceptance Testing 1week Open
6 Deployment 3weeks Open
6.1 Server installation 1week Open
6.2 Server configuration 1week Open
6.3 Deployment technical Training 1week Open
7 Final Report 1week Open
7.1 Writing report 1week Open

You might also like