Acknowledgement

We are pleased to present “Android Retail Management System”

projectand takethis opportunity to express our profound gratitude to all those
people who helped us in completion of this project.
We thank our college for providing us with excellent facilities that
helped us to complete and present this project. We would also like to thank
the staff members and lab assistants for permitting us to use computers in the
lab as and when required.
We express our deepest gratitude towards our project guide for his/her
valuable and timely advice during the various phases in our project. We would
also like to thank him/herfor providing us with all proper facilities and support
as the project co-coordinator. We would like to thank him/herfor support,
patience and faith in our capabilities and for giving us flexibility in terms of
working and reporting schedules.
We would like to thank all our friends for their smiles and friendship
making the college life enjoyable and memorable and family members who
always stood beside us and provided the utmost important moral support.
Finally, we would like to thank everyone who has helped us directly or
indirectly in our project.
 TABLE OF CONTENT
Sr. No. Contents
1 PROJECT OVERVIEW
1.1 Introduction
1.2 Scope and Objective
1.3 Modules and its Description
1.4 Existing System & Proposed System

2 PROJECT ANALYSIS
2.1 Gantt Chart
3 PROJECT LIFECYCLE

3.1 Project Lifecycle Details

4 PROJECT DESIGN
4.1 E-R Diagram
4.2 Use Case Diagram
4.3 Sequence Diagram
4.4 Activity Diagram
4.5 Data Flow Diagram
4.6 System Architecture

5 SNAPSHOTS
5.1 Project Snapshots
6 PROJECT IMPLEMENTATION
6.1 Project Implementation Technology
6.2 Feasibility Report

7 CODING
7.1 Project Coding

8 TESTING
8.1 Testing
8.2 Levels of Testing
8.3 Test Cases

9 ADVANTAGES &LIMITATIONS
9.1 Advantages
9.2 Limitations
9.3 Features
10 CONCLUSION
10.1 Project Conclusion
11 BIBIIOGRAPHY
11.1 Website Links
 PROJECT OVERVIEW

Introduction
Traditional retail management poses significant challenges, requiring
efficient solutions to address issues such as store administration, product
handling, and sales reporting. Administering multiple stores becomes
complex, as manual processes for adding, updating, viewing, and deleting
store information are time-consuming and prone to errors. Counter staff
faces hurdles in managing customer cart details during checkout, especially
when handling diverse products from various stores. Users encounter
difficulties in tracking and consolidating their purchases, especially when
items from different stores are involved.
To mitigate the challenges in retail management, the Android Retail
Management System offers a comprehensive solution. The system addresses
the inefficiencies in store management by empowering administrators with
functionalities to seamlessly handle store-related tasks, such as store
addition, updates, views, and deletions. It facilitates the smooth management
of counters by enabling counter staff to efficiently handle customer cart
details during checkout, ensuring a hassle-free experience.By leveraging
Android technology, this system aims to revolutionize retail management,
offering a user-friendly interface and efficient functionalities for improved
overall operations.
Scope and Objective

The Android Retail Management System is designed with the

overarching objective of streamlining and enhancing the efficiency of retail
operations. The scope of the system encompasses comprehensive store
management, empowering administrators to effortlessly add, update, view,
and delete store information. It extends to counter staff, providing tools for
seamless customer checkout experiences, particularly in handling diverse
products from various stores.

The system focuses on user convenience, prompting them to consolidate

items from different stores into a single-store order for a more straightforward
purchasing process. Additionally, robust sales reporting capabilities form a vital
aspect, enabling administrators to generate detailed reports on products,
quantities sold, and total prices in graphical formats. The ultimate goal is to
revolutionize retail management by leveraging Android technology to create
an intuitive, user-friendly system that optimizes store administration, enhances
the checkout process, and provides valuable insights through efficient sales
reporting, thereby contributing to overall operational excellence in the retail
environment.
Modules and their Description

The system comprises of 3 major modules with their sub-modules as follows:

1. Admin

 Login: The admin can log in using valid credentials.

 Manage Stores: The admin can add, update, view, or delete stores.
 Manage Counters: Admin can add, update, delete, and view counter
details. They can also assign stores to counters.
 Manage Products: The admin, upon selecting a specific store, can add,
update, view, or delete products, including inventory updates.
 Sales Report: The admin can choose a store and generate detailed
reports on products; quantities sold, and total prices on a weekly,
monthly, and yearly basis, as well as between two specific dates. These
reports are presented graphically.

2. Counter

 Login: Counter staff can log in using their designated credentials.

 Checkout: During checkout, counter staff can access and manage
customers' cart details for the assigned store. They can check the cart by
entering or scanning the consumer ID, adding, updating, or deleting
items, and facilitating checkouts via card or cash.
 Today’s Sales: The counter can compile a list of today's customers, along
with the purchased products.

3. User/Consumer

 Register: Users can register and obtain unique credentials.

 Login: Using their credentials, users can log in securely.
 Profile: Users can edit their profiles.
 Change Password: In emergencies, users can change their passwords.
 Home: If the items added to the cart belong to different stores, the
system will prompt users to replace their selections, as the ordering
process only accommodates products from a single store at a time. The
home screen displays the total amount, a list of added items, and any
newly scanned items. Users can conveniently checkout using a card, and
payment updates are reflected at the employees' end or the consumer's
end based on the payment location (counter or user).
 Previous Purchases: Users can access a list of their previous purchases.
Existing System & Proposed System

 Problem with the current scenario

 Manual calculation of stock present in any store is time-

consuming and very risky.
 The workers cannot maintain the store when there is no owner
as they do not know the prices.

Drawbacks of the existing system

 Maintenance of the system is very difficult.

 There is a possibility for getting inaccurate results.
 User friendliness is very less.
 It consumes more time for processing the task.
PROPOSED SYSTEM

 Considering the anomalies in the existing system computerization of the

whole activity is being suggested after initial analysis.
 The Android application is developed using Android Studio with JAVA as
a programming language.
 The proposed system is accessed by three entities namely, Admin,
Counter and User.
 Admin can securely login using valid credentials and wield the authority
to add, update, view, or delete stores. Moreover, they can efficiently
manage counters by adding, updating, deleting, and viewing counter
details, including the assignment of stores to specific counters.
 The admin, when selecting a particular store, gains the capability to add,
update, view, or delete products, with the added flexibility of managing
inventory updates.
 On the counter side, staff members can log in securely using their
designated credentials.
 During the checkout process, counter staff can access and oversee
customers' cart details for the assigned store, facilitating cart
management through consumer ID entry or scanning. This includes
adding, updating, or deleting items and enabling checkouts using cards
or cash.
 The counter functionality extends to compiling a list of today's
customers and their purchased products, offering a snapshot of daily
sales activities.
 For users/consumers, the system provides a user-friendly experience.
Users can register and obtain unique credentials, subsequently logging in
 securely. They retain the ability to edit their profiles and, in
emergencies, change their passwords.
 On the Homepage, if the items added to the cart belong to different
stores, the system will prompt users to replace their selections, as the
ordering process only accommodates products from a single store at a
time. This screen displays the total amount, a list of added items, and
any newly scanned items. Users can conveniently check out using a card,
and payment updates are reflected either at the employees' end or the
consumer's end, depending on the chosen payment location (counter or
user).
 Additionally, users have easy access to a list of their previous purchases.

Gantt Chart
Project Lifecycle Details

Waterfall Model

Description
The waterfall Model is a linear sequential flow. In which progress is seen
as flowing steadily downwards (like a waterfall) through the phases of software
implementation. This means that any phase in the development process begins
only if the previous phase is complete. The waterfall approach does not define
the process to go back to the previous phase to handle changes in
requirement. The waterfall approach is the earliest approach that was used for
software development.
 PROJECT DESIGN

ER Diagram
Use Case Diagram

Fig. Use Case Diagram of Admin

Fig. Use Case Diagram of Counter

Fig. Use Case Diagram of User

Sequence Diagram

Fig. Sequence Diagram of Admin

Fig. Sequence Diagram of Counter
Fig. Sequence Diagram of User
Activity Diagram

Fig. Activity Diagram of Admin

Fig. Activity Diagram of Counter

Fig. Activity Diagram of User
Class Diagram

Admin
New Registration
- User_id : String
- Password : String - Name : String
- DOB : Int
+ Login() - Gender : String
+ btn_Click () - Address : String
+ Logout () - Mobile No.: Int
- Email id : String
- User id : String
Counter
- Password : String
- User_id : String
- Password : String
+ Submit ()
+ Login() + btn_Click ()
+ btn_Click ()
+ Logout ()

User
- User_id : String
- Password : String

+ Login()
+ btn_Click ()
+ Logout ()
Data Flow Diagram (DFD’s)

A data flow diagram is graphical tool used to describe and analyze

movement of data through a system. These are the central tool and the basis
from which the other components are developed. The transformation of data
from input to output, through processed, may be described logically and
independently of physical components associated with the system. These are
known as the logical data flow diagrams. The physical data flow diagrams
show the actual implements and movement of data between people,
departments and workstations. A full description of a system actually consists
of a set of data flow diagrams. Using two familiar notations Yourdon, Gane
and Sarson notation develops the data flow diagrams. Each component in a
DFD is labeled with a descriptive name. Process is further identified with a
number that will be used for identification purpose. The development of DFD’s
is done in several levels. Each process in lower level diagrams can be broken
down into a more detailed DFD in the next level. The lop-level diagram is often
called context diagram. It consists a single process bit, which plays vital role in
studying the current system. The process in the context level diagram is
exploded into other process at the first level DFD.
The idea behind the explosion of a process into more process is that
understanding at one level of detail is exploded into greater detail at the next
level. This is done until further explosion is necessary and an adequate
amount of detail is described for analyst to understand the process.
Larry Constantine first developed the DFD as a way of expressing system
requirements in a graphical from, this lead to the modular design.
 A DFD is also known as a “bubble Chart” has the purpose of clarifying
system requirements and identifying major transformations that will become
programs in system design. So it is the starting point of the design to the
lowest level of detail. A DFD consists of a series of bubbles joined by data
flows in the system.

DFD SYMBOLS:
In the DFD, there are four symbols
1. A square defines a source(originator) or destination of system data
2. An arrow identifies data flow. It is the pipeline through which the
information flows
3. A circle or a bubble represents a process that transforms incoming data
flow into outgoing data flows.
4. An open rectangle is a data store, data at rest or a temporary repository of
data

Process that transforms data flow

Source or Destination of data

Data flow

Data Store
CONSTRUCTING A DFD:

Several rules of thumb are used in drawing DFD’s:

1. Process should be named and numbered for an easy reference. Each name
should be representative of the process.
2. The direction of flow is from top to bottom and from left to right. Data
traditionally flow from source to the destination although they may flow
back to the source. One way to indicate this is to draw long flow line back
to a source. An alternative way is to repeat the source symbol as a
destination. Since it is used more than once in the DFD it is marked with a
short diagonal.
3. When a process is exploded into lower level details, they are numbered.
4. The names of data stores and destinations are written in capital letters.
Process and dataflow names have the first letter of each work capitalized

A DFD typically shows the minimum contents of data store. Each data
store should contain all the data elements that flow in and out.
Questionnaires should contain all the data elements that flow in and out.
Missing interfaces redundancies and like is then accounted for often through
interviews.

SAILENT FEATURES OF DFD’s

1. The DFD shows flow of data, not of control loops and decision are
controlled considerations do not appear on a DFD.
 2. The DFD does not indicate the time factor involved in any process
whether the data flows take place daily, weekly, monthly or yearly.
3. The sequence of events is not brought out on the DFD.

TYPES OF DATA FLOW DIAGRAMS

1. Current Physical
2. Current Logical
3. New Logical
4. New Physical

CURRENT PHYSICAL:
In Current Physical DFD process label include the name of people or
their positions or the names of computer systems that might provide some of
the overall system-processing label includes an identification of the technology
used to process the data. Similarly, data flows and data stores are often labels
with the names of the actual physical media on which data are stored such as
file folders, computer files, business forms or computer tapes.

CURRENT LOGICAL:
The physical aspects at the system are removed as much as possible so
that the current system is reduced to its essence to the data and the
processors that transform them regardless of actual physical form.

NEW LOGICAL:
This is exactly like a current logical model if the user were completely
happy with the user were completely happy with the functionality of the
current system but had problems with how it was implemented typically
through the new logical model will differ from current logical model while
having additional functions, absolute function removal and inefficient flows
recognized.

NEW PHYSICAL:
The new physical represents only the physical implementation of the
new system.

RULES GOVERNING THE DFD’S

PROCESS
1) No process can have only outputs.
2) No process can have only inputs. If an object has only inputs than it
must be a sink.
3) A process has a verb phrase label.

DATA STORE
1) Data cannot move directly from one data store to another data store,
a process must move data.
2) Data cannot move directly from an outside source to a data store, a
process, which receives, must move data from the source and place
the data into data store
3) A data store has a noun phrase label.

SOURCE OR SINK
The origin and /or destination of data
 1) Data cannot move direly from a source to sink it must be moved by
a process
2) A source and /or sink has a noun phrase land

DATA FLOW
1) A Data Flow has only one direction of flow between symbols. It may
flow in both directions between a process and a data store to show a
read before an update. The later it usually indicated however by two
separate arrows since these happen at different type.
2) A join in DFD means that exactly the same data comes from any of
two or more different processes data store or sink to a common
location.
3) A data flow cannot go directly back to the same process it leads.
There must be at least one other process that handles the data flow
produce some other data flow returns the original data into the
beginning process.
4) A Data flow to a data store means update (delete or change).
5) A data Flow from a data store means retrieve or use.
Data Flow Diagrams (DFD’s)

1.0
Query
User Query Process0.0 Check for user
Request Requirement
User Android Retail Management System DB Database
User need

1.1

Feedback For
Relevant Database
User Data

DATABASE DETAIL
 LEVEL 1 DFD

Query 2.0

User Accept
Query

Give info about DB

2.1

Give request to user Check Availability of or for query processing

2.2

Process ViaAndroid Retail Management SystemDB

Query

LEVEL 2 DFD: PREDICTION

System Architecture
Snapshots
 PROJECT IMPLEMENTATION

Project Implementation Technology

The Project application is loaded in Android Studio. We used Android

Studio for Design and coding of project. Created and maintained all databases
into SQL Server, in that we create tables, write query for store data or record
of project.
 Hardware Requirement:

1. Laptop or PC

 i3 Processor Based Computer or higher

 1GB RAM
 5 GB Hard Disk
2. Android Phone or Tablet
 1.2 Quad core Processor or higher
 1 GB RAM

 Software Requirement:

1. Laptop or PC
 Windows 7 or higher.
 Java
 Android Studio
2. Android Phone or Tablet
 Android v5.0 or Higher
Introduction to Android
Android Studio is the official Integrated Development Environment (IDE) for
Android app development, based on IntelliJ IDEA . On top of IntelliJ's powerful
code editor and developer tools, Android Studio offers even more features that
enhance your productivity when building Android apps, such as:

 A flexible Gradle-based build system

 A fast and feature-rich emulator

 A unified environment where you can develop for all Android devices

 Instant Run to push changes to your running app without building a new
APK

 Code templates and GitHub integration to help you build common app
features and import sample code

 Extensive testing tools and frameworks

 Lint tools to catch performance, usability, version compatibility, and other

problems

 C++ and NDK support

 Built-in support for Google Cloud Platform, making it easy to integrate

Google Cloud Messaging and App Engine.
Project Structure

Each project in Android Studio contains one or more modules with source
code files and resource files. Types of modules include:

 Android app modules

 Library modules

 Google App Engine modules

By default, Android Studio displays your

project files in the Android project view, as
shown in figure 1. This view is organized by
modules to provide quick access to your
project's key source files.

All the build files are visible at the top level

under Gradle Scripts and each app module
contains the following folders:

 manifests: Contains
the AndroidManifest.xml file.

 java: Contains the Java source code files,

including JUnit test code.

 res: Contains all non-code resources, such as XML layouts, UI strings, and
bitmap images.
 The Android project structure on disk differs from this flattened
representation. To see the actual file structure of the project,
select Project from the Project dropdown (in figure 1, it's showing asAndroid).

You can also customize the view of the

project files to focus on specific aspects
of your app development. For example,
selecting the Problems view of your
project displays links to the source files
containing any recognized coding and
syntax errors, such as a missing XML element closing tag in a layout file.

The User Interface

1. The toolbar lets you carry out a wide range of actions, including running
your app and launching Android tools.

2. The navigation bar helps you navigate through your project and open files
for editing. It provides a more compact view of the structure visible in
the Project window.

3. The editor window is where you create and modify code. Depending on
the current file type, the editor can change. For example, when viewing a
layout file, the editor displays the Layout Editor.

4. The tool window bar runs around the outside of the IDE window and
contains the buttons that allow you to expand or collapse individual tool
windows.
5. The tool windows give you access to specific tasks like project
management, search, version control, and more. You can expand them and
collapse them.

6. The status bar displays the status of your project and the IDE itself, as well
as any warnings or messages.

You can organize the main window to give yourself more screen space by
hiding or moving toolbars and tool windows. You can also use keyboard
shortcuts to access most IDE features.

At any time, you can search across your source code, databases, actions,
elements of the user interface, and so on, by double-pressing the Shift key, or
clicking the magnifying glass in the upper right-hand corner of the Android
Studio window. This can be very useful if, for example, you are trying to locate
a particular IDE action that you have forgotten how to trigger.
Tool Windows
Instead of using preset perspectives, Android Studio follows your
context and automatically brings up relevant tool windows as you work. By
default, the most commonly used tool windows are pinned to the tool window
bar at the edges of the application window.

 To expand or collapse a tool window, click the tool’s name in the tool
window bar. You can also drag, pin, unpin, attach, and detach tool windows.

 To return to the current default tool window layout, click Window > Restore
Default Layout or customize your default layout by clicking Window > Store
Current Layout as Default.

 To show or hide the entire tool window bar, click the window icon in the
bottom left-hand corner of the Android Studio window.

 To locate a specific tool window, hover over the window icon and select the
tool window from the menu.

Navigation
Here are some tips to help you move around Android Studio.

 Switch between your recently accessed files using the Recent Files action.
Press Control+E (Command+E on a Mac) to bring up the Recent Files action.
By default, the last accessed file is selected. You can also access any tool
window through the left column in this action.

 View the structure of the current file using the File Structure action. Bring up
the File Structure action by pressing Control+F12 (Command+F12 on a Mac).
Using this action, you can quickly navigate to any part of your current file.
 Search for and navigate to a specific class in your project using the Navigate
to Class action. Bring up the action by pressing Control+N(Command+O on a
Mac). Navigate to Class supports sophisticated expressions, including camel
humps, paths, line navigate to, middle name matching, and many more. If
you call it twice in a row, it shows you the results out of the project classes.

 Navigate to a file or folder using the Navigate to File action. Bring up the
Navigate to File action by pressing Control+Shift+N (Command+Shift+O on a
Mac). To search for folders rather than files, add a / at the end of your
expression.

 Navigate to a method or field by name using the Navigate to Symbol action.

Bring up the Navigate to Symbol action by
pressing Control+Shift+Alt+N(Command+Shift+Alt+O on a Mac).

 Find all the pieces of code referencing the class, method, field, parameter,
or statement at the current cursor position by pressing Alt+F7

Gradle Build System

Android Studio uses Gradle as the foundation of the build system, with
more Android-specific capabilities provided by the Android plugin for Gradle.
This build system runs as an integrated tool from the Android Studio menu,
and independently from the command line. You can use the features of the
build system to do the following:

 Customize, configure, and extend the build process.

 Create multiple APKs for your app, with different features using the same
project and modules.

 Reuse code and resources across sourcesets.

 By employing the flexibility of Gradle, you can achieve all of this without
modifying your app's core source files. Android Studio build files are
namedbuild.gradle. They are plain text files that use Groovy syntax to
configure the build with elements provided by the Android plugin for Gradle.
Each project has one top-level build file for the entire project and separate
module-level build files for each module. When you import an existing project,
Android Studio automatically generates the necessary build files.

Multiple APK Support

Multiple APK support allows you to efficiently create multiple APKs

based on screen density or ABI. For example, you can create separate APKs of
an app for the hdpi and mdpi screen densities, while still considering them a
single variant and allowing them to share test APK, javac, dx, and ProGuard
settings.
Debug and Profile Tools
Android Studio assists you in debugging and improving the performance of
your code, including inline debugging and performance analysis tools.

Inline debugging
Use inline debugging to enhance your code walk-throughs in the debugger
view with inline verification of references, expressions, and variable values.
Inline debug information includes:

 Inline variable values

 Referring objects that reference a selected object

 Method return values

 Lambda and operator expressions

 Tooltip values

Performance monitors

Android Studio provides performance monitors so you can more easily

track your app’s memory and CPU usage, find deallocated objects, locate
memory leaks, optimize graphics performance, and analyze network requests.
With your app running on a device or emulator, open the Android Monitortool
window, and then click the Monitors tab.

Allocation tracker

Android Studio allows you to track memory allocation as it monitors

memory use. Tracking memory allocation allows you to monitor where objects
are being allocated when you perform certain actions. Knowing these
allocations enables you to optimize your app’s performance and memory use
by adjusting the method calls related to those actions.
Code inspections

Whenever you compile your program, Android Studio automatically runs

configured Lint and other IDE inspections to help you easily identify and
correct problems with the structural quality of your code.

The Lint tool checks your Android project source files for potential bugs and
optimization improvements for correctness, security, performance, usability,
accessibility, and internationalization.
Coding
FEASIBILITY REPORT

Feasibility Studyis a high level capsule version of the entire process

intended to answer a number of questions like: What is the problem? Is there
any feasible solution to the given problem? Is the problem even worth solving?
Feasibility study is conducted once the problem clearly understood. Feasibility
study is necessary to determine that the proposed system is Feasible by
considering the technical, Operational, and Economical factors. By having a
detailed feasibility study the management will have a clear-cut view of the
proposed system.
The following feasibilities are considered for the project in order to ensure
that the project is variable and it does not have any major obstructions.
Feasibility study encompasses the following things:

 Technical Feasibility
 Economic Feasibility
 Operational Feasibility

In this phase, we study the feasibility of all proposed systems, and pick the
best feasible solution for the problem. The feasibility is studied based on three
main factors as follows.
 Technical Feasibility

In this step, we verify whether the proposed systems are technically

feasible or not. i.e., all the technologies required to develop the system
are available readily or not.
Technical Feasibility determines whether the organization has the
technology and skills necessary to carry out the project and how this
should be obtained. The system can be feasible because of the following
grounds:

 All necessary technology exists to develop the system.

 This system is too flexible and it can be expanded further.
 This system can give guarantees of accuracy, ease of use, reliability
and the data security.
 This system can give instant response to inquire.
Our project is technically feasible because, all the
technology needed for our project is readily available.

Operating System : Android v5.0

or Higher (For Android Devices)

Languages : JAVA

Database System : MS-SQL Server

Documentation Tool : MS - Word

  Economic Feasibility

Economically, this project is completely feasible because it

requires no extra financial investment and with respect to time, it’s
completely possible to complete this project in 6 months.

In this step, we verify which proposal is more economical. We

compare the financial benefits of the new system with the investment.
The new system is economically feasible only when the financial benefits
are more than the investments and expenditure. Economic Feasibility
determines whether the project goal can be within the resource limits
allocated to it or not. It must determine whether it is worthwhile to
process with the entire project or whether the benefits obtained from
the new system are not worth the costs. Financial benefits must be
equal or exceed the costs. In this issue, we should consider:

 The cost to conduct a full system investigation.

 The cost of h/w and s/w for the class of application being considered.
 The development tool.
 The cost of maintenance etc...

Our project is economically feasible because the cost of development is

very minimal when compared to financial benefits of the application.
  Operational Feasibility

In this step, we verify different operational factors of the proposed

systems like man-power, time etc., whichever solution uses less operational
resources, is the best operationally feasible solution. The solution should also
be operationally possible to implement. Operational Feasibilitydetermines if
the proposed system satisfied user objectives could be fitted into the current
system operation.

 The methods of processing and presentation are completely accepted

by the clients since they can meet all user requirements.
 The clients have been involved in the planning and development of
the system.
 The proposed system will not cause any problem under any
circumstances.

Our project is operationally feasible because the time requirements and

personnel requirements are satisfied. We are a team of four members and we
worked on this project for three working months.
 TESTING

As the project is on bit large scale, we always need testing to make it

successful. If each component work properly in all respect and gives desired
output for all kind of inputs then project is said to be successful. So, the
conclusion is-to make the project successful, it needs to be tested.

The testing done here was System Testing checking whether the user
requirements were satisfied. The code for the new system has been written
completelyusing JAVA as the coding language and Android Studio as the
interface for front-end designing.The new system has been tested well with
the help of the users and all the applications have been verified from every
nook and corner of the user.

Although some applications were found to be erroneous these

applications have been corrected before being implemented. The flow of the
forms has been found to be very much in accordance with the actual flow of
data.
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:

Client Needs Acceptance Testing

Requirements System Testing

Design Integration Testing

Code Unit Testing

A series of testing is done for the proposed system before the system
is ready for the user acceptance testing.

The steps involved in Testing are:

 Unit Testing
Unit testing focuses verification efforts on the smallest unit of the
software design, the module. This is also known as “Module Testing”. The
modules are tested separately. This testing carried out during programming
stage itself. In this testing each module is found to be working satisfactorily as
regards to the expected output from the module.
  Integration Testing
Data can be grossed across an interface; one module can have
adverse efforts on another. Integration testing is systematic testing for
construction the program structure while at the same time conducting tests to
uncover errors associated with in the interface. The objective is to take unit
tested modules and build a program structure. All the modules are combined
and tested as a whole. Here correction is difficult because the isolation of
cause is complicate by the vast expense of the entire program. Thus in the
integration testing stop, all the errors uncovered are corrected for the text
testing steps.

 System testing
System testing is the stage of implementation that is aimed at ensuring that
the system works accurately and efficiently for live operation commences.
Testing is vital to the success of the system. System testing makes a logical
assumption that if all the parts of the system are correct, then goal will be
successfully achieved.

 Validation Testing
At the conclusion of integration testing software is completely
assembled as a package, interfacing errors have been uncovered and corrected
and a final series of software tests begins, validation test begins. Validation
test can be defined in many ways. But the simple definition is that validation
succeeds when the software function in a manner that can reasonably
expected by the customer. After validation test has been conducted one of two
possible conditions exists.
 One is the function or performance characteristics confirm to
specifications and are accepted and the other is deviation from specification is
uncovered and a deficiency list is created. Proposed system under
consideration has been tested by using validation testing and found to be
working satisfactorily.

 Output Testing
After performing validation testing, the next step is output testing of
the proposed system since no system could be useful if it does not produce the
required output in the specified format. Asking the users about the format
required by them tests the outputs generated by the system under
consideration. Here the output format is considered in two ways, one is on the
screen and other is the printed format. The output format on the screen is
found to be correct as the format was designed in the system designed phase
according to the user needs.
For the hard copy also the output comes as the specified
requirements by the users. Hence output testing does not result any
corrections in the system.

 User Acceptance Testing

User acceptance of a system is the key factor of the success of any
system. The system under study is tested for the user acceptance by constantly
keeping in touch with the prospective system users at the time of developing
and making changes wherever required.
Test Cases

Registration: To begin with login, user need to register by filling up basic

registration details. There are multiple fields in registration page and every
field has to fill by user. User cannot use character in the login id field.

Login: - Login id and password are kept compulsory fields, and if the id or
password doesn’t match then it will show an error message.

VALIDATION CRITERIA

1. In each form, no field which is not null able should be left blank.
2. All numeric fields should be checked for non-numeric values. Similarly,
text fields like names should not contain any numeric characters.
3. All primary keys should be automatically generated to prevent the user
from entering any existing key.
4. Use of error handling for each Save, Edit, delete and other important
operations.
5. Whenever the user Tabs out or Enter from a text box, the data should
be validated and if it is invalid, focus should again be sent to the text box
with proper message.
 ADVANTAGES OF PROJECT

Advantages:

 Streamlined Store Management

 Efficient Counter Operations
 Comprehensive Sales Reporting
 User-Friendly Experience
 Enhanced Accuracy
Limitations
 This application requires an active internet connection.
 The userneeds to put correct data or else it behaves abnormally.

Features

1) Load Balancing:
Since the system will be available only the admin logs in the
amount of load on server will be limited to time period of admin access.

2) Easy Accessibility:
Records can be easily accessed and store and other information
respectively.

3) User Friendly:
The application will be giving a very user-friendly approach for all
user.

4) Efficient and reliable:

Maintaining the all secured and database on the server which will be
accessible according the user requirement without any maintenance
cost will be a very efficient as compared to storing all the customer data
on the spreadsheet or in physically in the record books.

5) Easy maintenance:
Android Retail Management Systemis design as easy way. So
maintenance is also easy.
 CONCLUSION

This was our project of System Design about “Android Retail

Management System” developed in Android application based on Java
languagedeveloped in android programming language. The Development of
this system takes a lot of efforts from us. We think this system gave a lot of
satisfaction to all of us. Though every task is never said to be perfect in this
development field even more improvement may be possible in this application.
We learned so many things and gained a lot of knowledge about development
field. We hope this will prove fruitful to us.
 BIBLIOGRAPHY

► Websites

 en.wikipedia.org

 https://www.kashipara.com/project/idea/php/
retailmanagement_517.html
 https://www.studentprojectguide.com/php/online-retail-management-
system/