Digitally Automated Auction Procurement and Delivery Platfrom

ADAMA SCIENCE AND TECHNOLOGY
UNIVERSITY
SCHOOL OF ELECTRICAL ENGINEERING AND
COMPUTING
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
A SENIOR PROJECT DOCUMENTATION SUBMITTED FOR THE PARTIAL FULFILLMENT

OF DEGREE PROGRAM AT PROGRAM OF COMPUTER SCIENCE AND ENGINEERING
Project Title: Digitally Automated auction, procurement and delivery Platform
BY
NAME ID-NO SECTION
✓ Tadiwos Workeye A/ur14109/10 4
✓ Aklilu Zewdu A/ur14327/10 2
✓ Gutu Rarie A/ur14680/10 3
✓ Birhanu Gosa A/ur14249/10 1
✓ Chalchisa Tamiru A/ur14458/10 4
Submission date: June 08,2022

Advisor: Ms. Lomi Deresa
Submitted by
Tadiwos Workeye __________________________ June 8, 2022
Student Signature Date
Birhanu Gosa __________________________ June 8, 2022
Gutu Rarie __________________________ June 8, 2022
Aklilu Zewdu __________________________ June 8, 2022
Chalchisa Tamru __________________________ June 8, 2022

Approved by
1. Mss Lomi Deressa ___________________________ June 2, 2022

Advisor Signature Date
2. Mr. Abubeker Yimam ___________________________ ____________________

Senior project
coordinator Signature Date
Department
3. ______________________ ______________________ ____________________

Chairman, Dept.’s Signature Date
Acknowledgement
We would like to express special thanks of gratitude to our advisor as well as mentor MS. Lomi
Deressa for her excellent advice and active guidance throughout this project, which also helped
us to do this wonderful project on the Digitally Automated Auction, procurement and delivery-
platform also helped us doing a lot of research and we came to know about so many new things
in our implementation area.
Secondly, we would also like thank our friends and computer science and engineering
department instructors whose support and encouragements, which helped us to finalize our
project with in limited time frame.
Finally, we like to thank ASTU and employees who works in different governmental organization
who gave us necessary information.
iii
ACRONYMS
ASTU ADAMA Science and Technology University.

DAAPDP Digitally automated auction, and delivery plat-form.
DAAPD Digitally automated auction, procurement and delivery system parse.
OAPADP Online Auction, procurement and delivery plat-form.
MS Word Microsoft word.
HTML Hypertext Markup Language.
CSS Cascading Style Sheet.
US Use Case.
PHP Hyper Text Processor.
OOSD Object oriented system development.
OOA Object Oriented Analysis.
OOD Object Oriented Design.
CD Compact Disc.
DVD Digital Video Disc.
MYSQL My Structured Query Language.
EA Enterprise architecture.
AES Advanced Encryption Standard.
ADL Architecture Description Language.
MVC Model View Controller.
FR Functional Requirement.
TC Test Case.
iv
Contents
CHAPTER ONE ............................................................................................................................. 1
1.1. Introduction ...................................................................................................................... 1
1.2. Background of the organization ....................................................................................... 2
1.3. Background of Project ..................................................................................................... 2
1.4. Statements of problem ..................................................................................................... 3
1.5. Justification of project ...................................................................................................... 4
1.6. Objectives......................................................................................................................... 4
1.7. Scope and Limitation ....................................................................................................... 5
1.8. Feasibility study ............................................................................................................... 5
1.9. Significance of project ..................................................................................................... 6
1.10. Beneficiary of the project ............................................................................................... 7
1.11. Methodology .................................................................................................................. 7
1.12. Development tool ........................................................................................................... 9
1.13. Required resources with cost ....................................................................................... 11
1.14. Task and schedule ........................................................................................................ 14
1.15. Team composition ........................................................................................................ 15
Table 1.5 Team composition ................................................................................................. 16
CHAPTER TWO .................................................................................................................. 17
2. Description of existing system .................................................................................................. 17
2.1. Major functionality of existing system .......................................................................... 17
2.2. User of current system ................................................................................................... 18
2.3. Drawback of current system .......................................................................................... 19
2.4. Business rule of current system ..................................................................................... 19
CHAPTER 3 ................................................................................................................................. 21
3. Proposed System ....................................................................................................................... 21
3.1. Over View ...................................................................................................................... 21
3.2. Functional Requirements ............................................................................................... 21
3.3. Non – functional requirements ....................................................................................... 23
3.4. System model ................................................................................................................. 24
v
3.5. Object Model.................................................................................................................. 70
3.6. Dynamic model .............................................................................................................. 77
CHAPTER 4 ............................................................................................................................... 116
4.1. Overview ...................................................................................................................... 116
4.2.6. Database design............................................................................................................. 131
4.2.7. Access control ............................................................................................................... 132
4.2.8. User Interface design .................................................................................................... 134
CHAPTER 5................................................................................................................................... 135
Implementation ....................................................................................................................... 135
5.1. Overview .......................................................................................................................... 135
5.2. Coding Standard............................................................................................................... 135
5.2.1. Purpose .......................................................................................................................... 135
5.3. Development Tools .......................................................................................................... 138
5.4. Prototype .......................................................................................................................... 138
Chapter Six .................................................................................................................................. 149
System Testing ........................................................................................................................ 149
6.1 Introduction ................................................................................................................... 149
6.2 Scope ............................................................................................................................. 149
6.3 Resources ...................................................................................................................... 149
6.4 Schedule ........................................................................................................................ 150
6.5 Features to be tested and not to be tested .......................................................................... 150
6.5.1 Features to be tested ................................................................................................... 150
6.6 Pass/fail criteria ............................................................................................................. 151
Approach ............................................................................................................................. 151
6.7 Test case specification ...................................................................................................... 152
6.8 Estimated risk and contingency plan ................................................................................ 154
CHAPTER SEVEN..................................................................................................................... 155
7.1 Conclusion ........................................................................................................................ 155
7.2 Recommendation .............................................................................................................. 156
CHAPTER EIGHT (8) ................................................................................................................ 156
vi
8.1 User Manual .......................................................................................................................... 156
8.11 How to register. ........................................................................................................... 156
8.12 How to apply to procurements. ................................................................................... 158
8.13How Apply to Auction. ................................................................................................ 158
8.14 How to order delivery. ................................................................................................ 159
8.15 How to pay a payment. ............................................................................................... 160
8.16 How to get announcements and notifications. ............................................................ 161
8.2 Get-Address and Version of the project. .......................................................................... 161
REFERENCE .............................................................................................................................. 163
List of Figures
Figure 1 task and schedule………………………………………………..…………….…….…14.
Figure 2 actor identification individual user…………………………….…..………………..…25.
Figure 3 actor identification organizational user…………………………………………..……26.
Figure 4 actor identification admin…………………………………………………………...…27.
Figure 5 actor identification deliveryman…………………………….……………………...…28.
Figure 6 actor identification manager……………………………………………………..….…29.
Figure 7 use case diagram……………….………………………………………………………48.
Figure-8-Class-diagram…………………………………………………………………………76.
Figure 9 sequence diagram log in………………………………………………………….……77.
Figure 10 sequence diagram add product………………………………………………….……78.
Figure 11 sequence diagram update product……………………………………………………79.
Figure 12 sequence diagram delete product…………………………………………………….80.
Figure 13 sequence diagram delete product by manager……………………………………….81.
Figure 14 sequence diagram Purchasing or procurement ………………………………………82.
Figure 15 sequence diagram update product……………………………………………………83.
Figure 16 sequence diagram create auction……………………………………………………..84.
Figure 17 sequence diagram apply to bid……………………………………………………….85.
vii
Figure 18 sequence diagram delete auction……………………………………………………..86.
Figure 19 sequence diagram delete bidder………………………………………………………87.
Figure 20 sequence diagram update profile …………………………………………………….88.
Figure 21 sequence diagram feed-back………………………………………………………….89.
Figure 22 sequence diagram complain………………………………………………………….90.
Figure 23 sequence diagram add categories…………………………………………………….91.
Figure 24 sequence diagram update categories ………………………………………………...92.
Figure 25 sequence diagram block user…………………………………………………………93.
Figure 26 sequence diagram product store……………………………………………………...94.
Figure 27 sequence diagram delivery assignment………………………………………………95.
Figure 28 sequence diagram view delivery…………………………………………………..….96.

Figure 29 sequence diagram payment…………………………………………………………..97.
Figure 30 sequence diagram document validation……………………………………………...98.
Figure 31 Registration activity diagram………………………………………………….……..97.
Figure 37 Add manager activities diagram………………………………………………….….98.
Figure 38 Delete manager activities diagram……………………………………………….….99.
Figure 39 Apply bid activities diagram……………………………………………………….100.
Figure 40 Procurement activity diagram……………………………………………………...101.
Figure 41 Add delivery activities diagram…………………………………………………..…102.
Figure 42 Document validation activities diagram …………………………………………...103.
Figure 43 Payment activities diagram ………………………………………………………...104.
Figure 44 Registration state diagram…………………………………………………………..105.
Figure 45 create Auction state diagram………………………………………………………..107.
Figure 46 Apply auction state diagram………………………………………………………..108.
Figure 47 Delete product state diagram………………………………………………………..109.
Figure 48 Add delivery man state diagram…………………………………………………….110.
Figure 49 Update category state diagram……………………………………………………...111.
viii
Figure 50 Add category state diagram…………………………………………………………112.
Figure 51 Add manager state diagram…………………………………………………………113.
Figure 52 document validation state diagram………………………………………………….114.
Figure 53 procurement state diagram………………………………………………………….115.

Figure 54 payment state diagram………………………………………………………………116.
Figure 55 shows system architecture for our proposed system web application……………....117.
Figure 56 shows system process of user authentication……………………………………….118.
Figure 57 shows system process auction and procurement system……………………………119.
Figure 58 shows system process of manager in DAAPDP………………………………….…120.
Figure 59 shows system process of Admin in DAAPDP……………………………………...121.
Figure 60 shows system process of Delivery man in DAAPDP……………………………….121.
Figure 61 sub system decomposition…………………………………………………………..122.
Figure 62 hardware/ software mapping………………………………………………………..124.
Figure 63 persistent -data management………………………………………………………...125.
Figure 64 Object Bidder mapping……………………………………………………………...126.
Figure 65 Object auction mapping……………………………………………………………..126.
Figure 66 Object document legality check mapping…………………………………………..127.
Figure 67 Object Payment mapping…………………………………………………………...128.
Figure 68 Object Delivery man mapping………………………………………………………128.
Figure 69 Object complain mapping…………………………………………………………...129.
Figure 70 Object product category mapping…………………………………………………..129.
Figure 71 Procurement mappings……………………………………………………...………129.
Figure 72 Object order mappings……………………………………………………………..130.
Figure 73 Manager mappings………………………………………………………………….130.
Figure 74 Component diagram………………………………………………………………...131.
Figure 75 Database design……………………………………………………………………..132.
Figure 76 User interface design………………………………………………………………..135.
Figure 77 Interface login ………………………………………………………………………140.
Figure 78 Interface user registration…………………………………………………………...140.
ix
Figure 79 Interface Add Category……………………………………………………………..141.
Figure 80 Interface add product page………………………………………………………….141.
Figure 81 Interface product page………………………………………………………………142.
Figure 82 Interface Admin page……………………………………………………………….142.
Figure 83 Interface edit product page………………………………………………………….143.
Figure 84 Interface Home page………………………………………………………………..143.
Figure 85 Interface available auction…………………………………………………………..143.
Figure 86 code sample1………………………………………………………………………..145.
Figure 91 Register manual……………………………….…………………..………..…….…156.
Figure92procurement manual………………....………………………………………….……157.
Figure93 auction manual………………………………………………………………….……158.
Figure94Delivery manual………………………………………………………………...……159.
Figure95 Payment manual……………………………….…………………………..…………160.
Figure96 Notification manual………...………………………………………………………..160.
Figure97 Git hub info…………………………………………………………………………..161.
x
List of Table
Table1 Software-material………………..……………………………………….…….……..…11.
Table 2 Hardware resources with cost…………………………………………………….……..12.
Table 3 Software resources with cost…………………………………………………………....13.
Table 4 Other resources with cost………………………………………………………….……14.
Table 5 Team composition………………………………………………………………………16.
Table 6 use case description for login…………………………………………………………...49.
Table 7 use case description for registration…………………………………………………….50.
Table 8 use case description for create auction…………………………………………………50.
Table 9 use case description Notification and Suggestion ……………………………………...51.
Table 10 use case description Apply on auction………………………………………………...52.
Table 11 use case description procurement……………………………………………………..52.
Table 12 use case description Search Content…………………………………………………..53.
Table 13 use case description View Content……………………………………………………54.
Table 14 use case description View Bidder……………………………………………………..54.
Table 15 use case description Cancel Auction…………………………………………………..55
Table 16 use case description Complain………………………………………………………...56.
Table 17 use case description Payment…………………………………………………………56.
Table 18 use case description Manage account…………………………………………………57.
Table 19 use case description Update product…………………………………………………..58.
Table 20 use case description Admin Delete bidder…………………………………………….59.
Table 21 use case description Manager Delete outlawed bidder accounts……………………...59.
Table 22 use case description Report Generation……………………………………………….60.
Table 23 use case description Manager Categories……………………………………………..61.

Table 24 use case description Admin manage all user………………………………………….61.
Table 25 use case description Manager, Admin, Login…………………………………………62.
Table 26 use case description of log out…………………………………………...……………63.
Table 27 use case description of Document originality checking……………………………….64
Table 28 use case description of Product originality checking………………………………….65.
xi
Table 29 data dictionary…………………………………………………………………………67.
Table 30 Sub system decomposition…………………………………………………………...124.
Table 31: access matrix for class, manage product, manage category and deliveryman………133.
Table 32 access matrix for class’s, login, auction and manager……………………………….133.
Table 33 access matrix for class, login, auction and manager…………………………………134.
xii
CHAPTER ONE
1.1. Introduction
In our today’s global situation of technological evolution of every sector of life, computer systems
and machine learning plat-forms is considered to be the corner stone for every application
including from small to large sector areas of implementation. Technology has been making people’s
life easier since the earliest times. Different things which would have thought to be impossible in the past
are now being seen in reality with the help of technology. Yet, there are still a lot of problems in our country
which could have easily got fixed with the help of technology. Although particularly in the sector of auction,
procurements, and end-to-end delivery plat-forms which is used by most industrial sector of both
governmental and non-governmental organizations.
Auctions and Procurements are perhaps the oldest market places in history. For centuries, people
were allowed to place a price on an item for sale. The person who pledged the highest amount
won. Even though there were no legal contracts and laws in place, the underlying concept remained
the same; both buyer and seller gained something from the transaction. Currently, most of the
governmental and non-governmental organization in Ethiopia use a manual based system which
costs a lot of time and energy.
Giving everything happening using human labor is not a vital task for all companies. Although,
the expectation behind the companies and organization not to have the digital auction,
procurements, and delivery plat-form is the huge amount of money required to develop and
manage the system.
Our system will fix this problem by providing a platform where companies and organizations can
easily use, manage and have their agreement on plat-forms without spending a lot of money.
Besides, the platform provides both parties with an easy way to access all the available auctions,
procurements and delivery service in their areas, save their money, minimizing maladministration
activities, and avoiding loss of time which they would have spent without getting fair and valuable
services. So, we realized that developing this platform is the best solution.
1
1.2. Background of the organization
1.2.1. Mission of Organization
To establish Digital Auction, procurements, and delivery plat-forms as premier online auction
company, making a global impact in the industry and embodying the values of honesty, integrity
and personal touch as the foundation of our business.
1.2.2. Vision of Organization
We bridge the gap between buyers and sellers to provide a seamless experience for all by upholding
the highest standards of auctioneering and by matching the latest technology with the success of
transforming practices.
1.3. Background of Project
Few decades down the line, auctions and procurements were carried in auction houses and the
bids were made with the auctioneer delegating the bids and this method to be carried out either
manually or over the internet from anywhere in the world. The advent of online auctions presents
on its own, different downsides due to the lack of proper evaluation techniques of the products and
the sellers. This result in the buyer uncertainty thus resulting in the reduced effectiveness of the
online auctions making people need for offline auction markets.
Most of online auction and procurements system now a days do not allow for full effective product
description, suggestions, delivery platforms and failure to provide decision making assistance tools
to online bidders results in increased product and seller uncertainty. The buyer’s uncertainty
towards product and seller makes it difficult for the buyers to differentiate between the good and
bad sellers, the lack of differentiation may force higher quality sellers to leave the market since
their quality products do not signal and reward with fair prices thus reducing transaction activity.
Online systems come from a background where there is no full evaluation of the shilling activities,
which take place in different auction and other related systems. The evaluation of shilling activities
goes a long way in providing for certainty in the different type of seller and providing multi-lateral
services. This can be achieved through the provision of the shill scores or shill ratings for each
seller in an auction system and wise integration to form a robust plat-form which will meet their
requirements and by providing the sellers shill rating the different bidders can easily make choices
for the different sellers they decide to bid for their products. The current platform will allow for
2
proper description of the kind of sellers and the kind of products that they sell. These adopted
agency platforms will provide enough detailed information to evaluate the type of sellers and their
products.
1.4. Statements of problem
In Ethiopia a lot of organizations and individuals make different type of auctions and procurements
day to day. Most of these auctions and procurements are manually and faces a lot of problem. In
this manual system there is discrimination against competitors and inequality of access to
information that has been occurred in local auction and procurement system. The user cannot
participate on different auctions on the same time because of far location of bidder and their
document may take by another auction and usually they cannot apply more than one auction at the
same time. In this auction systems corruption, Bribery, and other type of crimes related with
auctions and procurements are committed by fraudster employer of organizations in this case
government and organization lost vast amount of money in each procurement and auction. There
is also a lack of proper document managing and handling this creates losing of necessary data,
auditing problem and security problem.
Due to the disparity of the buyers, fraudsters have always taken the advantage to offer item delivery
to the customers. Many fake items have found their way into the hands of the people, company,
and organizations, or buyers remain in the same condition of lack, as they don’t get the right items
from the sellers. Sometimes buyers struggle to find the right items, without any maladministration
and biases, in failure, stacking for long period of time accompanied by not getting delivery and
they seek to get back to their homes. On the other hand, we have suppliers and business people
who are qualified to supply and sell the items yet they have very few people who can come to
them, more so in the same locality.
The current online systems failed to solve the above problem. In addition, they didn’t include all
type of auctions. They are not inclusive and organizations can’t create and manage their auctions
and products as they want. There is a lack of transparency and efficiency in the bidding process in
the current online auction systems and they failed to identify whether the participant is legal or
not.
3
1.5. Justification of project
The motivation of this project is the lack of crimeless, effective, reliable, inclusive auction and
procurement system for any type of organizations and individuals and the amount of money the
government and other organizations lost by fraudsters in every auction and procurement.
As we know most available current auction, and procurement systems do not fully provide secure
and reliable service. They doesn’t fully evaluate the different type of sellers and bidders that
participate in the auctioning process and maximize participation opportunities and oversight,
increased opportunities for mistakes and corruption, they are not fully or partially integrated and
escorted by any of other bilateral platforms like payment and delivery systems. This project will
create a secure, crime less, reliable and inclusive auction and procurement platform for an
organizations and individuals. Using our project user can prepare their auctions and make
procurements without worrying so they can get quality product and good services related with bid
and procurement they can also save a lot of money which wasted by fraudster employers. Our
project can provide payment and delivery service in order to make full and comfortable platform.
1.6. Objectives
1.6.1. General objective
The general objective of this project is to develop a web based crime less and reliable digitally
automated auction, procurement and delivery platform for all organization and individuals.
1.6.2. Specific objectives
In order to achieving the general objective, the following specific objectives will be achieved:
 Study and research about the existing auctions and procurement system.
 Collect required and use full information for the proposed system.
 Analyze the gathers information and requirements
 Select an appropriate and easy software tool to implement DAAPDP
 Design and analyze DAAPDP
 Demonstrate the working model of DAAPDP
 Implement using the selected tools
4
 Test the system
 Deploy the system
1.7. Scope and Limitation
1.7.1. Scope
The scope of our system includes digital auctions system which includes preparing different type
of auctions like open bid and limited bid form of auctions, participating in auctions, managing
auctions, generate report and announce result. In this functionality the system will provides
document and product validation.
Procurement service is another major functionality of our platform. Organization and individuals
can buy products by choosing different mechanisms like ordering or buying from one or different
product provider or purchasing through auctions.
The other feature of our system is delivery and payment system. In some and common part of
Ethiopia we will have some product stores and delivery men who provide delivery service for the
customers. Current Ethiopian digital Payment system will be integrated with our platform. In
addition to this user can manage their account including managing their activity, login and
registration. The system will also provide notifications and suggestions according to their
experience and location.
1.7.2. Limitations
.
Delivery of product service may not address area part of Ethiopia due to lack of delivery men
and product stores.
1.8. Feasibility study
The fundamental idea here is that deciding if a proposed platform can be made or accomplished.
for example really looking at the acceptance of the platform, formally it is deciding the phase of
acceptance. We analyzed three different types of feasibility test.
5
1.8.1. Operational feasibility
The establishment of the framework it is simple, logical that the installer can without much of a
stretch introduce to the environment of the platform. Since the platform is web based it can be run
in different operating system and this system can be used any individual who have some common
computer or some other smart device skills.
This project is surely operationally feasible because the proposed web system is a good solution
maker for the existing problem related with auction and procurement or specific solution will work
in the existing system and create a good environment towards the user so when the platform is
reached the end users every personal or company that have a contact to the system will gain a
training from the developer how they use it and accessing every segment of the system part.
1.8.2. Technical feasibility
Implementation of this proposed platform will use any operating system, PHP and other scripting
programming language and some hardware devices. By assuming required human, hardware and
software resources, resources are available for the development and implementation of proposed
system. Therefore, it is technically feasible.
1.8.3. Economical feasibility
The proposed platform is economically feasible because the proposed system uses software and
hardware tools that are available by low cost or even for free (open sources software) except for
few major hardware components of the central system like the central data server.
In exciting system there is a lot of corruption and bribery related with from small to big auctions
and procurements. In this case organization lost a lot of money in every procurement and auctions.
Our system will solve this problem by providing secured platform for and it will reduce corruption
and bribery related with auction and procurement by 95%. So, our system is economically feasible.
1.9. Significance of project
By the time this system implemented, many government and non-government offices and citizen
of the country will be benefited
Bing able to create auctions and make procurements.
6
Being able to participate on different auction at the same time.
To decrease auction and procurement related crimes and create crime less auction and
procurement environment in our country.
To provide payment and delivery service for the people who use our system.
To save the money those organizations lost in each auction and procurements by fraudster
employers.
To provide reliable and secured bidding service for the user.
To provide document and product originality checking.
Being able to identify whether auctions and product seller is false or not.
1.10. Beneficiary of the project
Governmental organization:
Governmental organizations will use this system by preparing their own auction, participating in
auction as abider and by making procurement through auction or from one product provider.
Non-governmental organization
Non-governmental organizations also will use this system by preparing their own auction,
participating in auction as a bidder, and by making procurement through auction or from one
product provider.
Individuals:
Individuals can buy products that are provided by certified company by preparing the necessary
document in order to apply they can also participate in the auction. They can get the delivery
system if they are on the place where our delivery system can address.
1.11. Methodology
Data collection methodology

a. Interview:
We have made an interview with some organization and individual about auction and procurement
and get an overview of the current system and the problem of the existing system b. Observation:
We have observed some organizations auction and procurement system and we identified the
common problem in the current system.
7
c. Document analysis:
We have analyzed document which is stored in the office that shows the overview of the existing
system.
Software Development methodology

In order to develop our projects, we use agile software development. The Agile methodology is a
way to manage a project by breaking it up into several phases. It involves constant collaboration
with stakeholders and continuous improvement at every stage. Once the work begins, our teams,
cycle through a process of planning, executing, and evaluating. Continuous collaboration is vital,
both with team members and project stakeholders. Reasons to consider Agile software
developments are:-,
1. More Control: Incremental developments hold tremendous value for the project team and
the customer. Work can be broken into parts and conducted in rapid, iterative cycles. The regular
meetings that are part of agile allow project teams to share progress, discuss problems and work
out solutions. They also help make the entire process more transparent.
2. Better Productivity: The incremental nature of the agile method means that projects are
completed in shorter sprints, making them more manageable. It also allows products to be rolled
out quickly and changes to be easily made at any point during the process.
3. Better Quality: Because it is iterative, one big benefit of agile methodology is the ability
to find problems and create solutions quickly and efficiently. The flexibility of the agile method
allows project teams to respond to customer reaction and constantly improve the product.
4. Higher Customer Satisfaction: Close collaboration between the project team and the
customer provides immediate feedback. The customer is able to make tweaks to their expectations
and desires throughout the process. The result: a more satisfied customer
System analysis and system design methodology
In our project we prefer object-oriented system development methodology (OOSD).

it two phases.
8
a. Object Oriented Analysis (OOA)
During this phase the team used to model the function of the system (use case modeling), find and
identify the business objects, organize the objects and identify the relationship between them and
finally model the behavior of the objects.
b. Object Oriented Design (OOD)
During this phase the team uses enterprise architect software to refine the use case model, and to
reflect the implantation environment, model object interactions and behavior that support the use
case scenario, and finally update object model to reflect the implementation environment.
1.12. Development tool
We will perform this project using different hardware, software and other related materials. Using
these materials we will finish this project in effective and efficient manner. These tools are:-
1.12.1. Hardware material
The following hard ware materials will be used in our project.

Flash :-used for transfer data from one to others
Personal computer(laptop)
CD/DVD- for movement of data and used as a storage.
We will use these hardware materials while developing the project starts from the initial phase
of documentation to the end.
1.12.2. Software material
We will use the following software material for developing our platform. These are:-
Tool Full name Use
JAVA(optional) Used to perform different task

on android studio for mobile
application
PHP Hypertext pre processor For coding our system
9
HTML Hypertext mark-up language For configuration
CSS Cascading-style sheet -It describes how HTML

elements are to be displayed
on screen, paper, or in other

media.
-For layout design, content
decoration in user interface -
Give the style of the interface
MYSQL server Used for database
XAMPP It is also used for the database
Browser For browsing document in

plain text form.
Ms-word 2010 it is used for documentation

Notepad++ Used to editing the program or
source code.
-For writing PHP ,html CSS
and Js code
10
Enterprise architecture a comprehensive operational
(EA) framework that explores all of
an organization functional area.
while defining how technology
benefits and serves the
organization's overall mission.
Laravel It is a PHP frame work used to

implement the system
Table 1. Software material
1.12.3. Other related materials
The other materials that help us while developing our project are:-
Note book-to take some point about the project when we gathering different data.
1.13. Required resources with cost
1.13.1. Hardware resources with cost

No Resource Number of item Price per item(birr) Total price(birr)
1 Flash 2 300 600
2 CD/DVD 3 80 240
3 Personal 2 45000 90000

computer
4 Total 90840
11
Table 2. Hardware resources with cost
1.13.2. Software resources with cost
No Resources Cost
1 Ms-office 2007 or above Free
2 notepad++ Free
3 XAMPP Free
4 Java/optional Free
5 Dart/optional Free
6 Enterprise architecture Free
7 Laravel Free
Table 1.3 Software resources with cost
1.13.3. Other resource with cost
no resource Number of item Price per item(birr) Total cost per

Birr
1 Pen 10 10 100
2 paper 1 and half-packet 500 500
3 notebook 5 50 250
3 internet - 10000
12
4 Tea and coffee - 2000
5 transportation - 5000
6 Printing cost 250 1 250
6 total 18100
Table 1.4 Other resources with cost
13
1.14. Task and schedule
Figure 1.1 task and schedule
14
1.15. Team composition
Digital automation auction, procurement and delivery platform

No Full name Id Email Responsibility
1 Tadiwos A/UR14109/10 tadiwosworkeye6 • Designing

Workeye @gmail.com • implementation
• Testing
• Maintenance
2 Gutu Rarie A/UR14680/10 guturarie@gmail.c • Requirement gathering

om • Designing
• Testing
• Implementation
3 Birhanu Gosa A/UR14249/10 brexgosa267@gm • Requirement gathering

ail.com • Analysis and specification
• Testing
• Implementation
4 Aklilu Zewudu A/UR14327/10 aminaketema@gm • Requirement gathering

ail.com • Maintenance
• Analysis and specification
• implementation
5 Chachisa A/UR14458/10 chalchisatamiru10 Testing

Tamru @gmail.com Implementation
Maintenance
15
design
Table 1.5 Team composition
16
CHAPTER TWO
2. Description of existing system

Starting from earlier time in Ethiopia both government organization, nongovernment organization,
individuals and bidder agents uses old fashioned procurement and auction system which carried
out manually. The government of Ethiopia has drafted a new bill that introduces electronic reverse
auctions, an online real-time procurement process whereby suppliers vie to secure a deal by
offering increasingly lower prices during a scheduled period of time.
An online auction system is the automated and internet-based version of a traditional auction
system, which typically involves sellers and buyers gathered physically to sell and bid for items.
An online auction system can conduct the process through an auction server, which likely can
reduce cost and save energy. E-auction and procurements has gained much importance in recent
years. Although online auctions have been around for some time now, it wasn’t until recently that
various organization started using them revealed that it can play a key role in making online
auctions and procurements successful. Several companies in Ethiopia have tried to follow in the
steps, but have proven to be unsuccessful. As a result, there are a very limited number of eauction
and procurements are available in the context of successful auction system implementations in our
country.
2.1. Major functionality of existing system
Now days in Ethiopia there are several auctions and procurements activities have been developed
in universities, companies, embassies and some agencies become happening as bidding agents.
Some of these systems are AddisAbeba online auction using by us embassy, Edinat auctions.
The major functions of existing system are:
Registration
Wallet
Online transaction and transfers
Auction Message System and feed back
Registration
Any bidder has to have a simple account that identifies them on auction system to place a bid or
to bid, so registration is the main function of their system. Most of the existing system use phone
number as an identifier and verifier so any user that has phone number can register.
17
Wallet
Not all some of existing auction and procurement system uses wallet, this function is important for
the bidders to make transaction, instead of transferring payment from bank to bank or system to
system it stores all the payments and transactions on the wallet system.
Online transaction and transfers

One of big problem in old system, but important and main function of auction and procurement
system. There are a lot of transactions made by bidders in process of auction system so the system
has to do those transactions by connecting banks and payment systems which needs high security.
Nowadays some existing systems are started using online payment system including their own
payment system and existed system in order to make transactions.
Auction
Auction one of functionality in most of the existing system. The bid is set out and managed by
system manager, a person who owned the system, and One can only place bid on the system
through contact with system manager. This means the system does not provide a platform to place
a bid or procurement. Mostly auction is set only for bidders that are willing to buy not to sell.
Message System and feed back

The message system is alternative and easy way of communication between participants and the
bidder. Any additional information regarding the bid and procurement is given through message
system, also participant of the bid can forward complain through message system available.
2.2. User of current system
An auction system is a transaction between sellers (the auctioneers) and bidders (suppliers in
business-to-business scenarios) that takes place on an electronic marketplace or manually in both
governmental and non-governmental organization.
In general user of current systems are:
Governmental organization or public agency (bidder or procurement agent): The governmental
organization should have act as Bidder which means that make offer for the auction available
and also act as a supplier to make their product active for auction.
Private company: Private company also the user of the current system for both auction and
procurements.
18
Group of individuals or Team:
• They register individual who wants to apply for auction.
• They Perform the auction at the time where all bidder available in person.
• At the end they will decide the winner and lose.
Individual owner (Single person) o In current system any individuals can participate in auction
and products will be available for the user or bidder.
2.3. Drawback of current system
Auction and procurement systems should be reliable, efficient and flexible to be used and accepted
among organizations and individuals. The security should be ensured in order to protect user’s
transactions, submission form, personal information and alike.
Reviewing Existing Systems, we consider that they miss important functions that play crucial role
in auction and procurement system
Before the bidding process is end the system shows who is winning or losing which makes
the last person winner by default.
There is no system in which quality of material is measured, even if quality of material the
major basic of auction and procurement
The current System doesn’t recognize document originality
Comparing to the system going to be developed they don’t have integrated delivery
platform.
Every bidding is created and managed only by system manager (system owner) this means
user can’t place bid and customize without contacting system owner.
There is no platform in which organizations formally become member of the system in
which they can create bidding in their own terms and agreement.
They have lack of integrated systems like procurement, auction and delivery in one place.
2.4. Business rule of current system
As we know Ethiopia is one of the developing countries, there are several areas of sector needed
to be developed more, including sector of technology, infrastructure, electricity, education,
telecommunication and etc. This has huge effect on any kind of digital system.
Depending on this situation and other factors, we have categorized business rule of our system as
listed below.
19
Ability of user
Any participants or user of DAPADP (Digitally Automated Procurement, Auction and
Delivery Platform) is has to have ability to read and write.
Any participants or user of DAPADP should have some basic knowledge about using
Digital systems like Customization as needed, browsing, registering and messaging…
Infrastructure
Internet service is should be available to users and should be active to access and
communicate with the system at any time.
Any user should have computer devices like laptop, mobile, desktops and others to
access DAPADP.
Auction and Procurement system
Bid participants should provide a necessary information and items in accordance with
the bid prerequisites.
Any user including the bidder and participants should accept the system and the bid
terms and agreement.
The bidder has to provide the bids detail clearly in way that it can be measured in both
quantity and quality.
Any user including the bidder and participants should accept the legal rules and
regulation of the country set by proclamation including taxation and certifications.
Memorandum of Sale like legal document.
20
CHAPTER 3
3. Proposed System
3.1. Over View
Our system is going to fix the problem by providing a platform where companies and organizations can
easily use, manage and have their agreement on plat-forms without spending a lot of money. Besides, the
platform provides both parties with an easy way to access all the available auctions, procurements and
delivery service in their areas, save their money, minimizing mal-administration activities, and avoiding
loss of time which they would have spent without getting fair and valuable services. For the new user our
system gives recommendation about the conducted auction accordingly the user can easily apply for the
auction without any ambiguity. We also integrate out system with currently existing payment system
.Additionally this system will solve the issue of document validation of the user by using TIN number and
this make our project make different which is not solved by current existing system in our country. So, we
realized that developing this platform is the best solution.
3.2. Functional Requirements
Functional requirements for the Online Automated Auction and Procurement Platform have been developed
to make sure that the functionalities and functional aspects of the system are met.
Login:
System will allow the user to login.
System will verify the user name and password.
System will not allow user to login with invalid username or password.
System will be able to remember username and password.
Registration or create account:
System will allow users such as organizations and individuals to create account bidder
and seller.
Browsing and database search:
21
System will allow user to search products that are available for auction.
System shall display the result.
System will allow the bidder to bid on desired product.
Auction and Procurement:
System will allow users to post the ad for product they want to sell.
System will allow users view their active bids (that are in progress).
System will allow user to view their expired bids.
Create a panel where by a seller receives payment from a buyer.

Create an online platform where bidders create and manage auctions to present their item
for sell and also by using appropriate procedure and restriction they can create auction to
buy items.
System will allows the seller to customize the filed according to their interest
Create a panel where by a seller receives requests from a buyer and sends back a feedback,
an answer to a question or requests to meet the bidder.
To generate reports and view history for each completed bid, procurements, and delivery
actions in the platforms.
Create an online customize forum where procurements for items posted by the platforms
through the agency.
Provide a panel to upload and manage products of organizations.
Provide a panel where users can buy item through direct (without procurement) from
supplier.
Payment
Our system provide payment system by integrating with Ethiopian current digital payment system
Delivery system
22
Our system has delivery system for a user who want to delivery product through our
system
3.3. Non – functional requirements
1. Interactive and Good Performance
The website for online auction management system shall have the following abilities and
capabilities.
The responsiveness of the website shall be high and the website shall behave as per the
user action.
The user shall be acknowledged in the form of visual changes or feedback on the site to
enhance the interaction
Consistency on the website shall be maintained across all the web pages
any number of users can be able to access at a time
2. Security
The website shall offer secure login option to the users to avoid unauthorized Advanced access
control shall be included in the site
We will use encryption algorithm in order to encrypt messages files and in the site to avoid
misuse of the data sets.
3. Reliability
The web site shall provide the users with valid information at all time.
4. Adaptability
The system should adapt itself efficiently and fast to changed circumstances. Since the nature of
the electronic auction is very dynamic it should address adaptability to the changed environment.
5. Accessibility
23
The system should be accessible at any time since it is needed in every second. It is web-based
system; therefore, internet connection and platform are required for the system to be accessible.
6. Compatibility
The system should have to be compatible: - since this system is web based it has to be compatible
with any operating system environment, if web browser installed in the computer and internet
connection is available.
7. Maintainability
The system should be maintainable. It should be easy to add different modules at different times.
And also, the change in one module shouldn’t affect other modules of the system.
8. Usability
The system should be easy for the user, and easy to learn, operate, prepare inputs and outputs
through interaction with a system
3.4. System model
Actor identification
24
Figure 3.1 actor identification: individual user
25
Figure 3.2 Actor identification organizations
26
Figure 3.3: actor identification: Admin
27
Figure 3.4: actor identification: delivery man
28
Figure 3.4.1: actor identification: Manager
29
3.4.1. Scenario
Scenario 1:
Name of Scenario: Log in
Participating instance actor: Admin, user, delivery man, manager
Entry Condition:
The actor must have OAPADP account and Open the system.
Internet connection have to be available.
Flow of events:
user of the system open the login page

Then enters username and password
Click sign in button
The system will display home page of the system
Alternate conditions: If Actor enter invalid username or password that does not match with the
database, the system will send an error message
Exit condition: if the actor login to system properly.
Special requirement: any web browser have to be installed.
Scenario 2:
Name of Scenario: Registration
Participating instance actor: User
Entry Condition:
Flow of events:
user of the system open the system

user open sign up page
30
He/she fills correct registration form
Click sign up button
The system will display success message
Alternate conditions: If the user inputs invalid information the system will send an error message.
Exit condition: if the user registered to system properly.
Scenario 3:
Name of Scenario: Create Auctions
Entry Condition:
Flow of events:
user click Auctions button from navigation bar
31
Select buyer or seller button from create auction box on the top of the page.
Choose type of auction(open bidding, limited bidding)
Fill the necessary information.
Click post button.
Alternate conditions: If the user enter invalid information the system will send an error message
Exit condition: if the user create auction properly.
Scenario 4:
Name of Scenario: Notification and Suggestion
Participating instance actor: User, manager, Admin, Delivery man, Manager
Entry Condition:
Flow of events:
click notification icon

choose new notification and suggestion
Read notification message
Ignore the message or accept and give response..
Alternate conditions: if no new notification, the system will display no new notification message
and display old notifications.
Exit condition: if the system sent notification and the actors see the message without doubt.
Special requirement: Any web browsers have to be installed.

Scenario 5:
Name of Scenario: Apply on auction
32
Entry Condition:
Flow of events:
click notification icon

choose new notification and suggestion
Read notification message
Ignore the message or accept and give response.
Alternate conditions: If the actors enter invalid information or try to make invalid form the
system will send an error message
Exit condition: if the user create auction properly.
Special requirement: any web browsers have to be installed.
Scenario 6:
Name of Scenario: procurement
Entry Condition:
Flow of events:
click procurement button or

the user select the product what they want
fill the form
add to cart
Click Buy button
make payment
33
Alternate conditions: If the actors enter invalid information or try to make invalid form the
system will send an error message
Exit condition: if the user make procurement properly.
Scenario 7:
Name of Scenario: Search Content
Entry Condition:
Flow of events:
Type key on the search bar

Click search button
the system display lists of related item with the search key
Alternate conditions: if there is no result the system display no result found
Exit condition: if the user get result related with search key.

Scenario 8:
Name of Scenario: View Content
Participating instance actor: User, manager, Admin
Entry Condition:
34
Flow of events:
Click Auction or procurement button

Scroll and view available auctions or products which are listed based on order of posting
date.
View result
Alternate conditions: -
Exit condition: if the actors get content of the system without doubt.
Scenario 9:
Name of Scenario: View Bidder
Participating instance actor: User, Admin, Manager
Entry Condition:
Flow of events:
Click Profile button.

Click my auction button
View available auction and select what the user want to see its bidder.
Select bidders and view all applier
Alternate conditions:
If the user have no auction yet, the system will display you haven’t create any auction yet.
if there is no bidder the system will display no bidder applied for this auction yet.
Exit condition: if the actors view correct bidder for particular auction.
35
Scenario 10:
Name of Scenario: Cancel Auction
Entry Condition:
Flow of events:
Click Profile button

Click my auction button
View available auction and select what the user want to cancel.
Fill the reason on the reason from
Click cancel
The system send success message.
If the user fills the reasons which contradict the term and rule of the system, the system
will display error message.
Exit condition: if the user cancel the auction succesfully.

Scenario 11:
Name of Scenario: Complain
Entry Condition:
36
Flow of events:
Click complain button

Select type of complain (invalid bidder announcement or complain about the system)
Fill the form
Click submit button
If the user fills the reasons which contradict the term and rule of the system, the system
Exit condition: if user send complain successfully.
Scenario 12:
Name of Scenario: Procurement
Entry Condition:
The user should apply in auction or make procurement.
Flow of events:
Click payment button

The system will display ‘please confirm’ message.
make payment
The system will display success message.
If the user have not enough account the system will display error message.
37
Exit condition: if user send complain successfully.
Scenario 13
Name of use case: Manage account
Participating instance actor: All actors
Entry condition: All actors must have valid user name and password.
Flow of events:
Firstly, the system display login page after that the user enter username and password and click
login button. The system checks the validity of user name and password. If the user is not legal or
he/she inserts invalid inputs, which have limitations in formality or having differences between
the inserted value and the one which is stored in the database. Then if it’s matching then login the
user into the system. Then:-
He clicks on manage link on panel

The system displays the form
Then he will change, alter, change, Full name, Email address, phone number, and click on
update.
The system displays successful message
If the user enters wrong password and user name the system will display error message. Exit
condition:
Exit Condition: After completing process user is now successfully update in to the system or
rejected if he/she is not legal users.
38
Scenario 14
Name of use case: Report generation.
Participating instance actor: Manager.
Entry condition: Manager must have valid user name and password.
Flow of events:
He clicks on report link on panel

Then he will choose, year or month and click on generate report.
The system will display the generated report.
Alternate conditions: If the user enters wrong password and user name the system will display
error message.
Exit condition: After completing process user is now successfully update in to the system or
39
Scenario 15
Name of use case: Manager gives Feed -back to users
Flow of events:
The system display login page

The Manager enter username and password click login button.
The system checks the validity of manager name and password.
The system logs user in.
He clicks on manage give feed-back link on panel
Then he will see complain from the users and click on give feed-back button.
Then giving appropriate feed-back to the user.
The system displays successful message.
error message. Exit condition:
Exit conditions: After completing process user is now successfully gives feed-back to the users
in to the system or rejected if he/she is not legal users.
Scenario 16
Name of use case: Manager manage all user
40
Flow of events:

The Manager enter username and password click login button.
The system checks the validity of manager name and password.
He clicks on manage user link on panel
Then he will change, alter, change, user accounts, and click on update System displays
successful message.
Exit conditions: After completing process user is now successfully update in to the system or
Scenario 17
Name of use case: Manager Categories
Participating instance actor: Admin.
Entry condition: Admin must have valid user name and password.
Flow of events:
41

The Admin enter username and password click login button.
The system checks the validity of Admin name and password.
He clicks on manage categories link on panel
system displays the form
Then he will change, alter, change, product categories and click on update The system
displays successful message.
Alternate conditions: If the Admin enters wrong password and user name the system will display
Exit conditions: After completing process user is now successfully update product categories in
to the system or rejected if he/she is not legal users.
Scenario 18
Name of use case: Deleting bidders.
Participating instance actor: Admin.
Entry condition: Admin must have valid user name and password.
Flow of events:

The Admin enter username and password click login button.
The system checks the validity of Admin name and password.
42
He clicks on delete bidders link on panel
Then he will select bidder and click on delete.
The system displays bidders successfully deleted message.
Alternate conditions: If the Admin enters wrong password and user name the system will display
Scenario 19
Name of use case: Update product.
Entry condition: user must have valid user name and password.
Flow of events:

The user enter username and password click login button.
The system checks the validity of user and password.
He clicks on update product link on panel.
Then he will select bidder and click on delete.
The system displays bidders successfully deleted message.
43
If the Admin enters wrong password and user name the system will display error message. Exit
condition:
Scenario 20
Name of use case: document validation.
Entry condition:
Flow of events:
1. The system display login page

2. The user enter username and password click login button.
3. The system checks the validity of user and password.
4. The system logs user in.
5. He clicks on auction link on panel.
6. He select the auction as he want and click apply
7. He fill the form and click submit button
8. The system process tin number he submitted the system will display whether the given
information/document is correct or not by matching with tin number data base and
confirm the person user is real by sending validation code to the applier via phone
number.
4a. If the user enters wrong password and user name the system will display error message.
5a. he click on procurement link on panel
44
5b. he click buy item button on the panel
5c. select item and fill the form
5d. If the procurement need document or tin validation the system check the tin number
and display success message.
6a He select create auction
6b. He fill the form and click create
6c. The system process the data and display success message by validating the documents.
7a. The system process the document and display error message if the user submit incorrect
data.
Exit conditions: After completing process user is now successfully create or apply on auction or
make procurement in the system or rejected if he/she is not legal users.
Scenario 21
Name of use case: product originality checking.
Entry condition:
Flow of events:

5. He clicks on product link on panel.
6. The user can view the product review and the number of subscriber of the suppliers in
order to the product is original or not
45
Exit conditions: After completing process user is now successfully add product in to the system
or rejected if he/she is not legal users.
Scenario 22
Name of use case: payment
Entry condition:
Flow of events:

8. The system announce the winner of the auction
9. If the user win the auction he click payment button
10. Fill the form and select pay button
5a. He click on procurement link on panel
5b. He click buy item button on the panel
5c. Select item and fill the form and select buy
46
5d. he click payment button
6a. See the payment information and click confirm
6b.The system will display success message
7. If the user have not balance to pay for the required service the system will display error
message.
47
3.4.2. Use case Model
Figure 3.5 use case diagram
48
3.4.3. Use case Description
Description 1
Use case name Log in
Use case id Uc1
Use case description To authenticate the user
Actor Admin, user, delivery man, manager
Precondition The actor must have OAPADP account and

Open the system.
Post condition Leave from the login page. And display home page.
Main flow 1. user of the system open the login page
2. Then enters username and password
3. Click sign in button
4. The system will display home page of the system
Exceptional flow 3a. If Actor enter invalid username or password that

does not match with the database, the system will send
an error message
Table 2.1 use case description for login
Description 2
Use case name Registration
Use case id Uc2
Use case description Registration of new user
Actor User
49
Precondition The user must have OAPADP account and
Open login page.
Post condition Leave from the sign up page and the system will display
login page.
Main flow 1. user of the system open the system
2. user open sign up page
3. He/she fills correct registration form
4. Click sign up button
5. The system will display success message
Exceptional flow 5a. If the user inputs invalid information the system will
send an error message.
Table 2.2 use case description for Registration

Description 3
Use case name Create Auctions
Use case id Uc2
Use case description Creating various type auctions.
Actor User
Precondition User must have OAPADP account and login to the

system.
Post condition New record will add to database and the system will
notify manager for confirmation.
50
Main flow 1. user click Auctions button from navigation bar
2. Select buyer or seller button from create auction

box on the top of the page.
3. Choose type of auction(open bidding, limited

bidding)
4. Fill the necessary information.
5. Click post button.
Exceptional flow 3a. If the user enter invalid information or try to make
invalid form the system send an error message
Table 2.3 use case description for Create Auctions

Description 4
Use case name Notification and Suggestion
Use case id Uc2
Use case description Notification of useful information and suggestion about

auction.
Actor User, manager, Admin, Delivery man, Manager
Precondition Actors must have OAPADP account and login to the

system.
Post condition Update the status of the notification from unseen

notification to seen notification by the user on the
database
51
Main flow 1. click notification icon
2. choose new notification and suggestion
3. Read notification message
4. Ignore the message or accept and give response.
Exceptional flow 2a. if no new notification, the system will display no

new notification message and display old notifications.
Table 2.4 use case description for Notification and Suggestion
Description 5
Use case name Apply on auction
Use case id Uc2
Use case description Apply or participate to different auctions
Actor User

system. Connection also must be available.
Post condition New record will add to database and notifies manager,
admin and user.
52
Main flow 1. click Auction button
2. The user choose auction which the user want

to apply from available auctions list
3. Click detail button
4. fill the necessary form of auction in the

application form
5. Click apply button
Exceptional flow 4a. If the user enter invalid information, uncertified

document/tin number or if the user doesn’t fit for the
auction the system will display error message.
Table 2.5 use case description for Apply on auction

Description 6
Use case name Procurement
Use case id Uc2
Use case description Notification of useful information and suggestion about

auction.
Actor User, manager, Admin, Delivery man, Manager

Post condition New record will add to database and the system will
display payment page
53
Main flow 1. click procurement button or
2. the user select the product what they want
3 fill the form
4 add to cart
3. Click Buy button
4. make payment
Exceptional flow If the user fill incorrect data the system will display
error message
Table 2.6 use case description for procurement
Description 7
Use case name Search Content
Use case id Uc2
Use case description Search available auction and products.
Actor User, manager, Admin, Manager

Post condition User will apply on auction or make procurement on the

result.
Main flow 1. Type key on the search bar
2. Click search button
3. the system display lists of related item with the

search key
54
Exceptional flow 3a. If the user type invalid character the system will
display error message
3b.if there is no result the system display no result

found.
Table 2.7 use case description for search content

Description 8
Use case name View Content
Use case id Uc2
Use case description View available auction and products.

Post condition User will apply on auction or make procurement on the

available product.
Main flow 1. Click Auction or procurement button
2. Scroll and view available auctions or

productswhich are listed based on order of posting
date.
3. View result
Exceptional flow -
Table 2.8 use case description for view content

Description 9
Use case name View Bidder
Use case id Uc2
55
Use case description View available auction and products.

Post condition User can view the profile of bidder and documents they
submitted for bidding.
Main flow 1. Click Profile button
2. Click my auction button
3. View available auction and select what the

userwant to see its bidder.
4. Select bidders and view all applier
Exceptional flow 3a.If the user have no auction yet, the system will
display you haven’t create any auction yet.
4a. if there is no bidder the system will display no

bidder applied for this auction yet.
Table 2.9 use case description for view bidder

Description 10
Use case name Cancel Auction
Use case id Uc2
Use case description User will cancel his own auctions based on term and
policies
Actor User

56
Post condition Auction will be deleted from the data base and the
system send successfully deleted message.
Main flow 1. Click Profile button
2. Click my auction button
3. View available auction and select what the

userwant to cancel.
4. Fill the reason on the reason from
5. Click cancel
6. The system send success message.
Exceptional flow 5a.If the user fills the reasons which contradict the term
and rule of the system, the system will display error
message.
Table 2.10 use case description for Cancel Auction

Description 11
Use case name Complain
Use case id Uc2
Use case description User will send complain about the system or the bidder
who involve in to auction without valid document.
Actor User

Post condition Auction will be deleted from the data base and the
system send successfully deleted message.
57
Main flow 1. Click complain button
2. Select type of complain (invalid bidder

announcement or complain about the system )
3. Fill the form
4. Click submit button
Exceptional flow 4a.If the enter invalid information the system will
display.
Table 2.11 use case description for complain
Description 12
Use case name Payment
Use case id Uc2
Use case description User will make payment for procurement, auction and
service provider (for us).
Actor User

system. Connection also must be available. The user
should apply in auction or make procurement
Post condition The system will update account payment information

on the database and leave from payment page
58
Main flow 1. Click payment button
2. The system will display ‘please confirm’ message.
3. make payment
4. The system will display success message
Exceptional flow If the user have not enough account the system
Table 2.12 use case description for payment
Description 13
Use case name Manage account
59
Use case number 1
Use case description Manager, Deliveryman, user update, alter, change

account information.
Participating actor Manager, Delivery man, User
Precondition Internet Connection must be available

The instructor or manager has to go to the
website
Flow of event 1. He clicks on manage link on panel
2. The system displays the form
3. Then he will change, alter, change, Full name,

Email address, phone number, and click on update
4. The system displays successful message
Post condition The system saves the entered data into database
Alternative flow-of events o If the Manager fills the form incorrectly

then the system will generate an error
message
o The Manager had been entered wrong past
information.
Table 2.13 use case description Manage account
Description 14
Use case name Update product
60
Use case number 2
Use case description User update, alter, change product information.
Participating actor User
Precondition o Internet Connection must be

available
o The instructor or manager has
to go to the website
3. Then he will change, alter, change, Product

information, and click on update

message
o The Manager had been entered wrong past
information.
Table 2.14 use case description Update product
Description 15
61
Use case name Admin Delete bidder
Use case number 3
Use case description Manager delete outlawed bidder accounts.
Participating actor Manager

available
o The instructor or manager has to
go to the website
3. Then he will change, alter, change, Bidder

accounts,and click on update

message
o The Manager hadn’t successfully delete
bidders.
Table 2.15 use case description Admin Delete bidder
Description 16
Use case name Report Generation
62
Use case number 4
Use case description Manager generate report month or year wise.

available
o The instructor or manager has to
go to the website
Flow of event 1. He clicks on report link on panel
3. Then he will choose, year or month and click on

generate report.
4. The system will display the generated report.
Post condition The system select the entered data from database
Alternative flow-of events o If the Manager fills the form incorrectly then
the system will generate an error message.
Table 2.16 use case description Report Generation
Description 17
Use case name Manager categories
63
Use case number 5
Use case description Manager product categories like add. Delete …etc.

website
Flow of event 1. He clicks on manage categories link on panel
3. Then he will change, alter, change, product

categories, and click on update
Alternative flow-of events If the Manager fills the form incorrectly then
the system will generate an error message
The Manager hadn’t successfully manage the
categories.
Table 2.17 use case description Manager categories
Description 18
Use case name Admin manage all user
Use case number 6
64
Use case description Manager add, create, and delete user.

website
Flow of event 1. He clicks on manage user link on panel
3. Then he will change, alter, change, user

accounts,and click on update
4. The system displays successful message.
Alternative flow-of events If the Manager fills the form incorrectly then
the system will generate an error message
The Manager hadn’t successfully manage users.
Table 2.18 use case description Admin manage all user
Description 19
Use case name Manager, Admin, Login
Use case number 7
Use case description Gives feed-back to complaints.
65
The instructor has to go to the website
Flow of event 1. The system display login page
2. The Manager enter username and password

clicklogin button.
3. The system checks the validity of manager

name andpassword.
5. He clicks on manage give feed back link on

panel
8. Then he will see complain from the users and

clickon give feed-back button.
9. Then giving appropriate feed-back to the user.
10. The system displays successful message.
Alternative flow-of events If the Manager profile fills the form incorrectly
then the system will generate an error message
Table 2.19 use case description Manager, Admin, Login
Description 20
Use case name Log out
Use case number 20
66
Use case description Used to leave from the page
Participating actor Admin /manager/user

The manager /Admin/ user has to go to the
website
Actors must have username and password.
Flow of event a. Actors clicks logout link.
b. The actor leaves the page.
Post condition The actor must be leave from the page.
Alternative flow-of events - ---------
Table 2.20 use case description of log out
Description 21
Use case name Document validation
Use case number 21
Use case description Used to leave from the page

The manager /Admin/ user has to go to the
website

2. The user enter username and password click login
button.
67
3. The system checks the validity of user and
password.
8. The system process tin number he submitted the
system will display whether the given
information/document is correct or not by matching
with tin number data base and confirm the person
user is real by sending validation code to the applier
via phone number.
Alternative flow-of events 4a. If the user enters wrong password and user name the
system will display error message.
5a. he click on procurement link on panel
5b. he click buy item button on the panel
5c. select item and fill the form
5d. If the procurement need document or tin validation

the system check the tin number and display success
message.
6a. He select create auction
6b. He fill the form and click create
6c. The system process the data and display success

message by validating the documents.
7a. The system process the document and display error

message if the user submit incorrect data.
Table 2.21 use case description of Document originality checking
68
Description 22
Use case name Product originality checking
Use case number 22
Use case description Used to check whether the document is original or not.


2. The user enter username and password click login
button.
5. He clicks on product on on the panel he wanted.
6. The user can view the product review and the
number of subscriber of the suppliers in order to the
product is original or not
Alternative flow-of events 4a. If the user enters wrong password and user name the
system will display error message.
Table 2.22 use case description of Product originality checking
69
3.5. Object Model
3.5.1. Data dictionary
Object model is a description of an object-oriented architecture, including the details of the object
structure, interfaces between objects and other object-oriented features and functions.
Class Attributes Operations Description
Authenticate Id Authenticate() Authenticate the

user of the
Log
system
Document ID
Login Username Login() Log the user into

the system
Password Logout()
Check_account()
Reset Username, Email, Security Send Password Reset() Allow the user to
questions Link() reset the
Password password incase
VerifySecurity() they forget they
password
Question()
ValidateEmail()
Access Level Id Allow Access() Allow Access
Deny Access() Set Deny Acces)

Access Level()
getAccessLevel() Set Access
Level
getAccessLevel
70
SignUp User name Login() Allow the user to
Access
Password Get Access()
signup,register,to
Location Logout() request
new
Email Register() password inorder
to participate in
Document Forget Password() auction
Admin Username Register(); Allow the admin

to control the
Password Manage all User();
illegal action and
Add Manager() to start and
Generate_Auction() generate auction
Set_Block()
View_comment()
View_all_statics()
71
Auction auctionName Winner() It allows the
system to
auctionShow Lose()
generate
auctionId the
StartPrice winner and lose
ReservePrice with out the
cloesetTime
human
ownerId
auctionType intervation
Deliver Man User name Deliver_Product() Give delivery

based on the
Password Messaging() need of the user
or Deliver the
Set_Notification() product for the
Manage_Account() Winner
72
Manager Username Manage_Product() Allows
the manager
Password Messaging() to control
the buyer and
Report() seller
Delete_Bidder()
ManageCategory()
Give Feedback()
manateAccount()
Manage_Category()
Confirm_Activities()
Document Document Name Tin validation() Allows to check

legality Check the Legality of
Document ID seller and Buyer
in percentage
Seller User name CreateAuction() Allows the seller

to Create his
Password ViewContent() own aucton for
bidder,manage
CurrentLocation searchContent() auction,create
multiple auction
Tin number getAccess()
at a time and get
ManageAuction() notify about the
Document Id
history of the
Email CustomizeAuction() bidder
startPrice ParticipateAuction()
auctionType
ManageProfile()
73
ownerId Logout()
Register()
ForgetPassword()
OpenBidding()
Payment()
viewBidder()
Bidder User name createAuction() or Allows biddertheto

apply for the
Password getNotification available auction
getSuggestion()
CurrentLocation
setBidAmount()
Tin number
CustomizeAuction()
Document Id
Email ParticipateAuction()
phoneNumber
ManageProfile()
Logout()
Register()
ForgetPassword()
OpenBidding()
Doucment_Validation()
Payment_Transactiom()
SetComplain()
74
Procurement Username, password, email, Add Cart() The system
Tin-number, Document-Id. Create-Auction() View- Allows the

procurement
Content()
buys product from
Search-Content() get- one suppliers or
Access() different suppliers
Manage-Auction())
Participate-Auction()
Manage-Profile()
Logout() Register()
watch-List()
Manage Product Product name, Product-Bid- Update-Product() Allow the seller

Amount delete-Product() and bidder to
Product-Description delete and update
product
Payment amount Allows the user to

perform the
transaction for
admin
Table 2.23 data dictionary
75
3.5.2. Class diagram
Figure 3.6 Class diagram
76
3.6. Dynamic model
3.6.1. Sequence diagram
Figure 3.7 sequence diagram login
77
Figure 3.8 sequence diagram add product.
78
Figure 3.9sequence diagram update product
79
Figure 3.10 sequence diagram organization delete product
80
Figure 3.11 sequence diagram delete product by manager
81
Figure 3.12 Purchasing or procurement sequence diagram
82
Figure 3.13 sequence diagram create auction
83
Figure 3.14 sequence diagram apply to bid
84
Figure 3.15 sequence diagram delete auction
85
Figure 3.16 sequence diagram Delete Bidder
86
Figure 3.17 sequence diagram update profile
87
Figure 3.18 sequence diagram feed back
88
Figure 3.19 sequence diagram complain
89
Figure 3.20 sequence diagram add Categories
90
Figure 3.21 sequence diagram update categories
91
Figure 3.22 sequence diagram block user
92
Figure 3.23 sequence diagram product store
93
Figure 3.24 sequence diagram delivery assignment
94
Figure 3.25 sequence diagram view delivery
95
Figure 3.26 sequence diagram payment
96
Figure 3.27 sequence diagram document validation
3.6.2. Activity Diagrams
We use Activity Diagrams to illustrate the flow of control in a system and refer to the steps
involved in the execution of a use case. We model sequential and concurrent activities using
activity diagrams. So, we basically depict workflows visually using an activity diagram. An
activity diagram focuses on condition of flow and the sequence in which it happens. We describe
or depict what causes a particular event using an activity diagram
1. Registration Activity Diagram
97
98
Figure 3.28 Registration activity diagram
Figure 3.35 Delete manager activities diagram
99
Figure 3.36 Apply bid activities diagram
100
Figure 3.37 Procurement activity diagram
101
Figure 3.38 Add delivery activities diagram
102
Figure 3.39 Document validation activities diagram
103
Figure 3.40 Payment activities diagram
104
3.6.3. State Diagram
Figure 3.41 Registration state diagram
105
Figure 3.42 create Auction state diagram
106
Figure 3.43 Apply auction state diagram
107
Figure 3.44 Delete product state diagram
108
Figure 3.45 Add delivery man state diagram
109
Figure 3.46 Update category state diagram
110
Figure 3.47 Add category state diagram
111
Figure 3.48 Add manager state diagram
112
Figure 3.49 document validation state diagram
113
Figure 3.50 procurement state diagram
114
Figure 3.51 payment state diagram
115
CHAPTER 4
4. System design
4.1. Overview
This is a system Design document to online auction procurement and delivery systems which going
to replace all paper based auction and procurement to digital system for all governmental and non-
governmental organization in order to create corruption free auction and procurement platform.
This document includes the design goal, the proposed system design and object design. System
design is the first part to get in to the solution domain in a software development.
4.1.1. Purpose of the system design
This document describes the design issues of the overall system. It provides the complete
architectural overview of the proposed system and express the show that the system we are
building is designed to replace the paper-based auction and procurement system to an electronic
one. It is intended to capture and express the significant architectural decisions which have been
made on the system as well as to obtain the information needed to create stable auction and
procurement system.
4.1.2. Design Goal
DAAPDP is well designed to assure Reliability, Modifiability, Adaptability, Efficiency,

Portability, Well-defined interfaces, User-friendliness.
Reliability
Any customer based software should have reliability in order to be accepted and used widely.
DAAPDP assures reliability by providing security in order to protect customer’s profile,
transactions also by providing transparent auction system.
Efficiency
DAAPDP designed to achieve high efficiency in that it can give a good satisfaction to the user.
One of the main goal of DAAPDP is digitalizing auction system and avoid discrimination among
customer’s .
116
Well-defined interfaces
DAAPDP designed to provide well organize, simple to understand and easy use, flexible user
interface.
Developer/Maintainer design goal
Minimum number of errors, Modifiability, Readability, Reusability, Adaptability Well-defined

interfaces
For customer design goal
Functionality, User-friendliness, Usability, Ease of learning Fault tolerant Robustness Low cost,
Increased Productivity, Backward-Compatibility Traceability of requirements, Rapid
development, Flexibility
4.2. Proposed system architecture
System architecture is a conceptual model that describes the structure and behavior of multiple
components and subsystems like multiple software applications, network devices, hardware, and
even other machinery of a system. It is Architecture Description Language (ADL) which helps to
describe the entire system architecture. We used model view controller architectural system in our
system.
In the MVC architecture, developing different view components for your model component is
easily achievable. It empowers everyone to develop different view components, thus limiting code
duplication as it separates data and business logic. The MVC platform hugely supports the
development of seo-friendly web applications.
117
Figure 4.1 shows system architecture for our proposed system web application.
4.2.1. System process
The following system process diagrams show overall process of the system in a DAAPDP.
118
Figure 4.2 shows system process of user authentication.
Figure 4.3 shows system process auction and procurement system.
119
Figure 4.4 shows system process of manager in DAAPDP.
120
Figure 4.5 shows system process of Admin in DAAPDP.
Figure 4.6 shows system process of Delivery man in DAAPDP.
121
4.2.2. Sub System Decomposition
To reduce the complexity of the solution domain, we decompose a system into simpler parts, called
subsystems. The main need of this portion is to design the external part of the system. In this
project, there are seven sub system decompositions
Figure 4.7 sub system decomposition
Subsystem decomposition description
Sub system Purpose Functionality
122
User Responsible for managing Register
account, registration and Search content
accessing viewing the content,
notification and suggestion View content
which is produced by the system. manage account
notification and suggestion
view history
Auction Responsible for creating, Create auction
managing participating in Document validation
auction and document validation
in order to create and participate Bidding
in auction. Viewing bidder for View bidder
particular auction and perform
Participate in auction
bidding operation.
Manage auction
Manage auction Responsible for cancel and Cancel auction

delete auctions and delete
Delete bidder
bidders who can’t fulfill
requirement of auctions.
Procurement Enable organizations to manage Buy

and sell their products. Sell
Buying. Users can buy different Document validation
products.
Manage products
Delivery Responsible for delivery product Delivery
for the receiver properly. view delivery information
make delivery order
view order
Payment Responsible for managing Manage transaction
123
and make payment Deposit
Withdraw
Report Responsible for generating Generate report

report.
Table 4.1 Sub system decomposition
4.2.3. Hardware/ software mapping
When we say hardware/software mapping for the system, it describes how subsystems are assigned
to hardware and off-the-shelf components. It also lists the issues introduced by multiple nodes and
software reuse. In this system design mainly there are three hardware components, the client side,
server side and database side. When the team applies the system, necessary software will be loaded
to each side hardware components. Network should be installed between each side. Then each sub
systems software will be assigned and configured to the mapped hardware. Then the local area
network will be connected to the internet and the system will be functional. But now it is a design
phase. The hardware software mapping of the system is described below with a simple diagram.
124
Figure 4.8 hardware/ software mapping
4.2.4 Persistent data management
The purpose of this section is to show the mapping of the objects/classes of the system, identified
during the analysis stage, in to the corresponding relational database.
Figure 4.9 persistent data management
125
Figure 4.10 Object Bidder mapping
Figure 4.11 Object Auction mapping
126
Figure 4.12 Object document legality check mapping
Figure 4.13 Object Payment mapping
Figure 4.14 Object Delivery man mapping

127
Figure 4.15 Object complain mapping
Figure 4.16 Object Product category mapping
128
Figure 4.17 Procurement mappings
Figure 4.18 Object order mappings
Figure 4.19 Manager mappings
129
4.2.5. Component diagram
The following component diagram represents a group of graph of components connected by

dependency relationships and dependencies are shown as dashed arrows from the client
component to the supplier component
Figure 4.20 component diagram
130
4.2.6. Database design
The figure bellow shows the relationship mapping of each table in a relational database.
Figure 4.21 database design
131
4.2.7. Access control
The information which registered in the system must be very highly secure. Our system has
different actors and each actor have access to different functionality and they have different data
access privilege. Therefore, each privilege data access will give the users their own data access
privilege.
The table below will show the access table, describing the access relation b/t the actors, objects
and operations in the system.
Actor Manage Product Manage Category Delivery Man
Manager Delete Product() Delete category() Manage Delivery()

Delete Bidder() Update category
Request() Add category()
Table 4.2: access matrix for classes, manage product and manage category and delivery man
Actor Login Auction manager
Admin Login() Winner() Add manager()

Verify() Lose() Delete
manager()
Validate() Generate View
Set log() auction() comment()
viewBidder()
Close auction()
Start auction()
Table 4.3 access matrix for class’s, login, auction and manager
132
Actor Login bidder auction
User Login() create auction() Open bidding()

Verify() Payment(): Manage product()
payment
Validate() viewBidder() set
Set log() bid amount()
Cusomize
auction()
Manage product()
Document
validation()
Payment()
Manage profile()
Table 4.4 access matrix for class’s, login, bidder, auction
133
4.2.8. User Interface design
Figure 4.22 user interface
134
CHAPTER 5
Implementation
5.1. Overview
Implementation is the process of integrating the system functions or the development of software
and hardware.
Based on the functional and non-functional requirements of the project Our project implements
the functional and non-functional requirements of the proposed system.
Implementation is integral to systematically increasing maturity, reducing risk and ensuring the
system is ready for Integration, Verification, and Validation. The Implementation process
provides a system that satisfies specified design and stakeholder performance requirements. As a
best practice, the Systems Engineer should develop an implementation plan that includes
implementation procedures, fabrication processes, tools and equipment, implementation
tolerances and verification uncertainties.
5.2. Coding Standard
Coding standard is a standard or protocols that should be considered as a rule or way of coding
elements that are required to ensure a high level of technical interoperability between shared
programming language codes. Also these standards are collections of coding rules, guidelines,
and best practices that help us to write cleaner code.
These standards are required to tell which way the code must or must not implemented in a given
programming language.
5.2.1. Purpose
The goal of these coding standards is to create uniform coding habits among software personnel
in the implementation of the project so that reading, checking, and maintaining the code written
by different persons becomes easier. The intent of these standards is to define a natural style and
consistency, yet leave to the authors of the programmer source code, the freedom to practice
their craft without unnecessary burden.
135
When a project adheres to common standards many good things happen:
Programmers can go into any code and figure out what’s going on, so maintainability,
readability, and reusability are increased.
Code walk through become less painful and new people can get up to speed quickly.
People make fewer mistakes in consistent environments, so reliability is increased. .
Lead to high productivity, maintainability, shared authorship,
Experience over many projects points to the conclusion that coding standards help the
project to run smoothly.
Since a very large portion of project scope is after-delivery maintenance or enhancement,
coding standards reduce the cost of a project by easing the learning or re-learning task
when code needs to be addressed by people other than the author, or by the author after a
long absence.
Coding standards help ensure that the author need not be present for the maintenance and
enhancement phase.
The standards and guidelines described in this project were selected on the basis of common for
coding practices within our group and from many language specific programming standard
documents collected throughout the general principle and standards implemented in Laravel
frameworks. They can’t be expected to be complete or optimal for each project and for each
language. Individual projects may wish to establish additional standards beyond those given here
and the language specific documents. So that sweeping per-project customizations of the
standards are discouraged in order to make it more likely that code throughout a project and
across projects adopt similar styles.
This is a list of coding practices that should be standardized for each project, and may require some
specification or clarification beyond those detailed in the standards documents.
1. Naming conventions: What additional naming conventions should be followed is that in
particular, systematic prefix conventions for functional grouping of global data and also for
names of structures, objects, and other data types may be useful. Some of this are;
Meaningful and understandable variables names should be nouns and help
anyone to understand the reason for using them.
Class names also should use underscores and Capital letter for every word It
is better to avoid the use of digits in variable names.
136
Indentation: Proper indentation is very important to increase the readability
of the code.
For making the code readable, some of the spacing conventions are given below:
There must be a space after giving a comma between two function arguments.
Each nested block should be properly indented and spaced.
Proper Indentation should be there at the beginning and the end of each block in
the program.
All braces should start from a new line and the code following the end of braces
starts from a new line.
2. Project specific contents of module and subroutine headers.
Avoid using an identifier for multiple purposes: Each variable should be given a
descriptive and meaningful name indicating the reason behind using it.
This is not possible if an identifier is used for multiple purposes and thus it can lead to
confusion to the reader. Moreover, it leads to more difficulty during future
enhancements.
3. File Organization: What kind of Include file organization is appropriate for the projects data
hierarchy Directory structure Location of Make Files (note: “Actions taken before
compilation or assembly is performed should be the directory in which the source code
resides, unless otherwise specified.)
4. Specifications for Error Handling: specifications for detecting and handling of errors
specifications for checking boundary conditions for parameters passed to subroutines. All
functions that encounter an error condition should return either a zero or one for simplifying
the debugging.
5. Revision and Version Control: configuration of archives, projects, revision numbering, and
release guidelines.
6. Guidelines for the use of “lint” or other code checking programs.
7. Standardization of the development environment - compiler and linker options and
directory structures.
137
5.3. Development Tools
Client-side: the web browser is installed on the employee side as well as on the user’s side. This
web browser is responsible for interaction between the system and the users of both types. The
requests from users to be processed at the server-side of the system emanates from the user
interface presented on the web browser.
Server-side: is the program running on the server to respond to the requests from the users, which
are delivered through the client-side web browser.
The server-side performs the following main tasks are User authentication, Process user input,
Bid and procurement computation, Read/write file on the server Database query operations
Programs, applications, programming languages and frameworks used to develop the system
includes
Laravel: Is an open-source PHP framework designed to make developing web apps easier and
faster through built in features.
Bootstrap, Jquery, is css and javascript frameworks used to develop the system respectively.
MySQL: is a database management system that allows you to manage relational databases.
Visual Studio Code: is a source-code editor that can be used with a variety of programming
languages.
Xampp: is an open-source software developed by Apache Friends. XAMPP software package

contains Apache distributions for Apache server, PHP, and Perl. And it is basically local host or
a local server.
5.4. Prototype
A prototype is nothing but a mock test of our ideas in an early stage of production. It lets we gain
valuable feedback from the users before the final product is delivered to the clients. While we
run our prototypes, there are a lot of inputs that can be undertaken which improves the overall
workflow of the process, too.
138
Figure 5.1 Interface Login
Figure 5.2 Interface User registration
139
Figure 5.3 Interface add Category
140
141
Figure 5.4 Interface add product page
Figure 5.5 Interface product page
Figure 5.6 Interface Admin page
142
Figure 5.7 edit product page
143
Figure 5.8 Interface home page
Figure 5.9 Interface available auction
144
5.5. Implementation Detail
Since our platform is web based application, its implementation is basically categorized in tow
main implementation detail. These are: Client-Side implementation detail
Server-side Implementation detail
5.5.1 Client Side implementation detail
It is the program that runs on the client machine (browser) and deals with the user interface/
display and any other processing that can happen on client machine. This includes what the user
sees, such as text, images, and the rest of the UI, along with any actions that an application
performs within the user's browser. It is a part of program that runs on a user's local computer,
smartphone, or other device, and connects to a server as necessary. Our system client side has
the following major category
145
User front end
Manager front end
Administration front end
Delivery man front end
User front end: - The part of implementation which provide interface to interact users with the
system. These users can be organization or individuals.
Manager front end: - The part of implementation which provide interface to interact managers
with the system.
Administration front end: - The part of implementation which provide interface to interact
administrator of the system with the system.
Delivery man front end: - The part of implementation which provide interface to interact delivery
men with the system.
Some code of client side implementation
Fig 5.10 code sample1
146
Fig5.11: code sample2
147
Fig 5.14:- code sample5
148
5.5.2 Server-Side implementation detail
Server-side part of implementation refers to operations that are performed by the server in a
client–server relationship in computer networking. Some Operations should be performed
serverside because they require access to information or functionality that is not available on the
client, or because performing such operations on the client side would be slow, unreliable, or
insecure. It is used to interact with permanent storage like databases or files. The server
program will also render pages to the client and process user input. Server-side processing
happens when a page is first requested and when pages are posted back to the server.
Chapter Six
System Testing
6.1 Introduction
System testing is the process of testing how the systems functional and non-functional
requirements are performing their functions correctly and effectively. Especially the system
testing focuses on the back end of the system
6.2 Scope
The scope of the system includes register basic information, detail information, Tin number
validation, Auction processes, procurement processes, notifications, payment and
transactions, and delivery processes.
6.3 Resources
Are any materials used to specify utilized for testing the our system. Like SRS documents.
149
6.4 Schedule
Scheduling is the time arrangements given by the responsible body of the system to perform
whatever activities designed.
Table 22 schedule
Date Of Testing
Types Of Testing Tested By
Unit testing 11/03/2022 Aklilu and Birhanu.
Integration testing 27/04/2022 Tadiwos and Gutu.
System Testing(Installation 6/05/2022 Chalchisa.
Testing)
6.5 Features to be tested and not to be tested

6.5.1 Features to be tested
Are any features in the system that can be tested by the developers of the system? This is
mostly focus on functional requirements of the system.
Table 23 Feature to be tested
No Test Target Feature to Tested by

be tested
1 Functional requirements General Aklilu , Birhanu
Functionality of the
system
3 Code Each Tadiwos and Gutu

code/components
4 Platform Run on different Chalchisa
systems
6.5.2 Features not to be tested
Are any activities of the system that are not mostly tested by the developers of the system.
Table 24 features not to be tested
150
No Test Target Feature to Tested by
be tested
1 Non Functional requirements Non-functional Aklilu
requirements are
not tested except
security
6.6 Pass/fail criteria
Is the situation in which the pass and fail criteria’s of the system are determined using
standard terminologies of pass/fail pass/fail. These are mostly described in the table below.
Table 25 pass/fail criteria
Functional Expected result Actual outcome Pass/fail
requirement criteria
Login/Authentication pass Pass pass

Auction process pass Pass pass
Procurement process pass Pass pass
Delivery process pass Pass pass
Notifications pass Pass pass

Tin number pass Pass pass
validation
Payment and pass Pass pass
transactions
Approach
Is the method that can be used by the developers to specify the testing task.
Methodology:
151
With this testing approach, all the specs were ready for a prototype, and a plan was already
built to be shown; the tester started writing his or her code and saw if he or she could obtain the
same results that the specs mentioned. This way, the specs were tested on each prototype, and
continuous testing was applied. This also helped to minimize the testing that would have to be
implemented at the end of the software lifecycle. In the process, all aspects of the software were
tested. When the testing approach was implemented, the following Advantages and
Disadvantages regarding the testing approach were realized.
Advantages of using the methodology

✓ Helps to give a better understanding about the requirements.
✓ Better design at the end of the cycle.
✓ Reduced testing to be performed at the end of the cycle
✓ Documents produced would be of higher quality.
Disadvantages of using the methodology
✓ The person working on the document should be experienced.
✓ There are increased time and money involved with testing.
✓ Different viewpoints for the same problem can lead to varying results
6.7 Test case specification
Table below shows the test specifications of functional requirements used to write the test
cases along with the test case numbers for each test case and a short description of the test
cases.
Table 26 test case specification
Functional Test case Test-case short description

requirement no. no
FR01 TC01 To test the Login/Authentication interface for all
user.
FR02 TC02 To test the Tin number validation to proceed.
FR03 TC03 To test home page and services (auction,

procurements, delivery) interface for the system.
FR04 TC04 To test, users are able to get notifications.
FR05 TC05 To test, payment integration and transactions.
FR06 TC06 To test, Crud Operations of Admin on managers
and organizations.
FR07 TC07 To test the users able to use the delivery system.
152
The following list includes the steps that should be taken by the user, the conditions that
should be met for the successful execution of the test case, and the end result that should be
met for the test cases to pass.
1. TC01 To test the Login/Authentication interface
➢ Input: username and password
➢ Output: valid destination page
➢ Valid range: username->Alphanumeric, password->Alphanumeric.
➢ End message/Result:
I. If (User == Valid User), a success message is displayed on the login
interface and route to the dashboard.
II. If (User! = Valid User), an error message is displayed on the Login
interface. Incorrect Username/password combination.
2. TC02 To test the Tin number validation to proceed.

➢ Input: Tin number
➢ Output: valid destination page
➢ Valid range: Tin number >Alphanumeric.
➢ End message/Result:
III. If (Tin number == Valid), a success message is displayed on the login
interface and route to the dashboard or to the specified pages.
IV. If (User! = Valid), an error message is displayed on the Login interface.
Incorrect Tin number.
3. TC03 to test home page and services (auction, procurements, delivery) interface for the
system.
➢ Description of Purpose: The system shows all the users to view the homepage
and services available on the system. The user can choose any services among
given by our plat-forms or go back to continue for another services.
➢ Input: The customer login using valid user name and password.
➢ Output: The system displays the, home-page.
4. TC04 to test, users are able to get notifications.
➢ Description: The user can get notifications when there is announcements and
auctions results.
➢ Input: Authenticated users click notification icons on navigation bar.
➢ Output: New or modified announcements or information in the system will be
displayed.
5. TC05 to test, payment integration and transactions.
➢ Description: The user can check out or process systems.
153
➢ Input: Authenticated users click on payment link to proceed.
➢ Output: Payment form will be displayed.

➢ End result/message:
I. If (user == valid (User data || Information) && User data/Information
=existing), then display successful message.
6. TC06 to test, Crud Operations of Admin on Managers and organizations.
➢ Description: The Admin can add or upload auctions, products, procurements,
and Managers data to the system or organization data.
Input
VII. User=Admin
VIII. ii. Selection=User Data
IX. iii. Selection=Information
➢ Output: New or modified user data or information in the plat-form.
II. If (member type = “Admin” &Selection = (User data || Information) &&
User data/Information =existing), then display the modified data or
information in the DAAPDP.
7. TC07to test, users are able to use delivery system.

➢ Description: The user can get delivery service when if it’s needed for the
auction, procurements they are participated.
➢ Input: Authenticated users can select and order delivery service.
➢ Output: Delivery form will be displayed.
III. If (user == valid (User data || Information) && User data/Information
=existing), then display successful message.
6.8 Estimated risk and contingency plan
Risk: Is any risk that the system developer can face during developing the system and
contingency plan is the plan developed to solve the risk that the developer face.
Table 27 Risk Planning
Estimated Risks Contingency Plan
Lack of training on tools like MySQL, Allocate more time for training on the tools.
apache that are used during the
implementation
154
Difficult to test the performance of the Testing the performance of the system after the
system at the central level host.
Lack of knowledge on programming Allocate more time on programming-languages
languages
The resources that are used insufficient Analyze tools required and allocate them.
for implementation.
The time required to develop the Allocate one more week than deadline.
software is under-estimated.
Cost problems to buy and test the Using the algorithms those use the minimum cost for
algorithms we used in the system testing.
CHAPTER SEVEN
Conclusion and Recommendation
7.1 Conclusion
DAAPDP plat-form is the main thing which are undertaken in the national level.
This system is a web-based application to serve all users as well as the working group of the
system in better manner. The benefits of our system can be summarized as improved the
manual system and unique individual and organizational users by making centralized online
system without pretending or holding fake Tin number.
While developing DAAPDP system we have gained more knowledge and experience about
the different phases of the software development life-cycle, PHP, MVC structure,
programming languages. As a software engineering student, we are working together and to
solve a lot problems related to auction, procurements and delivery plat-forms.
Through various challenging, now the team is coming to the end of this project. Those
different challenges made possible by the cooperation of all the group members. In
developing this project all group members contributed their full capability with maximum
interest and all group members get ways toward developing a project.
155
.
7.2 Recommendation
While doing this system the team has faced different challenges. But by the cooperation of
all the group members now able to reach to the final result. Our plat-form is developed by
all the group members through strongly fought those challenge as much as possible. Now all
the group members recommend to other developers who want to maintain this system, to add
some features which are not completed on this system. Among the limitations adding google
tracer for delivery system and if it’s needed the system scope can also inclusive for
international users.
CHAPTER EIGHT (8)
8.1 User Manual
8.11 How to register.
DAAPDP is an online agency plat-form that enable every of it’s users to have account as
individuals and organizations in-order to assign.
1. In order to register to the system first you have to click the ‘register’ button on the top right
corner of the page
2. Then the registration form will display and after filling all the fields hit the sign-up button
that will submit your form.
156
Figure 91. Register Manual
157
8.12 How to apply to procurements.
All authorized users have full right to apply for auctions and participate in bidding processes.
1. Click on the apply button from procurement list, that you want to apply.
2. Read the description and fill all needed forms in order to start the application process.
3. After clicking the ‘Submit apply’ button that will submit the form.
Figure 92. Procurement Manual
8.13How Apply to Auction.
All authorized users have full right to apply for auctions and participate in bidding processes.
1. Click on the applynow button from auction list, that you want to apply.
3. After clicking the ‘Submit apply’ button that will submit the form.
158
Figure 93. Apply Auction manuals
8.14 How to order delivery.
Users of auction and procurements including buyers and sellers will use our delivery service by
applying to the form provided by our plat-forms.
1. Click on the register button from delivery page, that you want to apply.
3. After clicking the ‘register’ button that will submit the form.
159
Figure 94. Delivery Manual
8.15 How to pay a payment.

our plat-form supports yene-payment gate-way integration to provide transactions to all of our
users.
Figure 95. payment manual.
160
8.16 How to get announcements and notifications.
Notifications are provided to all users of our project to ensure accountability and transparency of
our system.
1.first the user must login into our plat-form.
2.Secondly there is navigation button notification click on it.
3.Then you can see notifications and announcements.
Figure 96. notification manuals

8.2 Get-Address and Version of the project.
The GitHub address of our project is https://github.com/Taaa-W/daapadp.

For more information you can refer our git-hub accounts with a given specified
links.
161
Figure 97. git hub account info.
162
REFERENCE
Clearwater, S.H., Xerox Corp, 2010. Auction-based control system for energy resource
management in a building. U.S. Patent 5,394,324.
Dutta, R. and Ramamoorthy, K., International Business Machines Corp, 2009. User rating system
for online auctions. U.S. Patent 7,552,081.
Fageha, M. and Aibinu, A. 2013. Managing Project Scope Definition to Improve
Stakeholdersâ€™ Participation and Enhance Project Outcome. Procedia – Social and Behavioral
Sciences, 74, pp.154-164.
Gemino, A. and Parker, D. 2009. Use Case Diagrams in Support of Use Case Modeling. Journal
of Database Management, 20(1), pp.1-24.
Kamau, C.,2015. Efficacy of Monitoring and Evaluation Function in Achieving Project Success
in Kenya: A Conceptual Framework. Science Journal of Business and Management, 3(3), p.82.
Konia, B.S., MARKET MY SITE Inc, 2007. Online auction bid management system and method.
U.S. Patent 7,225,151.
Lin, Z., Li, D., Janamanchi, B. and Huang, W., 2010. Reputation distribution and consumer-to-
consumer online auction market structure: an exploratory study. Decision Support Systems,
41(2), pp.435-448.
Maltzman, R., eBay Inc, 2008. Method and system to enable a fixed price purchase within a
online auction environment. U.S. Patent 7,340,429.
Milunovic, S. and Filipovic, J.,2013. Methodology for quality management of projects in
manufacturing industries. Total Quality Management & Business Excellence, 24(1-2), pp.91-107.
Sanchez, H., Robert, B., Bourgault, M. and Pellerin, R. (2009). Risk management applied to
projects, programs, and portfolios. International Journal of Managing Projects in Business, 2(1),
pp.14-35.
Rotman, G., Rotman, R. and Martin, J., Paid Inc, 2008. Method and system for improved online
auction. U.S. Patent 7,324,968.
Shavit, E. and Teichner, L., STRATEGIC PROCESSING CORP, 2011. Interactive market
management system. U.S. Patent 4,799,156.
Zwikael, O. (2009). The Relative Importance of the PMBOKÂ® Guide’s Nine Knowledge Areas
during Project Planning. Project Management Journal, 40(4), pp.94-103
https://en.wikipedia.org/wiki/Unified_Modeling_Language https://www.tutorialspoint.com
https:// www.google.com
https://www.wikipedia.org/
https://sparxsystem.com/
163

Digitally Automated Auction Procurement and Delivery Platfrom

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Digitally Automated Auction Procurement and Delivery Platfrom

Uploaded by

Copyright:

Available Formats

ADAMA SCIENCE AND TECHNOLOGY

A SENIOR PROJECT DOCUMENTATION SUBMITTED FOR THE PARTIAL FULFILLMENT

Project Title: Digitally Automated auction, procurement and delivery Platform

Submission date: June 08,2022

Tadiwos Workeye __________________________ June 8, 2022

Student Signature Date

Birhanu Gosa __________________________ June 8, 2022

Student Signature Date

Gutu Rarie __________________________ June 8, 2022

Student Signature Date

Aklilu Zewdu __________________________ June 8, 2022

Student Signature Date

Chalchisa Tamru __________________________ June 8, 2022

1. Mss Lomi Deressa ___________________________ June 2, 2022

2. Mr. Abubeker Yimam ___________________________ ____________________

3. ______________________ ______________________ ____________________

ASTU ADAMA Science and Technology University.

Figure 28 sequence diagram view delivery…………………………………………………..….96.

Figure 53 procurement state diagram………………………………………………………….115.

Figure93 auction manual………………………………………………………………….……158.

Figure95 Payment manual……………………………….…………………………..…………160.

Figure96 Notification manual………...………………………………………………………..160.

Figure97 Git hub info…………………………………………………………………………..161.

Table 23 use case description Manager Categories……………………………………………..61.

1.2.1. Mission of Organization

1.2.2. Vision of Organization

1.3. Background of Project

1.4. Statements of problem

1.6.1. General objective

1.6.2. Specific objectives

1.8. Feasibility study

1.8.2. Technical feasibility

1.8.3. Economical feasibility

1.9. Significance of project

1.10. Beneficiary of the project

Data collection methodology

Software Development methodology

System analysis and system design methodology

In our project we prefer object-oriented system development methodology (OOSD).

b. Object Oriented Design (OOD)

1.12. Development tool

1.12.1. Hardware material

The following hard ware materials will be used in our project.

1.12.2. Software material

JAVA(optional) Used to perform different task

PHP Hypertext pre processor For coding our system

CSS Cascading-style sheet -It describes how HTML

on screen, paper, or in other

MYSQL server Used for database

XAMPP It is also used for the database

Browser For browsing document in

Ms-word 2010 it is used for documentation

Laravel It is a PHP frame work used to

1.12.3. Other related materials

1.13. Required resources with cost

1.13.1. Hardware resources with cost

1 Flash 2 300 600

3 Personal 2 45000 90000

1.13.2. Software resources with cost

1 Ms-office 2007 or above Free

6 Enterprise architecture Free

Table 1.3 Software resources with cost

1.13.3. Other resource with cost

2. Mr. Abubeker Yimam _______

3.