Final Document For Department

ADDIS ABABA UNIVERSITY
FACULTY OF NATURAL AND COMPUTATIONAL

SCIENCES
DEPARTMENT OF COMPUTER SCIENCE
FDRE Procurement Management System
FINAL PROJECT BY:

NAME IDNO
Daniel Demeke NSR/2147/07
Million Haile NSR/0968/07
Yonas Beyene NSR/5834/07
ADVISOR: Mekonnen Geremew
December 2017
DECLARATION
This is to declare that this project work which is done under the supervision of Mekonnen
Geremew and having the title Design and Implementation of Web Based Procurement
i|Page
Management System, the case of FDRE Public Procurement and Property Administration
Agency is the sole contribution of:
Daniel Demeke
Million Haile
Yonas Beyene
No part of the project work has been reproduced illegally (copy and paste) which can be
considered as Plagiarism. All referenced parts have been used to argue the idea and have
been cited properly. We will be responsible and liable for any consequence if violation of this
declaration is proven.
Date:_____________________
Group Members:
Full Name Signature
Daniel Demeke ________________________________
Million Haile ________________________________
Yonas Beyene ________________________________
ii | P a g e
CERTIFICATE
I certify that this BSc final project report entitled Design and Implementation of Web Based
Procurement Management System, the case of FDRE Public Procurement and Property
Administration Agency by:
Daniel Demeke
Million Haile
Yonas Beyene
is approved by me for submission. I certify further that, to the best of my knowledge, the
report represents work carried out by the students.
_________________________ ____________________________________
Date Name and Signature of Supervisor
iii | P a g e
ACKNOWLEDGEMENT
We, the group members take this opportunity to give thank for God for all things that he did
for us.
We, also take this opportunity to express our profound gratitude and deep regards to our
advisor Mekonen Geremew for his exemplary guidance, monitoring and constant
encouragement throughout his project.
We are obliged to staff members of PPA, for the valuable information provided by them in
their respective positions. We are grateful for their cooperation during the period of our
assignment.
The group members
iv | P a g e
ABSTRACT
The purpose of this research is to identify the current system of agency and to device a well-
designed and organized automated procurement service giving software. The first phase of
the project involves a screening interview where we identify current working environment of
the agency. We also use observation of the working environment and related documents to
have a clear know how on the main activities of the agency.
v|Page
PREFACE
This project discusses the requirement analysis and elicitation of the working environment of
FDRE public procurement and property administration agency. Followed by the software
design document and object design document.
vi | P a g e
Contents
DECLARATION........................................................................................................................i
CERTIFICATE........................................................................................................................iii
ACKNOWLEDGEMENT........................................................................................................iv
ABSTRACT..............................................................................................................................v
PREFACE.................................................................................................................................vi
TABLE CONTENT.................................................................................................................xii
ACRONYMS.........................................................................................................................xiii
CHAPTER ONE........................................................................................................................1
INTRODUCTION.....................................................................................................................1
1.1 INTRODUCTION..........................................................................................................1
1.2 STATEMENT OF THE PROBLEM AND JUSTIFICATION...........................................2
1.3 PROJECT OBJECTIVE......................................................................................................3
1.3.1 General objective..........................................................................................................3
1.3.2 Specific objectives........................................................................................................3
1.4 SCOPE OF THE PROJECT................................................................................................4
1.5 METHODOLOGY..............................................................................................................4
1.5.1 Investigation (Fact-finding) Method.............................................................................4
1.5.2 Development Methodology..........................................................................................4
1.6 SIGNIFICANCE OF THE PROJECT.................................................................................6
1.7 BENEFICIARIES................................................................................................................6
1.8 TIME SCHEDULE..............................................................................................................6
CHAPTER TWO.......................................................................................................................9
REQUIREMENT ANALYSIS..................................................................................................9
2.1 INTRODUCTION...............................................................................................................9
2.2 CURRENT SYSTEM..........................................................................................................9
2.2.1 Major Function of the Current System/ Current System Description........................10
2.2.1.1 Director General..................................................................................................10
2.2.1.3 Government Procurement Directorate.................................................................10
2.2.1.4 Government Property Management Directorate..................................................11
vii | P a g e
2.2.1.5 Government Procurement and Property Management to investigate a complaint
Directorate.......................................................................................................................11
2.2.1.6 Information Technology /IT/Unit........................................................................11
2.2.2 Scenario..................................................................................................................11
2.2.3 Problems of Existing System......................................................................................19
2.3 REQUIREMENT GATHERING......................................................................................20
2.3.1 Requirement Gathering Methodology........................................................................20
2.3.2 Result Found...............................................................................................................20
2.4 PROPOSED SYSTEM......................................................................................................21
2.4.1 Overview.....................................................................................................................21
2.4.2 Functional Requirements............................................................................................21
2.4.3 Non-Functional Requirement.....................................................................................22
2.4.3.1 User Interface and Human Factors......................................................................22
2.4.3.2 Documentation.....................................................................................................22
2.4.3.3 Hardware Consideration......................................................................................23
2.4.3.4 Performance Characteristics................................................................................23
2.4.3.5 Error Handling and Extreme Conditions.............................................................23
2.4.3.6 Quality Issues.......................................................................................................23
2.4.3.7 System Modification............................................................................................23
2.4.3.8 Physical Environment..........................................................................................23
2.4.3.9 Security Issues.....................................................................................................24
2.5 CONSTRAINTS/ PSEUDO REQUIREMENTS..............................................................24
2.6 SYSTEM MODELS..........................................................................................................24
2.6.1 Use Case Models........................................................................................................24
2.6.1.1 Use Case Diagrams..............................................................................................24
2.6.1.2 Description of use case model.............................................................................25
2.6.3 Object Model..............................................................................................................35
2.6.3.1 Data Dictionary....................................................................................................36
2.6.3.2 Class Modeling....................................................................................................40
2.6.4.1 Sequence Diagram...............................................................................................41
2.6.4.2 State chart diagram..............................................................................................51
viii | P a g e
2.6.4.2 User Interface.......................................................................................................52
CHAPTER THREE.................................................................................................................62
SYSTEM DESING..................................................................................................................62
3.1 INTRODUCTION.....................................................................................................62
3.2 CURRENT SOFTWARE ARCHITECTURE...................................................................62
3.3 PROPOSED SOFTWARE ARCHITECTURE.................................................................62
3.3.1 Overview.....................................................................................................................63
3.3.2 Subsystem Decomposition..........................................................................................64
3.3.4 Persistent Data Management......................................................................................67
3.3.5. Access Control and Security......................................................................................74
3.3.6 Subsystem Services...............................................................................................77
3.4 Detailed Class Diagram.....................................................................................................80
3.5 packages.............................................................................................................................84
3.5.1 Description of Package...............................................................................................84
User management package..............................................................................................84
Bid management package................................................................................................84
Post management package...............................................................................................84
Interface package.............................................................................................................84
Message management package........................................................................................84
3.5.2 Dependency of Package.....................................................................................86
CHAPTER FIVE.....................................................................................................................87
IMPLEMENTATION..............................................................................................................87
5.1 Introduction........................................................................................................................87
5.2 Testing Plan.......................................................................................................................87
5.2.1 Features to be tested....................................................................................................87
5.2.2 Features not to be tested........................................................................................88
5.2.3 Pass Fail Criteria.........................................................................................................88
5.2.3.1 System Testing.....................................................................................................88
5.2.3.2 Integration testing................................................................................................88
5.2.3.3 Unit testing...........................................................................................................88
5.2.4 Approach.....................................................................................................................89
ix | P a g e
5.2.4.1 Testing Levels......................................................................................................89
5.2.4.2 System/Integration Testing..................................................................................89
5.2.4.3 Unit Testing.........................................................................................................89
5.2.4.4 Integration Testing Strategy................................................................................89
5.2 Testing Procedure..........................................................................................................90
5.3 Sample Code......................................................................................................................91
Post Management.................................................................................................................91
Post class..........................................................................................................................91
Bid Management..............................................................................................................95
Message management....................................................................................................100
Account management....................................................................................................104
Comment management..................................................................................................114
File Management...........................................................................................................117
System Log Management..............................................................................................117
CHAPTER SIX......................................................................................................................117
CONCLUSION......................................................................................................................117
REFERENCE........................................................................................................................119
Figure 2.1 the structure of the organization.............................................................................10

Figure 2.2 use case diagram.....................................................................................................25
Figure 2.3 class diagram..........................................................................................................43
Figure 2.4 Register user...........................................................................................................44
Figure 2.5 Register Agent........................................................................................................45
Figure 2.6 Register Public Body..............................................................................................45
Figure 2.7 Login......................................................................................................................46
Figure 2.8 Update account.......................................................................................................46
Figure 2.9 Create Message......................................................................................................47
Figure 2.10 Add user to black list............................................................................................47
Figure 2.11 Create Post............................................................................................................48
Figure 2.12 Create Comment...................................................................................................48
x|Page
Figure 2.13 Search...................................................................................................................49
Figure 2.14 Create bid.............................................................................................................49
Figure 2.15 Apply on bid.........................................................................................................50
Figure 2.16 Approve bid request.............................................................................................50
Figure 2.17 Save document.....................................................................................................51
Figure 2.18 Delete account......................................................................................................51
Figure 2.19 Password Recovery by admin..............................................................................52
Figure 2.20 Password Recovery by user..................................................................................53
Figure 2.21 system log............................................................................................................54
Figure 2.22 State chart of supplier and buyer..........................................................................55
Figure 2.23 State chart of public body and worker of agency.................................................55
Figure 2.24 Registration form screen mock-up.......................................................................56
Figure 2.25 Profile mock-up....................................................................................................57
Figure 2.26 Notification screen mock-up................................................................................57
Figure 2.27 Login form screen mock-up.................................................................................58
Figure 2.28 Bid document screen mock-up.............................................................................59
Figure 2.29 Worker of age.......................................................................................................60
Figure 3.1 subsystem decomposition.......................................................................................65
Figure 3.2 hardware/software mapping...................................................................................66
Figure 3.3 ER diagram.............................................................................................................68
Figure 3.4 detail class diagram six.........................................................................................84
Figure 3.5 Package diagram....................................................................................................86
Figure 3.6 package dependency...............................................................................................87
TABLE CONTENT
Table 1.1 Project activities Time table......................................................................................8
Table 2.1 supplier and buyer data dictionary...........................................................................38
Table 2.2 data dictionary of public body.................................................................................39
Table 2.3 data dictionary of agency worker............................................................................39
Table 2.4 data dictionary of message......................................................................................39
Table 2.5 data dictionary of saved document..........................................................................40
Table 2.6 data dictionary of bid document..............................................................................41
Table 2.7 data dictionary of post.............................................................................................41
Table 2.8 data dictionary of system log file............................................................................42
Table 3.1 Access control..........................................................................................................77
Table 3.2 subsystem service....................................................................................................80
xi | P a g e
Table 5.1 test procedure table
xii | P a g e
ACRONYMS
 Bid Document: - Documents required to be submitted to the agency from the buyer or
supplier in response to an invitation to bid. These include the prescribed bid form,
drawings, specifications, time lines, charts, price breakdowns, etc.
 Buyer: - organization who makes a purchase from the public body.
 Common use items: - is a type of materiel that is required for use by more than one
activity by the public body. In the agency policy the following are the common use
item:- Vehicle, Stationery Items, Computers, Printers, Office Furniture, Cleaning
Materials, Medicines and Drugs, Books and Magazines, Uniforms, Electrical
Equipment’s, Laboratory Supplies and Equipment, Pipes and Fittings, Filing
Cabinet, Herbicide and Insecticide, Laboratory Chemicals.
 Complains: - the supplier, buyer or public body expresses their dissatisfaction or
annoyance about something for the agency.
 PPA:- federal democratic republic of Ethiopia Public Procurement and Property
Administration Agency
 Procurement:- means the purchasing, hiring, or obtaining by any other contractual
means of goods, works and services.
 Procurement plan: - procurement management template to define how you are going
to purchase goods and services from suppliers. It prepared by public body.
 Public body: it is the governmental organization in the federal level where it
procurement and asset management is done by the agency
 Supplier: - organization that provides something needed such as a product or service
for the public body.
xiii | P a g e
CHAPTER ONE
INTRODUCTION
1.1 INTRODUCTION
The Federal Public Procurement and Property Administration Agency is one of the Federal
Agency found in the city Of Addis Ababa around sidist killo. The agency has different
departments that do the different work processes. We didn’t focus on all departments that
exist in the agency; we only focus on the departments that have connection with the
procurement process and Asset management.
Ethiopia Procurement Agency is committed to building a transparent and ethical civil

service. The Ethiopia government enacted a new public procurement proclamation in 2005,
issued a revised procurement directive, and Public Procurement Agency (PPA) was
established.
The strategy focused on the promotion of proper implementation on of the public

procurement proclamation, development of manpower capacity to carry out public
procurement functions, and the strengthening of uniform application of the procedures laid
down in the public procurement Directive and Standard Bidding Documents in all public
bodies at federal and regional levels.
Procurement means the purchasing, hiring, or obtaining by any other contractual means of
goods, works and services. Public procurement is the process of the acquisition, usually by
means of a contractual arrangement after public competition, of goods, services, works and
other supplies by the public entity. The procurement process spans the whole life cycle from
initial conception and definition of the needs through the end of the useful life of an asset or
the end of a contract.
In procurement process and asset management process there are different actors that
participate on it. We define some the actors that have relationship with our system:
1|Page
PROJECT PROPOSAL
 Public body: it is the governmental organization in the federal level where it

procurement and asset management is done by the agency.
 Supplier: - organization that provides something needed such as a product or service
for the public body.
 Buyer: - organization who makes a purchase from the public body.
The reason why we are interested to develop a system for the public Procurement Agency
(PPA) is the current system of the agency is paper based and because of this the Procurement
process takes long time and it is requires high cost to complete. If the agency system
becomes computerized, the process of procurement and asset management takes small time
and cost, the agency can manage easily and it reduces paper work.
1.2 STATEMENT OF THE PROBLEM AND JUSTIFICATION

The system of the agency is paper based currently due to this the Asset management process
and procurement process takes high time and cost. Not only this there is also other problem
of the current system like: the error rate of the request from the public body and suppliers is
high, the management process is hard, work of the agency is not transparent for the public
body and the suppliers, the sending and receiving request and answers to the public body or
to the suppliers is also hard, the chance of information duplicate in the current system is high,
the relationship between the agency and supplier and public body is not strong.
In the above paragraph we tried to describe the problem of the current system of the agency
from the agency point of view. In this paragraph we will try to describe the problem of the
current system from the public body point of view. The process of procurement takes a long
period of time due to this the public body can’t get the required service or the goods at
required time, almost all works are done on a paper, the way of sending request and receiving
answer from the agency also takes a long period of time, the rate of the order request error is
high and if the error happens the public body must send the request again, the relationship
between the public body, the agency and the supplier is not strong due to this the exchange of
the information between them is not strong.
2|Page
Design and Implementation of Web based Procurement Management System,
the case of FDRE Public Procurement and Property Administration Agency
We will also try to describe the problem of the current system from the supplier and buyer
point of view in this paragraph. The suppliers can register online on the website of the
agency this is the good side of the current system but the buyer registration is no included on
the current system. Only the supplier registration is computerized other process is still done
on paper due to this the process of sending complaints and getting information is hard, like
mention before the relationship between the three bodies is not strong because of this the
exchange of information between the three body is low, the current system takes long period
of time and high amount of cost.
Importance of the system:-
 The agency can receive complaints easily,

 The agency can manage the procurement process and asset.
 The agency, public body, supplier and buyer can save cost and time.
 The public body can send their requests and doubts easily.
 Reduce the order error rate.
 The suppliers and buyers can compete easily.
 Paper work can be reduced.
 The suppliers and buyer can get any information easily.
 The agency works will become transparent for the public body and suppliers.
1.3 PROJECT OBJECTIVE
1.3.1 General objective

The main objective of our project is to design and develop web based system for the FDRE
public procurement and property management agency.
1.3.2 Specific objectives

The specific objectives of the project are to:
 Elicit requirements.
 To prepare requirement analysis document.
 Design the objects of the system.
3|Page
PROJECT PROPOSAL
 Design the overall system.

 To design user interface
 To design database
 Implement efficient and interactive system.
 Test the system.
 Deploy the system.
1.4 SCOPE OF THE PROJECT

Our project changes the process of procurement, Asset management and the way of receiving
complains from the public body from paper based in to computerized system. The project
doesn’t work for the contract agreement between the supplier, buyers and public body and
other works that done by the agency.
1.5 METHODOLOGY
1.5.1 Investigation (Fact-finding) Method

In this project, we use the following methods in order to clearly point out the detailed
problems and requirements pertaining to the systems to be developed. These include:
 Observation
 Interview
 Document analysis
1.5.2 Development Methodology
Under this section we are going to describe the methods used to build this project.
Development Approach: we have selected agile development approach on our project, since
the approach has the following benefits: - there are regular checkups to see that the product is
working during the development, it allows the development team to address issues while
they’re still fresh, small incremental releases with each release building on previous
4|Page
functionality can help us build the system based on the functional requirements, each release
is thoroughly tested to ensure software quality is maintained this helps us to work on single
functionality at a time and make sure the functional requirement is met, demonstrating
working functionalities to customers in every sprint can help us get constructive feedback
which will be used to make the system better, it helps create Transparency between the
development team and the end users of the system, it virtually eliminate the chances of
absolute project failure since most functionalities of the system will be done before the
project deadline date.
Requirement analysis methodology Tools
For the diagrammatic and pictorial representation throughout the document we are going to
use
 Visual Paradigm. : Because visual paradigm is an easy tool to represent a system in a
diagrammatic way and explain the diagram to a third person.
For the other written documentation we intend to use
 Microsoft office professional 2016

It is the latest version of word processors and it is also widely used on most computers
 Microsoft project 2013: is an application that we are using for scheduling our
procedures during the phases of the project.
For the implementation phase we are going to use: -
 IIS server: we are going to use IIS server to develop and test our system before
deployment. We have chosen IIS because.
 C#: - handles the server side scripting. C# is popular among the developer community, is
easy to learn and code, recent researches show that C# is the most frequently used server
side scripting language. C# is also powerful with modern features and proper object
oriented programming model.
 Bootstrap: well be used to render the display. We selected bootstrap because it is easy
and have many pre-prepared classes that will come in handy in the system development.
5|Page
PROJECT PROPOSAL
 JavaScript will be applied to process the client side scripting because processing
everything on the server side will create an overhead on the server.
 SQL Server
 Razor Script
1.6 SIGNIFICANCE OF THE PROJECT

The significance present of our project is that it changes the paper based procurement system
of the agency into a computerized system due to this the agency, suppliers and public body to
do the procurement process easily and it take short time relative to the paper based process.
1.7 BENEFICIARIES
At the end of this project the main beneficiaries are:-
1. The Public Procurement Agency (PPA) is beneficiaries form our system because the
system reduce the paper work, the time that takes to accomplish the procurement
processes and the asset management, our system also decease the rate of duplicated
information in the system, the agency can receive information form the suppliers,
public body easily, the system decrease the cost of the agency and the agency can
easily manage the procurement process and it works became transparent for the
public body and suppliers.
2. Public body is beneficiaries from our system because the system reduces order error
rate, it decrease the paper work, the public body can easily communicate with the
agency or with the suppliers, it decrease the time for the procurement process, the
public body can get any information about the procurement process, the work of the
agency became transparent.
3. Suppliers and buyers is also beneficiaries from our system because the they can get
the information from the agency and can send any complains to the agency easily,
reduce the paperwork, cost and time saving.
6|Page
4. Lastly the beneficiary from this project is us. Because will learn how to collect the
data from the customers, the way to prepare document, and the implementation part
has also its own advantage on increasing skill of the group members.
1.8 TIME SCHEDULE

The project is supposed to be done according to the deadline set by the department.
So in order to finish the project perfectly we have subdivided in a preferable manner.
7|Page
PROJECT PROPOSAL
Table 1.1 Project activities Time table
8|Page
CHAPTER TWO
REQUIREMENT ANALYSIS
2.1 INTRODUCTION
The main benefit of our system is reduced the costs and time through various ways, including
the followings: Improved internal efficiency, Cut supplier costs, Reduces order error rate etc.
The most important benefits for management offered by online procurement are: greater
management influence and control over the purchasing process and improved management
information across all areas of purchasing and Asset management.
The public body’s benefits are: the reduced order rate error, they can order to the agency in
simplest way and in short period of time, the paperwork decreased, they can report any
questions or complain easily to the agency.
The supplier’s and buyer benefits are: improved relationships with the buyers, cost and time
savings, reduction of paperwork and duplicated records. From the strategic purchasing
benefits they also mentioned: increased purchasing power and profit margin, improved
efficiency and gaining competitive advantage.
2.2 CURRENT SYSTEM

As mentioned in the introduction part, the agency has many different departments. But we
will only focus on some departments of the agency that have relationship with the
procurement process and Property management. First we will try to represent the relationship
of the department in graph and then we will describe the function of each department listed
on the graph.
9|Page
2.2.1 Major Function of the Current System/ Current System Description
Director General
Deputy Director
General
Government Government Information

Government
Property Procurement Technology
Procurement
Management and Property /IT/Unit
Directorate
Directorate Management
to Investigate
a Complaint
Directorate
Figure 2.1 this figure shows the structure of the organization
2.2.1.1 Director General

The director general is responsible to manage and control the agency. And the director
general is responsible to decide on the special procurement process.
2.2.1.2 Deputy Director General
The deputy director general has the responsibility to administrate the agency and when the
director general is absent the deputy director general is responsible to work as the director
general.
2.2.1.3 Government Procurement Directorate

The government procurement directorate is responsible to control the procurement process
and it is also responsible to advice the public body about the procurement and it also
coordinates trainings for the public body about procurement.
10 | P a g e
2.2.1.4 Government Property Management Directorate

The government property management directorate is responsible to control the removing of
the expired material from the public body and it gives advice for public body about asset
management and it coordinate the training programs for the public body about asset
management.
2.2.1.5 Government Procurement and Property Management to investigate a complaint

Directorate
This department is responsible for receive complains from the public body, suppliers and
buyer and it investigate the correctness of complains. After investigation it gives decision or
sends complains into the agency board. The agency board makes a decision on the given
issues and sends its decision to the public body, suppliers and other the departments that has
the relationship to the case.
2.2.1.6 Information Technology /IT/Unit

The Information Technology unit is responsible to control the computer system in the agency
and it supports the agency worker about the computer.
2.2.2 Scenario
Here we try to describe the as-is scenario. As-is scenario is a story with narrative details on
how the operations are currently being performed on the agency.
Scenario Name Common Procurement Process

Participating actors  Addis Ababa University: - the public body. its procurement
instance property is managed by the agency.
 Hirut: - is work in the Government Procurement Directorate.
 Procurement Expert: - is worker in the government
procurement directorate and responsible to procurement
process.
Entry condition The Addis Ababa university determines the need to buy and prepare
the procurement plan document. Here the need of university is the
common use items and the procurement process is the normal. If the
need of the university are not the common use items and if the
11 | P a g e
procurement process is differ from normal the university used

special procurement process. The common use items are listed
below:- Vehicle, Stationery Items, Computers, Printers, Office
Furniture, Cleaning Materials, Medicines and Drugs, Books and
Magazines, Uniforms, Electrical Equipment’s, Laboratory Supplies
and Equipment, Pipes and Fittings, Filing Cabinet, Herbicide and
Insecticide, Laboratory Chemicals.
Flow events 1. The university sends the procurement plan document to the
agency. Hirut receive the procurement plan document.
2. The Procurement expert prepares criteria to compare the
suppliers on the trend process.
3. The procurement expert selects the procurement method.
4. The department starts bid process begins.
Exit condition The Addis Ababa university gets the answer of the request from
agency.
Scenario Name Special Procurement Process.

Participating actors  The public body: - governmental office in federal level or
instance high educational level.
 Director General
 Deputy Director General
 Procurement Expert: - the persons that has the profession
on procurement methods.
 Registry: - the place that the agency stores the document.
Entry condition The public body determines the need to buy and prepare the
procurement plan document.
Flow events 1. The procurement plan registered on the registry.
2. The procurement plan document sends in to the director
12 | P a g e
general.
3. The general director sends the procurement plan document to
the deputy general.
4. The deputy general sends the procurement plan document to
the procurement experts.
5. The procurement experts check the procurement plan
document and send their answer to the deputy general
director.
6. The deputy general director sends back to the general
director.
7. If the general director decision is allow the procurement
process. The Government Procurement Directorate prepares
the criterial of trend process to compare the suppliers, select
the procurement method and begin the trend process.
Alternative flow 7.1 If the general directors decision is not allow the procurement
process the agency stop the process here and send the answer to the
public body.
Exit condition The public body gets the answer of the trend document.
Scenario Name Register supplier

Participating actors  Mintesnot is the CEO of the Zzard Car Rental co.
instance
Entry condition The Mintesnot open the website (www.ppa.org.et) of the agency on
browser.
Flow events 1. The Mintesnot click on the link that says New Supplier
Registration.
2. The Mintesnot fulfill the required information on the form.
Required information is: - type of supplier, TIN No/Other
identification, city, country, email, telephone, fax, password,
verify password.
13 | P a g e
3. After fulfill the form correctly Mintesnot click on the register

button.
4. The Mintesnot goes to its email address and confirms the
request to active the account.
5. The Mintesnot back to the agency website and click on the
member login link. To login the Mintesnot must enter the
user name and password.
6. After login the supplier click on the new button. And the
form displayed on the screen.
7. The Mintesnot fulfill the form. To fulfill the form the
Mintesnot must enter the following information: - business
license number, region, sub city, town, wereda/kebele, house
number, capital and business type.
8. After fulfill the required information the Mintesnot click on
the save button. And say logout from the system.
9. If Mintesnot wants to check correctly registered. It click on
the supplier list and find his name on the list.
Exit condition The supplier registered on the supplier list of the agency.
Scenario Name Bid Process.

instance  Procurement Expert
 Hirut
Entry condition  The Mintesnot first registered on the supplier list of the
agency.
 The Government Procurement Directorate makes the bid
invitation to the Mintesnot.
Flow events 1. The Hirut tells bedding information to the Mintesnot.
14 | P a g e
2. The Procurement expert prepares the bid document.

3. If it is important Procurement expert make modification on
the bid documents.
4. The Mintesnot buys the bid document.
5. The Procurement expert receives the bid document and
opens it.
6. Procurement expert Performing initial assessment.
7. Procurement expert Make a detailed assessment.
8. Procurement expert Tell the result of bid to the Mintesnot.
9. Separate the winner supplier in the bid process and make
contract agreement with them.
Exit condition The winner of the bid is known.
Scenario Name Supplier Complains

instance  Yoseph is the worker on Government procurement and
property management to investigate a complaint directorate
department.
 Board of Appeals: this collection of different person from
different department and offices to investigate complains and
makes last decision.
Entry condition The Mintesnot prepare letter that describe about the problem.
Flow events 1. The Mintesnot gives letter to Yoseph.
2. The government procurement and property management to
investigate a complaint directorate make decision on
complain that come from the supplier.
Alternative flow 2.1 If the Government procurement and property management
to investigate a complaint directorate department is not
give the decision in 10 working days or if the Mintesnot
thinks the decision of the department is not correct the
15 | P a g e
Mintesnot can report its problem to the Board of Appeals.

2.2 The board collect the important information about
complain and make it decision.
Exit condition The Mintesnot gets the decision from the Board of Appeals or from
the government procurement and property management to
investigate a complaint directorate.
Scenario Name Public body complains.

Participating actors  Addis Ababa University
instance  Mintesnot is the CEO of the Zzard Car Rental co.
 Yoseph is the worker on Government procurement and
property management to investigate a complaint directorate
department.
 Board of Appeals: this collection of different person from
different department and offices to investigate complains and
makes last decision.
Entry condition  The Addis Ababa University prepare the report of complain
on Mintesnot works.
Flow events 1. Yoseph receive the report from Addis Ababa University.
2. The government procurement and property management to
investigate a complaint directorate gives decision on the
case. And if the decision may be banning the supplier from
competing in any governmental bid process for required
period of time.
Alternative flow 2.1 If the Government procurement and property management
to investigate a complaint directorate department is not give
the decision in 10 working days or if the Addis Ababa
University thinks the decision of the department is not
16 | P a g e
correct the Addis Ababa University or Mintesnot can report

its problem to the Board of Appeals.
2.2 The board collect the important information about complain
and make it decision.
Exit condition The Addis Ababa University and the Mintesnot get the decision of
the complaint report from the government procurement and property
management to investigate a complaint directorate or board appeals.
Scenario Name Consulting public body

instance  Government Procurement Directorate
 Government Property Management Directorate
Entry condition The Addis Ababa University send letter to the agency for
consulting.
Flow events 1. If the Addis Ababa University is for procurement
consulting the government procurement directorate gives
advices to the university.
Alternative flow 1.1 If the university request is for the property management the
government property management directorate gives the answers to
the request of the university.
Exit condition The Addis Ababa University gets the answer for their requests.
Scenario Name Remove expired material.

instance  Bekele worker on the Government property management
directorate department.
 The property management Experts is worker on the
government property management directorate department.
17 | P a g e
Entry condition The Addis Ababa university sends the request to agency for
removing expired material.
Flow events 1. The Bekele receives the request.
2. Property management experts Check the request to deiced
whether the expired material removed by the agency or
university.
3. If property management experts deiced to remove the
expired material by the agency they begin the bid process.
Alternative flow 3.1 If the property management expert deiced to remove the
expired material by the university. University organizes
the board that controls the bid process.
3.2 The public body begins the bid process by it own.
Exit condition The Addis Ababa University gets answer from the government
property management directorate for their request.
Scenario Name Bid process for removing expired material.

Participating actors  Chala is Buyer that want to compite on the bid process and it
instance has the renewed business licenses.
 Chaltu is the worker on the government property
management directorate department.
 The property management Experts is worker on the
government property management directorate department.
Entry condition The government property management directorate makes invitation
to the buyer to participate in the bid process.
Flow events 1. Chaltu tells bedding information to the buyer.
2. Property management experts prepare the bid document.
3. If it is important the experts can make modification on the
bid documents.
18 | P a g e
4. The chala buys the bid document.

5. The property management experts receive the bid document
and open it.
6. Property management experts performing initial
sassessment.
7. Property management experts make a detailed assessment.
8. Property management experts tell the result of bid to chala.
9. Separate the winner buyer in the bid process and make
contract agreement with them.
Exit condition The winner of the bid is known.
2.2.3 Problems of Existing System

The system of the agency is paper based currently due to this the Asset management process
and procurement process takes high time and cost. Not only this there is also other problem
of the current system like: the error rate of the request from the public body and suppliers is
high, the management process is hard, work of the agency is not transparent for the public
body and the suppliers, the sending and receiving request and answers to the public body or
to the suppliers is also hard, the chance of information duplicating in the current system is
high, the relationship between the agency and supplier and public is body is not strong. In the
above paragraph will try to describe the problem of the current system of the agency form the
agency point of view. In this paragraph will try to describe the problem of the current system
from the public body point of view. The process of procurement take a long period of time
due to this the public body can’t get the required service or the goods at required time, almost
all work done on a paper, the way of sending request and receiving answer from the agency
is also take a long period of time, the rate of the order request error is high and if the error
happens the public body must send the request again, the relationship between the public
body, the agency and the supplier is not strong due to this the exchange of the information
between them is not strong.
We also try to describe the problem of the current system from the supplier point of view in
this paragraph. The suppliers can register online on the website of the agency this is the good
side of the current system but other process is stile done on paper due to this the process of
19 | P a g e
sending complains and get information is hard, like mention before the relationship between
the three body is not strong because of this the exchange of information between the three
body is low, the current system take long period of time and high amount of cost.
2.3 REQUIREMENT GATHERING
2.3.1 Requirement Gathering Methodology

We gathered the information from the agency in the different ways. The ways that we used to
gather the information are listed below:-
1. By reading the manuals: - the first method of gathering information from the agency
is by reading the manual of the agency. The manuals are prepared by different body
of the agency. Like asset management and procurement management agencies. We
get the manuals from the website and the worker of the agency.
2. By viewing the website of the agency: - the agency has website to register the
suppliers and to post news and also the manuals are download from the website.
3. By interview the workers of the agency: - the other method of gathering information
from the agency is by interview the workers in different department. In this time we
ask the worker different type of question like:-
1. The organization of the current system.
2. The steps of the current procurement process and the way of asset management
3. The responsible of each department that exist on the current system.
4. The authority of the agency.
5. We ask to give for us the paper manual and blushers and we ask others question.
2.3.2 Result Found

After the gathering the information we get the following results:
1. The structure of the existing system.
20 | P a g e
2. The name and function of the department that participate on the process of procurement
and asset management.
3. The stages of the procurement process and asset management.
4. The way of the public body or the suppliers send complains request to the agency.
5. The required thing from the supplier and buyer to participate on the trend process.
6. The objective and visions of the agency.
7. Polices of the agency in the procurement process and asset management.
8. The type of the procurement process and the way of removing expired materials from
the public body.
2.4 PROPOSED SYSTEM
2.4.1 Overview
The proposed system is aimed at providing simple, efficient, and effective means by which
the procurement process and asset management increases accuracy, minimizes cost and
increases the agency workers, public body and supplier satisfaction. This means the system
facilitates the procurement process, asset management and other activities of the agency.
2.4.2 Functional Requirements

In this section we will describe the functional requirement our proposed system. The
functional requirement is describe the relationship between the system and its environment.
The environment includes the supplier, public body and other users or system that interacts
with our proposed system.
The functional requirements that the proposed system must fulfill are listed below:-
FR-1:- Only authorized users shall login to the system.

FR-2:- The system shall allow suppliers and buyers to create account.
FR-3:- The system shall allow admin to create account for public body and worker of
agency.
FR-5:- The system shall allow admin to delete accounts any account in the system.
FR-6:- The system shall allow department of the agency to exchange information through
message.
FR-7:- The system shall allow departments to post data.
21 | P a g e
FR-8:- The system shall allow user to view, comment and like on posts.
FR-9:- The system shall allow users and agency to exchange message.
FR-11:- The system shall allow Government Procurement Directorate to create bid
process.
FR-12:- The system shall allow supplier or buyer to view and participate on bid process.
FR-13:- The system shall allow Admin to add supplier or buyer to black list.
FR-14:- The system shall allow users to manage their account.
FR-15:-The system shall allow admin to recover password of any account except supplier
and buyer account.
FR-16: - The system shall allow supplier and buyer to recover their password.
FR-17:- The system shall generate log file that contains any action taken by the user and
any change made in system.
FR-18:- The system shall allow admin to view the log file.
2.4.3 Non-Functional Requirement
2.4.3.1 User Interface and Human Factors

NFR-1:- Anybody can access the website on the mobile or computer.
NFR-2:-Users shall provide instructions to the system using mouse and keyboard by clicking
on the menu items and typing into the fields provided by the system.
NFR-3:- The system is easily to learn.
2.4.3.2 Documentation
NFR-4:-Because system documentation addresses programmers, system developers, owners
and users, the system shall generally provide internal – program source code and use case
22 | P a g e
models, the conceptual model and interaction diagrams (activity, sequence, and state
diagrams) documentations.
2.4.3.3 Hardware Consideration

NFR-5:-System shall run on any computer or mobile.
NFR-6:- System shall run on centralized main server.
NRF-7:-The system shall need networked environment.
2.4.3.4 Performance Characteristics
NFR-8:- The system shall respond to a given request within seconds.
2.4.3.5 Error Handling and Extreme Conditions

NFR-10:-Accidental threats like improper data input, destruction of data during processing
shall be controlled by the system.
NFR-11:-Physical threats like theft and natural and human disasters shall be prevented using
guards, backup and physical proofing of the system components.
2.4.3.6 Quality Issues

NFR-12:-Quality issues shall be considered by observing the reliability requirements like:
backup, user requirements, technical issues such as algorithm and the like.
NFR-13:- The system can be accessed by any type of computer and operating system.
2.4.3.7 System Modification
NFR-14:-Parts of the system which are likely the candidates for later modification shall be
user interfaces and the class diagrams of the system which may encounter a change based on
the new requirement of the owner, or new introduction of governmental policies.
2.4.3.8 Physical Environment

NFR-15:-Any user of the system can access the system in any place and in any time.
NFR-16:-The main server of the system is placed on the office of the agency.
23 | P a g e
2.4.3.9 Security Issues

NFR-17:-The system shall authenticate every user to login to the system.
NFR-18:-The system validate the interred information from the supplier or buyer to create
account is correct or not.
2.4.3.10 Resource Issues
NFR-19:- The system installation shall be undertaken by the project deployment team and
the department of the agency Information Technology unit.
NFR-20:-The information technology unit is responsible for the system back up.
NFR-21:-The information technology unit is responsible for the system maintenance.
2.5 CONSTRAINTS/ PSEUDO REQUIREMENTS

In the constraints or pseudo requirement we will describe the client restrictions on the new
system. The user of system like supplier, public body, worker of the agency and buyer must
have user name and password to get the functionality of system.
2.6 SYSTEM MODELS
2.6.1 Use Case Models

A use case is a list of actions or event steps typically defining the interactions between a role
and a system to achieve a goal. The actor can be a human or other external system. The use
case can be represented by diagram or the text on the first.
2.6.1.1 Use Case Diagrams

In the above figure we show use case model in diagram. The diagram contains actors and the
name of the use case, the diagram also represents the interaction between the actors and use
case.
24 | P a g e
Figure 2.2 use case diagram
2.6.1.2 Description of use case model

In this part the use case describe in detail. The detail information contains the use case name,
participating actors on the use case, entry condition contains the requirement from the actor
to participate on the use case process, flow of event to achieve the required goal on the use
case process, alternative flow of event that represent the other way to achieve the goal and
exit condition.
Use case ID UC-1

Use case name Register user.
Objective To register new users on the database.
Participating Actor Supplier and buyer
Entry condition  user open website
Flow of events 1. User click on the buyer registration button.
2. The system displays a form for the buyer to fill. The form
contains: -name, type of buyer, TIN No/Other identification,
city, country, email, telephone, fax, password, verify
25 | P a g e
password, business license number, region, sub city, town,

wereda/kebele, house number, capital, business type.
3. The user fills the form.
4. The user clicks the register button.
5. The system sends a confirmation code to the buyer’s email.
6. User goes to his/her email address and confirms it.
7. After the email confirmation is done the account of the buyer
become active.
8. The system stores the information on the data base.
Exit condition The user gets user name and password.
Use case ID UC-2

Use case name Register Agent
Objective To create account for worker of agency.
Participating Actor Admin
Entry condition  Amin login to the system
Flow of events 1. Admin clicks on create account for worker of agency.
2. The system displays a form that contains name,
department, position, office number, telephone, username
and password.
3. The admin fills the form.
4. The admin clicks on the save button.
Exit condition The system stores information on database.
Use case ID UC-3

Use case name Register Public Body
Objective To create account for the public body.
26 | P a g e
Entry condition  Admin login to the system

Flow of events 1. Admin clicks on create account for public body.
2. The system displays a form containing: - name, username
and password.
3. Admin fills the form.
4. Admin clicks on the save button.
Exit condition The system stores information on database.
Use case ID UC-4

Use case name Login
Objective To log into the system with the appropriate user ID and password
in order to undertake the tasks assigned to that user.
Participating Actor Admin, Workers of agency, public body, supplier and buyer
Entry condition  The user opens the website.
Flow of events 1. The system displays a form containing email and user
name.
3. The click on the login button.
4. The system checks the user name and password on
database.
Exit condition The user logins to the system.
Use case ID UC-5

Use case name Update Account
Objective To modify existing users information on the system.
Participating Actor Supplier, buyer, public body and Workers of agency
Entry condition  The user login to the system.
Flow of events 1. The users click on the edit profile.
27 | P a g e
2. The system displays the form to update profile. The users

can update the information that exits on the system
except the agency workers cannot modify their name,
position, and department. This information can change by
the information technology unit.
4. The user click on the save button.
5. The system over write the new information on the old
information on the database.
Exit condition The users get notification.
Use case ID UC-6

Use case name Create Message
Objective To create message and send it for other users.
Entry condition  The user login to system.
Flow of events 1. The user click on the message button.
2. The system displays list of users.
3. The user selects the receiver of the message from the list.
4. The system displays a form containing: - message type,
message title, message body and a button named attach
for attaching a file.
6. The user clicks on the send button.
7. The system saves the message, receiver, sender, time and
date on the data base.
Exit condition  The user gets the notification about the message and the
receiver gets the message in his account.
28 | P a g e
Use case ID UC-7

Use case name Add user to black list
Objective To prevent the supplier or buyer on participation on the bid
process for a limited amount of time.
Participating Actor Workers of agency
Entry condition  The department worker login to the system
Flow of events 1. The user searches the account of the supplier or buyer of
the account.
2. The system displays a list of supplier or buyer meeting
the search criteria.
3. The Workers of agency clicks on the name of the
supplier or the buyer.
4. The worker of the agency click on block button.
5. The system opens a form that contains: reason for
blocking the user, and the duration of the block.
6. The Workers of agency fills the form.
7. The worker of agency clicks on the save button.
8. The system saves the updated information.
9. The worker of the agency get notification
Alternative flows
Exit condition  The supplier or the buyer added to the black list and the
supplier or the buyer gets notification.
Use case ID UC-8

Use case name Create Post
Objective It create any type of post for agent.
Participating Actor Workers of agency
29 | P a g e

Flow of events 1. The system displays the home page which contains a
form for posting announcements.
2. The worker of agency fill the form by suppling the title
the post, description of the post, the privacy of the post,
attaches an external file if needed.
3. The worker of agency clicks on the post button.
4. The worker of agency gets notification.
5. The system saves the post and owner on the database.
Exit condition  The authorized users of the system get the news on their
timeline.
Use case ID UC-9

Use case name Create Comment
Objective To handle the comment posted by the user.
 The new post appears on time line of the user.
Flow of events 1. The user clicks on the post they want to comment.
2. The system displays a form that contains a like button, a
dislike button, a comment field and a reply button.
3. The user clicks the like or dislike button based on how
they feel about the post.
4. The user writes comment on the comment field.
5. The user clicks the comment button.
6. The system saves the comment and owner of comment,
like and dislike.
Alternative flows
Exit condition  The owner of the post gets the notification.
30 | P a g e
Use case ID UC-10

Use case name Search
Objective To search any type of data on system database.
Participating Actor Supplier, buyer, public body and department of the agency
Entry condition  Users login to the system
Flow of events 1. The system opens the home page which contains a form
that contains a search field.
2. The user fills the search constraint on the search text
field.
3. The user clicks on the search button.
4. The system displays a list of results that meet the search
constraint.
5. The user click on the result to see the detail.
Exit condition  The user gets the search result.
Use case ID UC-11

Use case name Create Bid
Objective This use case handles the process of bid creation.
Participating Workers of agency.
Actor
Entry condition  Workers of agency login to the system.
Flow of events 1. Workers of agency click on create bid button on the home
page.
2. The system displays the bid process form.
3. A worker of agency selects fills the form. The form
contain: - the type of the bid process, the bid description,
criteria of the supplier or the buyer that can participate on
the bid process. Type of bids is: - open tender, limited
31 | P a g e
tender, two stage tendering, request for proposal, request

for quotation and single source procurement.
4. Workers of agency click on the create button.
5. The worker of agency gets notification.
6. The system stores the bid process on the data base.
Alternative flows
Exit condition  Bid process appears on the home page of the supplier or the
buyer account.
Use case ID UC-12

Use case name Apply on Bid.
Use case description To register of supplier and buyer that applies on the bid process.
Participating Actor Supplier, buyer.
Entry condition  Supplier or buyer login to the system
Flow of events 1. The supplier or buyer clicks on the bid process that appear
on their notification or on his home page.
2. The system displays the description of bid.
3. The supplier or buyer click on the apply button.
4. The system displays the application form.
5. The supplier or buyer attach the bid document on form or
write on text filed.
6. The supplier or buyer click on the apply button.
7. The system gives notification to the supplier or buyer.
8. The system store bid document on the data base and
update the list of applier on the data base.
Exit condition  The worker of the agency gets notification.
Use case ID UC-13
32 | P a g e
Use case name Approve bid request.

Use case description Handle the approval of bid process request that comes from the
buyer and supplier.
Participating Actor Supplier, buyer, worker of agency.
Entry condition  Supplier or buyer goes to the office of the agency.
Flow of events 1. The supplier or buyer buy the bid document from the
agency and fulfill other criteria of the bid process.
2. The worker of agency log in to the system.
3. The system displays the search form.
4. The agency worker fills the search form with the name
of bid process.
5. The agency worker clicks on the search button.
6. The system displays the result of search.
7. The worker of the agency click see applier list.
8. The system displays the list of applier.
9. The worker of the agency searches the supplier or
buyer name on the list.
10. Worker of agency clicks on the approve button that
appear in front of the supplier or buyer name.
11. The system updates the proved list on the database.
Exit condition  The supplier or buyer gets the notification.
Use case ID UC-14

Use case name Delete Account
Objective Admin delete users account.
Entry condition  Admin login to the system.
33 | P a g e
Flow of events 1. The system opens the home page which contains a
form that contains a search field.
2. Admin fills the search constraint on the search text
field.
3. Admin clicks on the search button.
4. The system displays a list of results that meet the
search constraint.
5. Admin clicks on the result.
6. The system displays the profile of result.
7. Admin clicks on delete account button.
8. The system delete the information of the profile or
other document that store by the deleted account.
Exit condition  Admin units get notification.
Use case ID UC-15

Use case name Recover password.
Objective To recover the forgotten or lost password.
Participating Actor Admin, user
Flow of events 1. The system opens the home page which contains a form
that contains a search field.
2. Admin fills the search constraint on the search text field.
3. Admin clicks on the search button.
4. The system displays a list of results that meet the search
constraint.
5. Admin clicks on the result.
6. The system displays the profile of result.
7. Admin click on change password button.
34 | P a g e
8. The system displays the form.

9. Admin enter the new password and confirm password on
the form.
10. Admin click on the change button.
11. The system stores the over write the new password on the
old password on the database.
Exit condition  Admin gets the notification.
 The user gets new password
Use case ID UC-16

Use case name View log
Objective To view changes made on the system.
Flow of events 1. Admin clicks on see log button.
2. The system displays the system log.
3. Admin clicks on the more buttons to see more.
4. The system displays the total information about the
system log.
5. Admin can filter the system log by enter the date.
Exit condition The system displays the filtered system log.
2.6.3 Object Model

Object model represents the structure of the system in terms of objects, attributes, operations
and association through the use of class diagrams.
2.6.3.1 Data Dictionary

Supplier and Buyer
Attribute Data type Length Description

Name STRING 50 Name of supplier is holds the name of
35 | P a g e
supplier who registered

type STRING 255 Type of supplier is holds the category of
the supplier that it work.
TIN No/Other INT 20 TIN number is the unique identification
identification number of the supplier in country.
City CHAR 30 Is the name of city that supplier head
office exists
country CHAR 20 The supplier nation.
Email VARCHAR 255 Is a supplier email address
Telephone INT 15 Is a supplier telephone number
Fax INT 20 Is a supplier fax number
Password VARCHAR 15 The password of the account.
business license INT 10 License number of supplier.
number
Region CHAR 20 A region of supplier
wereda/kebele VARCHAR 20 Supplier fulfill woreda or kebele name
house number INT 10 A house number of supplier
capital CHAR 10 The amount of birr that registered on
business license of supplier.
Business type CHAR 20 The type of business type that registered
on his business license.
Photo STRING 255 The logo of the supplier or other photo
that describe the supplier
Black List BOOLEAN 1 The status of the supplier.
Table 2.2 supplier and buyer data dictionary
Public body

Name CHAR 20 The name of the public body.
36 | P a g e
User name CHAR 20 The user name of public body used to login
in his account.
Password VARCHAR 15 The password of the public body account
Fax INT 20 The fax of public body
Telephone INT 15 The telephone of public body manager.
Region CHAR 20 The region of the public body head office
exists.
city CHAR 30 The city of public body head office exists.
wereda/kebele VARCHAR 20 The public body head office location in
terms of wereda and kebele.
Photo STRING 255 The logo of the public body.
Table 2.3 data dictionary of public body
Agency Worker

Name CHAR 20 The name of agency worker
Department CHAR 30 The department that the worker work on the
agency.
Position STRING 255 The position of the worker on the department.
Office number INT 10 The office number of the worker.
Telephone INT 15 The telephone number of the worker office.
Username VARCHAR 20 The user name of worker account.
Password VARCHAR 15 Password of the worker agency.
Photo STRING 255 The photo of worker.
Table 2.4 data dictionary of agency worker
Message

Message ID INT The number used to identify the message
Message title CHAR 30 The title of message.
37 | P a g e
Message body STRING The description or detail of the message

Sender VARCHAR 255 The user name of message sender.
Receiver VARCHAR 255 The user name of message receiver.
Message Type CHAR 20 The type of message.
Date and time DATE The time and date that the message sends to
receiver.
External file STRING 255 The external file that attached to the message
by the sender.
Table 2.5 data dictionary of message
Bid document

Bid id Int A unique number used to identify the bid
process.
Owner VARCHAR 20 The user name of the creator of the bid
document.
Title STRING The title of the bid process.
Body STRING The description of the bid process
Type CHAR 20 The type of bid process.
Participant CHAR 20 The criterial that the supplier or buyer can
apply on the bid process.
Applier username CHAR 20 The user name of applier on the bid
process.
Number of apply INT 10 The total number of applier on the bid
process.
Applier bid STRING 255 The external document that attached by
Document the applier.
Applier Approved BOL 1 The status of applier approved its request
or not.
38 | P a g e
Date and time Date Contains the date and time of the
document created.
Table 2.6 data dictionary of bid document
Post

Post id Integer The unique id of the post.
post Owner VARCHAR 255 The user name of the post creator.
post Title STRING 255 The title of the post.
post Body STRING The description of post.
Number of comment INT 10 The number of comment that give on
the post.
Comment owner VARCHAR 255 The user name of commented account.
Comment body STRING 255 The description of the comment.
Number of like INT 10 The number of like on post gives by
other users.
Owner of like VARCHAR 255 The user name of liker on post.
Data and time Date Contains the date and time that the
post created, comment and like.
Photo STRING 255 The photo that attached on the
comment and post.
Table 2.7 data dictionary of post
System Log File

Log Id Int The unique number used to identify log.
User name VARCHAR 20 The account name.
Action STRING 255 The action that done by the account.
Date and time DATE The date and time that the account do the
action.
39 | P a g e
Table 2.8 data dictionary of system log file
2.6.3.2 Class Modeling

Class diagrams are used to describe the structure of the system. Classes are abstractions that
specify the common structure and behavior of a set of objects. They are used to describe the
structure of the system. Class diagrams help to analyze the structure of the system. They are
drawn by identifying objects in the system. Once use cases have been consulted, participating
objects for each use case are identified. The participating objects are identified by examining
each use cases and by identifying candidate objects. Also I have used the natural language
analysis which is an intuitive set of heuristics for identifying objects, attributes, and
associations from a system specification.
Objects are instances of classes that are created, modified and destroyed during the execution
of the system. The class diagram of system is presented as follows.
Figure 2.3 class diagram
2.6.4 Dynamic Modeling
The dynamic model, represented with Sequence Diagrams, State Chart diagrams, and
Activity Diagram. Activity Diagrams describes the internal behavior of the system. Sequence
Diagrams describe behavior as a sequence of messages exchanged among a set of objects,
whereas State Chart diagrams describe behavior in terms of states of an individual object and
the possible transitions between states.
2.6.4.1 Sequence Diagram

Sequence Diagrams describe patterns of communication among a set of interacting objects.
An object interacts with another object by sending messages. The reception of a message by
an object triggers the execution of an operation, which in turn may send messages to other
40 | P a g e
objects. The main sequence diagrams identified in our project are presented as follows. The
analysis object model consists of entity, boundary, and control objects Entity
objects represent the persistent information tracked by the system. Boundary objects
represent the interactions between the actors and the system. Control objects represent the
tasks that are performed by the user and supported by the system. Control objects are
responsible for coordinating Boundary and Entity objects. They are responsible for collecting
information from the boundary objects and dispatching it to entity objects. Control objects
usually do not have a concrete counterpart in the real world.
Figure 2.4 Register user
41 | P a g e
Figure 2.5 Register Agent
Figure 2.6 Register Public Body
42 | P a g e
Figure 2.7 Login
Figure 2.8 Update account
43 | P a g e
Figure 2.9 Create Message
Figure 2.10 Add user to black list
44 | P a g e
Figure 2.11 Create Post
Figure 2.12 Create Comment
45 | P a g e
Figure 2.13 Search
Figure 2.14 Create bid
46 | P a g e
Figure 2.15 Apply on bid.
Figure 2.16 Approve bid request
47 | P a g e
Figure 2.17 Delete account
48 | P a g e
Figure 2.17 Password Recovery by admin
49 | P a g e
Figure 2.18 Password Recovery by user
50 | P a g e
Figure 2.19 system log
2.6.4.2 State chart diagram

State Chart diagrams describe behavior in terms of states of an individual object and the
possible transitions between states. The following diagrams show the different states of
Pensioner. To ensure clarity and ease understandability two State Chart Diagrams are
presented (as State Chart Diagram –Generic and State Chart Diagram of
Pensioner Object - with respect to Monthly Payment).
51 | P a g e
Figure 2.20 State chart of supplier and buyer
Figure 2.21 State chart of public body and worker of agency
2.6.4.2 User Interface

User interface is a mechanism by which the user interacts with the system either for query,
input or update of information. The user interfaces and functions that will be available to the
user depend on the “User Designation” of the user and determined upon successful user
logon of the user. The following are some of screen mockups projected to be implemented.
52 | P a g e
Figure 2.22 Registration form screen mock-up
53 | P a g e
Figure 2.23 Profile mock-up
Figure 2.24 Notification screen mock-up
54 | P a g e
Figure 2.25 Login form screen mock-up
55 | P a g e
Figure 2.26 Bid document screen mock-up
56 | P a g e
Figure 2.27 Worker of age
57 | P a g e
CHAPTER THREE
SYSTEM DESING
3.1 INTRODUCTION
System design is the process of defining the elements of a system such as the architecture,
modules and components, the different interfaces of those components and the data that goes
through that system to satisfy specific needs and requirements of the organization.
The system design document used the requirement analysis document and its output is used
in the implementation time. Under the system design we try to describe the architecture of
the current system and we will describe the system we proposed to replace the current
system. We have decomposed the system in terms of subsystems; we described the software
hardware mapping of the system, the data storage we implement, the access control and
security type we used.
3.2 CURRENT SOFTWARE ARCHITECTURE

Currently procurement and property management agency used the paper based except the
registration of supplier. In the current system of the agency is the supplier can register online
on the website of the agency. But other works of the agency is paper based and the process
wants high number of workers.
3.3 PROPOSED SOFTWARE ARCHITECTURE

The new system is will be a web based client server system that interacts with its
users (clients) by communicating with a server. We have chosen this architecture
because it gives us the advantages of.
 It is easier to install and maintain. In addition to this the agency has a well- structured
up and running server so we will not have a difficulty during deployment.
62 | P a g e
 Proper management: - Since resource and files are centralized managing and
administering resources is easy.
 Accessibility: - any user can access the system anywhere and at any time in any
devices that supports the internet access.
 Update: - the user interface of web-based applications is easier to customize. This

makes it easier to update the look and feel. And in addition to this customize the
presentation of information to different user groups is simple. Therefore, there is no
longer any need for everyone to settle for using exactly the same interface at all times.
Instead, you can find the perfect look for each situation and user.
 Security: - Web-based applications are typically deployed on dedicated servers,
which are monitored and maintained by experienced server administrators. This
means that security is tighter and any potential breaches should be noticed far more
quickly.
3.3.1 Overview
This is the brief overview of our proposed system. As the development progresses and the
functionalities are identified the system must be classified and decomposed carefully because
once it is past this level it becomes difficult to understand and implement the system for
developers. So we decomposed the system in into detail subsystems, described the hardware
and software mapping of the system, the persistent data management, access control and
security, subsystem services and detailed class diagram.
63 | P a g e
SYSTEM DESIGN
3.3.2 Subsystem Decomposition
64 | P a g e
Figure 3.1 subsystem decomposition
65 | P a g e
SYSTEM DESIGN
3.3.3 Hardware/Software Mapping
Figure 3.2 hardware/software mapping
66 | P a g e
3.3.4 Persistent Data Management

Persistent data management describes and models how the data we process on the
system is going to be stored on the database in detail including the entities, attributes
with their respective types.
We have chosen relational database management system to store data and information
we need. We selected this model because of the reasons of
- It is simple to structure and we are also familiar with the model so it will be
easy to implement.
- It is easy to get data since relational model doesn’t require navigating a rigid
pathway through a tree or hierarchy. We just write a query to retrieve the specific
data and it gets it right away.
- Easy to add tables and requirements emerging in the future. So it is flexible.
The following objects are identified to be stored persistently and the respective tables will be
maintained with the database
1. Supplier and buyer: - this table contains the information about supplier and buyers.
2. Agency worker: - this table is responsible to contain the information of the agency
workers.
3. Public body: - in this table the information of the public body will be stored.
4. File table: - this table contains the files that are uploading by the user to the system.
5. Bid document: - this table is responsible to store the information of bid document.
6. Applier list: - this table is responsible to store the applier list that applies on the bid
process.
7. System log list: - this table contains the system log information.
8. Post: - this table used to store the post.
9. Comment table: - this table is responsible to store comments that are given by the
user on a post.
10. Like list: - this table is responsible to store list of users that like the post.
67 | P a g e
SYSTEM DESIGN
11. Message: - this table used to message.
ER Diagram
Figure 3.3 ER diagram
Relationships and cardinality
Under this section we have listed the tables and their cardinality
Normalization
1. First normal: a table is said to be in a first normal form if it only has an atomic value
meaning that it cannot have multiple values for a single attribute.
68 | P a g e
2. Second normal: A relation is in 2nd normal form if it is in 1st normal form and no non-
prime attributes is dependent on any proper subset of any candidate key of a relation.
A non-prime attribute is an attribute that is not a subset of a candidate key.
3. Third normal: First of all a relation must be in a second normal form and all attributes
in a table must be identified by the candidate key.
After applying this rule in our entity we get the following tables.
Supplier
buyer
and
licenses no
Business
Wereda/
kebele
House
Constraints:
1. Primary key: email

2. Not null: name, type, city, password, region, house number, capital.
Supplier and buyer tin no
Email Tin no
Constraints:
1. Primary key: tin no

2. Foreign key: email.
Supplier and buyer business

licensees no
Email Business licensees no
69 | P a g e
SYSTEM DESIGN
Constraints:
1. Primary key: Business licensees no

2. Foreign key: email.
Agency worker table
Agency
worker
Name Departmen Position Office Telephone Username Password Photo

t No
Constraints:
1. Primary key: user name

2. Not null: name, department, position, office no and password.
Public body table
Public body
Name User Pass Fax Telepho Regi City sub wereda/ Photo
name word ne on city kebele
Constraints:

2. Not null: name, telephone, region, city and password.
File table
File table
File id Name Path file
Constraints:
70 | P a g e
1. Primary key: file id

2. Not null: name, path, file
Bid document table
Bid
Document
Bid Id Owner Title Body Type Participant File id Date and time
Constraints:
1. Primary key: bid id

2. Not null: name, path, file
3. Foreign key :owner, file id
Applier list table
Applier list
Bid id User name Apply approved File id
Constraints:

2. Not null: apply approved
3. Foreign key: bid id and file id.
System log list table
System log
file
71 | P a g e
SYSTEM DESIGN
Log Id User name Action Date and time
Constraints:
1. Primary key: log id

2. Not null: action and date time
3. Foreign key: user name.
Post table
Post
Post id Owner Title Body No of comment No of like Date and time Photo File id
Constraints:
1. Primary key: post id

2. Not null: title
3. Foreign key :owner and file id
Comment table
Comment
table
Comment Post id Comment Comment Date and File id

id owner body time
Constraints:
1. Primary key: comment id

2. Not null: comment body and date and time.
3. Foreign key : comment owner and file id
Like list table
72 | P a g e
Like list
post id Owner of like Date and time
Constraints:
1. Primary key: owner of like

2. Not null: date and time
3. Foreign key: post id and owner of like.
Message table:
Message
Message Id Message title Message body Message Type File id Date and time
Constraints:
1. Primary key: message id

2. Not null: message title, message body and date and time.
3. Foreign key :file id
Message sender
Message sender
Message id sender
Constraints:
1. Primary key: message id and sender

2. Foreign key :message id and sender
Message Receiver
Message Receiver
73 | P a g e
SYSTEM DESIGN
Message id Receiver
Constraints:
1. Primary key: message id and receiver

2. Foreign key :message id and receiver
3.3.5. Access Control and Security

Subsystem Classes Operations Actors
Worker Supplie Buye Admi Publi

of r r n c
Agenc Body
y
User Supplier register()  

management
And passwordRecovery(  
)
Buyer
search()  
Managemen
t view()  
Public body create() 

and worker
search() 
of agency
management view() 
Account login()     
Handler logout()     
update()     
74 | P a g e
deleteAccount()   
blockAccount()  
unblockAccount()  
recoverPassword()    
System writeReport()
Log readReport() 
Managemen search() 
t
view() 
Post PostHandler create()  

Managemen
t Subsystem update()  
delete()  
read()  
privacy()  
Worker Supplier Buyer Admi Public

of n Body
Agency
Post Like like()     

Management
75 | P a g e
SYSTEM DESIGN
Subsystem Handler dislike()     
Comment comment()     
Handler
update()     
delete()     
reply()     
FileHandler upload()     
download()     
delete()     
Message Message send()     

Management
Subsystem Handler read()     
delete()     
reply     
delete()     
Bid BidHandler create() 

Management
subsystem update() 
delete() 
privacy() 
invite()   
76 | P a g e
Apply apply()  
Handler approved() 
Worker Supplier Buyer Admi Public

of n Body
Agency
Data Document create()     

Management Handler
Subsystem edit()     
delete()     
search()     
delete()     
Table 3.1 Access control
77 | P a g e
SYSTEM DESIGN
3.3.6 Subsystem Services

Subsystem Classes Operations Description
User management Supplier register() Used to register the new supplier and buyers
And passwordRecover Used to get recover password

y()
Buyer
search() Used to search other that fulfill the search criteria
Management
view() Used to the personal profile or other profiles on
the system.
Account login() Used to login in to the system.
Handler logout() Used to leave the system.
update() To change the account profile.
deleteAccount() Used to delete the account.
blockAccount() Used to block the account.
unblockAccount() Used to unblock the account.
recoverPassword() Used to recover the forgotten password in the

information technology unit.
Public body create() Used to register the public body or the worker of
and worker the agency.
management
search() Used to search the account.
view() Used to view the detail of the account
System writeReport() Used to write any activity that done by one

account to the system log.
Log
readReport() Used to read the written report from the system
78 | P a g e
Management log.
search() Used to search anything in the system log that

fulfills the search criteria.
view() Used to see the detail of the report.
Post Management PostHandler create() Used to create post.

Subsystem update() Used to modify the post updated before.
delete() Used to delete the post.
read() Used to see the detail of the post
privacy() Used to set the privacy of the post.
LikeHandler like() Used to like the post.
dislike() Use to dislike the post.
Comment comment() Used to give a comment on the post.
Handler update() Used to update the comment written before.
delete() Used to delete the comment.
reply() Used to reply on comment.
FileHandler upload() Used to attach or upload file on the post or on the
comment time.
download() Used to download the upload file from the post or
comment part.
delete() Used to delete the upload file from the post or the
comment.
Message Message send() Used to send message.
Management Handler read() Used to see the detail of the message.
Subsystem
delete() Used to delete received or send message from account.
79 | P a g e
SYSTEM DESIGN
reply Used to give answer to message.
FileHandler upload() Used to upload file to a message.

download() Used to download file from message.
delete() Used to delete file from the message history.
80 | P a g e
Bid Management BidHandler create() Used to create the bid process.

update() Used to update the created bid.
delete() Used to delete the created bid form system.
privacy() Used to set the privacy of the bid.
invite() Used to invite the supplier or buyers to the bid process.
Apply apply() Used to apply on bid process.
Handler approved() Used to approve the request on bid process to participate.
FileHandler upload() Used to upload file to apply the bid process. Or to create
a bid process.
download() Used to download the attached file from bid process
delete() Used to delete the upload file form the bid process.
Data Document create() Used to create a new document.

Management Handler
edit() Used to modify the document that are saved before.
Subsystem
delete() Used to delete the document.
search() Used to search the document by fulfill the search criteria.
FileHandler upload() Used to upload file and attaché to document.

download() Used to download the file on the document.
delete() Used to delete to delete the file on the document.
Table 3.2 subsystem service
81 | P a g e
SYSTEM DESIGN
3.4 Detailed Class Diagram

In this section we will describe the detail of each class.
82 | P a g e
83 | P a g e
SYSTEM DESIGN
84 | P a g e
Figure 3.4 detail class diagram
85 | P a g e
SYSTEM DESIGN
3.5 packages
To reduce the complexity of application domain we identified the small part called class
during analysis. Now we organize this class into package.
3.5.1 Description of Package

The packages of our system are presented as the following:
User management package

User management package contains classes that are responsible for user account management
and control the activity of each user on the system.
Bid management package

The bid management package contains different class that responsible for the bid process.
Post management package

The post management package contains different classes which are responsible for the post
management.
Interface package
The interface package contains different classes which control the loading and unloading of
the interfaces with which the users interface different parts of the system.
Message management package

The message management package contains different class which control the sending and
receiving process of message between to user.
86 | P a g e
Figure 3.5 Package diagram
87 | P a g e
SYSTEM DESIGN
3.5.2 Dependency of Package
Figure 3.6 package dependency
88 | P a g e
CHAPTER FIVE
IMPLEMENTATION
5.1 Introduction
In this section of the document sample codes of some major functionality (classes) and test
cases are documented.
5.2 Testing Plan

In this section of the document sample codes of some major functionality (classes) and test
cases are documented. The purpose of Test case is to describe the scope, approach, resources,
and schedule of the testing activities for the PPA System. The goal of the Test Case is to
identify the items being tested, the features to be tested, the testing tasks to be performed, the
personnel responsible for each task, and the risks associated with the test case.
5.2.1 Features to be tested

The following features are going to be tested:
 Can system allow login to users

 Can system register the supplier and buyers
 Can system allow supplier or buyer recover their password
 Can system allow message exchange process
 Can system allow to create post
 Can system allow to crate bid
 Can system allow to admin to create account for publicbody and worker of the agency
 Can system allow to admin to edit the account of public body and worker of the
agency
 Can system allow to like and give comment on post
 Can system allow to apply bid the supplier or buyer
 Can system allow to worker of agency to accept the bid apply request
 Can system allow the user to modify he’s profile
 Can system allow to modify the post and bid
 Can system allow to see and delete admin to the system log
 Can system allow to admin to see and administrate any user account
 Can system allow to admin to block supplier or buyer account
89 | P a g e
SYSTEM DESIGN
90 | P a g e
91 | P a g e
SYSTEM DESIGN

 Can system allow to publicbody or supplier or buyer to send reports.
5.2.2 Features not to be tested

 If the system goes down can it come up with in 10 minutes? This feature cannot be
tested as we cannot simulate an actual server crash and try and recover it.
 How does the system performance vary during high loads? This non-functional
feature of performance under higher loads could not be tested due to lack of time and
resources to generate large volumes of documents
 Does the system perform optimally under low/normal load? It is hard to determine in
short time as to what should equate to optimal performance. Hence this feature cannot
be tested. Also it is hard to say what low and normal load is.
 Is the system portable across different platforms? This could be not tested, as the
system could not be deployed across different platforms for testing due to lack of
time.
5.2.3 Pass Fail Criteria
5.2.3.1 System Testing

The test process will be complete (Pass) if supplier or buyer register by fulfill all requirement
and it is stored in the database. This is what we call as the pass criteria. A problem in any
place in the entire process is termed as “System failure” (Fail criteria). However, a successful
test is termed as a test which breaks the system. In other words, a test is successful if it can
make the system fail.
5.2.3.2 Integration testing

When testing the integration of various sub-parts the services offered by the sub-systems are
tested. These services are invocated and if the service results in completion of expected tasks
then it is the success. If the sub-system fails to perform a task which is intended to do then it
is a failure. The whole concept of successful testing described in the previous section is
applicable here too.
5.2.3.3 Unit testing

In unit testing the pass and fail criteria for each sub-system depends on the functionality of
those sub-system. If pre conditions and post conditions are satisfied then it is the (Black box)
success otherwise failure. White box testing goes more into the execution paths of the
program.
92 | P a g e
5.2.4 Approach
5.2.4.1 Testing Levels

The testing for the PPA system project will consist of Unit, System/Integration (combined),
Acceptance test levels (Out of scope) and Installation test (Out of scope). It is expected that
the entire test team will be available for system/integration testing. However, with such a
short time line established; most of the Unit testing will be done by the development team
with the test team’s knowledge. The only system test that will be performed is
Functional/Performance test.
5.2.4.2 System/Integration Testing

This will be performed by the test team and with the knowledge from the individual
developers who were also involved with developing the system is required. No specific test
tools are available for this project. Programs will enter into System/Integration test after all
critical defects have been corrected (In the unit testing). A program may have errors only in
the interfacing level and should not have any errors in the internal functionality.
5.2.4.3 Unit Testing

It will be done by the developer and will be approved by the development team lead. Proof of
unit testing (test case list, sample output, data printouts, and defect information) is provided
by the development team. This must be provided by the programmers to the development
team lead before unit testing will be accepted and passed on to the testing team. All unit test
information will also be provided to the test team.
5.2.4.4 Integration Testing Strategy

Out of three Integration testing strategy we have opted the bottom-up Integration testing
strategy for the following purposes,
 The system we developed is an object-oriented system and has been decomposed

accordingly.
 The PPA system also has to interact to the real world environment variables like
Supplier, buyer, worker of agency, etc. it’s a real time system. The system operates in
real time and time is crucial.
93 | P a g e
SYSTEM DESIGN
 Since we have planned to do the system testing along with the integration testing,
bottom up will help us move slowly from sub-parts (Bottom) to the entire system
(Up).
 Since bottom-up testing is more intuitive and natural we follow it.
 Bottom-up testing does not need any additional stuff like stubs.
 It leads to good performance of testing and it is very simple to perform.
5.2 Testing Procedure

Tested Unit Operation Test Outcome
Tested
Create
Bid All the operation functions are Expected
Update
management Delete and successful
Apply
Accept
Create
Post All the operation functions are Expected
Update
Like
comment
Create
Message All the operation functions are Expected
Update
Create
Report All the operation functions are Expected
Update
Create
Account All the operation functions are Expected
Update
94 | P a g e
Proper functionality of each unit of the system is tested through unit testing. The
functionality of the entire system is done with integration testing. The following table
summarizes test results
Table 5.1 test procedure table
Moreover query operations of all the units are tested and function successfully.
5.3 Sample Code

Post Management
Post class
namespace PPA.Models
{
using System;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations.Schema;
using System.Web;
public partial class post

{
[System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Usage",
"CA2214:DoNotCallOverridableMethodsInConstructors")]
public post()
{
this.commments = new HashSet<commment>();
this.likeLists = new HashSet<likeList>();
}
public int id { get; set; }

public string postOwner { get; set; }
public string title { get; set; }
public string body { get; set; }
public Nullable<int> noOfComment { get; set; }
public Nullable<int> noOfLike { get; set; }
public System.DateTime dateAndTime { get; set; }
public string photo { get; set; }
public Nullable<int> fileId { get; set; }
public virtual agent agent { get; set; }
95 | P a g e
SYSTEM DESIGN
"CA2227:CollectionPropertiesShouldBeReadOnly")]
public virtual ICollection<commment> commments { get; set; }
public virtual fileTable fileTable { get; set; }
public virtual ICollection<likeList> likeLists { get; set; }
[NotMapped]
public HttpPostedFileBase ImageUpload { get; set; }
[NotMapped]
public HttpPostedFileBase FileUpload { get; set; }
[NotMapped]
public string like { get; set; }
}
}
[HttpGet]
public ActionResult OpenPost(int id)
{
post openPost = ppaDatabase.posts.Where(x => x.id == id).FirstOrDefault();
return View("EditePost",openPost);
}
[HttpPost]
public ActionResult EditePost(post newPost)
{
bool state = false;
if (ModelState.IsValid)
{
ppaDatabase.Entry(newPost).State = EntityState.Modified;
ppaDatabase.SaveChanges();
state = true;
systemLog newLog = new systemLog();
newLog.userName = user.userName;
newLog.actionDone = user.userName + "Edite a post with title " +
newPost.title;
newLog.dateAndTime = DateTime.Now;
ppaDatabase.systemLogs.Add(newLog);
}
if(state == true)
{
AllPost();
//RedirectToAction("PostDetail", newPost);
//return View("PostDetail",newPost);
return Json(new { success = true, html = PostDetail(newPost), message
= "Submitted Successfully" }, JsonRequestBehavior.AllowGet);
//return Json(new { success = state,, message = "Success fully Edited"
}, JsonRequestBehavior.AllowGet);
}
else
{
return Json(new { success = state, message = "Sorry Error Occured" },
JsonRequestBehavior.AllowGet);
}
}
96 | P a g e
[HttpPost]
public ActionResult CreateOrEditPost(post newPost)
{
try
{
newPost.postOwner = user.userName;
newPost.dateAndTime = DateTime.Now.Date;
newPost.noOfComment = 0;
newPost.noOfLike = 0;
newPost = ppaDatabase.posts.Add(newPost);
newLog.actionDone = user.userName + "create a post with title " +
newPost.title;
}
catch (Exception ex)
{
return Json(new { success = false, message = ex.Message },
}
try
{
if (newPost.ImageUpload.ContentLength > 0)
{
string fileName =
Path.GetFileNameWithoutExtension(newPost.ImageUpload.FileName);
string extension =
Path.GetExtension(newPost.ImageUpload.FileName);
fileName = "post" + newPost.id + extension;
newPost.photo = "~/Photo/" + fileName;
newPost.ImageUpload.SaveAs(Path.Combine(Server.MapPath("~/Photo/"), fileName));
}
}
catch(Exception ex)
{
Console.Write(ex);
}
try
{
if (newPost.FileUpload.ContentLength > 0)
{
fileTable postFile = new fileTable();
string fileName =
Path.GetFileNameWithoutExtension(newPost.FileUpload.FileName);
string extension = Path.GetExtension(newPost.FileUpload.FileName);
string path = "postFile" + newPost.id + extension;
97 | P a g e
SYSTEM DESIGN
postFile.filePath = "~/File/" + path;

postFile.name = fileName;
newPost.FileUpload.SaveAs(Path.Combine(Server.MapPath("~/File/"),
path));
postFile = ppaDatabase.fileTables.Add(postFile);
newPost.fileId = postFile.id;
}
}
catch(Exception ex)
{
Console.Write(ex);
}
return Json(new { success = true, message = "Success fully Created" },
}
public ActionResult Post(int? page)
{
var model = AllPost();

var pageNumber = page ?? 1;
var onePageOfBid = model.ToPagedList(pageNumber, 6);
return View(onePageOfBid);
}
[HttpPost]
[ActionName("DeletePost")]
public ActionResult DeleteByPostId(int id)
{
post postDelete = ppaDatabase.posts.Where(x => x.id ==
id).FirstOrDefault();
if (postDelete.fileId != null)
{
ppaDatabase.fileTables.Remove(ppaDatabase.fileTables.Where(file =>
file.id == postDelete.fileId).FirstOrDefault());
}
if (postDelete.noOfComment != 0)
{
List<commment> commentOfpost = ppaDatabase.commments.Where(x =>
x.postId == postDelete.id).ToList();
foreach (commment comments in commentOfpost)
{
if (comments.fileId != null)
{
ppaDatabase.fileTables.Remove(ppaDatabase.fileTables.Where(file => file.id ==

comments.fileId).FirstOrDefault());
}
ppaDatabase.commments.Remove(comments);
}
}
if (postDelete.noOfLike != 0)
{
98 | P a g e
List<likeList> likeOfpost = ppaDatabase.likeLists.Where(x => x.postId
== postDelete.id).ToList();
foreach (likeList like in likeOfpost)
{
ppaDatabase.likeLists.Remove(like);
}
}
string temp = postDelete.id.ToString();
List<notificationTable> postNotificaiton =
ppaDatabase.notificationTables.Where(x => x.fileNotification ==
temp).ToList<notificationTable>();
foreach (notificationTable tempNotification in postNotificaiton)
{
ppaDatabase.notificationTables.Remove(tempNotification);
}

newLog.actionDone = user.userName + "Delete a post with title " +
postDelete.title;
ppaDatabase.posts.Remove(postDelete);
return View("Index");
}
Bid Management
{
using System;
using System.Web;
public partial class bid

{
public bid()
{
this.applierLists = new HashSet<applierList>();
}

public string bidOwner { get; set; }
public string bidType { get; set; }
99 | P a g e
SYSTEM DESIGN
public string participant { get; set; }

public Nullable<int> noOfApplier { get; set; }
public virtual agent agent { get; set; }

public virtual ICollection<applierList> applierLists { get; set; }
[NotMapped]
[NotMapped]
public bool apply { get; set; }
}
}
[HttpGet]
public ActionResult CreateOrEditBid(int bidId = 0)
{
if (bidId != 0)
{
post oldPost = ppaDatabase.posts.Where(x => x.id ==
bidId).FirstOrDefault();
return View("EditeBid");
}
return PartialView("CreateBid");
}
[HttpPost]
public ActionResult CreateOrEditBid(bid newBid)
{
try
{
newBid.bidOwner = user.userName;
newBid.dateAndTime = DateTime.Now.Date;
newBid.noOfApplier = 0;
newBid = ppaDatabase.bids.Add(newBid);
newLog.actionDone = user.userName + "create a bid with title " +
newBid.title;
}
{
}
try
{
if (newBid.FileUpload.ContentLength > 0)
100 | P a g e
{
string fileName =
Path.GetFileNameWithoutExtension(newBid.FileUpload.FileName);
string extension = Path.GetExtension(newBid.FileUpload.FileName);
string path = "bidFile" + newBid.id + extension;
newBid.FileUpload.SaveAs(Path.Combine(Server.MapPath("~/File/"),
path));
newBid.fileId = postFile.id;
ppaDatabase.Entry(newBid).State = EntityState.Modified;
}
}
{
Console.Write(ex);
}
return Json(new { success = true, message = "Success fully Created" },
}
[HttpGet]
public ActionResult EditeBid(int id)
{
bid openBid = ppaDatabase.bids.Where(x => x.id == id).FirstOrDefault();
return View(openBid);
}
[HttpPost]
public ActionResult EditeBid(bid newBid)
{
bool state = false;
if (ModelState.IsValid)
{
ppaDatabase.Entry(newBid).State = EntityState.Modified;
newLog.actionDone = user.userName + "Edite a bid with title " +
newBid.title;
state = true;
}
return new JsonResult { Data = new { status = state } };

}
[HttpGet]
public ActionResult DeleteBid(int id)
101 | P a g e
SYSTEM DESIGN
{
bid bidDelete = ppaDatabase.bids.Where(x => x.id == id).FirstOrDefault();
return View(bidDelete);
}
[HttpPost]
[ActionName("DeleteBid")]
public ActionResult DeleteByBidId(int id)
{
bid bidDelete = ppaDatabase.bids.Where(x => x.id == id).FirstOrDefault();
if (bidDelete.fileId != null)
{
fileTable bidFile = ppaDatabase.fileTables.Where(file => file.id ==
bidDelete.fileId).FirstOrDefault();
ppaDatabase.fileTables.Remove(bidFile);
}
if (bidDelete.noOfApplier != 0)
{
List<applierList> bidApplierList = ppaDatabase.applierLists.Where(x =>
x.bidId == bidDelete.id).ToList();
foreach (applierList applier in bidApplierList)
{
if (applier.fileId != null)
{
ppaDatabase.fileTables.Remove(ppaDatabase.fileTables.Where(file => file.id ==

applier.fileId).FirstOrDefault());
}
ppaDatabase.applierLists.Remove(applier);
}
string temp = bidDelete.id.ToString();

List<notificationTable> postNotificaiton =
ppaDatabase.notificationTables.Where(x => x.fileNotification ==
temp).ToList<notificationTable>();
foreach (notificationTable tempNotification in postNotificaiton)
{
ppaDatabase.notificationTables.Remove(tempNotification);
}

newLog.actionDone = user.userName + "Delete a Bid with title " +
bidDelete.title;
ppaDatabase.bids.Remove(bidDelete);
return RedirectToAction("Index");
}
102 | P a g e
public ActionResult Bid(int? page)
{
var model = AllBid().OrderByDescending(x => x.dateAndTime); ;
return View(onePageOfBid);
}
public IEnumerable<ApplierListTable> ApplierList()
{
List<applierList> ApplierList =
ppaDatabase.applierLists.ToList<applierList>();
List<ApplierListTable> applierListTable = new List<ApplierListTable>();
ApplierListTable singleApplierList = new ApplierListTable();
supplierBuyer singleSupplierBuyer = new supplierBuyer();
bid singleBid = new bid();
foreach (var temp in ApplierList)
{
singleApplierList.bidId = Convert.ToInt32(temp.bidId);
singleBid = ppaDatabase.bids.Where(x => x.id ==
temp.bidId).FirstOrDefault<bid>();
singleApplierList.bidTitle = singleBid.title;
singleSupplierBuyer = ppaDatabase.supplierBuyers.Where(x => x.email ==
temp.userName).FirstOrDefault<supplierBuyer>();
singleApplierList.applierUserName = singleSupplierBuyer.email;
singleApplierList.applierName = singleSupplierBuyer.name;
singleApplierList.approved = temp.applyApprove;
singleApplierList.dataAndTime = temp.dateAndTime;
fileTable applierFile = ppaDatabase.fileTables.Where(x => x.id ==
temp.fileId).FirstOrDefault();
singleApplierList.applierFile = applierFile.name;
singleApplierList.applierFilePath = applierFile.filePath;
applierListTable.Add(singleApplierList);
}
return applierListTable;
}
public ActionResult RequestList()
{
return View(ApplierList());
}
public ActionResult RequestAccepted(int bidId = 0)
{
if(bidId != 0)
{
applierList applier = ppaDatabase.applierLists.Where(x => x.bidId ==
bidId).First();
applier.applyApprove = true;
ppaDatabase.Entry(applier).State = EntityState.Modified;
bid Bid = ppaDatabase.bids.Where(x => x.id == bidId).FirstOrDefault();
newLog.actionDone = user.userName + "Accepted the request of " +
applier.userName + "on the bid of "+Bid.title ;
103 | P a g e
SYSTEM DESIGN
}
return View("RequestList", ApplierList());
Message management
{
using System;
public partial class messageReceiver

{
public int number { get; set; }
public Nullable<int> id { get; set; }
public string receiver { get; set; }
public virtual messageTable messageTable { get; set; }

}
}
{
using System;
public partial class messageSender

{
public Nullable<int> id { get; set; }
public string sender { get; set; }
public virtual messageTable messageTable { get; set; }

}
}
{
using System;
using System.Web;
public partial class messageTable

{
public messageTable()
{
this.messageReceivers = new HashSet<messageReceiver>();
this.messageSenders = new HashSet<messageSender>();
104 | P a g e
}

public string messageType { get; set; }
public bool messageStatus { get; set; }
public System.DateTime reciveDataAndTime { get; set; }
public Nullable<System.DateTime> seenDateAndTime { get; set; }

public virtual ICollection<messageReceiver> messageReceivers { get; set; }
public virtual ICollection<messageSender> messageSenders { get; set; }
[NotMapped]
public string messagesender { get; set; }
[NotMapped]
public string messagereceiver { get; set; }
[NotMapped]
}
}
public IEnumerable<messageTable> AllMessage()
{
List<messageReceiver> agentMessage =
ppaDatabase.messageReceivers.Where(x => x.receiver ==
user.userName).ToList<messageReceiver>();
List<messageTable> allMessage = new List<messageTable>();
messageTable singeleMessage;
messageSender senderMessage;
foreach (var message in agentMessage)
{
singeleMessage = ppaDatabase.messageTables.Where(x => x.id ==
message.id).FirstOrDefault<messageTable>();
senderMessage = ppaDatabase.messageSenders.Where(x => x.id ==
message.id).FirstOrDefault<messageSender>();
singeleMessage.messagesender = senderMessage.sender;
singeleMessage.messagereceiver = user.userName;
allMessage.Add(singeleMessage);
}
int numberOfMessage = 0;
foreach (var message in allMessage)
{
if (message.messageStatus == false)
{
numberOfMessage++;
}
}
Session["numberOfMessage"] = numberOfMessage;
105 | P a g e
SYSTEM DESIGN
List<messageSender> sendMessage = ppaDatabase.messageSenders.Where(x

=> x.sender == user.userName).ToList<messageSender>();
messageReceiver messageReceiver;
foreach (var message in sendMessage)
{
singeleMessage = ppaDatabase.messageTables.Where(x => x.id ==
message.id).FirstOrDefault<messageTable>();
messageReceiver = ppaDatabase.messageReceivers.Where(x => x.id ==
message.id).FirstOrDefault<messageReceiver>();
singeleMessage.messagesender = user.userName;
singeleMessage.messagereceiver = messageReceiver.receiver;
allMessage.Add(singeleMessage);
}
return allMessage;
public PartialViewResult MessageList()
{
return PartialView(AllMessage().Where(x =>
x.messagereceiver==user.userName).Take(5));
}
[HttpGet]
public ActionResult MessageDetail(int ? id)
{
id = id ?? 0;
messageTable Message = new messageTable();
AllMessage();
if (id != 0)
{
if(Message.messagesender != user.userName)
{
Message = ppaDatabase.messageTables.Where(x => x.id ==
Message.messageStatus = true;
Message.seenDateAndTime = DateTime.Now;
ppaDatabase.Entry(Message).State = EntityState.Modified;
AllMessage();
}
}
return View(Message);
}
public PartialViewResult ReceivedMessage(int? page)
{
var model = AllMessage().Where(x => x.messagereceiver ==
user.userName).OrderByDescending(x => x.reciveDataAndTime); ;
return PartialView(onePageOfBid);
}
[HttpGet]
public PartialViewResult SendMessage()
{
return PartialView();
}
[HttpPost]
public ActionResult SendMessage(MessageToSend message)
106 | P a g e
{
messageTable MessageTable = new messageTable();
messageReceiver MessageReceiver = new messageReceiver();
if (ppaDatabase.accounts.Where(x => x.userName ==
message.messageReciver).FirstOrDefault() == null)
{
return Json(new { success = false, message = "The Message Reciver is
not valide!" }, JsonRequestBehavior.AllowGet);
}
try
{
MessageTable.title = message.messageTitle;
MessageTable.body = message.messageBody;
MessageTable.messageType = message.messageType;
MessageTable.reciveDataAndTime = DateTime.Now;
MessageTable = ppaDatabase.messageTables.Add(MessageTable);
messageSender MessageSender = new messageSender();
MessageSender.id = MessageTable.id;
MessageSender.sender = user.userName;
ppaDatabase.messageSenders.Add(MessageSender);
MessageReceiver.receiver = message.messageReciver;
MessageReceiver.id = MessageTable.id;
ppaDatabase.messageReceivers.Add(MessageReceiver);

newLog.actionDone = user.userName + "sends Messsage to " +
MessageTable.messageReceivers;
}

{
}
try
{
if (message.FileUpload.ContentLength > 0)
{
string fileName =
Path.GetFileNameWithoutExtension(message.FileUpload.FileName);
string extension = Path.GetExtension(message.FileUpload.FileName);
string path = "MFile" + MessageTable.id + extension;
message.FileUpload.SaveAs(Path.Combine(Server.MapPath("~/File/"),
path));
107 | P a g e
SYSTEM DESIGN
MessageTable.fileId = postFile.id;
ppaDatabase.Entry(MessageTable).State = EntityState.Modified;
}
}
{
Console.Write(ex);
}
return Json(new { success = true, message = "Your Message Sends succesfuly
To " + MessageReceiver.receiver}, JsonRequestBehavior.AllowGet);
}
public void ReplyMessage(FormCollection message)

{
messageTable MessageTable = new messageTable();
MessageTable.title = message["title"];
MessageTable.body = message["body"];
MessageTable.messageType = message["type"];
MessageTable.reciveDataAndTime = DateTime.Now;
MessageTable = ppaDatabase.messageTables.Add(MessageTable);
messageSender MessageSender = new messageSender();
MessageSender.id = MessageTable.id;
MessageSender.sender = user.userName;
ppaDatabase.messageSenders.Add(MessageSender);
messageReceiver MessageReceiver = new messageReceiver();
MessageReceiver.receiver = message["reciver"];
MessageReceiver.id = MessageTable.id;
ppaDatabase.messageReceivers.Add(MessageReceiver);
newLog.actionDone = user.userName + "Reply to the message of " +
MessageTable.messageReceivers;
}
public PartialViewResult SendMessageList(int? page)
{
var model = AllMessage().Where(x => x.messagesender ==
user.userName).OrderByDescending(x => x.reciveDataAndTime); ;
return PartialView(onePageOfBid);;
} }
Account management
{
using System;
108 | P a g e
public partial class account

{
public account()
{
this.notificationTables = new HashSet<notificationTable>();
this.notificationTables1 = new HashSet<notificationTable>();
this.systemLogs = new HashSet<systemLog>();
}
public string userName { get; set; }

public string userPassword { get; set; }
public string accountType { get; set; }
public virtual likeList likeList { get; set; }
public virtual ICollection<notificationTable> notificationTables { get; set; }
public virtual ICollection<notificationTable> notificationTables1 { get;
set; }
public virtual ICollection<systemLog> systemLogs { get; set; }
}
}
{
using System;
using System.Web;
public partial class agent

{
public agent()
{
this.bids = new HashSet<bid>();
this.posts = new HashSet<post>();
photo = "~/Photo/profile-default-male.png";
109 | P a g e
SYSTEM DESIGN
public string name { get; set; }

[NotMapped]
public string password { get; set; }
[NotMapped]
public string confirmPassword { get; set; }
public string Department { get; set; }
public string Position { get; set; }
public string officeNo { get; set; }
public string telephone { get; set; }
public virtual ICollection<bid> bids { get; set; }
public virtual ICollection<post> posts { get; set; }
[NotMapped]
}
}
{
using System;
using System.Web;
public partial class publicBody

{
[NotMapped]
[NotMapped]
public string region { get; set; }
public string city { get; set; }
public string subCity { get; set; }
public string weredaKebele { get; set; }
public string fax { get; set; }
public publicBody()
{
}
[NotMapped]
}
}
110 | P a g e
{
using System;
using System.Web;
public partial class supplierBuyer

{
public supplierBuyer()
{
this.supplierbuyerTinNoes = new HashSet<supplierbuyerTinNo>();
this.supplierbuyerLicensees = new HashSet<supplierbuyerLicensee>();

public string email { get; set; }
[NotMapped]
[NotMapped]
public string userType { get; set; }
public double capital { get; set; }
public string fax { get; set; }
public string region { get; set; }
public string city { get; set; }
public string weredaKebele { get; set; }
public Nullable<int> houseNumber { get; set; }
public Nullable<bool> block { get; set; }
public Nullable<bool> validAccount { get; set; }
public virtual applierList applierList { get; set; }

public virtual ICollection<supplierbuyerTinNo> supplierbuyerTinNoes { get;
set; }
public virtual ICollection<supplierbuyerLicensee> supplierbuyerLicensees {
get; set; }
[NotMapped]
}
}
{
using System;
111 | P a g e
SYSTEM DESIGN
public partial class supplierbuyerLicensee

{
public string licenseesNo { get; set; }
public virtual supplierBuyer supplierBuyer { get; set; }

}
}
{
using System;
public partial class supplierbuyerTinNo

{
public string tinNo { get; set; }
public virtual supplierBuyer supplierBuyer { get; set; }

}
}
public ActionResult Account()

{
agent profile = ppaDatabase.agents.Where(x => x.userName ==
user.userName).FirstOrDefault();
return View(profile);
}
[HttpPost]
public ActionResult ChangePassword(FormCollection formCollection)
{
account userAccount = ppaDatabase.accounts.Where(x => x.userName ==
user.userName).First();
userAccount.userPassword = formCollection["password"];
ppaDatabase.Entry(userAccount).State = EntityState.Modified;
agent profile = ppaDatabase.agents.Where(x => x.userName ==

newLog.actionDone = user.userName + "change the password of account on "
+ DateTime.Now;
return null;
}
public void ChangeProfile(FormCollection formCollection)
{
112 | P a g e
agent userAccount = ppaDatabase.agents.Where(x => x.userName ==
userAccount.telephone = formCollection["newValue"];
ppaDatabase.Entry(userAccount).State = EntityState.Modified;
}
[HttpGet]
public ActionResult UserProfile(string userName)
{
UserProfile profile = new UserProfile();
account userAccount = ppaDatabase.accounts.Where(x => x.userName ==
userName).First();
if(userAccount.accountType == "publicBody")
{
publicBody tempProfile = ppaDatabase.publicBodies.Where(x =>
x.userName == userName).First();
profile.name = tempProfile.name;
profile.userName = tempProfile.userName;
profile.photo = tempProfile.photo;
profile.telephone = tempProfile.telephone;
profile.region = tempProfile.region;
profile.city = tempProfile.city;
profile.weredaKebele = tempProfile.weredaKebele;
profile.fax = tempProfile.fax;
profile.accountType = "publicBody";
}
else if (userAccount.accountType == "agent" || userAccount.accountType ==
"admin")
{
agent tempProfile = ppaDatabase.agents.Where(x => x.userName ==
userName).First();
profile.userName = tempProfile.userName;
profile.department = tempProfile.Department;
profile.posision = tempProfile.Position;
profile.officeNo = tempProfile.officeNo;
profile.accountType = "agent";
}
else
{
supplierBuyer tempProfile = ppaDatabase.supplierBuyers.Where(x =>
x.email == userName).First();
profile.userName = tempProfile.email;
profile.userType = tempProfile.userType;
profile.houseNumber = tempProfile.houseNumber;
profile.region = tempProfile.region;
profile.city = tempProfile.city;
profile.weredaKebele = tempProfile.weredaKebele;
profile.fax = tempProfile.fax;
profile.accountType = "supplierBuyer";
113 | P a g e
SYSTEM DESIGN
}
return View(profile);
}
namespace PPA.Controllers
{
public class LoginController : Controller
{
PPAEntities ppaDatabase = new PPAEntities();
[HttpGet]
public ActionResult Index()
{
if (Session["admin"] != null)
{
return RedirectToAction("Index", "Admin");
}
else if (Session["publicbody"] != null)
{
return RedirectToAction("Index", "PublicBody");
}
else if (Session["agent"] != null)
{
return RedirectToAction("Index", "Agent");
}
else
return View();
}
[HttpPost]
public ActionResult Index(Login loginInfo)
{
account user = new account();
try
{
user = ppaDatabase.accounts.Where(e => e.userName ==
loginInfo.userName.ToString() && e.userPassword ==
loginInfo.password.ToString()).Single();

newLog.actionDone = user.userName + "Login to System at " +
DateTime.Now;
if (user.accountType == "admin" || user.accountType == "Admin")

{
Session["admin"] = user;
return RedirectToAction("Index", "Admin");
}
else if (user.accountType == "publicBody" || user.accountType ==
"PublicBody")
{
Session["publicbody"] = user;
return RedirectToAction("Index", "PublicBody");
}
114 | P a g e
else if (user.accountType == "Agent" || user.accountType == "agent")
{
Session["agent"] = user;
return RedirectToAction("Index", "Agent");
}
else if(user.accountType == "supplierBuyer" || user.accountType ==
"supplierBuyer")
{
supplierBuyer data = ppaDatabase.supplierBuyers.Where(x =>
x.email == user.userName).First();
if(data.block == false)
{
Session["supplierBuyer"] = user;
return RedirectToAction("Index", "SupplierBuyer");
}
else
{
return RedirectToAction("Error");
}
}
else
{
ModelState.AddModelError("password", "Wrong Email or Password");
return View(loginInfo);
}
}
{
ModelState.AddModelError("password", "Wrong Email or Password");
return View(loginInfo);
}
}
[HttpGet]
public ActionResult Register()
{
return View();
}
[HttpPost]
public ActionResult Register(supplierBuyer supplierbuyer)
{
account Account = new account();

Account.userName = supplierbuyer.email;
Account.userPassword = supplierbuyer.password;
Account.accountType = "SupplieBuyer";
ppaDatabase.accounts.Add(Account);
ppaDatabase.supplierBuyers.Add(supplierbuyer);
//ppaDatabase.registerSupplierBuyer(supplierbuyer.name,
supplierbuyer.email, supplierbuyer.userType, supplierbuyer.capital,
supplierbuyer.city, null);
115 | P a g e
SYSTEM DESIGN
supplierbuyer = ppaDatabase.supplierBuyers.Where(x => x.email ==

supplierbuyer.email).First();
supplierbuyer.block = true;
ppaDatabase.Entry(supplierbuyer).State = EntityState.Modified;
BuildEamilTemplate(supplierbuyer.number);
return null;
}
public ActionResult Confirm(int regId)
{
ViewBag.regId = regId;
return View();
}
public JsonResult RegisterConfirm(int regId)
{
supplierBuyer data = ppaDatabase.supplierBuyers.Where(x => x.number ==
regId).FirstOrDefault();
data.block = false;
ppaDatabase.Entry(data).State = EntityState.Modified;
var msg = "your Emair is Verfied!";
return Json(msg, JsonRequestBehavior.AllowGet);
}
public JsonResult IsUserNameIsAvailibal(string email)
{
return Json(!ppaDatabase.accounts.Any(user => user.userName ==
email),JsonRequestBehavior.AllowGet);
}
public void BuildEamilTemplate(int regId)
{
string body =
System.IO.File.ReadAllText(HostingEnvironment.MapPath("~/EmailTemplate/") + "Text" +
".cshtml");
var logInfo = ppaDatabase.supplierBuyers.Where(x => x.number ==
regId).FirstOrDefault();
var url = "http://localhost:52892/" + "Login/Confirm?regId=" + regId;
body = body.Replace("@ViewBag.confirmationLink", url);
body = body.ToString();
BuildEamilTemplate("Your Account Is Successfully Created", body,
logInfo.email);
}
private void BuildEamilTemplate(string subjectText , string bodyText , string
sendTo)
{
string from, to, bcc, cc, subject, body;
from = "ethioppa@gmail.com";
to = sendTo.Trim();
bcc = "";
cc = "";
subject = subjectText;
StringBuilder sb = new StringBuilder();
sb.Append(bodyText);
body = sb.ToString();
MailMessage mail = new MailMessage();
mail.From = new MailAddress(from);
mail.To.Add(new MailAddress(to));
if (!string.IsNullOrEmpty(bcc))
116 | P a g e
{
mail.Bcc.Add(new MailAddress(bcc));
}
if (!string.IsNullOrEmpty(cc))
{
mail.CC.Add(new MailAddress(cc));
}
mail.Subject = subject;
mail.Body = body;
mail.IsBodyHtml = true;
SendMail(mail);
}
public static void SendMail(MailMessage mail)
{
SmtpClient client = new SmtpClient();
client.Host = "smtp.gmail.com";
client.Port = 587;
client.EnableSsl = true;
client.UseDefaultCredentials = false;
client.DeliveryMethod = SmtpDeliveryMethod.Network;
client.Credentials = new
System.Net.NetworkCredential("ethioppa@gmail.com", "PPA12345ppa");
try
{
client.Send(mail);
}
catch (Exception ex )
{
throw ex;
}
}
}
}
Like Management
{
using System;
public partial class likeList

{
public Nullable<int> postId { get; set; }
public string likeOwner { get; set; }
public virtual account account { get; set; }

public virtual post post { get; set; }
}
}
public ActionResult LikeControler(post item)
{
117 | P a g e
SYSTEM DESIGN
likeList LikeList = ppaDatabase.likeLists.Where(x => x.postId == item.id

&& x.likeOwner == user.userName).FirstOrDefault();
likeList tempLike = new likeList();
if (LikeList == null)
{
item.noOfLike = item.noOfLike + 1;
ppaDatabase.Entry(item).State = EntityState.Modified;
tempLike.likeOwner = user.userName;
tempLike.dateAndTime = DateTime.Now.Date;
tempLike.postId = item.id;
ppaDatabase.likeLists.Add(tempLike);
ppaDatabase.SaveChanges(); notificationTable newNotification = new
notificationTable();
newNotification.actionOwner = user.userName;
newNotification.notificationOwner = item.postOwner;
newNotification.fileNotification = item.id.ToString();
newNotification.fileType = "post";
newNotification.body = user.userName + "Likes on your post";
newNotification.dateAndTime = DateTime.Now;
ppaDatabase.notificationTables.Add(newNotification);

newLog.actionDone = user.userName + "Like the post of " +
item.postOwner + "the Tiltle of the post is " + item.title;
}
else
{
item.noOfLike = item.noOfLike - 1;
ppaDatabase.Entry(item).State = EntityState.Modified;
ppaDatabase.likeLists.Remove(LikeList);
notificationTable oldNotification =
ppaDatabase.notificationTables.Where(x => x.actionOwner == user.userName &&
x.fileNotification == item.id.ToString()).FirstOrDefault();
ppaDatabase.notificationTables.Remove(oldNotification);
}
return Json(item.noOfLike,JsonRequestBehavior.AllowGet);
}
Comment management
{
using System;
public partial class commment

{
118 | P a g e
public Nullable<int> postId { get; set; }
public string commentOwner { get; set; }

public virtual post post { get; set; }
[NotMapped]
public string OwnerName { get; set; }
[NotMapped]
public string OwnerProfile { get; set; }
}
}
public PartialViewResult CommentList(int postId)
{
List<commment> temComment = ppaDatabase.commments.Where(x => x.postId ==
postId).ToList();
account ownerAccount = new account();
List<commment> allComment = new List<commment>();
foreach(commment item in temComment)
{
ownerAccount = ppaDatabase.accounts.Where(x => x.userName ==
item.commentOwner).FirstOrDefault();
if(ownerAccount.accountType == "agent" || ownerAccount.accountType ==
"admin")
{
agent commentOwner = ppaDatabase.agents.Where(x => x.userName ==
ownerAccount.userName).FirstOrDefault();
item.OwnerName = commentOwner.name;
item.OwnerProfile = commentOwner.photo;
}
else if (ownerAccount.accountType == "publicBody")
{
publicBody commentOwner = ppaDatabase.publicBodies.Where(x =>
x.userName == ownerAccount.userName).FirstOrDefault();
}
else if (ownerAccount.accountType == "supplierbuyer")
{
supplierBuyer commentOwner = ppaDatabase.supplierBuyers.Where(x =>
x.email == ownerAccount.userName).FirstOrDefault();
}
else
{
continue;
}
119 | P a g e
SYSTEM DESIGN
allComment.Add(item);
}
return PartialView(allComment.OrderByDescending(x => x.dateAndTime));
}
public ActionResult CommentController(FormCollection formCollection)
{
if(Session["postId"] != null)
{
commment newComment = new commment();
newComment.postId = Convert.ToInt32(Session["postId"]);
newComment.commentOwner = user.userName;
newComment.body = formCollection["commentBody"];
newComment.dateAndTime = DateTime.Now;
ppaDatabase.commments.Add(newComment);
post commentPost = ppaDatabase.posts.Where(x => x.id ==
newComment.postId).FirstOrDefault();
commentPost.noOfComment = commentPost.noOfComment + 1;
ppaDatabase.Entry(commentPost).State = EntityState.Modified;
notificationTable newNotification = new notificationTable();

newNotification.actionOwner = user.userName;
newNotification.notificationOwner = commentPost.postOwner;
newNotification.fileNotification = commentPost.id.ToString();
newNotification.fileType = "post";
newNotification.body = user.userName + "commented on your post";
newNotification.dateAndTime = DateTime.Now;
ppaDatabase.notificationTables.Add(newNotification);

newLog.actionDone = user.userName + "commented on the post of " +
commentPost.postOwner + "the Tiltle of the post is " + commentPost.title;
AllPost();
if (commentPost.fileId != null)
{
fileTable Temp = ppaDatabase.fileTables.Where(x => x.id ==
commentPost.fileId).FirstOrDefault();
Session["path"] = Temp.filePath.ToString();
Session["fileName"] = Temp.name.ToString();
}
else
{
Session.Remove("path");
Session.Remove("fileName");
}
return View("PostDetail",commentPost);
120 | P a g e
}
else
{
return View("Error");
}
}
[HttpPost]
public ActionResult DeleteComment(int id)
{
ppaDatabase.commments.Remove(ppaDatabase.commments.Where(x => x.id ==
id).FirstOrDefault());
return View();
}
[HttpPost]
public ActionResult EditeComment(int id)
{
return View();
}
[HttpPost]
public ActionResult EditeComment(int id)
{
return View();
}
File Management
{
using System;
public partial class fileTable

{
public fileTable()
{
this.applierLists = new HashSet<applierList>();
this.bids = new HashSet<bid>();
this.messageTables = new HashSet<messageTable>();
this.posts = new HashSet<post>();
}

public string filePath { get; set; }
121 | P a g e
SYSTEM DESIGN
public virtual ICollection<applierList> applierLists { get; set; }
public virtual ICollection<bid> bids { get; set; }
public virtual ICollection<messageTable> messageTables { get; set; }
public virtual ICollection<post> posts { get; set; }
}
}
System Log Management
{
using System;
public partial class systemLog

{
public int logId { get; set; }
public string actionDone { get; set; }

}
}
public ActionResult SystemLog()
{
return View(AllSystemLog());
}
public IEnumerable<systemLog> AllSystemLog()
{
return ppaDatabase.systemLogs.ToList<systemLog>();
}
[HttpPost]
public ActionResult DeleteSystemLog(int id)
{
systemLog log = ppaDatabase.systemLogs.Where(x => x.logId ==
ppaDatabase.systemLogs.Remove(log);
return View("SystemLog", AllSystemLog());
}
122 | P a g e
CHAPTER SIX
CONCLUSION
This project is intended as Partial Fulfillment of the Requirements for the B.Sc Degree in
Computer Science. The project that we have selected “FDRE Procurement Management
System” is aimed to computerize procumbent and assets Management activities of the
Agency, publicbody, buyers and supplier.
As we have been working in this project we have gone through almost all the phases of
Software Engineering. It gives us a chance to implement our knowledge of Software
Engineering, Database Management System, Programming and Project Management which
we have gained through lesson at HiLCoE and work experience. While working on the
project we have observed many drawbacks associated with the current system and practices
of the agency and build a belief that the actual implementation of this project will assist all
the stakeholders by large. And hence we made an internal and professional commitment to
work on the real implementation of the project after working out the modules and scenarios
left undone
123 | P a g e
SYSTEM DESIGN
REFERENCE
1. International Journal of Emerging Technology and Advanced Engineering
Website: www.ijetae.com (ISSN 2250-2459, ISO 9001:2008 Certified
Journal, Volume 3, Issue 7, July 2013)
2. Regular Expression pocket references, O’reilly® Tony Stubblebin, 2 nd
Edition, July 2007
3. Software Engineering a practitioners approach, 5 th edition, Roger S.
Pressman, Ph.D.
124 | P a g e

Final Document For Department

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

Final Document For Department

Uploaded by

Copyright:

Available Formats

ADDIS ABABA UNIVERSITY

FACULTY OF NATURAL AND COMPUTATIONAL

FINAL PROJECT BY:

ADVISOR: Mekonnen Geremew

Full Name Signature

Daniel Demeke ________________________________

Million Haile ________________________________

Yonas Beyene ________________________________

Date Name and Signature of Supervisor

The group members

Figure 2.1 the structure of the organization.............................................................................10

Ethiopia Procurement Agency is committed to building a transparent and ethical civil

The strategy focused on the promotion of proper implementation on of the public

 Public body: it is the governmental organization in the federal level where it

1.2 STATEMENT OF THE PROBLEM AND JUSTIFICATION

Importance of the system:-

 The agency can receive complaints easily,

1.3 PROJECT OBJECTIVE

1.3.1 General objective

1.3.2 Specific objectives

 Design the overall system.

1.4 SCOPE OF THE PROJECT

1.5.1 Investigation (Fact-finding) Method

1.5.2 Development Methodology

Requirement analysis methodology Tools

For the other written documentation we intend to use

 Microsoft office professional 2016

For the implementation phase we are going to use: -

1.6 SIGNIFICANCE OF THE PROJECT

1.8 TIME SCHEDULE

Table 1.1 Project activities Time table

2.2 CURRENT SYSTEM

2.2.1 Major Function of the Current System/ Current System Description

Government Government Information

Figure 2.1 this figure shows the structure of the organization

2.2.1.1 Director General

2.2.1.2 Deputy Director General

2.2.1.3 Government Procurement Directorate

2.2.1.4 Government Property Management Directorate

2.2.1.5 Government Procurement and Property Management to investigate a complaint

2.2.1.6 Information Technology /IT/Unit

Scenario Name Common Procurement Process

procurement process is differ from normal the university used

Scenario Name Special Procurement Process.

Scenario Name Register supplier

3. After fulfill the form correctly Mintesnot click on the register

Scenario Name Bid Process.

2. The Procurement expert prepares the bid document.

Scenario Name Supplier Complains

Mintesnot can report its problem to the Board of Appeals.

Scenario Name Public body complains.

correct the Addis Ababa University or Mintesnot can report

Scenario Name Consulting public body

Scenario Name Remove expired material.

Scenario Name Bid process for removing expired material.

4. The chala buys the bid document.

2.2.3 Problems of Existing System

2.3 REQUIREMENT GATHERING

2.3.1 Requirement Gathering Methodology

2.3.2 Result Found

1. The structure of the existing system.

2.4.2 Functional Requirements

FR-1:- Only authorized users shall login to the system.