FINAL PROJECT REPORT

ON
(PROJECT TITLE)

Submitted To
Mam Tanzila

Submitted By
Naseem Akhtar
Registration No
2017-2019

Institute of Computer Science and Information Technology

The Women University, Multan.
 FINAL APPROVAL

I hereby submit this thesis to Institute of Computer Science and Information

Technology, The Women University, Multan in partial fulfilment of the requirements
for the degree of Bachelor of Science in Computer Science BS(CS).

____________________
Student Name Naseem Akhtar
Registration No

____________________
Supervisor
Mam Tanzila
Institute of Computer Science and Information Technology
The Women University, Multan

____________________
External Examiner
Examiner Name

____________________
Director
Director Name
Institute of Computer Science and Information Technology
The Women University, Multan
 EXORDIUM

In the name of Allah, the Most Gracious, the Most Merciful

Praise be to Allah, Lord of Creation,
The Compassionate, The Merciful,
King of Judgement Day

You alone we worship, and to You alone we pray for help,

Guide us to straight path

The path of those who You have favored

Not of those who you have incurred your wrath,

Nor of those who have gone astray
 DEDICATION

I dedicate my work to my parents who gave me strength to move on which

educated me and enabled me to reach at this level. I really love my parents and I also
humbly dedicate this project to my supervisor (mam tanzila) whose untiring support
and assistance has made possible the fruition of my efforts. Thanks to all my friends
for their cooperation in our studies. And most of all to our great creator “ALLAH
ALMIGHTY” author of knowledge and wisdom that made this possible.
 ACKNOWLEDGEMENT

I would like to express our special thanks of gratitude to our teacher “mam
tanzila” who gave me the golden opportunity to do this wonderful project on the topic
of “Auction system” which also helped me in doing a lot of research and I came to
know about so many new things. I am really thankful to my gratitude teacher.
Secondly, I would also like to thanks my parents and friends who helped me a
lot in finalizing this project within limited time.

Thank You
 ABSTRACT

This project, An Online Auction System has two parts- customer interface and
admin interface. Customer Panel permits a customer to upload a product for sale and
bid on a particular product to buy. This system presents an online display of category
wised products they want to sell or bid. There is an admin panel by which an admin
can control the whole bidding system. Admin can approve products by the categories
and also can control the registered custoers. There is fixed delivery policy. After
finishing the bidding process there is a notify system to notify the sellers and bidders.
This is a fully dynamic system which can be easily operated by the users.
 PROJECT BRIEF

Project Name: Auction System

Undertaken By: Naseem Akhtar
Supervised By: Mam Tanzila
Starting Date: 01-11-2018
Completion Date: 11-05-2019
Operating System: Windows 10
System Used: Intel Core i3
Platform: Sublime Text
Application Server: Apache (XAMPP)
Database Server: MySQL
Language: PHP, JavaScript
Framework: Bootstrap
 PREFACE

The online auctioning system is a flexible solution for supporting lot- based
online auctions. The thesis explains the construction of an auction website. The
system has been designed to be highly-scalable and capable of supporting large
numbers of bidders in an active auction. The online auction system lets you easily
browse lots and place bids using a secure server. All cost of mailing lots will be paid
by the buyer. The objective is to develop a user-friendly auctioning site where any
kind of product can be auctioned and provide value added services to the bidders and
the sellers. The products will be authenticated and the site provides a safe
environment for online users.by using XAMPP, and MySQL database was used to
store the application data.
 TABLE OF CONTENT

CHAPTER 1 INTRODUCTION 1

1.1. INTRODUCTION 2
1.2. OBJECTIVE OF PROJECT 2
1.3. SCOPE OF PROJECT 2
1.4. BENEFITS 3
1.5. SYSTEM REQUIREMENTS 3
1.5.1. SOFTWARE REQUIREMENTS 3
1.5.2. HARDWARE REQUIREMENTS 3
1.6. ORGANIZATION OF THESIS 4
1.7. SUMMARY 4

CHAPTER 2 EXISTING SYSTEM & REQUIREMENT ANALYSIS 5

2.1. INTRODUCTION 6
2.2. EXISTING SYSTEM 6
2.3. ANALYSIS OF EXISTING SYSTEM 6
2.3.1. UNDERSTANDING THE SYSTEM 6
2.3.2. UNDERSTANDING INVOLVEMENT 6
2.3.3. DATA GATHERING 6
2.3.4. DATA ANALYSIS 6
2.3.5. SYSTEM REQUIREMENT 7
2.4. REQUIREMENT ANALYSIS 7
2.4.1. RAD MODEL 7
2.5. ADVANTAGE OF REQUIREMENT ANALYSIS 8
2.6. SUMMARY 8

CHAPTER 3 PROPOSED SYSTEM & DESIGN 9

3.1. PROPOSED SYSTEM 10

3.2. OBJECTIVE OF PROPOSED SYSTEM 10
3.3. SYSTEM DESIGN 11
3.4. UNIFIED MODERN LANGUAGE 12
3.4.1. GOALS OF UML 12
3.5. WHY USE UML 12
3.6. USE CASE 13
3.6.1. ADMIN USE CASE 13
3.6.2. USER USE CASE 13
3.7. USAGE SCENARIO 13
3.8. SEQUENCE DIAGRAM 13
3.9. ACTIVITY DIAGRAM 14
3.10. ER DIAGRAM 15
3.11. DATAFLOW DIAGRAM 16
3.11.1. DFD FOR ADMIN 17
3.11.2. DFD FOR USER 17
3.12. SUMMARY 17

CHAPTER 4 SOFTWARE REQUIREMENT SPECIFICATION 18

4.1. INTRODUCTION 19
4.2. SOFTWARE REQUIREMENT SPECIFICATION 19
4.3. FUNCTIONAL REQUIREMENTS 20
4.3.1. ADMINS FUNCTIONAL REQUIREMENTS 20
4.3.2. USERS FUNCTIONAL REQUIREMENTS 20
4.3.3. COMMON FUNCTIONAL REQUIREMENTS 20
4.4. NON-FUNCTIONAL REQUIREMENTS 20
4.5. OPERATING ENVIRONMENT 20
4.6. USER CHARACTERISTICS 20
4.7. DESIGN & IMPLEMENTATION CONSTRAINTS 20
4.8. ASSUMPTIONS & DEPENDENCES 21
4.9. SUMMARY 21

CHAPTER 5 DATABASE DESIGN 22

5.1. INTRODUCTION 23
5.2. NORMALIZATION 23
5.3. HOW TO DESIGN DATABASE 23
5.4. ENTITIES OF THE SYSTEM 23
5.5. SUMMARY 24

CHAPTER 6 SYSTEM DEVELOPMENT & TESTING 25

6.1. PLATFORM SELECTION 26

6.2. SELECTION OF LANGUAGES 26
6.2.1. PHP 26
6.2.2. JAVASCRIPT 26
6.2.3. HTML/CSS 27
6.3. SELECTION OF TOOLS 27
6.3.1. XAMPP 28
6.3.2. SUBLIME TEXT 28
6.3.3. MS WORD 28
6.3.4. MS VISIO 28
6.4. TESTING OF SYSTEM 28
6.4.1. SOFTWARE TESTING TYPES: 29
6.4.2. TESTING METHODS: 29
6.4.3. TESTING APPROACHES 29
6.4.4. TESTING LEVELS 30
6.5. TEST CASES 30
6.6. SUMMARY 30
CHAPTER 7 USER GUIDE 31

7.1. INTRODUCTION 32
7.2. ADMIN PANEL 32
7.3. USER SITE 32
7.4. SUMMARY 32

CHAPTER 8 CONCLUSION & FUTURE WORK 33

8.1. CONCLUSION 34
8.2. HURDLES 34
8.3. FUTURE WORK 34
8.4. FEW WORDS IN THE END 34

REFERENCES 35
 LIST OF FIGURES

FIGURE 1 RAD METHOD 7

FIGURE 2 ADMIN USE CASE 13
FIGURE 3 SELLER USE CASE 13
FIGURE 4 BIDDER USE CASE 13
FIGURE 5 SEQUENCE DIAGRAM 15
FIGURE 6 ACTIVITI DIAGRAM 16
FIGURE 7 ER DIAGRAM 18
FIGURE 8 DFD ADMIN 20
FIGURE 9 DFD SELLER 20
FIGURE 10 DFD BIDDER 21
FIGURE 11 SRS TYPES 23
FIGURE 12 NEW CATEGORY PAGE 43
FIGURE 13 ADS LIST PAGE 43
FIGURE 14 VIEW MEMBERS PAGE 44
FIGURE 15 HOME PAGE 44
FIGURE 16 LOGIN MODAL 45
FIGURE 17 REGISTER MODAL 45
FIGURE 18 PROFILE PAGE 45
FIGURE 19 PRODUCT DETAIL PAGE 46
FIGURE 20 START AUCTION 46
 LIST OF TABLES

TABLE 1 ATTACHMENT TABLE.................................................................................................................30

TABLE 2 BID TABLE...................................................................................................................................30
TABLE 3 CATEGORY TABLE.......................................................................................................................30
TABLE 4 COMMENT TABLE......................................................................................................................30
TABLE 5 OPTION TABLE............................................................................................................................30
TABLE 6 LISTING TABLE............................................................................................................................31
TABLE 7 MESSAGE TABLE.........................................................................................................................31
TABLE 8 NOTIFICATION TABLE.................................................................................................................31
TABLE 9 TOS TABLE..................................................................................................................................31
TABLE 10 TRANSACTION TABLE...............................................................................................................32
TABLE 11 USER TABLE..............................................................................................................................32
 THESIS
ON
AUCTION SYSTEM
 CHAPTER 1
INTRODUCTION
1.1. Introduction
The online auction system is a web application where all products are displayed in
different categories and a customer can bid to the selected category wised product
without facing any problem. The online auction system deals between sellers and
bidders. It provides the users for sign up to this application and search for products,
manages their accounts. Each customer will have their own account showing their
username they have logged in. On the other hand users can also see all product pages
without having an access with their account. Signed up users will have to log in first
then they can upload products on the site from their account and also can bid for other
products which are not owned by them. Users can edit their profile and see their
uploaded products and bided products. Administration panel can approve products,
update products, delete products, delete user, update and delete all ongoing bids and
can also see all the products, categories, users and bids. All particular bids have
limited time to finish. After finishing the bids admin can notify the sellers and also the
bidders. This is a well secured system and can be easily operated. This is fully
dynamic. There is nothing static here. The main aim of this web application is to
make a good online system that provides a great alternative of bidding policy for
general people that saves both time and money

1.2. Objective of Project

General efficiency:
 To increase efficiency and services to the customers through better application
of technology in daily operation.
 For increasing the efficiency of the system, we used object-oriented
programming method.
 To be able to stand out from competitors in the ecommerce sites.
Specific objectives:
 To enable customers to see all the products without any authentication.
 To enable the customers to have a visual confirmation that the bid was placed
correctly.
 To enable the customers to know product details before bid.
 To ensure correct bid placement through visual interface.

1.3. Scope of Project

Following are the scope of the developed systems:
Online Auction System- Bid On will be a web based application which main language
of programming will be PHP. Its main aim is to simplify and improve the efficiency
of the bidding process for users, minimize data entry and ensure data accuracy and
security bid placement process. Users will also be able to view all product menus in
categorized way with their full details. Users will also be able to have a visual
confirmation that the order was place correctly.
1.4. Benefits
The primary benefit to searching for a home by using an online auction is
convenience. As a bidder, you can make offers no matter your location.
The second huge benefit of using online auction sites to buy your home is that you
can place offers at all hours of the day.
By choosing to do your business online, you will usually receive instant feedback. As
the price increases from bids, you will be able to see and adjust your own bids, if
interested.
Using auction sites online to buy your home will save you both time and money. By
doing your shopping online, you won’t waste time traveling to a bunch of properties.
A final benefit to looking for your perfect home online is the number of options you
will have.

1.5. System Requirements

1.5.1. Software Requirements
Operating System: Windows 10
Platform: Sublime Text
Application Server: Apache (XAMPP)
Database Server: MySQL
Language: PHP, JavaScript
Framework: Bootstrap

1.5.2. Hardware Requirements

Computer Used: Intel Core i3
Requirements: Any system with min dual core processor, 1 GB of ram and 40GB
space dedicated to the software can run this software very easily

1.6. Organization of Thesis

Thesis is organized in the following way
Chapter 1
It contains introduction, scope and objectives of the system
Chapter 2
It contains drawbacks of the existing system as well as requirement analysis
Chapter 3
It contains objectives and design of the proposed system
Chapter 4
It contains functional and non-functional requirements of the system
Chapter 5
It contains design of the database and entities of the system
Chapter 6
It contains selection of tools, development of the system as well as testing of the
system
Chapter 7
It contains user guide and screenshots of the projects
Chapter 8
It contains future work and conclusion regarding the project

1.7. Summary
This chapter explain the introduction of the project. It introduces about the
background of the project. Tells what is the scope of the projects, what are the
objectives of the project, what are the software requirements and as well as hardware
requirements and, in the end, tell organization of thesis.
 CHAPTER 2
EXISTING SYSTEM &
REQUIREMENT ANALYSIS
2.1. Introduction
In this step the system before doing something is understood to improve its
functioning. In other words, we must first find out what is going on. It is essential for
system designer to understand the functioning of the system so that he can improve
the existing system. To understand the system, we must first involve in the system.
And sometimes this involvement in the system become very deep. During this system
designer greatly deals with the subject matter. So that he can know what is going on
and what he must do.

2.2. Existing System

The existing system is managed manually. Prior to each auction, the day of auction,
the venue and the items on auction are announced through news media. Those who
wish to take part in the auction have to arrive at the venue on that day on time. This
conventional method most of the times prevent aspiring bidders from participating in
the bidding process. Another headache of the old system is to track each bidding
process and to make it culminate in financial settlement. So the system has to keep
records of both buyers and sellers until the end of settlement. The process is very
cumbersome and time consuming.

2.3. Analysis of Existing System

The analysis is primarily concerned with studying of the system. After
analysis of the existing system, we can design and implement better user-friendly
system.

2.3.1. Understanding the System

The most important thing for successful computerized system is to complete
understand the existing system

2.3.2. Understanding Involvement

The most successful system or project are those in which user plays an
important, active and vital role. The user knowledge about existing system is useful
for the better system

2.3.3. Data Gathering

Basic work in analysis phase is the gathering and analyzing of the data. Two
common data gathering techniques are interview and questionnaires.

2.3.4. Data Analysis

The collected data serves as foundation for the documentation of the system
analysis phase.

2.3.5. System Requirement

 The purpose of gathering and analysis of the data is to establish the system
requirement because the design of the new system will be based on the requirements

2.4. Requirement Analysis

After an initial feasibility study, the next stage of requirement engineering
process is requirement elicitation and analysis. In this activity, software engineering
work with customers and system end-user to find out about the application domain,
what services the system should, the required performance of the system, hardware
constraints and so on.

2.4.1. Incremental Model

Incremental model is a process of software development where requirements are

broken into multiple standalone module of SDLC(software development life cycle).
Incremental development is done in steps from analysis design, implementation,
testing/verification, maintenance. Each iteration passes through the requirements,
design, coding and testing phases. And each subsequent release of the system
adds function to the previous release until all designed functionality has been
implemented.

This can quickly give the customer something to see and use and to provide feedback
regarding the delivery and their requirements.

Diagram of INCREMENTAL-Model:

Figure 1 INCREMENTAL Method

The phases in the INCREMENTAL model are:

It is assumed that in the early stages of the life cycle
(planning, analysis and design of the project), the system is
designed as a whole Data modeling: At these stages, the
increments and functions related to them are determined.
Each increment then passes through the remaining phases
of the life cycle: coding, testing, and delivery.
2.5. First, we design, test and implement a set of functions that
form the basis of the product, or the requirements of
paramount importance, which play the main role for the
successful implementation of the project or reduce the
degree of risk. The subsequent iterations extend to the core
of the system, gradually improving its functionality or
performance. The addition of functions is carried out by
performing significant increments in order to fully satisfy
the user’s needs. Each additional function is certified in
accordance with a set of requirements.

Following are the advantages of INCREMENTAL Model:

 Not need to spend in advance the funds necessary for the development of the
entire project.
 As a result of each increment, a function product is obtained.
 Cost for the initial delivery of the software product is reduce.
 Risk of failure and changing requirements is reduce.
Scop of INCREMENTAL model:
 If most requirements can be formulated in advance, but their
appearance is expected after a certain period of time;
 If the market window is too “narrow” and there is a need to quickly
put on the market a product with functional basic properties;
 For projects that require a long development time period, typically
one year;
 When developing programs related to low or medium risk;.
 When the results are obtained at regular intervals.
2.6. Summary
This chapter explain the existing system and also describe the failure that it
contains. It also tells that why designers need the computerized system for their users.
Further it describes the requirements for new system. It also explains the software
process model which designers use for development of any system. It tells the model
which has been used in the development of the system.
 CHAPTER 3
PROPOSED SYSTEM &
DESIGN
3.1. Proposed System
After the detail study of existing file system. I have suggested an automated
system as it will eliminate the different problem faced by user in the file system. This
new computerized system will be the best possible solution to the problem being
faced by existing system.
In the proposed system customer need not go to the shop for buying the
products. He can order the product he wish to buy through the website. The shop
owner will be admin of the system. Shop owner can appoint moderators who will help
owner in managing the customers and product orders. The system also recommends a
home delivery system for the purchased products.

3.2. Objective of Proposed System

The new computerized system is designed in a way to minimize the drawback of
present system. The proposed system has following objectives
Efficiency
Efficiency is the degree to which we utilization of resources of achieving the object.
The proposed system is more efficient than currently file system.
Data Security
he data required for decision-making is highly sensitive and valuable. Therefore, the
reliability of the proposed system is secured by giving a regular and guaranteed
services to the user.
Time Factor
The searching and reports make the user to produce reports quickly.
Flexibility
The system allows for changes and enhancement to incorporate future requirement.
Accuracy
The system will provide accurate information, needed for decision making. It will
ensure efficient and accurate record keeping.
User Friendly
User will communicate through easy button clicking
Reliability
Software Reliability is the probability of failure-free software operation for a
specified period of time in a specified environment. So, it is also taken care while
making the project that it should be reliable that's why it is developed in most
advanced language PHP.
Usability
The term "usability" in the context of creating software represents an approach that
puts the user, rather than the system. at the center of the process. This philosophy,
called user-centered design, incorporates user concerns and advocacy from the
beginning of the design process and dictates that the needs of the user should be
foremost in any design decisions. In designing of the project, it is taken care that it
can be easy to use no more complex abilities.
Supportability
Supportability is also very important factor that a system which cans design. It can be
supportable in most of environment. This project is a website which has not too much
supportably issues because it can run on simple browser.
Performance
The system should reduce the time and effort required retrieving information. It
should have the capability to ensure various requirements instantly and efficiently.
Comprehensive Database
The proposed system comprehensive database in which insertion. deletion, searching
and modification. There will be such facilities in the system the user will feel easy and
comfort to drive the system and to save the data according to its will.
Minimize Redundancy
The proposed system has no redundancy. This mean that file is designed in such a
way that minimum data is duplicated in the files.
Ease of Operation
Menu driven facility in main form and command button in other form makes it very
easy to operate the proposed system. Screen guides the operator through the system to
provide the required task

3.3. System Design

System design lies at the core of the software engineering process and is applied
regardless of the software process model that is used. Design is the first step in the
development phase for any engineered product or system. The designer's goal is to
produce a model or representation of an entity that will later be built. Beginning, once
system requirement has been specified and analyzed, system design is the first of the
three technical activities design, code and test that is required to build and verify
software. The importance can be stated with a single word "Quality". Design is the
place where quality is fostered in software development. Design provides us with
representations of software that can assess for quality. Design is the only way that we
can accurately translate a customer's view into a finished software product or system.
Software design serves as a foundation for all the software engineering steps that
follow. Without a strong design, we risk building an unstable system one that will be
difficult to test, one whose quality cannot be assessed until the last stage.
During design, progressive refinement of data structure, program structure, and
procedural details are developed reviewed and documented. System design can be
viewed from either technical or project management perspective. From the technical
point of view, design is comprised of four activities architectural design, data
structure design. interface design and procedural design.

3.4. Unified Modern Language

The Unified Modelling Language (UML) is a standard language for specifying,
visualizing, constructing, and documenting the artefacts of software systems, as well
as for business modelling and other non-software systems. The UML represents a
collection of best engineering practices that have proven successful in the modelling
of large and complex systems. The UML is a very important part of developing
object-oriented software and the software development process. The UML uses
mostly graphical notations to express the design of software projects. Using the UML
helps project teams communicate, explore potential designs, and validate the
architectural design of the software.

3.4.1. Goals of UML

The primary goals in the design of the UML were:
 Provide users with a ready-to-use, expressive modeling language so they can
develop and exchange meaningful models.
 Provide extensibility and specialization mechanisms to extend the core
concepts.
 Be Independent of particular programming languages and development
processes.
 Provide a formal basis for understanding the modeling language.
 Encourage the growth of the 00 tools market.
 Support higher-level development concepts such as collaborations.
frameworks, patterns and components.
7. Integrate best practices.

3.5. Why use UML

As the strategic value of software increases for many companies, the industry looks
for techniques to automate the production of software and to improve quality and
reduce cost and time-to-market. These techniques include component technology,
programming, patterns and frameworks. Businesses also seek techniques to manage
the complexity of systems as they increase in scope and scale. In particular, they
recognize the need to solve recurring architectural problems, such as physical
distribution, concurrency, replication, security, load balancing and fault tolerance.
Additionally, the development for the World Wide Web, while making some things
simpler, has exacerbated these architectural problems. The Unified Modeling
Language (UML) was designed to respond to these needs.
3.6. Use Case
UML Use Case Diagrams. Use case diagrams are usually referred to as behavior
diagrams used to describe a set of actions (use cases) that some system or systems
(subject) should or can perform in collaboration with one or more external users of the
system (actors).
A use case diagram contains four components.
• The boundary, which defines the system of interest in relation to the world
around it.
• The actors, usually individuals involved with the system defined according to
their roles.
• The use cases, which are the specific roles played by the actors within and
around the system.
• The relationships between and among the actors and the use cases.

3.6.1. Admin Use Case

Figure 2 Admin Use Case

3.6.2. Seller Use Case

Figure 3 Seller Use Case

3.6.3. Bidder Use Case

 Figure 4 Bidder Use Case

3.7. Usage Scenario

It is easy to mix up the definitions of use case and use case scenario. A use
case represents the actions that are required to enable or abandon a goal. A use case
has multiple "paths" that can be taken by any user at any one time. A use case
scenario is a single path through the use case. This article provides an example use
case and some diagrams to help visualize the concept.
A usage scenario, or scenario for short, describes a real-world example of how
one or more people or organizations interact with a system. They describe the steps,
events, and/or actions which occur during the interaction. Usage scenarios can be very
detailed, indicating exactly how someone works with the user interface, or reasonably
high-level describing the critical business actions but not the indicating how they're
performed.
Here is some Usage Scenario which can show the process flow of the System.

Use Case Name: User Login

Description: User enters his credentials and then clicks the login button. System
contact with server than server contact with database to match the entered detail of
registered user.
Actor: User
Pre-Conditions: User must be Registered
Success Outcome: Login Successful Fail Outcome: Return to Login Page

Use Case Name: User Registration

Description: User enters his detail and then clicks the register button. System
contact with server than server contact with database to enter detail of requested
user.
Actor: User
Pre-Conditions: Email shouldn’t be used first.
Success Outcome: Use Registered Fail Outcome: Return to Register Page

Use Case Name: Upload Product

Description: User enters his product and then clicks the add button. System contact
with server than server contact with database to enter detail of product.
Actor: Seller
Pre-Conditions: User must be logged in
Success Outcome: Product Uploaded Fail Outcome: Error Alert

Use Case Name: Make Bid

Description: User enters amount and then clicks the bid button. System contact
with server than server contact with database to insert bid.
Actor: Bidder
Pre-Conditions: User must be logged in and Amount should be greater
Success Outcome: Bid Made Fail Outcome: Error Alert

Use Case Name: Add Category

Description: Admin enters his category detail and then clicks the add button.
System contact with server than server contact with database to insert category.
Actor: Admin
Pre-Conditions: Category must be unique.
Success Outcome: Category Added Fail Outcome: Error Alert

3.8. Sequence Diagram

A sequence diagram simply depicts interaction between objects in a sequential order
i.e. the order in which these interactions take place. We can also use the terms event
diagrams or event scenarios to refer to a sequence diagram. Sequence diagrams
describe how and in what order the objects in a system function. These diagrams are
widely used by businessmen and software developers to document and understand
requirements for new and existing systems.
Sequence Diagram Notations –
Actors – An actor in a UML diagram represents a type of role where it interacts with
the system and its objects. It is important to note here that an actor is always outside
the scope of the system we aim to model using the UML diagram.
Lifelines – A lifeline is a named element which depicts an individual participant in a
sequence diagram. So basically each instance in a sequence diagram is represented by
a lifeline. Lifeline elements are located at the top in a sequence diagram. The standard
in UML for naming a lifeline follows the following format – Instance Name : Class
Name
Messages – Communication between objects is depicted using messages. The
messages appear in a sequential order on the lifeline. We represent messages using
arrows. Lifelines and messages form the core of a sequence diagram.
 Figure 5 Sequence Diagram

3.9. Activity Diagram

Activity diagram is another important diagram in UML to describe the dynamic
aspects of the system.
Activity diagram is basically a flowchart to represent the flow from one activity to
another activity. The activity can be described as an operation of the system.
The control flow is drawn from one operation to another. This flow can be sequential,
branched, or concurrent. Activity diagrams deal with all type of flow control by using
different elements such as fork, join, etc
Purpose
The basic purposes of activity diagrams is similar to other four diagrams. It captures
the dynamic behavior of the system. Other four diagrams are used to show the
message flow from one object to another but activity diagram is used to show
message flow from one activity to another.
Activity is a particular operation of the system. Activity diagrams are not only used
for visualizing the dynamic nature of a system, but they are also used to construct the
executable system by using forward and reverse engineering techniques. The only
missing thing in the activity diagram is the message part.
The purpose of an activity diagram can be described as −
• Draw the activity flow of a system.
• Describe the sequence from one activity to another.
• Describe the parallel, branched and concurrent flow of the system.
 Figure 6 Activiti Diagram

3.10. ER Diagram
An entity-relationship diagram (ERD) is a graphical representation of an information
system that shows the relationship between people, objects, places, concepts or events
within that system. An ERD is a data modeling technique that can help define
business processes and can be used as the foundation for a relational database.
While useful for organizing data that can be represented by a relational structure, an
entity-relationship diagram can't sufficiently represent semi-structured or unstructured
data, and an ERD is unlikely to be helpful on its own in integrating data into a pre-
existing information system.
Three main components of an ERD are the entities, which are objects or concepts that
can have data stored about them, the relationship between those entities, and the
cardinality, which defines that relationship in terms of numbers.
For example, an ER diagram representing the information system for a company's
sales department might start with graphical representations of entities such as the sales
representative, the customer, the customer's address, the customer's order, the product
and the warehouse. (See diagram) Then lines or other symbols can be used to
represent the relationship between entities, and text can be used to label the
relationships.
Finally, cardinality notations define the attributes of the relationship between the
entities. Cardinalities can denote that an entity is optional (for example, a sales rep
could have no customers or could have many) or mandatory (for example, the must be
at least one product listed in an order.)
Relationships: A relationship, in the context of databases, is a situation that exists
between two relational database tables when one table has a foreign key that
references the primary key of the other table. Relationships allow relational databases
to split and store data in different tables, while linking disparate data items.
Cardinality and ordinality, respectively, refer to the maximum number of times an
instance in one entity can be associated with instances in the related entity, and the
minimum number of times an instance in one entity can be associated with an instance
in the related entity. Cardinality and ordinality are
When it comes to notation, data modelers have many options to choose from. While
crow's foot notation is widely accepted as the most intuitive style, some developers
use OMT, IDEF, Bachman, or UML notation to indicate cardinality. Since crow's foot
notation shows both minimum and maximum cardinality in an easy-to-read graphic
format.
The three main cardinal relationships are:
One-to-one (1:1). For example, if each customer in a database is associated with one
mailing address.
One-to-many (1:M). For example, a single customer might place an order for multiple
products. The customer is associated with multiple entities, but all those entities have
a single connection back to the same customer.
Many-to-many (M:N). For example, at a company where all call center agents work
with multiple customers, each agent is associated with multiple customers, and
multiple customers might also be associated with multiple agents.
While there are tools to help draw entity-relationship diagrams, such as CASE
(computer-aided software engineering) tools, some relational database management
systems also have design capabilities built in.
 Figure 7 Er Diagram

3.11. Dataflow Diagram

A two-dimensional diagram that explains how data is processed and transferred in a
system. The graphical depiction identifies each source of data and how it interacts
with other data sources to reach a common output.
Individuals seeking to draft a data flow diagram must
(1) identify external inputs and outputs,
(2) determine how the inputs and outputs relate to each other, and
(3) explain with graphics how these connections relate and what they result in.
This type of diagram helps business development and design teams visualize how data
is processed and identify or improve certain aspects. A data flow diagram (DFD)
illustrates how data is processed by a system in terms of inputs and outputs. As its
name indicates its focus is on the flow of information, where data comes from, where
it goes and how it gets stored.
DFD graphically representing the functions, or processes, which capture, manipulate,
store, and distribute data between a system and its environment and between
components of a system. The visual representation makes it a good communication
tool between User and System designer. Structure of DFD allows starting from a
broad overview and expand it to a hierarchy of detailed diagrams. DFD has often been
used due to the following reasons:
• Logical information flow of the system
• Determination of physical system construction requirements
• Simplicity of notation
• Establishment of manual and automated systems requirements
There are four basic symbols that are used to represent a data-flow diagram.
Process
A process receives input data and produces output with a different content or form.
Processes can be as simple as collecting input data and saving in the database, or it
can be complex as producing a report containing monthly sales of all retail stores in
the northwest region.
Data Flow
A data-flow is a path for data to move from one part of the information system to
another. A data-flow may represent a single data element such the Customer ID or it
can represent a set of data element (or a data structure).
Data Store
A data store or data repository is used in a data-flow diagram to represent a situation
when the system must retain data because one or more processes need to use the
stored data in a later time.
External Entity
An external entity is a person, department, outside organization, or other information
system that provides data to the system or receives outputs from the system. External
entities are components outside of the boundaries of the information systems.

3.11.1. DFD for Admin

 Figure 8 DFD Admin

3.11.2. DFD for Seller

Figure 9 DFD Seller

3.11.3. DFD Bidder

 Figure 10 DFD Bidder

3.12. Summary
This chapter explain the proposed system and also describe the objective of it.
It tells the only a computerized system can fulfil our needs. Further it describes the
system design which is first step in development phase. It also explains the UML,
Goals of UML and usage scenario.
 CHAPTER 4
SOFTWARE REQUIREMENT
SPECIFICATION
4.1. Introduction
This chapter presents the functional and non-functional requirement of the
system and it also discuss the guideline for system designer to start working on the
system.

4.2. Software Requirement Specification

A System Requirement specification (SRS) is a comprehensive description of
the intended purpose and environment for software under development. The SRS fully
describe what the software will do and how it will be expected to perform. It discusses
the different type of requirements for the system including functional, non-functional
requirements also describe the environment in which the system will operate. Next
section describes all these requirements.
Qualities
• Correct
• Unambiguous
• Complete
• Consistent
• Ranked for importance and/or stability
• Verifiable
• Modifiable
• Traceable
Types of Requirements
The below diagram depicts the various types of requirements that are captured during
SRS.

Figure 11 SRS Types

4.3. Functional Requirements
Functional requirements describe how a product must behave, what its features and
functions.

4.3.1. Admins Functional Requirements

The system ensures high security, business integrity and confidentiality through full
information logon to the system by the administrator. The administrator has to login
to the system with his user-id and password in order to perform his responsibilities.
The responsibilities of the web administrator are as follows
• Admin shell manage the users of the system like seller, bidder, buyer, auction
manager.
•Shell manage the fraud data, if admin detects any fraud data entered by any user then
he can block those users from accessing the site.
• Shell add categories for the products.
• Shell view transaction reports.
• Shell view auction process details.

4.3.2. Auction Manager / Seller

An auction manager has access to the whole process of auction. The auction manager
has the following responsibilities.
• Edit the product details like closing date of bidding for the product.
• Get the detailed product information from the seller.
• Manage the bidding history of a product
• Select the bidder to whom the product must be sold.
• Process the transaction by contacting the buyer and seller through e-mail
• Settle the transaction within a time frame
• Give points to the buyer and the seller after receiving feedback
The seller can sell his products through the auction website in a easier way. He can
perform the following actions.
• View and edit his account details.
• Register products for auction.
• Registrations need payment from the seller. He can pay through credit card or
paypal account to the website.
• Select category under which he needs to add products.
• Add product information like product name, product details, starting bid amount ,
shipping cost involved and also upload image for the product.
• View bidding history of the product.
• View bidding history of bidder
• Answer to the questions of bidder.
• Contact the buyer though email for further transactions.
• Contact the auction manager through email regarding the problems in the auction.
• Deliver the product to the buyer after getting the payment for the product.
• Give feedback to the buyer after getting the payment.

4.3.3. Bidder/ Buyer Functional Requirements

The bidder is the person who participates in the bidding of a product. The bidder have
access to only few functionalities listed below and is restricted from other
functionalities depending on the system.
• View his profile
• Edit his account details
• View his bidding history
• View the products in the website
• Select the product for bidding.
• View the points of seller.
• Can bid any number of times on a single product.
• The bid amount given by the bidder must be greater than or equal to the starting bid
amount given by the seller.
• View FAQ
• Ask questions to the seller of product.
• View his answers given by the seller.
Buyer is the bidder who gave the largest bidding amount for a product. He can
perform all the actions of a bidder as well as the following ones
• Pay for the product through paypal or credit card including the shipping cost of the
product.
• Give details of himself to the seller so that the seller can deliver the product.
• Give feedback to the seller after receiving the product.

4.4. Non-Functional Requirements

Nonfunctional requirements describe the general characteristics of a system. They are
also known as quality attributes.
This section discusses the non-functional requirements of the system.
User Friendly:
This system is very interactive and easy to use.
Maintainability:
Backups for database are available.
Performance:
Easy tracking of records and updating can be done.
Security:
Only authorized user can access system.

4.5. Operating Environment

The following System is a website and shall operate in all famous browsers.
For a model, we are taking Google chrome, Mozilla Firefox with flash player and
JavaScript.

4.6. User Characteristics

User of this system are general public and administrators who maintain the
website. General public are assumed to have basic knowledge of Computer and
Internet browsing. Administrator of the system should have more knowledge of
internal modules of the system ad able to rectify small problem that may arises due to
disk crashes, power failures and other catastrophes.

4.7. Design & Implementation Constraints

• The information of all the records must be stored in a database that is
accessible by the website.
• MySQL Server will be used SQL engine and database.
• This system is working 24 hours a day.
• User may access from any computer that has Internet browsing capabilities
and an Internet connection.
• User must have their correct username and password to enter into their online
accounts and do action.

4.8. Assumptions & Dependences

The product needs the following third-party products.
• MySQL server to store the database.

4.9. Summary
 This chapter is about the requirements of the system being developed. It
contains the features that present in the proposed system. It also describes working of
the system. It explains the operational, functional & non-functional requirement of the
system. Further, it contains environment in which the system will operate and the
users who will use the system.
 CHAPTER 5
DATABASE DESIGN
5.1. Introduction
The most important phase of any project is design of database i.e. the
designing of different normalized tables and then the relationship between those
normalized tables. So, after a Comprehensive study of the existing system it is
decided to develop the normalized tables for the database. Before describing those
normalized tables, it will be better to understand the term normalization.

5.2. Normalization
Database Normalization is a technique of organizing the data in the database.
Normalization is a systematic approach of decomposing tables to eliminate data
redundancy(repetition) and undesirable characteristics like Insertion, Update and
Deletion Anomalies. It is a multi-step process that puts data into tabular form,
removing duplicated data from the relation tables.
Normalization is used for mainly two purposes,
• Eliminating redundant (useless) data.
• Ensuring data dependencies make sense i.e. data is logically stored.
The inventor of the relational model Edgar Codd proposed the theory of normalization
with the introduction of First Normal Form, and he continued to extend theory with
Second and Third Normal Form. Later he joined with Raymond F. Boyce to develop
the theory of Boyce-Codd Normal Form.
Theory of Data Normalization in SQL is still being developed further. For example,
there are discussions even on 6th Normal Form. However, in most practical
applications, normalization achieves its best in 3rd Normal Form. The evolution of
Normalization theories is illustrated below-

5.3. How to Design Database

This phase is also most time-consuming part of the project and it comes after the
comprehensive study of the existing system. If the analyst will not spend adequate
time in this phase, he will not be able to fulfil the requirement of the users. This phase
has following three tasks:
• Identifying the entities of the system.
• Identifying the relation between entities.
• Designing the normalized database.

5.4. Entities of the System

Entity is an object, or concept about we have to store data m the system. The
attribute of an entity set define its properties and qualities. After the detail study of the
system the following entities have been identified with their attributes.
5.4.1. Attachment Table

Table 1 Attachment Table

5.4.2. Bid Table

Table 2 Bid Table

5.4.3. Category Table

Table 3 Category Table

5.4.4. Comment Table

Table 4 Comment Table

5.4.5. Option Table

Table 5 Option Table

5.4.6. Listing Table

Table 6 Listing Table

5.4.7. Message Table

Table 7 Message Table

5.4.8. Notification Table

Table 8 Notification Table

5.4.9. Tos Table

Table 9 Tos Table

5.4.10. Transaction Table

Table 10 Transaction Table

5.4.11. User Table

Table 11 User Table

5.5. Summary
This chapter explains the database, structure of the database, the design of the
database. It discusses the entities of the database and their attributes. It also shows the
structure of the tables stored in the database of the proposed system.
 CHAPTER 6
SYSTEM DEVELOPMENT &
TESTING
6.1. Platform Selection
Platform selection is very important step in software development. Because
software that you needed to develop or run may not be able to if a wrong platform is
selected. But since I am developing a php website which can be done on any platform
so I selected Windows 10 for OS. Because I am very much familiar with it.

6.2. Selection of Languages

Many points play an important role in selection of languages. For the
designing of the frontend the straight forward answer was to use HTML and CSS
because we don’t have any other options. For some functions we needed JavaScript.
But the most important selection was of the server-side language. Since I had to up to
5 months, I had to use rad model for development. I had to preferred PHP over ASP
because it seem easier. And I had a bit of familiarity with it.

6.2.1. PHP
The PHP Hypertext Pre-processor (PHP) is a programming language that
allows web developers to create dynamic content that interacts with databases. PHP is
basically used for developing web-based applications. PHP is an HTML-embedded
Web scripting language. This means PHP code can be inserted into the HTML of a
Web page. When a PHP page is accessed, the PHP code is read or "parsed" by the
server the page resides on. The output from the PHP functions on the page are
typically returned as HTML code, which can be read by the browser. Because the
PHP code is transformed into HTML before the page is loaded, users cannot view the
PHP code on a page. This make PHP pages secure enough to access databases and
other secure information.
A lot of the syntax of PHP is borrowed from other languages such as C, Java
and Perl. However, PHP has a number of unique features and specific functions as
well. The goal of the language is to allow Web developers to write dynamically
generated pages quickly and easily. PHP is also great for creating database-driven
Web sites.

6.2.2. JavaScript
JavaScript is a programming language commonly used in web development. It
was originally developed by Netscape as a means to add dynamic and interactive
elements to websites. While JavaScript is influenced by Java, the syntax is more
similar to C and is based on ECMAScript, a scripting language developed by Sun
Microsystems.
JavaScript is a client-side scripting language, which means the source code is
processed by the client's web browser rather than on the web server. This means
JavaScript functions can run after a webpage has loaded without communicating with
the server. For example, a JavaScript function may check a web form before it is
submitted to make sure all the required fields have been filled out. The JavaScript
code can produce an error message before any information is actually transmitted to
the server.
Like server-side scripting languages, such as PHP and ASP, JavaScript code
can be inserted anywhere within the HTML of a webpage. However, only the output
of server-side code is displayed in the HTML, while JavaScript code remains fully
visible in the source of the webpage. It can also be referenced in a separate .JS file,
which may also be viewed in a browser.

6.2.3. HTML/CSS
Hypertext Markup Language (HTML) is the standard markup language for
creating web pages and web applications. With Cascading Style Sheets (CSS) and
JavaScript, it forms a triad of cornerstone technologies for the World Wide Web.
Web browsers receive HTML documents from a web server or from local
storage and render the documents into multimedia web pages. HTML describes the
structure of a web page semantically and originally included cues for the appearance
of the document.
HTML can embed programs written in a scripting language such as
JavaScript, which affects the behavior and content of web pages. Inclusion of CSS
defines the look and layout of content. The World Wide Web Consortium (W3C),
maintainer of both the HTML and the CSS standards, has encouraged the use of CSS
over explicit presentational HTML since 1997.
Cascading Style Sheets (CSS) is a style sheet language used for describing the
presentation of a document written in a markup language like HTML. CSS is a
cornerstone technology of the World Wide Web, alongside HTML and JavaScript.
CSS is designed to enable the separation of presentation and content, including
layout, colors, and fonts. This separation can improve content accessibility, provide
more flexibility and control in the specification of presentation characteristics, enable
multiple web pages to share formatting by specifying the relevant CSS in a separate
.css file, and reduce complexity and repetition in the structural content.
The CSS specifications are maintained by the World Wide Web Consortium
(W3C). Internet media type (MIME type) text/css is registered for use with CSS by
RFC 2318 (March 1998). The W3C operates a free CSS validation service for CSS
documents. In addition to HTML, other markup languages support the use of CSS
including XHTML, plain XML, SVG, and XUL.

6.3. Selection of Tools

I had only two choices either to choose WAMP or XAMPP since we were
developing on windows while other of configuring apache, php and MySQL by our
self was painful and time consuming. I decided to go with XAMPP as it has built-in
debugger and easy to trace errors. For editor I used sublime text as it very light and
very easy to code in it. It provides many shortcuts. For thesis reporting I choose MS
Word since my platform is Microsoft Windows and I also choose Microsoft Visio for
drawing purpose again as we are developing in Microsoft Windows.

6.3.1. XAMPP
XAMPP is a free and open-source cross-platform web server solution stack
package developed by Apache Friends, consisting mainly of the Apache HTTP
Server, MariaDB database, and interpreters for scripts written in the PHP and Perl
programming languages. Since most actual web server deployments use the same
components as XAMPP, it makes transitioning from a local test server to a live server
possible.
XAMPP's ease of deployment means a WAMP or LAMP stack can be
installed quickly and simply on an operating system by a developer. With the
advantage a number of common add-in applications such as Wordpress and Joomla!
can also be installed with similar ease using Bitnami.
The term XAMPP is an apparent acronym. However, there is no official
acronym expansion specified on the Apache Friends website. Their homepage header
reads "XAMPP Apache + MariaDB + PHP + Perl", indicating that this abbreviation is
a recursive acronym.

6.3.2. Sublime Text

Sublime Text is a proprietary cross-platform source code editor with a Python
application programming interface (API). It natively supports many programming
languages and markup languages, and functions can be added by users with plugins,
typically community-built and maintained under free-software licenses.

6.3.3. MS Word
Word processing is an application program. It provides different tool to create
all kind of text documents. With word processor images, sounds, chart and graphics
can be added to the documents. Word processor can also be used to create web
documents. Hyperlinks, text and graphics can also be added to the web documents.
Different type of Word processing software is available as open source. Microsoft
office one of the famous that are available freely to be used different users.MS word
in also the component of the suite which is used in the project for documentation.

6.3.4. MS Visio
Microsoft Visio is software for drawing a variety of diagrams. These include
flowcharts, org charts, building plans, floor plans, data flow diagrams, process flow
diagrams, business process modeling, swimlane diagrams, 3D maps, and many more.

6.4. Testing of System

Software testing is a process, to evaluate the functionality of a software application
with an intent to find whether the developed software met the specified requirements
or not and to identify the defects to ensure that the product is defect free in order to
produce the quality product.
Let’s see standard definition, software testing types such as manual and automation
testing, testing methods, testing approaches and types of black box testing.
Definition:
According to ANSI/IEEE 1059 standard – A process of analyzing a software item to
detect the differences between existing and required conditions (i.e., defects) and to
evaluate the features of the software item.

6.4.1. Software Testing Types:

Manual Testing: Manual testing is the process of testing the software manually to find
the defects. Tester should have the perspective of end users and to ensure all the
features are working as mentioned in the requirement document. In this process,
testers execute the test cases and generate the reports manually without using any
automation tools.
Automation Testing: Automation testing is the process of testing the software using
an automation tool to find the defects. In this process, testers execute the test scripts
and generate the test results automatically by using automation tools. Some of the
famous automation testing tools for functional testing are QTP/UFT and Selenium.

6.4.2. Testing Methods:

• Static Testing
• Dynamic Testing
Static Testing: It is also known as Verification in Software Testing. Verification is a
static method of checking documents and files. Verification is the process, to ensure
that whether we are building the product right i.e., to verify the requirements which
we have and to verify whether we are developing the product accordingly or not.
Activities involved here are Inspections, Reviews, Walkthroughs
Dynamic Testing: It is also known as Validation in Software Testing. Validation is a
dynamic process of testing the real product. Validation is the process, whether we are
building the right product i.e., to validate the product which we have developed is
right or not.
Activities involved in this is Testing the software application

6.4.3. Testing Approaches

• White Box Testing
• Black Box Testing
• Grey Box Testing
White Box Testing: It is also called as Glass Box, Clear Box, Structural Testing.
White Box Testing is based on applications internal code structure. In white-box
testing, an internal perspective of the system, as well as programming skills, are used
to design test cases. This testing is usually done at the unit level.
Black Box Testing: It is also called as Behavioral/Specification-Based/Input-Output
Testing. Black Box Testing is a software testing method in which testers evaluate the
functionality of the software under test without looking at the internal code structure.
Grey Box Testing: Grey box is the combination of both White Box and Black Box
Testing. The tester who works on this type of testing needs to have access to design
documents. This helps to create better test cases in this process.

6.4.4. Testing Levels

• Unit Testing
• Integration Testing
• System Testing
• Acceptance Testing
Unit Testing: Unit Testing is done to check whether the individual modules of the
source code are working properly. i.e. testing each and every unit of the application
separately by the developer in the developer’s environment. It is AKA Module
Testing or Component Testing
Integration Testing: Integration Testing is the process of testing the connectivity or
data transfer between a couple of units tested modules. It is AKA I&T Testing or
String Testing. It is subdivided into Top-Down Approach, Bottom-Up Approach and
Sandwich Approach (Combination of Top Down and Bottom Up).
System Testing (end to end testing): It’s a black box testing. Testing the fully
integrated application this is also called as end to end scenario testing. To ensure that
the software works in all intended target systems. Verify thorough testing of every
input in the application to check for desired outputs. Testing of the user’s experiences
with the application.
Acceptance Testing: To obtain customer sign-off so that software can be delivered
and payments received. Types of Acceptance Testing are Alpha, Beta & Gamma
Testing.

6.5. Test Cases

A test case is a document, which has a set of test data, preconditions, expected results
and postconditions, developed for a particular test scenario in order to verify
compliance against a specific requirement.
Test Case acts as the starting point for the test execution, and after applying a set of
input values, the application has a definitive outcome and leaves the system at some
end point or also known as execution postcondition.

6.5.1. Login Test Case

Test case: Login Priority(H,L): High
Test objective: Verifying login
Test descriptions: “user enter the required field, press login button”, client
program contact to the server, server contact with database, database update the
result and send the results to the user.
Requirements verified: Yes
Test environment: Person must have the access to website
Test setup/ pre-condition: Working Internet connection and user must be
registered
Location Expected result
The user will login to access application “Login successfully”. Display main menu.

Pass: Yes Condition: Pass Fail:

No
Problem /issues: NIL
Status: Successfully Executed

6.5.2. Register Test Case

Test case: Register Priority(H,L): High
Test objective: Create a new user
Test descriptions: “user enter the required field, press register button”, client
program contact to the server, server contact with database, database update the
result and send the results to the user.
Requirements verified: Yes
Test environment: Person must have access to website
Test setup/ pre-condition: Internet must be working
Location Expected result
“Register successfully”. Display main
The user will register to access application
menu.

Pass: Yes Condition: Pass Fail:

No
Problem /issues: NIL
Status: Successfully Executed

6.5.3. Upload Product Test Case

Test case: Upload Product Priority(H,L): High
Test objective: Make ad for auction
Test descriptions: “user enter the required field, press add button”, client program
contact to the server, server contact with database, database update the result and
send the results to the user.
Requirements verified: Yes
Test environment: Person must have the access to website
Test setup/ pre-condition: User must be login
Location Expected result
The user must be on add ad page “Add successfully”. Display alert.

Pass: Yes Condition: Pass Fail: No

Problem /issues: NIL
Status: Successfully Executed

6.5.4. Make Bid Test Case

Test case: Make Bid Priority(H,L): High
Test objective: Make bid for the uploaded product
Test descriptions: “user select the product, enter amount, press bid button”, client
program contact to the server, server contact with database, database update the
result and send the results to the user.
Requirements verified: Yes
Test environment: Person must have the access to website
Test setup/ pre-condition: User must be login
Location Expected result
The user must be on make bid page “Bid successfully”. Display alert.

Pass: Yes Condition: Pass Fail: No

Problem /issues: NIL
Status: Successfully Executed

6.5.5. Add Category Test Case

Test case: Add Category Priority(H,L): High
Test objective: Add categories for the auction
Test descriptions: “admin enter required fields, press add button”, client program
contact to the server, server contact with database, database update the result and
send the results to the user.
Requirements verified: Yes
Test environment: Person must have the access to admin website
Test setup/ pre-condition: Admin must be login
Location Expected result
Admin must be on category page “Added successfully”. Display alert.

Pass: Yes Condition: Pass Fail: No

Problem /issues: NIL
Status: Successfully Executed

6.6. Summary
This chapter explains the platform selection and selections of tools which were
needed for the development of the project. It also discusses different type of testing
phases from which software has passed through to make sure this software is efficient.
It also explains some test cases.
CHAPTER 7
USER GUIDE
7.1. Introduction
This chapter will discuss the user interface. It describes all the modules of the system.
Working of the modules will be described with the help of screenshots. This will help
the users to easily understand the system.

7.2. Admin Panel

7.2.1. Add Category

Figure 12 New Category Page

7.2.2. View ads list

Figure 13 Ads List Page

7.2.3. View members

Figure 14 View Members Page

7.3. User Site

7.3.1. Home
 Figure 15 Home Page

7.3.2. Login

Figure 16 Login Modal

7.3.3. Register

Figure 17 Register Modal

7.3.4. Account

Figure 18 Profile Page

7.3.5. Product Page

Figure 19 Product Detail Page

7.3.6. Start Auction

 Figure 20 Start Auction

7.4. Summary
This chapter explain the user interface and working of all the modules with the help of
screenshots. Which make it very easy for user to understand the working of the
system.
 CHAPTER 8
CONCLUSION & FUTURE
WORK
8.1. Conclusion
 Online Auction System will give new approach and dimension to auction
system
 It will encourage both Buyers and Sellers to participate in auction process
 Removes geographical boundaries, location constraint and time constraint
 Transparent process
 No manual work

8.2. Hurdles
I have to face many hurdles. Few of them are listed below:
• This project is about Ecommerce. It was hard to find interface best suited for
this project and even making my own design
• Creating new design that is easy to understand
• Implementation of this design in the project

8.3. Future Work

The project has been developed in a very short period of time and all efforts have
been taken so that this project is very efficient in its execution there still exists some
scope of improvement in my project. There are also few features which can be
integrated with this system to make it more flexible. Below list shows the future
points to be consider
• Adding more functionalities to the system
• Converting to Single Page Application
• Make a supportive android app

8.4. Few Words in the End

I learned a lot through this project. This project has sharpened my concept of
PHP and MySQL.
I learned a lot about different documentation. The success of this project may
give pleasure to billions of people wanting this Ecommerce system. This project not
only tested my technical skills but also my temperament.
There were times that I almost lost hope but I recovered through constant
concentration and hard work.
If any kind of suggestion, improvements, more efficient development idea
please feel free to communicate with me.
REFERENCES
Books:
• Database Systems: Design, Implementations, and Management: Catherine
Ricardo
• Software Engineering: Design, Implementations, and Management: Pressman
• Advance PHP with MySQL: A. Seeker
• JavaScript and JQuery: Interactive Front-End Web Development: Jon Duckett
• Beginning HTML5 and CSS3 For Dummies: Chris Minnick and Ed Tittel
Websites:
• SMARTDRAW
http://www.smartdraw.com

• TECHNOPEDIA
https://www.techopedia.com

• UML-DIAGRAM
http://www.uml-diagrams.org

• GURU99
https://www.guru99.com/

• W3SCHOOL
https://www.w3schools.com/

• WIKIPEDIA
https://www.wikipedia.org/