ADVENTIST UNIVERSITY OF CENTRAL AFRICA

(AUCA)

Faculty of Information Technology

Department of Information Management

E-Procurement Management System (e-PMS)

Case study MUSANZE District

A research project presented in partial fulfillment of the requirements of the

award of Bachelor’s Degree in Information Management

By

NDIZIHIWE Eric

Supervisor: INGABIRE Marie Ange

Kigali, May 2012

Abstract

This study focuses on developing and implementing a web-based procurement system of

Musanze called E-procurement system that will help to improve the tender process in Musanze
district, this project is conceived with an aim of providing an adequate solution to these
problems. The objective of this study is to make software able to assist the District of Musanze to
overcome with the problems.

The above mentioned system has three main parties that are tender management system,
announcing the acquisition of goods and services, electronic access to tender documents, and
tender evaluation in order to get the award bidder of a certain tender. The bidder will be able to
get information they need for long as they have access to the internet.
Analysis and design approach, object oriented methodology was chosen and UML was used. The
software methodology called waterfall model which has been used due to its good progress
tracking and well-defined development stages used to provide a very robust notation, which
grows from analysis into design.

ii
Acknowledgment

Success is the outcome for hard work and patience. I am therefore greatly indebted to all those
persons who restlessly assisted me financially, materially, morally, spiritually or otherwise
during the course of my study, in particular during this project work. I shall however talk about a
few whose services were absolutely indispensable as it is difficult to mention all of you here.
Special thanks go to the Mayor of Musanze District, Department of Public Procurement, in
particular Mr. Charles RUZINDANA President of Tender Committee and Mr. Isaac
BIDAHARINKA Secretary of Tender Committee moral support towards this noble cause.
I wish to extend my sincere thanks to my supervisor, INGABIRE Marie Ange, for the
professional and academic guidance she accorded me while carrying out this project.
I cannot end without thanking the entire Staff and fellow information technology Students (2008-
2012) at the Institute, later on Faculty of Information Technology for the intellectual support
throughout the course of my stay at the faculty.
Lastly, I thank the members of my family and friends.

iii
Table of Contents

Abstract ............................................................................................................................................ i
Acknowledgment ........................................................................................................................... iii
Table of Contents........................................................................................................................... iv
List of Tables ................................................................................................................................ vii
List of Figures .............................................................................................................................. viii
List of Abbreviations ..................................................................................................................... ix
CHAPTER 1: GENERAL INTRODUCTION ............................................................................... 1
1.1. Introduction.......................................................................................................................... 1
1.2. Problem statement................................................................................................................ 2
1.3. Motivation............................................................................................................................ 3
1.4. Objectives of the Study....................................................................................................... 3
1.4.1. General Objective............................................................................................................ 3
1.4.2. Specific Objectives.......................................................................................................... 3
1.5. Methodology and technical.................................................................................................. 4
1.6. Scope of the Study ............................................................................................................... 5
1.7. Structure of the work .......................................................................................................... 5
CHAPTER 2: THE EXISTING SYSTEM ANALYSIS ................................................................ 6
2.1. Specific terminology................................................................................................................ 6
2.2. Thorough analysis of the existing system............................................................................ 7
2.2.1. The description of Musanze District ............................................................................... 7
2.2.1.1. The District vision.............................................................................................................. 7
2.2.1.2. The District mission........................................................................................................... 8
2.2.1.3. District objectives .............................................................................................................. 8
2.2.2. Survey of the existing system ............................................................................................... 8
2.2.2.1. Preparation of bidding documents ..................................................................................... 9
2.2.2.2. Invitation to tender........................................................................................................... 10
2.2.2.3. Advertisement .................................................................................................................. 11
2.2.2.4. Provision of bidding document........................................................................................ 11

iv
2.2.2.5. Tender security................................................................................................................. 11
2.2.2.6. Submission and receipt of tenders ................................................................................... 12
2.2.2.7. Bids opening .................................................................................................................... 12
2.2.2.8. Evaluation of bids ............................................................................................................ 14
2.2.2.9. Evaluation Award Recommendation ............................................................................... 16
2.2.2.10. Notification of contract award ....................................................................................... 17
2.2.2.11. Publication of Award Results ........................................................................................ 18
2.3. Problems of existing system .................................................................................................. 18
2.4. Proposed solutions ................................................................................................................. 19
CHAPTER 3: ANALYSIS AND DESIGN OF THE NEW SYSTEM ........................................ 20
3.1. Introduction............................................................................................................................ 20
3.2. Analysis and design methodology ......................................................................................... 20
3.3. System analysis...................................................................................................................... 22
3.3.1. Requirement analysis.................................................................................................. 22
3.3.1.1. Use case diagrams............................................................................................................ 22
3.3.2. Domain analysis.................................................................................................................. 35
3.3.2.1. A class diagram................................................................................................................ 35
3.4. System design ........................................................................................................................ 38
3.4.1. Architecture design ............................................................................................................. 38
3.4.2. Mechanistic design.............................................................................................................. 39
3.4.2.1. Sequence diagram ............................................................................................................ 39
1.Sequence diagram for create users............................................................................................. 40
2.Sequence diagram for create tender document .......................................................................... 41
3.Sequence diagram for create invitation to tender ...................................................................... 42
4.Sequence diagram for submit bids............................................................................................. 43
5.Sequence diagram for evaluation bids ....................................................................................... 44
6.Sequence diagram for opening bids........................................................................................... 45
3.4.3.Detailed design..................................................................................................................... 45
3.4.3.1. Activity diagrams............................................................................................................. 45
3.4.3.2. Database schema diagram................................................................................................ 49
Database Summary ....................................................................................................................... 51

v
CHAPTER 4: NEW SYSTEM IMPLEMENTATION AND TESTING ..................................... 58
4.1. Introduction............................................................................................................................ 58
4.2. Languages and tools used for the system implementation..................................................... 58
4.2.1. Microsoft Visual C#.Net 2008............................................................................................ 58
4.2.2. Microsoft SQL Server 2005................................................................................................ 59
4.2.3. Crystal Reports for Visual Studio .NET ............................................................................. 60
4.2.4. ASP.NET 3.5 ...................................................................................................................... 61
4.2.5. Ozeki Message Server 6...................................................................................................... 61
4.3. Software Testing and Results................................................................................................. 61
4.3.1. Testing Methodology, Tools and techniques ...................................................................... 61
4.3.2. Unit Testing Results............................................................................................................ 63
4.3.3. Integration Testing Results ................................................................................................. 63
4.3.4. User Acceptance Test Results............................................................................................. 63
4.3.5. E-PMS graphical interfaces ................................................................................................ 64
CHAPTER 5: CONCLUSION AND RECOMMENDATION .................................................... 68
5.1. Conclusion ............................................................................................................................. 68
5.2. Recommendation ................................................................................................................... 68
REFERENCES ............................................................................................................................. 69
1. Bibliography .......................................................................................................................... 69
2. Websites................................................................................................................................. 69

vi
List of Tables

Table 1: Users table details ........................................................................................................... 51

Table 2: Tendering document details............................................................................................ 52

Table 3: Resources details ............................................................................................................ 52

Table 4: Procedures details ........................................................................................................... 53

Table 5: Publications details ......................................................................................................... 53

Table 6: InvitationToTender details.............................................................................................. 53

Table 7: Lots details...................................................................................................................... 53

Table 8: EvaluationCriteria........................................................................................................... 54

Table 9: Companies details........................................................................................................... 54

Table 10: RepresentativePersons details....................................................................................... 54

Table 11: Bids details.................................................................................................................... 55

Table 12: OpeningBids details...................................................................................................... 55

Table 13: PreliminaryEvaluations details ..................................................................................... 55

Table 14: FinancialEvaluations details ......................................................................................... 56

Table 15: Reports details .............................................................................................................. 56

Table 16: AwardContract details .................................................................................................. 56

Table 17: CommitteeMembers details .......................................................................................... 57

vii
List of Figures

Figure 1: Procurement Stage and Activities ................................................................................... 9

Figure 2: Procuring entity and committee member Use cases diagram........................................ 25
Figure 3: public and bidders Use case diagram. ........................................................................... 26
Figure 4: Class diagram for e-procurement management system ................................................ 37
Figure 5: System architecture for E-procurement management system ....................................... 39
Figure 6: Sequence diagram for creating users............................................................................. 40
Figure 7: Sequence diagram for creating tender document .......................................................... 41
Figure 8: Sequence diagram for creating invitation to tender....................................................... 42
Figure 9: Sequence diagram for submit bids ................................................................................ 43
Figure 10: Sequence diagram for evaluation bids......................................................................... 44
Figure 11: Sequence diagram for opening bids ............................................................................ 45
Figure 12: Activity diagram for invitation to tender..................................................................... 47
Figure 13: Activity Diagram for download tender ....................................................................... 48
Figure 14: Activity Diagram for Evaluation and send notifications............................................. 48
Figure 15: Database schema for E-procurement management system ......................................... 50
Figure 16: Home page................................................................................................................... 64
Figure 17: Download tender document......................................................................................... 65
Figure 18: Login page................................................................................................................... 65
Figure 19: Administrator menu..................................................................................................... 66
Figure 20: Evaluation form........................................................................................................... 67

viii
List of Abbreviations

ASP: Active Server Page

BNR: Banque Nationale du Rwanda

CRL: Common Language Runtime

DML: Data Manipulation Language

E-PMS: Electronic Procurement Management System

GSM: Global System for Mobile Communication

GUI: Graphical User Interface

ICT: Information and Communications Technology

IDE: Integrated Development Environment

IT: Information Technology

OCL: Object Constraint Language

OMT: Object Modeling Language

OO: Object Oriented

OOAD: Object Oriented Analysis and Design

SMS: Short Message Service

SQL: Structured Query Language

UML: Unified Modeling Language

XML: Extensible Markup Language

ix
CHAPTER 1: GENERAL INTRODUCTION

1.1. Introduction

Today, the use of technologies takes an increasing importance in our everyday life as it makes
the world a small planetary village, and this constitutes a major concern for our country. Rwanda
Government plans to use the ICT for Development and National Information and
Communication infrastructure framework.

Achieving the implementation of the ICT framework in Rwanda, requires the government to
spread the use of high technologies in all government institutions, which means, from offices to
public academic centers to private academic centers. To do so, the government of Rwanda has
started various programs to quicken (quick start) the use of the ICT in the country. Those
programs include the distribution of computers, the installations of optic fibers, and the set up of
the ICT departments at different government offices, so as to efficiently manage data. ICT has a
lot of advantages for the government institutions, as it gives an easy way to store data.
Traditionally, the bidders’ details had been kept manually on the shelves, and the evaluation
process of tenders was erroneous and lengthy. Again, bidders were having difficulties to access
results of their bids.

As technology advances, the world tends to be more technology dependent, as a way to improve
their working environment. Procurement is the acquisition of goods and services and it is
favorable goods and services be appropriate and procured at the best possible cost to meet the
needs of the purchaser in terms of quality, quantity, time and location. The procurement
departments have always been seeking effective ways to improve how the procurement process
works. Bearing that in mind, it seems fitting for the Musanze district, to further embrace the use
of the ICT, and introduce the e-procurement management system. The use of such a system
could be of great importance, because it should be very supportive in terms of easy storage of
bids and easy access of results.
This e-procurement management system has been designed to help the storage of data, and
therefore, facilitating the Musanze district to store its data regarding the bids of goods, services
and works.

1.2. Problem statement

As above mentioned, the manual system of data storage has many problems as any other manual
systems. The following are problems we found in procurement unit in Musanze District:

1. The current system has a problem of keeping the records separately because of keeping the
records separately in hard copies in shelves.

2. The procuring entity is facing the problem of getting the information on time because of
searching the information related to one tender in disorderly classified files.

3. It is hard to get reports on time as they have to write them on papers and then take time to type
them.

4. The current system is lacking enough security in controlling tender documents and other
related documents.

5. In the current system, the process of evaluating tenders takes a lot of time doing analysis of
each document as they write down.

6. The bidders are facing the problem of getting the information they want such as a tender
document and also the final results, they have to go to the district, about the results they have to
wait for notification letters or calls from district.

2
1.3. Motivation

The new system will help the District in the department of procurement unit to improve the
speed of work, to reduce the time spent on writing reports and the staff will manage their
documents more effectively and efficiently.

1.4. Objectives of the Study

1.4.1. General Objective

The main objective of the study was to design and implement an e-procurement management
system that may be adopted for the public procurement in Musanze District to facilitate easy
storage, retrieval and dissemination of information on public procurement to prospective
providers and the public.

1.4.2. Specific Objectives

To achieve the main objective, the specific objectives of the study were the following:

1. To identify critical e-procurement user requirements for Musanze District.

2. To implement a procurement management system relevant to Rwanda basically at Musanze

District office.

3. To develop a system that bidders will be able to get the information they want on time for
example tendering document.

4. To develop a system that people will be able to know the final results of evaluation in specific
tender.

5. To validate the developed system using historical data.

3
1.5. Methodology and technical

In programming, methodology is defined as an organized documented set of procedures

and guidelines for one or more phases of the software life cycle, such as analysis or design.

The following techniques and methods were used in the e-procurement management system
analysis and design:

 The Unified Process: is a software development process that is use-case driven,

architecture centric, and iterative and incremental. A use-case is similar to a traditional
functional requirements analysis except that every function must provide something of
value to at least one of the users of that use case. A good architecture, on the other hand,
provides a shared vision of various views of models of the system to be developed that
allows development to be proceed, risks to be mitigated, and changes to be made, both
now and in the future. Instead of a once and done strategy, which cannot be done in
practice, the unified process is iterative and incremental.

 The UML is a visual system/language for specifying, developing, visualizing, and

documenting software systems and, as such supports the Unified Process with a large
number of diagrams that are connected together throughout the software development
process.

 Interview: An interview is a conversation between two people (the interviewer and the
interviewee) where questions are asked by the interviewer to obtain information from the
interviewee.

We have used this tool to get the information we needed, for example to get detailed information
about the current tendering system and identify the problems and solutions for the new system.
We got a chance to interview three members among six members who are working in tender
process.
 Documentation: is a method we used to collect data using their profile which contains
tender documents.
4
We considered this tool as the main tool because we got full information about the system in
collecting reports and reading different documents related to tender process.

 Observation: Observation method is a technique in which the behavior of research

subjects is watched and recorded without any direct contact.

This tool gave us a clear picture of the existing system, spending time with them seeing how the
documents are flowing within the current system.

1.6. Scope of the Study

The case study for this research is Musanze district. This research focused on designing and
implementing e-tender, evaluation of bids and awards of contracts of tender.

1.7. Structure of the work

This research work has four chapters. The first chapter gives the general description of the
research; the second chapter will highlight different procurement existing systems and explain
the details of the current system of procurement. The third chapter will show the solutions about
the problems found in the existing system. Also this chapter has full details of methods,
techniques and procedures I am going to follow in order to solve the problems of the existing
system. Chapter four will contain the details of implementation, testing and the software tools I
have used to implement E-procurement management system. Finally, the last chapter has both
the conclusion and recommendation.

5
CHAPTER 2: THE EXISTING SYSTEM ANALYSIS

2.1. Specific terminology

In order to better understand the existing system, we are going to explore the following
definitions of key terms that are used in the current system.

Bid: refers to offer from a bidder

Bidder: means any potential participant or participant in public procurement proceedings.

Bid security: means any guarantee by a bank or other relevant institution to allow the
prospective bidder to participate in tendering.

Contract: means the agreement between the procuring entity and the successful bidder.

Goods: means objects of every kind and description including raw materials, products,
equipment in solid, liquid or gaseous form.

Procuring Entity: means Central Government authority, Local Government authority, public
institution, commission, Government Projector any specialized institution engaged in
procurement process and entering in contract with successful bidder.

Public Procurement: refer to the supplies or goods, work, services they may be needed by a
procuring entity.

Tender Committee: means a committee established by the procuring entity to assist the
Procurement Unit, in the bid opening, evaluation and recommended for award of procurement
contracts.

Tendering Document: means the document containing information required for the preparation
of bids, the award process and tender execution

Services: refers to any services other than consultant services.

6
Successful bidder: means a bidder whose offer has been accepted after being considered the
most competitive both technically and financially.

Works: means all activities related to the realization of building or engineering works upon the
request by the clients

2.2. Thorough analysis of the existing system

2.2.1. The description of Musanze District

Musanze District is one of the 5 Districts of the Northern Province; its capital is Musanze town
which is one of the largest cities in Rwanda.

Musanze district is bordered by Uganda and the Democratic Republic of Congo in the North,
Gakenke district in the South, Burera district in the East, and in the West by Nyabihu district.

Musanze district has 15 sectors which are: Busogo, Cyuve, Gacaca, Gashaki, Gataraga, Kimonyi,
Kinigi, Muhoza, Muko, Musanze, Nkotsi, Nyange, Remera, Rwaza and Shingiro.

The capital city Musanze is located in Muhoza Sector. Musanze city is in the middle of Muhoza
Sector and it acts as the central hub for most businesses of Musanze district, such as trade,
tourism…
In Muhoza, it is where the office of Musanze district is found as well as all the administrative
work concerning the district’s governance. In Musanze city, transactions and business deals only
take place during working hours.

2.2.1.1. The District vision

The District aims at the well-being of its population, by the noticeable reduction of poverty,
through obvious food security and the development of community tourism programs, sustained
by good governance and quality education, centered on science and technology.

7
2.2.1.2. The District mission

The mission of the District is to ensure the socio-economic development of its population
through its active participation in the planning as well as the implementation of programs related
to the promotion of good governance, education for all, agriculture, breeding and environment
protection, trade, basic infrastructures and tourism.

2.2.1.3. District objectives

1. To promote quality education for all, the Rwandese culture and sport.
2. To improve the health conditions of the population, gender and the rights of children.
3. To contribute in a lasting way to the increase of production and the marketing of agricultural
and animal products.
4. To contribute to the improvement of rural and urban infrastructures.
5. To promote the well being of the population by good governance through the strengthening of
collaborating approaches of decentralization and the participation of the population.
6. To improve the quality of human, material and financial management.
7. To ensure the establishment of the government’s policy on good governance, economic
development, state of law and social affairs

2.2.2. Survey of the existing system

The existing system has procedures that must be followed according to the law and regulations
of tender in Rwanda. I spent time at Musanze District analyzing, interviewing users and
observing the way they prepare tenders.

8
Figure 1: Procurement Stage and Activities

During the procurement planning process and the preparation of bidding documents, the
procurement shall ensure that there is sufficient budget allocation.

2.2.2.1. Preparation of bidding documents

The Procurement Unit prepares the bidding documents and incorporates the technical
specifications based on the standard bidding documents. The bidding document is prepared
based on the approved annual procurement plan which provides important details like quantities,
cost estimates, method of procurement etc. Once the bidding document is ready it must be given
to the Tender Committee which will review and provide comments. The bidding document is
then finalized. In accordance with the procurement law, the bidding document should provide the
following information:

1. The specific requirements relating to the goods, works or services being procured and the
time limit for delivery or completion;

9
2. If works are being procured, relevant drawings and bills of quantities;
3. The general and specific conditions governing the contract, if the performance security is
provided;
4. The tender number assigned to the procurement proceedings by the procuring entity;
5. Instructions for the preparation and submission of tenders including:
a. The bid form;
b. The number of copies to be submitted with the original bid;
c. Any bid security required, the form and amount of such security;
d. Any proof evidencing the bidder’s qualifications.
e. A statement of where and when tenders shall be submitted,
f. A statement of where and when the tenders shall be opened;
6. A statement of whether those submitting tenders or their representatives shall be allowed to
attend the tender opening session;
7. A statement of the period during which tenders shall remain valid;
8. The procedures and criteria for bid evaluation and comparison;
9. A statement that the procuring entity may cancel the bids at any time before the signing of
the contract;
10. Anything else as may be provided by the bidding document in accordance with this Law or
public procurement regulations.

Administrative documents required for foreign bidders shall refer to the Laws in force in the
bidders’ home countries.

2.2.2.2. Invitation to tender

The procuring entity shall prepare invitations to tender that sets out the following:

1. The name and address of the procuring entity.

2. The tender number assigned to the procurement proceedings by the procuring entity.
3. A brief description of the works, goods, and services needed including the excepted time
for delivery or completion.
4. An explanation of how to obtain the tender documents, including the amount of any fee.
10
 5. An explanation of where and when tenders must be submitted and where and when
tenders will be opened.
6. A statement that those submitting tenders or their representatives are allowed to attend
the opening of tenders.
7. Currency to be used for bidding and payment of services rendered

2.2.2.3. Advertisement

The procuring entity shall bring the invitation to tender to the attention of those who wish to
submit tenders.

The procuring entity shall advertise the invitation to tender in at least one newspaper of nation-
wide circulation and, if the procuring entity has a website, on its website.

2.2.2.4. Provision of bidding document

The procuring entity shall provide copies of the bidding document in accordance with the
invitation to tender.

The procuring entity may charge a fee for obtaining copies of the bidding document. The
procurement regulations shall establish such fee.

2.2.2.5. Tender security

All tender proceedings conducted under open competitive bidding and restricted bidding shall
request for a bid security.

The procuring entity may determine the form and amount of the tender security. The amount of
tender security shall be a percentage of the bid price or a fixed fee not higher than 2% of the bid
price.

11
2.2.2.6. Submission and receipt of tenders

A tender shall be duly signed and well sealed in an envelope.

The envelope containing the tender must bear the tender number assigned to the procurement
proceedings by the procurement entity.

A tender must be submitted before the deadline of tender submission and any tender received
after that deadline shall be returned unopened.

The procuring entity shall ensure that the place where tenders must be submitted is open and
accessible and shall provide in that place a secure area as safe keeping of received bids.

Every procuring entity shall have a register of received bids in which all bids received are
recorded and a safe place where bids received are kept.

This place may be the office of the procurement unit which must be equipped with a cupboard or
cupboards in which the received bids shall be kept and locked until the opening time when they
will be moved to the opening room.

It shall be the duty of the procurement officer to receive the bids and record them in the register
of received bids.

When a bid is submitted the one delivering it will have his/her name recorded in the register and
shall sign for it.

2.2.2.7. Bids opening

The Tender Committee is responsible for the bids’ opening. However Procurement Unit will co-
ordinate the administration of the bids’ opening to assist the Tender Committee and ensure
smooth operation of the proceedings including taking minutes and to advise on procedural issues
if requested. The bid opening meeting will be chaired by the chairperson of the tender committee
or any member of the tender committee nominated by him or her and attended by at least two
more members of the committee.

12
The Chairman of the bids’ opening session will control and direct the bid opening and shall not
allow anyone to interfere with proceedings. Any objections by a bidder to the procedures or
decisions of the bids’ opening should be made in writing to the procuring entity. For purposes of
transparency bids should be opened in one session and it is not permitted for a bids’ opening
event to be halted or postponed once a bid has been opened.
During bids’ opening:
 Bidders’ representatives should be seated before from the officials of the Procuring
Entity, and names of the organizations represented and contact details of all attendees are
recorded on attendance list.

 Check that the writing on each envelope or sample inside confirms that it is for the
correct bid Stack all envelopes in clear view of the bidders ready for opening. Samples
supplied by bidders shall be stacked separately after checking that the bidder’s name is
clearly identified on each sample provided.

 The Chairperson of the bids’ opening session will outline the procedures to be used for
the Bid Opening.

 Bidders are not permitted to amend their bid or to submit any additional documents, after
registration of their submission.

 Check for any withdrawals or modifications and match with the original bid before
proceeding. Withdrawn bids shall not be opened once the authenticity of the withdrawal
notice has been confirmed.

 Open bids’ envelopes and identify originals and copies including any separate sections
and attachments. Also verify how many copies have been submitted.

 Read out the following details of each bid from the Original copy:

- Any bid modifications or withdrawals;

- The name and country of the bidder;

- A brief description of the goods or services and lot number if applicable;

13
 - The currency of the bid;

- The total bid price;

- Any discounts offered;

- The presence or absence of any required bid security;

- The Chairperson and two members of the committee shall initial the original each bid
and all attachments including any samples provided by the bidder. Any corrections to
prices or obvious errors and omissions shall be initialed.

- Any envelopes containing substitutions, or modifications, must be subject to the same

level of scrutiny, including the reading out of critical details, such as price changes.
- Minutes of the Bids’ Opening shall be prepared by the Procurement Unit, signed by all
members of the tender committee who attended the opening session and made available
to any bidder involved in the bidding who requests a copy in writing.

2.2.2.8. Evaluation of bids

The Tender Committee will undertake the evaluation of received bids and make
recommendations for the award of contract. The bids evaluation must be commenced and
completed as soon as possible after the bid opening and within 21 days prescribed by
procurement regulations and ensure that the award of contract is made within the period of bid
validity.

Under the single envelope bidding system, the Tender Committee will conduct the preliminary
examination of bids, technical evaluation and the financial evaluation in one stage. In
preliminary examination, the bids are evaluated initially by reviewing responsiveness against the
requirements stated in the bidding documents, and bids that are determined not to be
substantially responsive will be rejected.

14
The procuring entity shall evaluate and compare the responsive tenders. The evaluation and
comparison shall be done using the procedures and criteria set out in the bidding documents and
no other criteria shall be used.
The technical evaluation should involve checking physical and chemical characteristics of goods
offered and conformity of samples with the specification (where appropriate). Bids failing the
technical examination are to be rejected.
The following requirements shall apply with respect to the procedures and evaluation criteria:
- The criteria must, to the possible extent, be objective and quantifiable;
- The criteria other than price must be expressed clearly and applied, in accordance with
the procedures, for purposes of determining the lowest evaluated bid.

The financial evaluation of the bids will normally involve the following as specified in the
bidding documents:
 Check the bids for arithmetic errors:
- Where there is a discrepancy between the amounts in figures and in words, the amount in
words will govern;
- Where there is a discrepancy between the unit rate and the line item total resulting from
multiplying the unit rate by the quantity, the unit rate as quoted will govern, unless in the
opinion of the Committee there is an obviously gross misplacement of the decimal point
in the unit rate, in which case the line item total as quoted will govern and the unit rate
will be corrected.
- All corrections made in accordance with the procedure specified in the bidding
document, are considered binding on the bidder.

- Modifications and Discounts: Discounts offered in accordance with the bidding document
that are conditional on the simultaneous award of other contracts or lots in the bidding
documents shall not be evaluated until the completion of all other evaluation steps. Non-
conditional discounts should be included at this stage.
- Currency Conversions: If bids in different currencies are permitted in the bidding
documents, convert the bid prices to the single currency (normally Rwandan Francs) as
stated in the bidding documents:

15
 - The selected source and date for currency exchange rates must be as specified in the
bidding documents.
- The source of exchange rates will normally be the selling rate quoted by the National
Bank of Rwanda (BNR) on the selected date.
- The selected date should not be earlier than four weeks prior to the deadline for the
receipt of bids, or later than the original date for the closing of bids.

Apply the appropriate conversion rate to each corrected bid price to arrive at the evaluation price
in the common currency.

2.2.2.9. Evaluation Award Recommendation

The Tender Committee shall prepare an evaluation report containing a summary of the
evaluation and comparison of bids and recommendation of award of contract to the bidder with
the lowest evaluated bid.
The amount of the recommended contract award is the bid price as submitted by the lowest
evaluated bidder and adjusted as described in the bidding documents for corrections, any
discounts and acceptance of alternative offers from the lowest evaluated responsive bidder.
In brief, the evaluation report should ensure that:
 Justification is provided for any decisions reached by the committee on rejection of
bidders (if necessary provide copies of selected pages from bids) and the
recommendation for award of contract;

 Inconsistencies between prices and modifications to prices read out at bids’ opening are
explained.

 Substantial corrections for arithmetic errors which may affect the ranking of bidders are
explained.

 Any additions, adjustments, and priced deviations that may affect the ranking of bidders
are explained.

16
  Clarification correspondence between the procuring entity and the bidders which result in
major decision by the committee should be attached.

 Any separate evaluation or assessment report from a consultant, if one was engaged for
this purpose is attached.

The tender committee undertaking an evaluation shall be composed of at least 3/5 members.
Decisions of the committee shall be taken unanimously and all members present have to sign the
report.
NB: In case of many successful bidders with equal prices, the procuring entity shall invite them
to submit their new bids with reduced prices. In the event the bidders are again on par, the
procuring entity shall resort to lot casting among those bidders.

2.2.2.10. Notification of contract award

Before the expiry of the bid validity period, the procuring entity shall simultaneously notify the
successful and the unsuccessful bidders of the provisional outcome of the bid evaluation. Every
unsuccessful bidder shall be informed of the main reason(s) why it did not qualify for the award
in the notification letter.

The notification shall specify that the major elements of the procurement process would be made
available to the bidders upon request and that they have seven (7) days in which to lodge a
protest, if any, before a contract is signed with the successful bidder.

The successful bidder shall be required to provide a performance security in accordance with the
procurement regulations. Such security shall not exceed ten per cent (10%) of the contract price.

If the successful bidder fails to enter into a written procurement contract, the procuring entity
may award the tender to the qualified bidder that ranked second. However if the period during
which tenders must remain valid has already expired, then award may not be applicable.

17
2.2.2.11. Publication of Award Results

Upon signature of a procurement contract, the procuring entity shall notify other bidders that
their bids were not successful. The procuring entity shall publish the results of the tender as soon
as the contract is signed. The results so published shall include at least the following: winner of
the tender, amount of the tender awarded and the duration of the contract.

2.3. Problems of existing system

In this existing system that I have explained above, users face different problems:

1. The existing system has a problem of keeping the records separately because of using a file-
based system.

2. Users are using Word or Excel to record companies’ names and personal details, writing one
record many times in different sheets which leads to inconsistency of data. Consequently, users
are facing the problem of getting reports on time because of searching the information related to
one tender in different files.

3. The existing system has many problems associated with it, for instance: it wastes time for
recording the process of tender information.

4. In the existing system, the process of evaluating tenders takes a lot of time to do analysis and
to compare documents as they (users) write down and also remember they have to search for the
documents they want manually.

5. It is hard to get reports on time because they have to type them manually. In other words, each
record they keep is not in the format of reports, and at the time of issuing the report, they have to
type it manually.

18
2.4. Proposed solutions

1. Design a database which is able to keep every transaction related to tender process.

2. The user will be able to generate a report they need on time because every record will be saved
in database.

3. Implement the level of security so that every user will be able to access the information
according to their role in the system.

4. This new system will avoid the duplication of data that leads to consistency of data.

19
CHAPTER 3: ANALYSIS AND DESIGN OF THE NEW SYSTEM

3.1. Introduction

The goal of the system analysis and design phase in development is to refine the project goals
into defined functions and operation of the intended application. System requirements are
documented by using the Unified Modeling Language (UML).

Analysis: is the decomposition of problems into their component parts. In computing it is

understood as the process of specification of system structure and function independently of the
means of implementation or physical decomposition into modules or components. Analysis was
traditionally done top-down using structured analysis, or an equivalent method based on
functional decomposition, combined with separate data analysis.

Design: design is the process of defining the solution. It involves defining the ways in which the
system satisfies each of requirements identified during analysis.

3.2. Analysis and design methodology

Object-oriented analysis and design (OOAD) is a software engineering approach that models a
system as a group of interacting objects. Each object represents some entity of interest in the
system being modeled, and is characterized by its class, its state (data elements), and its
behavior. Various models can be created to show the static structure, dynamic behavior, and run-
time deployment of these collaborating objects. There are a number of different notations for
representing these models, such as the Unified Modeling Language (UML).

Object-oriented analysis and design consist two parts:

1. Object Oriented Analysis (OOA)

Object Oriented Analysis is concerned with developing requirements and specifications

expressed as an object model (population of interacting objects) of a system, as opposed to
the traditional data or functional views.

20
 2. Object Oriented Design (OOD)

Object Oriented Design is concerned with developing object-oriented models of a

software/system to implement the requirements identified during OOA.

There are a number of different notations for representing these models. In this project, the
chosen modeling language is Unified Modeling Language (UML).
UML is a graphical language with sets of rules and semantics. The rules and semantics of a
model expressed in English, in a form known as object constraint language (OCL). OCL is a
specification language that uses simple logic for specifying the properties of a system.

The Unified Modeling Language (UML) is an object-oriented language for specifying,

visualizing, constructing, and documenting the artifacts of software systems, as well as for
business modeling. The UML was developed by Rational Software and its partners. It is the
successor to the modeling languages found in the Booch, OOSE/Jacobson, OMT and other
methods.
The UML, a visual modeling language, is not intended to be a visual programming language.
The UML notation is useful for graphically depicting object oriented analysis and design models.
It not only allows you to specify the requirements of a system and capture the design decisions,
but it also promotes communication among key persons involved in the development effort. The
emphasis in modeling should be on analysis and design, focusing on front-end conceptual issues,
rather than back-end implementation issues, which unnecessarily restrict design choices.

These techniques are using diagramming technique such as use case diagram, sequence diagram,
activity diagram and class diagram. Use case diagram explains about the system, environment
and the association between the system and its environment. Use case diagram is presented
through actors whereby the actors are modeling the processes that involved in the system and to
give a view about overall system functions.

21
Sequence diagram explains the scenario of the use case, the actor actions and the sequences of
the cases. Meanwhile, collaboration diagram presents the interactions which are occurred among
a
objects in the system. Class diagram is a view of classes and objects involved in the system.

3.3. System analysis

System analysis involves the system as an object and considers it for environment use. A system
analysis produces a specification that covers those aspects of a system that are relevant for its
external representation and use.

3.3.1. Requirement analysis

The activity of requirements analysis involves trying to figure out what the users and customers
of a software effort want the system to do. A number of UML techniques can come in handy
here:

3.3.1.1. Use case diagrams

Use case diagrams consist of named pieces of functionality (use

( cases),
), the persons or things
invoking the functionality (actors
actors), and possibly the elements responsible for
or implementing the
use cases (subjects).
 Use cases,, which describe how people interact with the system.
Use cases give you a structured way of capturing the behavioral requirements of a system, so
that you can reasonably create a design from them. They help you to answer some fundamental
questions:
What are the users of the system trying to do? What’s the user experience?
experience

Notation:

22
 Actor: An actor represents any outside entity that interacts with your system. It may request
services from your system; and it may perform services for your system. An actor can be a
person; but it may also be another system, or perhaps a device such as a printer.
 Types of Actors
- Initiator versus participant:
When there is more than one actor in a use case, the one that generates the stimulus is
called the initiator and the others are participants.
- Primary versus secondary:
The actor that directly interacts with the system is called the primary actor, others are
called secondary actors.

Notation:
 Relationships:
- Between Actors and Use Cases (communicates):
(communicates): This relationship shows participation
of an actor in a use case, and is the only relationship between actors and use cases.

- Between Use Cases:: here there is two type of relationship extends and uses.

Extends: An extend relationship from one use case to another indicates that an instance of
another use case may includee the behavior of use case one. This shows as a generalization arrow
from the use case providing the extension to the base use case. The arrow is labeled with the
stereotype <<extends>>.

Uses: A uses relationship from one use case to another indicates that an instance of the use case
one will also include the behavior specified by another use case. This shows as a generalization
arrow from the use case doing the use case to the use case being used. The arrow is labeled with
the stereotype<<uses>>.

- Between Actors:: a user may act as one or several actors as it interacts with the system,
while several individual users may act as different instances of one and the same actor.

23
  System Boundary: It is shown as a rectangle. It helps to identify what is an external
verse internal, and what the responsibilities of the system are. The external environment
is represented only by actors.

In this section requirements analysis of the e-Procurement management system are to be

explained regarding a component of the system namely e-Tendering. These requirements have
been identified in order to form a basis for the succeeding software development phases. The
requirements, which have requirement traceability number, are implemented in the scope of this
study.

Since the object oriented analysis and design methodology is used in this thesis, functional
requirements are presented in terms of use cases.
The detailed descriptions of these use cases represent the requirements of the system. Use cases
for e-procurement management system are presented in the both figure 2 and figure 3.

24
Figure 2: Procuring entity and committee member Use cases diagram

25
 E-Procurement Management System

View announcement

Download Tender
Document

View black list

and winner

Bidders/Public

Figure 3: public and bidders Use case diagram.

Use Case Description
There are twenty two use cases in this system and every use case has its use case description.
1. Use Case Description for Login
Use case name : Login System
ID : 1
Primary Actor: Committee member, Administrator.
Secondary Actor: Procuring entity.
Preconditions:
Flow of event
1. The users insert their username and password.
2. If their username and password has been recorded in database,
the user can access the system; else the user can not use the system.
Post conditions:
1.The users login in the system

26
2. Use Case Description for Logout

Use case name : Logout System

ID : 2
Primary Actor: Committee member, Administrator.
Secondary Actor: Procuring entity.
Preconditions: A valid procuring entity logged on to the system
Flow of event
1. After finishing access the system, the users will logout the
system.
It is more for the security.
2. After Log out, the user back to main menu.
Post conditions:

3. Use Case Description for Create Tender

Use case name : Create tender

ID : 3
Primary Actor: Procuring entity, Administrator.
Preconditions: A valid procuring entity logged on to the system
Flow of event
1. After finishing access the system, the users will logout the
system.
It is more for the security.
2. After Log out, the user back to main menu.
Post conditions:

27
4. Use Case Description for Upload Tender

Use case name : Upload Tender document

ID : 4
Primary Actor: Procuring entity, Administrator.
Preconditions: A valid procuring entity logged on to the system
Flow of event
1. Choose Upload tender menu
2. Browse where tender document is saved and upload it.

Post conditions:

5. Use Case Description for Create Invitation

Use case name : create invitation

ID : 5
Primary Actor: Procuring entity, Administrator.
Preconditions: A valid procuring entity logged on to the system
Flow of event
1. Choose create invitation menu
2. Fill all invitation information
3. Save and publish invitation information
Post conditions:

28
6. Use Case Description for Add criteria for tender

Use case name : Add criteria to tender

ID : 6
Primary Actor: Procuring entity, Administrator.
Preconditions: A valid procuring entity logged on to the system
Flow of event
1. Choose add criteria menu
2. Fill all criteria information according to tender document
3. Save all criteria information
Post conditions:

7. Use Case Description for Add Bidders

Use case name : Add bidders

ID : 7
Primary Actor: Procuring entity, Administrator.
Preconditions: A valid procuring entity logged on to the system
Flow of event
1. Choose opening tender document menu
2. Fill all information for bidder and representative person
3. Save all information
Post conditions:

29
8. Use Case Description for Add a member to evaluation committee

Use case name : Add a member to evaluation committee

ID : 8
Primary Actor: Procuring entity, Administrator.
Preconditions: A valid procuring entity logged on to the system
Flow of event
1. Choose add committee menu
2. Fill names for committee
3. Save
Post conditions:

9. Use Case Description for publishing blacklist and winner

Use case name: publish blacklist and winner

ID : 9
Primary Actor: Procuring entity, Administrator.
Preconditions: A valid procuring entity logged on to the system
Flow of event
1.Procuring entity create a report of all bidders and who are fail in
evaluation and who is win and publish it.
Post conditions:

30
10. Use Case Description for Create and send notification

Use case name: Create and send notification

ID : 10
Primary Actor: Procuring entity, Administrator.
Preconditions: A valid procuring entity logged on to the system
Flow of event
1.Choose create and send notification menu
2.Create all notification and send it to all bidders
Post conditions:

11. Use Case Description for Prepare Contract

Use case name: Prepare Contract

ID : 11
Primary Actor: Procuring entity, Administrator.
Preconditions: A valid procuring entity logged on to the system
Flow of event
1. Choose create contract menu.
2. Create contract for awarded bidder.
Post conditions:

31
12. Use Case Description for evaluation to tender

Use case name: Evaluation to tender

ID : 12
Primary Actor: Committee member.
Preconditions: A valid procuring entity logged on to the system
Flow of event
1. Choose evaluation menu.
2. Evaluate every bidder.
Post conditions:

13. Use Case Description for create users

Use case name: Create users

ID : 13
Primary Actor: Administrator.
Preconditions: A valid procuring entity logged on to the system
Flow of event
1. Choose Create users menu.
2. Fill all information related to user and save it.
Post conditions:

32
14. Use Case Description for Backup

Use case name: Backup

ID : 14
Primary Actor: Administrator.
Preconditions: A valid administrator logged on to the system
Flow of event
1. Choose backup menu.
2. Make backup for all information in tender process.
Post conditions:

15. Use Case Description for download tender document

Use case name: Download tender

ID : 15
Primary Actor: Public, bidder.
Preconditions
Flow of event
1. From main page.
2. Choose download tender menu.
3. Download tender document.
Post conditions:

33
16. Use Case Description for view announcement

Use case name: View announcement

ID : 16
Primary Actor: Public, bidder.
Preconditions
Flow of event
1. From main page
2. Choose view announcement menu
3. Click on announcement you need.

Post conditions:

17. Use Case Description for view blacklist and winner

Use case name: View blacklist and winner

ID : 17
Primary Actor: Public, bidder.
Preconditions
Flow of event
1. From main page
2. Choose view blacklist and winner menu
3. All bidders displayed

Post conditions:

34
3.3.2. Domain analysis

The main objective of domain object modeling is to improve understanding and communication
by rigorously describing how concepts and phenomena in the domain are related. This is done by
defining objects and classes that represent the domain phenomena and concepts.

3.3.2.1. A class diagram

A class diagram describes the types of objects in the system and the various kinds of static
relationships that exist among them. Class diagrams also show the properties and operations of a
class and the constraints that apply to the way objects are connected. The UML uses the term
feature as a general term that covers properties and operations of a class.
A class represents the operations and attributes of one or more objects within your system.
An attribute: is a characteristic that describes objects of the class.
An operation: describes something an object of the class can do.
Notation:

In UML, a class appears as a rectangle broken into three sections. The top section identifies the
name of the class, the middle section lists the attributes of the class, and the bottom section lists
the operations of the class.

A relationship is a connection among things. The three most important relationships are:

Dependency is a relationship between two elements where a change to one element (the
supplier) may affect or supply information needed by the other element (the client).
We use dependencies to model relationships between classifiers where one classifier depends on
the other in some way, but the relationship is not really an association.

35
  Generalization is a process of organizing the features of different kinds of objects that
share the same purpose.

 Association is a structural relationship that specifies that objects of one thing are
connected to objects of another.

 Aggregation is a plain association between two classes represents a structural

relationship between peers, meaning that both classes are conceptually at the same level,
no one more important than the other.

 Composition is a form of aggregation, with strong ownership and coincident lifetime as

part of the whole.

Multiplicity: constrains the number of objects of a class that can be involved in a particular
relationship at any point in time.

36
Figure 4: Class diagram for e-procurement management system

37
3.4. System design

System Design is the transformation of analysis models of the problem space into design models
(based on the solution space).
It involves selecting strategies for building the system e.g. software/hardware platform on which
the system will run and the persistent data strategy.

3.4.1. Architecture design

Architecture is a set of significant decisions about the organization of a software system. Such
decisions include:
1. The selection of structural elements and their interfaces.
2. The composition of this structural and behavioral element into progressively larger subsystem.
3. The architectural style that guides this organization, the elements and their interfaces, their
collaboration and composition.

This system will be built in a web based environment to allow users to access the system
anywhere and anytime. The identified main users are committee members, procuring entity,
bidders and administrator. The users have different roles when using the system and they will be
connected to the database by interface. This interface will make the process of system user’s
activities easier and practical.

38
Figure 5: System architecture for E-procurement management system

3.4.2. Mechanistic design

3.4.2.1. Sequence diagram

Sequence diagram shows simple interactions between objects arranged in a time sequence. It
shows the objects with their lifeline and the exchange of messages between objects. If may also
show the creation of new objects.
The sequence diagram shows if the object is activated with a rectangular lifeline. When an object
is not active, just existing, and cannot be activated again.

39
The lifeline can be split into two or more concurrent lifelines. Each lifeline corresponds to a
conditional branch in the message flow. The separate lifeline can merge together at some later
point in time.
Along the time axis timing marks can be specified. These timing marks can be used to give
constraints, like specify the maximum time a message exchange may take.

1. Sequence diagram for create users

:WebBrowser :WebServer :epms autorization server epms database

Administrator
Click on login link Request login page

Display login page Send login page

Fill out login form and click on login

validate form

Submit login form Authenticate Request Data

Display menu page Send menu page Authenticate Return Data

Choose and click on create user link Request user form

Display user form Send user form

Fill out user form and click save

Validate user form
Submit user form Authenticate Create user

Display message Send message Authenticate Send action message

Figure 6: Sequence diagram for creating users

40
 2. Sequence diagram for create tender document

Figure 7: Sequence diagram for creating tender document

41
 3. Sequence diagram for create invitation to tender

Figure 8: Sequence diagram for creating invitation to tender

42
 4. Sequence diagram for submit bids

Figure 9: Sequence diagram for submit bids

43
Sequence diagram for evaluation bids

Figure 10: Sequence diagram for evaluation bids

44
 6. Sequence diagram for opening bids

Figure 11: Sequence diagram for opening bids

3.4.3. Detailed design

3.4.3.1. Activity diagrams

Activity diagrams are a technique to describe procedural logic, business process, and work flow.
In many ways, they play a role similar to flowcharts, but the principal difference between them
and flowchart notation is that they support parallel behavior.

45
The elements of activity diagram:

- Start state: signals the beginning of the activity diagram.

Notation:

- End state: signals the end of the activity diagram.

Notation:

- Action State: shorthand for a state with an entry action and at least one outgoing
transition involving the implicit event of completing the entry action.
Action expression is placed in the action state symbol.

Notation:

- Fork: used for modeling concurrency and synchronization in business processes uses a
synchronization bar.
Fork represents the splitting of a single flow of control into two or more concurrent flows of
controls and indicates that activities of each of these flows are truly concurrent when deployed
across multiple nodes or sequentially interleaved if deployed on a single node.

Notation:

46
 - Decisions: Decisions are expressed as guard conditions.
Different guards are used to indicate different possible transitions that depend on Boolean
conditions of the owning objects. The predefined guard else may be defined for at most one
outgoing transition which is enabled if all the guards labeling the other transitions are false.

Notation:
act Inv itation to tender
Procuring entity

Create public inv itation to Publish inv itation to

tender tender

Refer to inv itation to

tender
Bidder

Figure 12: Activity diagram for invitation to tender

47
 act Uplaod and dow nload tender

Procuring Entity

Create Tender Upload Tender

Bidders/Public

Dow nload
Tender

Figure 13: Activity Diagram for download tender

act Ev aluation and send notifications

Tender committee

Open all bids Ev aluate bids

documents documents

Publish blacklist and

Procuring entity

w inner
Create repport and
notifications

Send notifications to all

bidders

View Blacklist ande Receiv e Tender

Bidders/public

w inner notifications

Figure 14: Activity Diagram for Evaluation and send notifications

48
3.4.3.2. Database schema diagram

The database, stored in the server-side, has been created to Store the information required for the
proposed application.
Description of the database tables is given below.

49
Figure 15: Database schema for E-procurement management system

50
Database Summary

This section presents a list of all tables in the database.

A short description of each table is also provided. This list along with the database schema
overview is meant to be the main point of reference, when explaining the function of each
element in the database.
Number of tables: 17
Number of columns: 100
Number of primary keys: 17
Number of foreign keys: 14

Table 1: Users table details

Columns Constraints Data type Size Description
UserID Primary key Number 4 Uniquely identify User
FirstName Text 20 First name of user
LastName Text 20 Last name of user
Password Text 20 Password of user
E-mail Text 20 e-mail of User
PhoneNumber Number 10 Mobile telephone numbers of user
Role Text 15 Role of user

51
Table 2: Tendering document details
Columns Constraints Data type Size Description
TenderID Primary key Text 20 Uniquely identify Tender
TenderTitle Text 50 Title of tendering document
TenderCategory Text 10 Category of tender document
TenderDescription Text 50 Description of tender
NumberOfLots Number 4 Number of lots of tender
DateCreated Date Date record was created
TentativeDateOfPublication Date Date of tentative of publication
TenderSubmissionDate Date Date of beginning to submit bids
DeadlineOfSubmission Date Deadline of submitting bids
ClosingTimeForSubmission Date Last time of submitting bids
VisitingDate Date Visiting date of tender
OpeningDateForBids Date Date for opening bids
PlanedDateForExecution Date Planning date for execution
TenderStatus Text 20 Status for tender
Filename Text 20 Name of file for tender
FilePath Text 20 Path where tender is stored
DateUploaded Date Date for uploaded tender
ProcedureID Foreign key Number 4 Identify procedure
ResourceID Foreign key Number 4 Identify Resource

Table 3: Resources details

Columns Constraints Data type Size Descriptions
ResourceID Primary key Number 4 Uniquely identify resource
ResourceName Text 20 Name of resource

52
Table 4: Procedures details
Columns Constraints Data type Size Descriptions
ProcedureID Primary key Number 4 Uniquely identify procedure
ProcedureMethod Text 20 Method used in tendering process
ProcedureExplanation Text 20 Explanation of procedure

Table 5: Publications details

Columns Constraints Data type Size Descriptions
PublicationID Primary key Number 4 Uniquely identify publication
ReferenceName Text 50 Name of journal
PublicationDate Date/Time Date of publication for tender
TenderID Foreign key Number 4 Identify for tender document

Table 6: Invitations details

Columns Constraints Data type Size Descriptions
InvitationID Primary key Number 4 Uniquely identify invitation
InvitationDate Date/Time Date of invitation to tender
InvitationTitle Text 50 Title of invitation for tender
InvitationDescription Text 500 Description of invitation
TenderID Foreign key Number Identify for tender document

Table 7: Lots details

Columns Constraints Data type Size Descriptions
LotID Primary key Number 4 Uniquely identify lot
LotName Text 50 Name of lot
LotDescription Text 300 Description of lot
LotSecurity Number 9 Security of lot
TenderID Foreign key Number 4 Identify for tender document

53
Table 8: EvaluationCriteria
Columns Constraints Data type Size Descriptions
criteriaID Primary key Number 4 Uniquely identify evaluation criteria
CriteriaName Text 50 Name of criteria
CriteriaCategory Text 20 Category of criteria
CriteriaWeight Number 3 Weight of criteria
LotID Foreign Key Number Identify for lot

Table 9: Companies details

Columns Constraints Data type Size Descriptions
CompanyID Primary key Number 4 Uniquely identify company
CompanyName Text 20 Name of company(bidder)
TinNumber Text 20 Tin number of company
PhoneNumber Number 10 Telephone of company
E-mail Text 20 E-mail of company
BoxOffice Text 15 Office box of company

Table 10: RepresentativePersons details

Columns Constraints Data type Size Descriptions
personID Primary key Number 4 Uniquely identify person
FirstName Text 20 First Name of person
LastName Text 20 Last Name of person
PhoneNumber Number 10 Telephone of person
E-mail Text 20 E-mail of person
CompanyID Foreign key Number 4 Identify of company

54
Table 11: Bids details
Columns Constraints Data type Size Descriptions
bidID Primary key Number 4 Uniquely identify bid
NumberOfEnvelopes Number 2 Number of envelopes
DateReceived Date Date of receive bid
LotID Foreign key Number 4 Identify of lot
CompanyID Foreign key Number 4 Identify of company

Table 12: OpeningCriteria details

Columns Constraints Data type Size Descriptions
OpeningID Primary key Number 4 Uniquely identify opening bid
PriceWithoutTaxes Number 10 Price of tender without taxes
PriceWithTaxes Number 10 Price of tender with all taxes
ExecutionPeriod Date Period of execution
AmountOfSecurity Number 10 Amount of security of tender
openingDate Date Date of opening bids
BidID Foreign key Number 4 Identify bid

Table 13: PreliminaryEvaluations details

Columns Constraints Data type Size Descriptions
PreliminaryID Primary key Number 4 Uniquely identify Preliminary evaluation
CriteriaName Text 20 Criteria name of evaluation
Answer Text 50 Answer of evaluation
Weight Number 4 Weight of evaluation
Score Number 4 Score of evaluation
category Text 20 Category of evaluation
BidID Number 4 Identify bids

55
Table 14: FinancialEvaluations details
Columns Constraints Data type Size Descriptions
FinancialID Primary key Number 4 Uniquely identify Financial result
AmountBeforeError Number 10 Amount of calculation of before error
AmountAfterError Number 10 Amount of calculation of after error
BidID Foreign key Number 4 Identify bid

Table 15: Reports details

Columns Constraints Data type Size Descriptions
reportID Primary key Number 4 Uniquely identify of report
Category Text 20 Decision of evaluation
Status Text 20 Status of evaluation
Decision Text 20 Decision of evaluation
Date Date Date of evaluation
BidID Foreign key Number 4 Identify bid

Table 16: AwardContract details

Columns Constraints Data type Size Descriptions
ContractID Primary key Number 4 Uniquely identify contract
DateCreated Date Date created
DateStartingContract Date 20 Date of starting contract
ContractAmount Number 10 Amount of contract for tender
ExecutionPeriod Text 100 Execution period for tender
DeadlineForCompletion Date Deadline of execution for tender
CompanyNameForWinner Text 20 Name of bidder
LotID Foreign key Number 4 Identify lot

56
Table 17: CommitteeMembers details
Columns Constraints Data type Size Descriptions
CommitteeID Primary key Number 4 Uniquely identify committee members
CommitteeFirstname Text 20 First Name of committee member
CommitteLastname Text 20 Last Name of committee member
Role Text 20 Role of committee member
UserID Foreign key Number 4 Identify user
tenderID Foreign key Number 4 Identify tender

57
CHAPTER 4: NEW SYSTEM IMPLEMENTATION AND TESTING

4.1. Introduction

In this chapter, will describe more about the result from design phase whereas it is used as an
input for the implementation and testing process before implement the new system, must
complete the detail planning to ensure the developed system can be functioning well and
complete. The end result which is e-Procurement Management System will undergo certain
implementation steps which will be explained in the following part.

4.2. Languages and tools used for the system implementation

To develop e-Procurement Management System, we used the following tools:

- Microsoft Visual C#.Net 2008;

- Microsoft SQL Server 2005;
- Crystal Reports for Visual Studio .NET;
- Ozeki Message Server 6

4.2.1. Microsoft Visual C#.Net 2008

Microsoft Visual Studio is an integrated development environment (IDE) from Microsoft. It is

used to develop console and graphical user interface applications along with Windows Forms
applications, web sites, web applications, and web services in both native code together with
managed code for all platforms supported by Microsoft Windows and Windows Mobile.

Visual Studio includes a code editor supporting IntelliSense as well as code refactoring. The
integrated debugger works both as a source-level debugger and a machine-level debugger. Other
built-in tools include a forms designer for building GUI applications, web designer, class
designer, and database schema designer.

58
Visual Studio supports different programming languages by means of language services, which
allow the code editor and debugger to support nearly any programming language, provided a
language-specific service exists. Built-in languages include C/C++ (via Visual C++), VB.NET
(via Visual Basic .NET) and C# (via Visual C#).

4.2.2. Microsoft SQL Server 2005

Microsoft SQL Server is a relational database server, developed by Microsoft: it is a software

product whose primary function is to store and retrieve data as requested by other software
applications, be it those on the same computer or those running on another computer across a
network (including the Internet).

SQL Server 2005 released in October 2005, is the successor to SQL Server 2000. It included
native support for managing XML data, in addition to relational data. For this purpose, it defined
an xml data type that could be used either as a data type in database columns or as literals in
queries.

XML is converted to an internal binary data type before being stored in the database. Specialized
indexing methods were made available for XML data. XML data is queried using XQuery;
Common Language Runtime (CLR) integration was a main feature with this edition, enabling
one to write SQL code as Managed Code by the CLR. SQL Server 2005 added some extensions
to the T-SQL language to allow embedding XQuery queries in T-SQL. In addition, it also
defines a new extension to XQuery, called XML DML that allows query-based modifications to
XML data.

A database is typically a group that includes at least a set of table objects and, more often than
not, other objects, such as stored procedures and views that pertain to the particular grouping of
data stored in the database’s tables.

59
4.2.3. Crystal Reports for Visual Studio .NET

Crystal Reports has enjoyed a long association with Microsoft and has shipped with Visual
Studio as the default report writer since 1993.
In simplest terms, Crystal Reports is a report design tool that allows you to create reports that can
retrieve and format a result set from a database or other data source.

In addition to a powerful toolset for actually creating reports, Crystal Reports also features a
number of APIs and tools specifically created for developers to allow them to integrate these
reports into their own applications.

To start with, Crystal Reports.NET includes an integrated Report Designer available within the
Visual Studio IDE that you can use to create report files (.rpt) to integrate with your application.

Once you have a basic report designed, you can then add features like formula fields, running
totals, graphs, and so on to make your report design as complex as required. Reports come in all
shapes, sizes and forms.

After you have created a report, you need some way to display this report from your application,
and Crystal Reports.NET has two different viewers to make this happen.
- The Windows Forms Viewer can be used with windows applications to preview any
reports you have integrated into your application and feature a rich object model that
allows you to control the appearance of the viewer and some aspects of the report at run
time.
- For web-based application, there is also a Web Forms Viewer that has similar
functionality and allows you to view reports you have integrated into your web
applications.

60
4.2.4. ASP.NET 3.5

ASP.NET is a unified Web development model that includes the services necessary for you to
build enterprise-class Web applications with a minimum of coding. ASP.NET is part of the .NET
Framework, and when coding ASP.NET applications you have access to classes in the .NET
Framework. You can code your applications in any language compatible with the common
language runtime (CLR), including Microsoft Visual Basic, C#, JScript .NET, and J#. These
languages enable you to develop ASP.NET applications that benefit from the common language
runtime, type safety, inheritance, and so on.

I’ve chosen Visual C#.Net 2008 for this project. It’s easy to use, it’s also the most popular
computer language ever created.
Visual C#.Net 2008, pronounced C sharp, is a programming language designed for building a
wide range of applications that run on the .NET Framework. It is a new object oriented language
from Microsoft. It is a major part of the Visual Studio .NET development environment.

4.2.5. Ozeki Message Server 6

Ozeki Message Server 6 is a powerful, flexible SMS Gateway application that enables you and
your applications to send/receive SMS messages to mobile devices with your computer. It has an
easy-to-use user interface, and an excellent internal architecture. The application can use a GSM
mobile phone attached to the PC with a phone-to-PC data cable or IP SMS technology to
transmit and receive the messages.

4.3. Software Testing and Results

4.3.1. Testing Methodology, Tools and techniques

Software testing is a process of verifying and validating that a software application or program
meets the business and technical requirements that guided its design and development, and works
as expected.

61
Software testing has three main purposes: verification, validation, and defect finding.

- The verification process confirms that the software meets its technical specifications.
A specification is a description of a function in terms of a measurable output value given
a specific input value under specific preconditions.

- Validation is the process of evaluating a system or component during or at the end of the
development process to determine whether it satisfies specified requirements.

- A defect is a variance between the expected and actual result. The defect’s ultimate
source may be traced to a fault introduced in the specification, design, or development
(coding) phases.

There are two basic techniques of software testing: black box testing and white box testing.

 Black box testing (also called functional testing) is testing that ignores the internal
mechanism of a system or component and focuses solely on the outputs generated in
response to selected inputs and execution conditions.

 White box testing (also called structural testing and glass box testing) is testing that
takes into account the internal mechanism of a system or component.

With black box testing, the software tester does not (or should not) have access to the source
code itself. The code is considered to be a “big black box” to the tester who can’t see inside the
box. The tester knows only that information can be input into to the black box, and the black box
will send something back out. Based on the requirements knowledge, the tester knows what to
expect the black box to send out and tests to make sure the black box sends out what it’s
supposed to send out. Alternatively, white box testing focuses on the internal structure of the
software code. The white box tester (most often the developer of the code) knows what the code
looks like and writes test cases by executing methods with certain parameters.

62
4.3.2. Unit Testing Results

Unit testing is the testing of individual hardware or software units or groups of related units.
Using white box testing techniques, the developers creating the code implementation verify that
the code does what it is intended to do at a very low structural level.

4.3.3. Integration Testing Results

Integration test is testing in which software components, hardware components, or both are
combined and tested to evaluate the interaction between them.
The purpose of this testing is to verify application works with other applications. This means, an
output from one module can be used as an input for other module.
For example when testing a web interface, this means testing for compatibility with different
browsers and connection speeds.

4.3.4. User Acceptance Test Results

After functional and system testing, the product is delivered to a customer and the customer runs
black box acceptance tests based on their expectations of the functionality.
Acceptance testing is formal testing conducted to determine whether or not a system satisfies its
acceptance criteria (the criteria the system must satisfy to be accepted by a customer) and to
enable the customer to determine whether or not to accept the system.

63
4.3.5. E-PMS graphical interfaces

In this section the detailed of E-PMS is represented with sample views from tendering activity
conducted by using the system. The detailed description of the functionality provided through
these user interfaces.

Figure 16: Home page

Figure 16 shows the starting point of E-PMS. This screen has 4 main functions namely
“Announcement” for public to get information, “Download tenders” for public to get tender
document online, “View tender result” for bidders to get the final result of evaluation and
”Login” for users to log into the system.

64
Figure 17: Download tender document

Figure 17 shows how the public and bidders can download tender document by clicking on file
name for tender document.

Figure 18: Login page

65
Figure 18 above shows the login page of E-PMS. Each user of the system must be authenticated
to access system resources.
This aspect takes into consideration the system security and information integrity.
Depending on the rights held, one can login as Administrator, Procuring Entity or Committee
member.
After selecting role of user and typing username and password, the system will display main
menu of each user according to its right.

Figure 19: Administrator menu

Figure 19 show main menu for administrator at this level it is assumed that an administrator is
the person with super rights to manage the system resources like the knowledge engineers.

66
Figure 20: Evaluation form

Committee members log into the system and execute the evaluation task by selecting answers
according to criteria description as shown in figure 20 above.

67
CHAPTER 5: CONCLUSION AND RECOMMENDATION

5.1. Conclusion

Based on the findings from the study, the following conclusions were drawn.
E-Procurement Management System can improve the procurement process significantly. It can
help in terms of having an easy access on data, easy storage of data and in the evaluation process
in the procuring unit of the Musanze district. The project improves the quality of existing
operations in Procurement system in Musanze District. It is considered to be successful with the
objectives met and with the new system working as it should be.

5.2. Recommendation

Recommend to Musanze District the scope of study to use this system in order to improve their
services. The people with similar objectives are encouraged to provide future enhancement of the
system. This will allow making adjustments to increase the efficiency of the system, for example
to facilitate the procurement unit to keep the bidders’ details and evaluate accuracy of the
bidders’ submissions.

68
REFERENCES

1. Bibliography

Dan, P., Neil, P. (2005).UML 2.0 in a Nutshell, O'Reilly, the United States of America.

Doug, R., Matt, S. (2007).Use Case Driven Object Modeling with UML: Theory and Practice,
Apress, the United States of America.

Jim, A., Ila, N. (2002).UML and the Unified Process Practical object-oriented analysis and
design, Pearson Education, Great Britain.

Mukwende, P. (2011).Course of Software Engineering, Adventist University of Central Africa,

Kigali, Rwanda.

Mathieu, M., Adam, F., Mario, S. (2010).Pro ASP.NET 4 in C# 2010, Apress, the United States
of America.

Nsegiyumva, S., Kayoranga, R. E. (2007).Module de formation sur les procedures de passion

des marches publics, RPPA, Kigali, Rwanda.

Official Gazette of the Republic of Rwanda (2007). Law on Public Procurement.

Sebahashyi, N. A.(2011).Cours de Methodologies de conception de système d’information,

Adventist University of Central Africa, Kigali, Rwanda.

2. Websites

http://www.musanze.gov.rw

http://www.wikipedia.com

http://www.google.com

http://www.msdn.microsoft.com

69
70