A Major Project Final Report on

“Auction System” Android Application

Submitted in Partial Fulfillment of the Requirements for the Degree of

Bachelors of Engineering in Information Technology

Under Pokhara University

Submitted by:

Anil Gurau, 15452

Dinesh Aryal, 15461

Puspa Poudel, 15471

Sudeep Banjade, 15484

Date: 24 November, 2019

Department of IT Engineering

NEPAL COLLEGE OF
INFORMATION TECHNOLOGY
Balkumari Lalitpur, Nepal.
ACKNOWLEDGEMENT
This project being part of Engineering Curriculum under Pokhara University, we are glad to
present our final project report. Support from teachers and colleagues, help and encouragement
from IT experts and development environment from college have played vital role in the
preparation of this project report, so we are thankful to all of them.

We would like to express our gratitude and appreciation to all those who gave us the possibility to
complete this report. We want to give a special thank to our project Supervisor and Scrum Master
Er. Prakash Poudel for his regular guidance, suggestion, and encouragement in completing the
project.

We also like to extend our special thanks to the Head of IT Department of Nepal College of
Information Technology, Er. Madan Kadariya, for his regular guidance, suggestion, and necessary
support for the project.

Finally, we would also like to thank teachers and colleagues that have contributed directly or
indirectly on our project development time.

Project Members

Anil Gurau: CRN 15452

Dinesh Aryal: CRN 15461

Puspa Poudel: CRN 15471

Sudeep Banjade: CRN 15484

I
ABSTRACT
Auction System is a well-designed platform for auction of some valuable and antique goods. As
mobile phone is being so common and has been a good medium to connect with customers.
Auction System aims to connect with sellers and buyers where seller will be able to post their
products with minimum cost and buyers will bid for the product if they want. Bidding process will
be instantaneous and the higher bidder will get the product. The whole concept of our Auction
System is based on “Pay if you want” which indicates that user will be able to get product by
bidding higher price within the limited time. This platform will make seller satisfied as their
product will get price which it deserve. Seller will be provided with a web portal for their content
control and report observation. Users will be notified about any new bidding and the bided
products.

Keywords: Bid, Web portal, Android, Pay, Notification, Buyer, Seller, Limited.

II
LIST OF FIGURES

1. Figure 1: Incremental Model………………………………………………………….6

2. Figure 2: Application Architecture…………………...…………………….…….......12

3. Figure 3: Use case Diagram………………………………………..............................13

4. Figure 4: Class Diagram...............................................................................................16

5. Figure 5: Data Flow Diagram………………………………………………………...17

6. Figure 6: Entity-Relationship Diagram………………………………………………18

7. Figure 7: Sequence Diagram (Login) ………………………………………………..19

8. Figure 8: Sequence Diagram (Log out) ……………………………………………...19

9. Figure 9: Sequence Diagram (Register) ……………………………………………..20

10. Figure 10: Sequence Diagram (Bidding System) …………………………………..21

11. Figure 11: Gantt-chart for Increment 1……………………………………………...24

12. Figure 12: Gantt-chart for Increment 2……………………………………………...24

13. Figure 13: Gantt-chart for Increment 3……………………………………………...24

III
LIST OF TABLES

Table 1: Team member work division ...................…............................................................10

Table 2: Used tools and purpose…………………………………………………………….11

Table 3: Use-case (Sign In)………………………………………………………………….14

Table 4: Use-case (Sign Out) ……………………………………………………………….15

Table 5: Use-case (Register) ………………………………………………………………..15

Table 6: Functional Requirement……………………………………………………………22

Table 7: Non-Functional Requirement………………………………………………………22

Table 8: Project task and time Schedule……………………………………………………..23

Table 9: Test Cases…………………………………………………………………………..26

Table 10: Test Results………………………………………………………………………..27

IV
TABLE OF CONTENTS
1. INTRODUCTION…………………………………………………………………………..1
1.1. Project Overview…………………………………………………………………...1
1.2. Problem Statement………………………………………………………………….1
1.3. Project Objectives…………………………………………………………………..2
1.4. Significance of Study……………………………………………………………….2
1.5. Scope and Limitations………………………………………………………………3
2. LITERATURE REVIEW……………………………………………………………………4
2.1. Review………………………………………………………………………………4
2.2. Existing Development………………………………………………………………4

3. METHODOLOGY…………………………………………………………………………..6
3.1. Software Development Life Cycle : Incremental Model…………………………....6
3.1.1. Incremental Modal Advantages………………………………………..9
3.1.2. Reasons for choosing Incremental Model……………………………...9
4. PROCESS, MODEL AND TOOLS…………………………………………………………10
4.1. Team Member………………………………………………………………………10
4.2. Tools and Technology………………………………………………………………11
5. ANALYSIS AND UML DESIGN PHASE…………………………………………………12
5.1. Architectural Skeleton……………………………………………………………...12
5.2. Use-Case Diagram………………………………………………………………….13
5.2.1. Actor…………………………………………………………………...14
[Link]. Primary Actor…………………………………………………14
[Link]. Secondary Actor………………………………………………14
5.2.2. Use Cases………………………………………………………………14
5.3. Class Diagram………………………………………………………………………16
5.4. Data Flow Diagram…………………………………………………………………17
5.5. Entity-Relationship Diagram……………………………………………………….18
5.6. Sequence Diagram………………………………………………………………….19
6. REQUIREMENTS…………………………………………………………………………..22
6.1. Functional Requirements…………………………………………………………...22
6.2. Non-Functional Requirements……………………………………………………...22
7. TASK AND TIME SCHEDULE…………………………………………………………....23

V
 7.1. Increment 1: Develop Web App System…………………………......................24
7.2. Increment 2: Develop Android App System…………………………………….24
7.3. Increment 3: System Integration………………………………………………...24
8. TESTING………………………………………………………………………………...25
8.1. Test Plans………………………………………………………………………..25
8.2. Test Strategy…………………………………………………………………….25
8.2.1. Unit Testing………………………………………………………..25
8.2.2. Integration Testing…………………………………………………25
8.2.3. System Testing……………………………………………………..25
8.3. Test Cases……………………………………………………………………….26
8.4. Test Results……………………………………………………………………...27
9. BUDGET………………………………………………………………………………...28
9.1. Functional Points………………………………………………………………..28
9.2. Line of code……………………………………………………………………..30
10. CONCLUSION AND FUTURE EXTENSIONS…………………………………….....31
11. APPENDIX………………………………………………………………………………32
12. REFERENCES…………………………………………………………………………...39

VI
1. INTRODUCTION
“Auction System” is a well-designed platform for connecting buyers and sellers where buyers will
pay for item by bidding and seller will get deserving price for their item. This project aims to bid
for some valuable items like antique items and other important items. The item are well categorized
and users will find easy to find items. Within a limited time i.e. bidding period user will be able
bid for product. So user will be able to pay higher if they like the product or leave the product if
they feel the price tag is higher. This system have refund policy if the user’s lose in the bidding
process.

1.1. PROJECT OVERVIEW

The main aim of this project is to provide user with a reliable platform where they can buy
valuable items by bidding. Here user will pay for item as much they think it deserve. If
they feel like cancelling the bidding they will be refunded. Our project aims to support the
sellers too. As the process of buying is totally based on bidding, sellers will post their
products with minimum cost and bidding period. So seller will get deserving price for their
items. This product will categorize items for easiness of users. Sellers will have to register
to our web portal and after reviewing their portfolio they will be selected or rejected to
add items on the app through their web panel.

1.2. PROBLEM STATEMENT

The problem that gave us hint for this project is unavailability of user willingness while
shopping on e-commerce. There is no option for user to buy an item on less price or higher
if he/she want it in case of limited stock. There is biasness to seller where they can’t get
more money for a valuable item which it deserve. There is no way or platform for user to
decide the price for a product after the seller post for it with a minimal price. Like a
traditional way of bidding which involve a lots of paper works and having to wait for hours
despite the weather condition. There is no platform for the user to get instant notification
for their bidding and can bid more for a particular items if they think that the item deserve
more money than bided by other users.

1
1.3. PROJECT OBJECTIVES
The main idea of this project is to develop a platform which enables user to bid for items
and sellers will be able to post their items for auctions to get a deserving price to their
items.
The final goals of this project are as follows:-
 To increase efficiency and improve services provided to the customers through
better application of technology in daily operations.
 To eliminate manual/paper work and increase level of accuracy.
 To increase speed of service and customer satisfaction.
 To make user friendly system so that user can easily view and bid for items.
 To make system more Secure and Integral.
 Provide login based system to enter into personal profile.
 The system makes use of API for fetching the details of users and items.
 The usage of this application reduces the time required for long paper works.
 Since this system is instantaneous so user will get notified instantly and can increase
their bidding price.
 Provide the interface for push notification on start and ending of related bidding
process.

1.4. SIGNIFICANCE OF STUDY

This project on “Auction System” is aimed to make the whole auction system easy for all
peoples. The people refers to both the seller and buyers where a common platform is
created. The contents on the system is maintain by the end user of the system. Here the
items will be added by the seller through a web portal whose profile will be verified. This
project aims to overcome the late and long paper work involve on auction of any kind of
items. There will be one time verification of user documents and profile details. Then user
will be able to participate on the auction system. However user will be able to view the
items and its details on the app even if their profile is unverified.

2
1.5. SCOPE AND LIMITATIONS
The scope of this project is to provide user with all the facilities of bidding for valuable
items through android based applications. Scope of our projects are:
 Integrating payment gateways for buying bided items.
 Recommendation of items through app for user interest.
 Addition of product through web portal is available so variety of items is
added after the verification of sellers account.
 Efficient use and integration of digital currencies to make whole process a
lot easier.
 We might go for online support system.
Despite working on the problems of customers our project seems to have some
limitations. Some of the limitations of our projects are:
 It required a smartphone for android application which should have installed
android OS.
 As we don’t have our own items for auction so process may lag through a
verification and other securities.
 Internet, as our system is totally online based.

3
2. LITERATURE REVIEW
This section consists of literature review which defines all possible services of application. The
survey had been carried out to find out best algorithm strategy available .We had referred
research journals, existing system and analyze the results of same, also take the experts opinion.
Literature review is focused on a research questions, trying to identify, appraise, select any
synthesize all high quality research evidence and argument relevant to that question. This paper
assumes that the application described would be a prototype that would shape the future & amp;
there still remains much to do in terms of development and improvement of the existing models.
Applications created with ease of understanding and the design can be created and tailored to
the travel process to make it more effective and user friendly, thus making it easier and
convenient for the users to do the entire bidding process with the use of this application along
with the seller to have easy and reliable platform to put their items on auction.

2.1. REVIEW
There has been vast improvement and development in technology, mobile application has
been very essential in our day to day life. Even this kind of service has advanced; it still
requires more areas for improvement. Our project aims to solve all the problems coped
during the bidding process.

2.2. EXISTING DEVELOPMENT

As we have reviewed many apps, software’s, websites and many software technologies
related to auction system. We have a found rough picture of present development and
scenario of related field in technology advancement. There has been vast improvement
and development in technology, mobile application has been very essential in our day to
day life. Even this kind of service has advanced; it still requires more areas for
improvement. Our project defines all possible services application. With growth of
internet and internet based devices, most of the people are fond of things available over
the internet. Facebook and online media have grown their popularity very much these
days. We found such project existed outside our country.

Some of the popular products that we have research are follows:

 Online Auction

4
 Online Auction is an android app developed by Ama Information System[1]. It is
based on Dubai, UAE. Some of its pros and cons[2] are:
 Pros
- Online auction allows to browse through different category on auction
- Review auction results and higher bid update
- View location of items on auction.
- View Information details of each items on auctions along with its
picture.
 Cons
- Need to improve highly on UI/UX
- Dissatisfied user due to crash on app
- Only available in Dubai

 [Link]:
[Link][3] is a travel planner app supports Android, IOS and website that
has amazing feature of selling any car within 30 minutes inside Dubai. They buy
car after reviewing all the condition and buy it within 30 minutes.
Some of its pros and cons[4] are:
 Pros
- Instant evaluation of your property
- Multiplatform (Android and IOS)
- Well organization of data and input/output system
- No haggling and no hassle as money is directly deposited on your bank
account
 Cons
- Delay payment.
- Seller complain of getting much lesser price than expected.

5
3. METHODOLOGY

We have planned to work following these methodologies for application of knowledge, skills,
tools and techniques to a wide range of activities and design in order to meet the requirements
of our project.

3.1. SOFTWARE DEVELOPMENT LIFE CYCLE: INCREMENTAL

MODEL
The framework we will be using for the developing this project is Incremental model. This
is an umbrella term for several iterative and incremental software development
methodologies. Each of the method is unique and share common core values. This method
suits for this project as there are three increments that needs to be done separately( we
development, API Development, android development, system integration).The
requirements of system can be clearly understand and well defined and backed system also
needs to be integrated and implemented. In this development first we decide or plan by
gathering and analyzing useful requirements of the user and also the suitable system
specification to make sure it matches. After the plan we go ahead to designing system
followed by component design and when design is done then we do the coding then finally
check if our project meets the requirements. We follow the same process several steps
until all the requirements are fulfilled.

Increment1: WebApp
Development

Delivery Of Web
Analysis Design Coding Testing
Development

Increment2: AndroidApp
Development

Delivery Of
Analysis Design Coding Testing Android
Development

Increment3: System Integration

Delivery Of System
Analysis Design Coding Testing
Integration

Time

Fig 1: Incremental Model

6
 The different phases in incremental model are:

 Analysis phase
In this phase, analysis was performed in order to find out the requirements of the system.
The outcome of this phase was SRS which is an acronym for “System Requirement
Specifications”. First we planned to collect the requirements and analyzed the system for
designing the system.
 Design phase:
In this phase the SRS was translated into the system’s design. Context Diagram, DFD, ER
– Diagram, Use Case Diagram and Class Diagram was developed. After analysis we design
the system for different app modules development.
 Coding phase:
In this phase, coding was done according to the design and a working system was
developed by the end of this process.
 Testing phase:
In this phase, the system was tested. With each testing a list of changes to the system
developed, is suggested and the changes was applied to the software and the software was
delivered as a successive increment until a satisfying system was achieved.

The different increments in our incremental model are:

 INCREMENT 1: Develop Web App and Admin Panel Modules
With the help of the objective of our project we focused on analysis, design, coding and
testing phase of the web app modules of the system which helped us to figure out every
aspects of the project and we took them in consideration. In this phase we developed Full-
fledged Web Application. In this phase several artifacts were produced and they are as
follows:
 Use Case
 Project Boundary
 System Modules (Web App Modules)
 Initial System Architecture
 Feasibility Study

7
  Risk Assessment
 Domain model
 ER Diagram
 Context Diagram
 Data Flow Diagram
 Software Architecture Document
 Cost and Schedule Estimates
 Activity Diagram
In this phase we worked on integrating API to our system as we have to create a three-tier
architecture for our system. The above artifacts are produced in both web and android
development phases. In this increment phase we developed full web modules as well as
admin panel modules.

 INCREMENT 2: Develop Android App System

In this increment phase we performed analysis, design, coding and testing of the system
for the android platform. After the web and admin panel module development, we
developed the android modules for this application. The artifacts are produced in this phase
which is same as the web development.
Some of the modules that we was made in the android application are follows:
 Login/Signup Activity
 Main Activity
 Push Notification Modules
 User Profile Modules
 Bidding System Modules
 Different Categories of items etc.

 INCREMENT 3: Develop full Integrated System

In this phase we worked on integration of the frontend system and backend system of the
web and android application of the system. At initial part of this phase we analyzed the
frontend design and overall frontend system and as well as we did same to backend system

8
like database system. We also focused on overall performance of the project and its
architecture. The artifacts produced in this phase are:
 Integrated module of system
 Class diagram

3.1.1. INCREMENTAL MODEL ADVANTAGES

 During early SDLC it helps to create working software quickly.
 It is more flexible i.e. require less cost to change scope and requirements
 It is easier to test and debug the software.
 Easy for risk analysis at early phase.
 Each iteration can be managed easily.
 During iteration process it will be easy to handle functionality.

3.1.2. REASONS FOR CHOOSING INCREMENTAL MODEL

 Requirements will be defined clearly and understood.
 Easy to design and develop software.
 Easy to integrate front-end and back-end system.

9
4. PROCESS, MODEL AND TOOLS
4.1. Team Members

The role and designation of each member are explained in table below
Work Name

Dinesh Aryal, Sudeep Banjade

Android Developer
Sudeep Banjade
XML
Dinesh Aryal
API
Anil Gurau
UI/UX Design
Anil Gurau, Sudeep Banjade,
UML designer
Dinesh Aryal, Puspa poudel

Puspa Poudel
Database Design
Anil Gurau, Sudeep Banjade,
Documentation
Dinesh Aryal, Puspa Poudel

Anil Gurau, Sudeep Banjade,

Presentation
Dinesh Aryal, Puspa Poudel

Table 1: Team member work division

10
4.2. Tools and Technology
The tools used for documentation, designing and developing UI/UX, testing are listed below
in the table.
Tools Purpose
Adobe XD, Adobe Illustrator, Adobe Designing UI/UX,
Photoshop
Android Studio Development of Android Application
PHP my admin Designing Database
[Link] Designing UML Diagram
Android Smart Phone Android Application Testing

Table 2: Used tools and purpose

11
5. ANAYSIS AND UML DESIGN PHASE
UML combines best techniques from data modelling (Entity Relationship Diagrams), objects
modeling and component modeling. It can be used with all processes, throughout the software
development life cycle, and across different implementation technologies.

5.1. Architectural skeleton

The system architecture of our project is a Three-Tier Architecture System which includes
a Presentation Tier, an Application Tier and Data Tier. The Architecture skeleton of the
project is shown in the figure below[5].
 Presentation Tier
It is user friendly GUI through which users are allowed to interact with our system.
Sign-In/ Sign-Up pages restrict unauthorized users to use the application and GUI
for display for the Events and Google Map for the location of the organized events.
 Architecture Tier
It consists of logical operations and data access. In the project application users
command processing, making enquiry of the events, make decision for the network
group. With Android background services and Asynchronous Tasks, the
application notifies users for the upcoming Events. Use of APIs such as Google
Map, Facebook and Google and Use of libraries such as Retrofit and other material
Design libraries are included in Application Tier of the project.
 Data Tier
It is our Database where information are stored and retrieved upon user and system
request. Data tier of the project also includes other third party databases which are
accessed with the call of provided API function calls.

Fig 2: Application Architecture

12
5.2. Use Case Diagram

Fig 3: Use Case Diagram

13
5.2.1. Actor
[Link]. Primary Actor
The Primary actor are the system user. Primary actor can register into
application and manages and uses the available features of application such as
manages users account, register, search for categories and make payment.
[Link]. Secondary Actor
The secondary actor is the admin. The secondary actor is responsible for
sending mail to system users, check auction user and keep product for bidding
if not paid.
5.2.2. Use Cases
Use Case 1: Sign In

Name Sign In

Actor Primary User, Secondary User, System

Precondition Application users are not signed in.

Description 1. Application users type his/her username

and password.

2. Application users click Sign In button.

3. Application users are signed in.

If application users enter invalid username

and password then they are restricted to bid
in the application.

Post condition Application users are now signed in and

can bid in Application.

Table 3: Use Case (Sign In)

14
Use Case 2: Sign Out

Name Sign Out

Actor Primary User, Secondary User, System

Precondition Application users are signed in.

Description 1. Application users click sign out button.

2. Application users are sign out from the

application.

Post condition Application users are now sign out and are
restricted to use event subscribed
packages.

Table 4: Use Case (Sign Out)

Use Case 3: User Register

Name Register

Actor Primary User, Secondary User, System.

Precondition User is not Registered in the system.

Description 1. Users click Register button.

2. Users Input the required information
and click confirm.

Post Condition Application users are now registered in the

system and are able to sign in now.

Table 5: Use Case (Register)

15
5.3. Class Diagram
The class diagram is the main building block in object oriented modeling. The classes in a
class diagram represent both the main objects and/or interactions in the application and the
objects to be programmed.
The Auction system consist of 7 classes, which are as follows:
- User
- Payment
- Auction
- Buyer
- Seller
- Bid
- Admin

Fig 4: Class Diagram

16
5.4. Data flow Diagram
A data-flow diagram (DFD)[6] is a way of representing a flow of a data of a process or a
system. The DFD also provides information about the outputs and inputs of each entity and
the process itself. A data-flow diagram has no control flow, there are no decision rules and no
loops

Fig 5: Data Flow Diagram of the system.

17
5.5. Entity-Relationship Diagram(E-R)
The ER diagram[7] is the pictorial representation of the overall logical structure of the system’s
database. The ER diagram of our system is given below. It shows the relationship among the six entities
of the system. The entities are represented in the rectangle, their attributes are presented in the oval
and the attributes that are underlined are the primary key.

Fig 6 : E-R Diagram

18
 5.6. Sequence Diagram
Sequence Diagram is the logical interaction diagram between object to perform specific task.
It show how the events occurs and in what order. Following are the sequence diagram of our
system.
To use the system functionalities users have to login and login sequence diagram is shown in
the figure below. Here in login sequence diagram there are five objects in the system. Users
provide username and password and are validated and are verified for the right users to login.

Fig 7: Sequence Diagram (Login)

For the system functionalities to exit from the system users have to logout with the change in the
status of the users and the sequence diagram of logout is shown in the figure below.

Fig 8: Sequence Diagram (Logout)

19
Fig 9: Sequence Diagram (Register)

20
Fig 10: Sequence Diagram (bidding system)

21
6. REQUIREMENTS
This section deals with the functional and non-functional requirements of the project.

6.1. Functional Requirements

S.N Requirement Priority

1. Sign In to the application. Essential

2. Essential
Sign Out from the application.

3. Essential
User Register to the application.

4. Essential
Search and View different item categories

5. Essential
Bid any valid item.

6. Essential
Management of user Profile by user him/herself.

7. Essential
Seller can showcase their item for auction

Table 6: Functional Requirement

6.2. Non-Functional Requirement

S.N Requirement Priority

1. The system works on Android Phone ( Kitkat 4.4 and above). Essential

2.
The user interface should be user friendly. Essential

3.
The system is implemented using tools specified(Android Studio, Essential
php myadmin, E-draw, Adobe XD, Adobe Illustrator, Adobe
Photoshop)

4.
The system must be able to operate in only Android operating Desirable
system.

Table 7: Non-Functional Requirement

22
7. TASK AND TIME SCHEDULE
The project schedule has been designed as per requirements and constraints involved. This project
was scheduled to be completed in about 2 months. Analysis, design and documentation had been
given more emphasis. Debugging and testing was done prior to the completion of the project.

TASK 1st Increment 2nd Increment 3rd Increment APPROX.

Period Period Period DURATION(Days)

Requirement 3 3 3 9
Analysis

and Specification

Undertake Analysis 4 4 2 10

of The System

Design System 4 6 3 13

Develop Application 15 21 5 41

Modules

Overall System 3 5 4 12

Testing

Develop 23 31 11 65

Documentation

Table 8: Project Task and Time Schedule

23
7.1. INCREMENT 1: DEVELOP WEB APP SYSTEM

Fig 11: Gantt-Chart for Increment 1

7.2. INCREMENT 2: DEVELOP ANDROID APP SYSTEM

Fig 12: Gantt-Chart for Increment 2

7.3. INCREMENT 3: SYSTEM INTEGRATION

Fig 13: Gantt-Chart for Increment 3

24
8. TESTING
8.1. Test plan
The purpose of the test plan is to communicate the intent of the testing activities with end user
representatives, stakeholders, system integrator, implementer and tester. Test cases are
conducted with the last version. Functional and non-functional requirements are tested with
test cases. All the requirements are listed and tested according to the priority. For instance,
“Essential” requirement have higher priority than “Desired” requirements and “optional”
requirement .Higher Priority requirements are tested before lower priority requirements.
8.2. Test strategy
The test strategy[8] presents the recommended approach for testing a part of a system of
system as a whole.
8.2.1. Unit Testing
Unit testing ensures that the part of the program works well. It is performed by implementer
at the time of implementation. The implementer checks values for the return types. They
will also validate the different tools boxes used like Text View, Edit Text etc.
8.2.2. Integration Testing
The components in the implementation model are integrated and tested to ensure proper
operation. One bigger working package will be integrated to other smaller working
packages in incremental manner.
8.2.3. System Testing
System testing will be conducted by tester after the completion of construction phase. After
well-formed subset of the use case behavior is implemented, all the functional and non-
functional requirements are tested.

25
 8.3. Test Cases

Step Action Expected System Response Pass/Fail

1 Click Sign In The system displays a form asking

pass
the user to enter the username and
password.

2 Enter username :'user_123' The system displays a message of

pass
Password:12345 successful login

3 Re-enter 'user_321' Password entered is incorrect.

fail
Password :52355

4 Click Register button The system displays a form asking

pass
the user details.

5 Enter user details, and The system displays a message of

fail
Email=”xyz@[Link]” invalid email

6 Reenter user detail and The system displays a message of

pass
email=”zyx@[Link]” successful register.

7 Click sign out button The system displays a message of

pass
successful log out

8 Bid Test System proceeds the payment

pass
process.

9 Proceed payment System displays insufficient

fail
balance.

10 Re-proceed payment System displays successful

pass
payment.

Table 9: Test Case

26
 8.4. Test Results
The test coverage results are as follows:

Total Test Case Successful Test Case Failed test case

10 7 3

Table 10: Test Results

Out of 10 test cases, 7 test cases passed and remaining 3 test cases failed which were sent for
repair. Failure is found to be related to layout and design.

27
9. BUDGET
9.1. Functional Point
The value of the count and the count multipliers is average.[9]

Number of users

Each user input that provides distinct application oriented data to the software is counted.

Number of user outputs

Each user output that provides application oriented information to the user is counted. In this
context “output” refers to reports, screens, error messages, etc. Individual data items within a report
are not counted separately.

Number of user inquiries

An inquiry is defined as an on-line input that results in the generation of some immediate software
response in the form of an on-line output. Each distinct inquiry is counted.

Number of files

Each logical master file is counted.

Number of external interfaces

All machine-readable interfaces that are used to transmit information to another system are counted.

28
Information Domain Weight Count Total count[Weight *
Values Count]

No of User Inputs 12 4 48

No of User Outputs 5 5 25

No of User Inquiries 5 4 20

No of Logical Files 21 10 210

No of External 14 7 98
Interfaces

Count Total 401

Function Point (FP) = Count Total * Complexity Multiplier

= 401*[.06 + .001 * i]

=401 * 1.01

=405.01

405

Average Productivity =10 FP/pm

Labor Rate = Rs.25000 per month

Effort =

Total Project Cost = FP * = 405 *

29
9.2. LINE OF CODE
Using Lines of Code metric, the project size is estimated by counting the number of source
instructions in the developed program.
Estimated LOC = 4258
Average Productivity = 100 LOC/PM
Labor Rate = Rs.25000
Now,
Estimated Project Cost = Estimated LOC * Cost/LOC

= 4258 *

Estimated Efforts =

30
10. CONCLUSION AND FUTURE EXTENSIONS
The Auction System is now at initial phase with it’s simple version having most of the basic
functionalities as mentioned in objectives. All the modules have been working after
integrating and are ready for the demo. As the features adding up the level of complexity have
been increasing as well. However, it is not complete with the ideas we have put through and
might need more improvisation in coming days as well. This makes us think about the future
extensions that we are going to implement in the auction system. Some of the extensions we
have planned are as follows:
- More category of products will be sold in future.
- More security features will be added.
- System will be more reliable.
- Enhanced UI.
- Local payment system will be added for future.

31
11. APPENDIX

32
33
34
35
36
37
38
12. REFERENCE
[1] "Online Auction". [Online]. Available
[Link] [Accessed: 21-Jul-2019].

[2] “pros and cons of online system”. [Online]. Available [Link]

cons-of-selling-to-a-dealer-1420680466390/ [Accessed: 26-Jul-2019].

[3] “Sell Any Car Site”. [Online]. Available [Link] [Accessed: 28-Jul-2019].

[4] “pros and cons of Sell Any Car”. [Online]. Available [Link]
cons-of-selling-to-a-dealer-1420680466390/ [Accessed: 26-Jul-2019].

[5] “Architectural skeleton”. [Online]. Available [Link]

architecture [Accessed: -2-Nov-2019].

[6] “Data Flow Diagram (DFD)”. [Online]. Available [Link]

flow_diagram [Accessed: 5-Nov-2019].

[7] “Entity-relationship diagram (E-R)”. [Online]. Available [Link]

relationship-diagram/ [Accessed: 5-Nov-2019].

[8] “Test strategy” [Online]. Available [Link]

strategy-document-template/ [Accessed: 14-Nov-2019].

[9] “Functional Point”. [Online]. Available [Link]

analysis [Accessed: 14-Nov-2019].

39