Dilla University

College of Engineering and Technology

School of Computing and Informatics
Department of Computer Science

Project Title: Web Based Agro-Farming Management System for SNNPR,

Gedeo Zone

Group Members

Student full name ID Number

Kushabo Kurawo.......................................................…RCSC-1575/17

Mulualem Wondim….................................................RCSC-8795/17

Hailemariyam Mengstie….........................................RCSC-4750/17

Maereg Hailu..............................................................RCSC-4499/17

Salegeta Ambachew....................................................RCSC-1580/17

Advisor Name: Girmaye Teklay

Date_____-Signature__________

Dilla, Ethiopia
January 2021
 ABSTRACT
In SNNPRS, Gedeo zone a large section of people works in the agriculture sector. The remaining
is also directly dependent on the field. This is because from agriculture, we get various raw
materials, especially food crops, which serve as prerequisites for food. As the sector is basic for
the Zone, the region as well for our country’s economy, we need to give much attention and we
need to apply some modern technologies to improve our country’s economy. This team
develops a web-based system titled “Agro Farming Management System” in order to facilitate
the information sharing between agro offices.

Our project documentation is comprises of four chapters. Chapter one, which is the introduction
part, is mainly about statements of the problem, objectives, methodology and scope of the
project. The second chapter focuses on the description of existing system. The requirement
specification of the project by including different subtitles like functional and non-functional
requirements, system model, use case diagrams with brief description, sequence diagrams and
activity diagrams are the major focus area of chapter three. The last chapter is mainly about
system design which includes purpose and goals of design, deployment and component
diagrams, subsystem decomposition and user interface design.

i
 ACKNOWLEDGMENT

First of all, we would like to thank our God keeping us healthy. Secondly, we would like to express our
special thanks to our advisor Mr. Girmaye Teklay for the valuable guidance and advice he gave us. We
also would like give thank for the SNNPRS Region Pastoral and Agro pastoral Research Institute
(RPARI) head Mr.Ali Bashe and SNNPRS Crop Protection Expert Mr. Wolde Berta and other staff
member of the office. They give us very important information and idea with much respect that helped
us in doing our project to know about so many new things we are really thankful to them. Our thanks
and appreciations also go to department of computer science and anyone who willingly helped us in
developing this project. Finally, we would also like to thank our family and friends who helped us a lot
in finalizing this project within the limited time frame.

ii
 TABLE OF CONTENTS

Contents
ABSTRACT.................................................................................................................................................................... i
ACKNOWLEDGMENT..................................................................................................................................................ii
LIST OF ABBREVIATION..............................................................................................................................................vi
LIST OF TABLES..........................................................................................................................................................vii
TABLE OF FIGURE......................................................................................................................................................vii
CHAPTER ONE.............................................................................................................................................................1
1.INTRODUCTION.......................................................................................................................................................1
1.1Background of the Organization........................................................................................................................1
1.2. Statement of the Problem...............................................................................................................................2
1.3. Objectives of the Project.................................................................................................................................2
1.3.1. General Objective.....................................................................................................................................2
1.3.2. Specific Objective.....................................................................................................................................2
1.4. Scope of the Project.........................................................................................................................................3
1.5. Limitation of the Project..................................................................................................................................3
1.6. Methodology of the Project.............................................................................................................................3
1.6.1 data gathering methodology.......................................................................................................................3
1.6.2. Systems Analysis and Design...................................................................................................................4
1.7. Significance of the Project...............................................................................................................................4
1.8. Risk Assessment and Management.................................................................................................................5
1.9. Operating Environment...................................................................................................................................5
1.9.1. Hardware Tools........................................................................................................................................5
1.9.2. Software Tools..........................................................................................................................................6
1.10. Feasibility Analysis.........................................................................................................................................6
1.10.1. Technical Feasibility...............................................................................................................................6
1.10.2. Operational Feasibility............................................................................................................................6
1.10.3. Legal Feasibility.....................................................................................................................................7
1.10.4. Economic Feasibility..............................................................................................................................7
1.11. Project Time Schedule and Cost Estimation...................................................................................................7
1.12.Team Composition..........................................................................................................................................9
1.13. Document Organization...............................................................................................................................11

iii
CHAPTER TWO..........................................................................................................................................................13
1. DESCRIPTION OF THE EXISTING SYSTEM...................................................................................................13
2.1. Introduction...................................................................................................................................................13
2.2. Main Activates in the Existing System...........................................................................................................14
2.3. Functions of the Existing System...................................................................................................................14
2.4. Players in the Existing System........................................................................................................................15
2.5. Report Generated in the Existing System......................................................................................................15
2.6. Forms and Other Documents of the Existing Systems...................................................................................15
2.7. Weakness of the Existing System...................................................................................................................15
2.8. Strength of the Existing System.....................................................................................................................16
2.9. Alternative Solutions.....................................................................................................................................17
CHAPTER THREE.......................................................................................................................................................15
2. REQUIREMENT SPECIFICATION AND ANALYSIS.........................................................................................15
3.1. Introduction...................................................................................................................................................15
3.1.1. Purpose...................................................................................................................................................15
3.1.2. Intended Audience and Reading Suggestions.........................................................................................15
3.1.3. Document Convention............................................................................................................................16
3.2. Objectives......................................................................................................................................................16
3.3. Functional Requirements...............................................................................................................................16
3.4. Product Perspective.......................................................................................................................................17
3.5. Product Functions..........................................................................................................................................17
3.6. Principal Actors..............................................................................................................................................18
3.7. User characteristics.......................................................................................................................................18
3.8. General constraints.......................................................................................................................................19
3.9. Assumptions and Dependencies....................................................................................................................19
3.10. Non Functional Requirements.....................................................................................................................20
3.11. System models.............................................................................................................................................21
3.11.1. Use Case Diagram................................................................................................................................21
3.11.2. Use Case Descriptions..........................................................................................................................24
3.11.3 Sequence Diagram.................................................................................................................................36
3.11.4. Class Diagram (Conceptual Modeling).................................................................................................48
3.11.5. Activity Diagram..................................................................................................................................49
CHAPTER FOUR.........................................................................................................................................................56

iv
3. SYSTEM DESIGN........................................................................................................................................56
4.1. Introduction to System Design......................................................................................................................56
4.2. Goals of System Design..................................................................................................................................56
4.2.1. Performance Criteria...............................................................................................................................58
4.2.2 Maintenance Criteria................................................................................................................................58
4.2.3. End User Criteria....................................................................................................................................58
4.3. System Architecture......................................................................................................................................58
4.4. Subsystem Decomposition............................................................................................................................61
4.5. Component Modeling....................................................................................................................................62
4.6. Deployment Modeling...................................................................................................................................63
4.7. Persistence Data Management......................................................................................................................65
4.8. Access Control and Security...........................................................................................................................65
4.8.1. Boundary condition.................................................................................................................................54
4.8.2. Exception handling.................................................................................................................................54
4.9. User Interface Design....................................................................................................................................54
Chapter Five: Implementation and Testing..............................................................................................................59
5.1. Introduction to Implementation and Testing.................................................................................................59
5.2. Final Testing Procedures of the System.........................................................................................................59
5.3. Hardware software acquisitions....................................................................................................................75
5.3.1. Hardware:-..............................................................................................................................................75
5.3.2. Software:-...............................................................................................................................................76
5.4. User Manual Preparation...............................................................................................................................76
5.5. Training..........................................................................................................................................................76
5.6. Installation Process........................................................................................................................................76
5.7. Start-up strategy............................................................................................................................................77
Chapter Six-Conclusion and Recommendation.........................................................................................................78
6.1. Conclusion.....................................................................................................................................................78
6.2. Recommendation..........................................................................................................................................78
REFERENCES.............................................................................................................................................................79

v
 LIST OF ABBREVIATION
SNNPRS---------------------South nation nationality and people’s regional state
WBFMSGZ-----------web based farming management system for Gedeo zone

vi
 LIST OF TABLES
Table 1: Software tools....................................................................................................................6

Table 2: Time Schedule...................................................................................................................7

Table 3: Login use case description...............................................................................................22

Table 4: Update information use case description.........................................................................23

Table 5: Views feedback use case description...............................................................................23

Table 6: Response Solution use case description..........................................................................24

Table 7: Send feedback uses case description...............................................................................24

Table 8: Major crop production use case description....................................................................25

Table 9: View information use case description............................................................................25

Table 10: Create Account use case from description....................................................................26

Table 11: News and events use case from description..................................................................26

Table 12: Production and productivity use case description.........................................................27

Table 13: Generate report use case description.............................................................................27

Table 14: Land use management use case description..................................................................28

Table 15: Log in Test case specification………………………………………………………….59

vii
 TABLE OF FIGURE

Figure 1: Use case Diagram for WBFMSGZ................................................................................21

Figure 2: Login form.....................................................................................................................29

Figure 3: Sequence Diagram for Create Account..........................................................................29

Figure 4: Sequence diagram for upload information.....................................................................30

Figure 5: Sequence diagrams for news and events........................................................................31

Figure 6: Sequence diagrams for annual target plan......................................................................32

Figure 7: Sequence diagrams for Generate report.........................................................................33

Figure 8: Sequence diagram for send feedback.............................................................................34

Figure 9: Sequence diagrams for view information......................................................................35

Figure 10: Sequence diagrams for Woreda/District office Send report.........................................36

Figure 11: Sequence diagrams for send type of major crop production........................................37

Figure 12: Sequence diagram for admin change password...........................................................38

Figure 13: Class diagram for web-based farm management system.............................................39

Figure 14: Login activity diagram.................................................................................................40

Figure 15: Activity diagram for Woreda/District office send feedback........................................41

Figure 16: Activity diagram for Woreda/District view type of information.................................41

Figure 17: Activity diagram for insert information.......................................................................42

Figure 18: Activity diagram for generate report............................................................................43

Figure 19: Activity diagram for post the zone office news & events............................................44

Figure 20: Activity diagram for view production and productivity..............................................45

Figure 21: Class Type Architecture diagram.................................................................................48

Figure 22: Subsystem decomposition............................................................................................50

vii
Figure 23: Component Modeling for Web based Farm management system...............................51

Figure 24: Deployment Modeling Diagram..................................................................................52

Figure 25: Homepage user interface..............................................................................................55

Figure 26: Login user interface......................................................................................................56

Figure 27: Sign up/Create account user interface..........................................................................56

viii
 CHAPTER ONE

1.INTRODUCTION

This project is a web-based system for an existing manual system. Zones in SNNPRS Region having
an agriculturally based economy do not have a system of this nature. SNNPRS Region, Gedeo(dilla)
Zone economy mainly depends up on agriculture; so, this information system used for Gedeo(dilla)
Zone Agriculture Office. As information system this technology performs controlling roles from
Zone office to each Woreda /District office. So, it is very important requirement to transfer
information online.

1.1Background of the Organization

Gedeo is a Zone in the Southern Nations, Nationalities, and Peoples' Region (SNNPR) of Ethiopia.

This Zone is named for the Gedeo people, whose homelands lie in this zone. Gedeo is an exclave of
the SNNPR consisting of a narrow strip of land along the eastern escarpment of the Ethiopian
Highlands. It is surrounded by the Oromia Region, which borders the Zone on the east, south and
west; Gedeo shares its northern boundary with the Sidama Region. Dilla is the administrative center;
other towns include Irgachefe. Woredas of Gedeo Zone are Bule, Dilla ,Town, Dilla Zuria, Gedeb,
Kochere, Wenago and Yirgachefe Raphe werede Chorso wereda woredaYirgachefe Cheleletu
Administrative town Gedebe Administrative town. Mainly the Regional State economy is based on
pastoralism and agro-pastoralism. However, dilla is an agricultural zone. Maize, sorghum, Onion,
Tomato, Wheat and Barley are the main crops grown in this zone. dilla is one of the most
economically developed parts of SNNPRS. dilla Zone Agricultural Development Office is located in
dilla city.
1.2. Statement of the Problem
In SNNPRS region Gedeo(dilla) Zone the current situation is manual system so it’s difficult to know
the overall information of farming materials like fertilizer, seed and insecticide in each Woreda that is
required to produce a good production. The manual system is time consuming.
It also makes the estimation more complicated.
Generally, we list the problem in the following points:
 Prone to error (information of one office may recorded in different places with different
information).
 It consumes more time and effort for doing the day-to-day activities.
 Since processes are being manually implemented, they need much manpower.
 The communication from Zone to Woreda/District office by letters so it consumes time.
 Persistent data storage and management is difficult.
 Not accurate.
 Decrease in data completeness.
 Response rates are systematically low in some cases (e.g. machinery and pesticides).
1.3. Objectives of the Project
The project would have the following general and specific objective.

1.3.1. General Objective

The main objective of this project is to introduce web based agro farming management system for Gedeo zone
agricultural sector; change the manual system into web-based system.

1.3.2. Specific Objective

The aim of this project is to develop a web based agro farming management system with the
following specific objectives:
 Identify the problems of the existing system.
  Perform requirement analysis.
 Design the architecture for the proposed system.
 Develop user friendly and interactive system.
 Test the developed system.
1.4. Scope of the Project
 The scope of this project is to design and implement a web based agro farming management
system for Gedeo Zone agricultural sector that can be used by agro office particularly
employees.
 The main scope of our system is concerned on transferring information about crop production,
fertilizer, pest, crop, seed and so on between zone office, Woreda office and consumers.
 The system uses English language.
1.5. Limitation of the Project
 The system not supports local languages of the region (Gedeo local language what are called Gedeofa
language).
 The system is limited to the employees residing in the Gedeo zone office and Woreda office
only.
 The system is not support for all agricultural department and individual farmer.
1.6. Methodology of the Project

1.6.1 data gathering methodology

To gather data from the different users and administrator of the existing system, the team used
following techniques.
A) Data Source
 Gedeo zone agricultural development office.
 Documented analysis.
B) Interview
The researcher will interview dilla agriculture office employees personally and through phone calls for
follow up questions and clarifications regarding their present system. Users need enough information
regarding farming materials to cultivate particular amount of crops. Most people in the dilla give
complaints because they do not receive enough information on materials.
C) Observation
We observe that people raise complaints because there is no efficient information on farming product
material.
1.6.2. Systems Analysis and Design
We have selected an Object-Oriented Approach. Because of Object-oriented Approach takes pride in its
suitability for sustaining huge software and web development projects. This is a far better option than using
structured Approach when you have massive code bases. The nature of object-oriented programs allows the
developer to save a lot of time and energy when developing programs as the components of the programs are in
the form of objects which can be plugged into the program wherever they are needed. And it minimizes the risk
throughout the project and we are interested to apply this approach to do so.

Some advantages of object-oriented approach are as follows:

 Reduced maintenance

 code reusability

 real-world modelling

 and improved reliability and flexibility

1.7. Significance of the Project

Web based agricultural information system is a technology that uses internet connection to
share the farming data in order to analyze the amount of farming materials required each year.
This system minimizes the set of problem in traditional estimation technique.
In general, the system has the following benefits:
 Reduce the time and resource required to transfer information or data between Zone and
Woreda/District.
 Easy data storage and management.
 Reducing the probability of errors.
 Provide timely and well-organized information.

 Reduce time to search the particular data.

 Increase the fertility, productivity and marketing system of the agricultural sectors.
1.8. Risk Assessment and Management
Risk assumptions are problems that occur when the team is doing the works. The risks include:
 Connection or Internet access problem
 System/computer/ attacked by virus
 Computer failure-hardware

 Shortage of Internet access

 Shortage of electric power

Risk analyses are to solve the above problems we have used different techniques for protecting the
data from infection. The methods include

 By updating the antivirus software

 Making copies in CD-RW, Flash, other materials for computer failure

 Using internet café

1.9. Operating Environment
Software and hardware tools are necessary for the development and simulation of the project.
The following tools are used to analyze the proposed system.
1.9.1. Hardware Tools
 Desktop computer/laptop.
 Output devices like printer and monitor.
 Storage devices: hard disk, flash disc.
 Internet cable.
 1.9.2. Software Tools

Activities Software Tools

Client-Side Scripting HTML

Platform MS Windows
Database Server MySQL
Design proposed system Xampp
Web server Apache
Server-Side scripting PHP
Browsers Mozilla Firefox, Internet Explorer, Chrome
Editors Adobe Dream weaver CS5.5, EdrawMax,
Notepad++,

Expression web
Documentation Microsoft Office
Presentation Microsoft Power Point

Table 1: Software tools

1.10. Feasibility Analysis

Feasibility study is made to see if the project on completion will serve the purpose of the
organization for the amount of work, effort and the time that spent on it lets the developer predict
the future of the project and the usefulness.
By using the gathered information on the requirements for web based agro farming management
system provider we do feasibility study from different perspectives.

1.10.1. Technical Feasibility

The proposed system can be technically feasible because it doesn’t require any technical expert
and also, we would develop this system by familiar programming language like, HTML, PHP
languages.

1.10.2. Operational Feasibility

The system is operational in way that we have decided to work by effort and in collaboration
with agro office. This may include giving training to users.
 1.10.3. Legal Feasibility
The system is not conflict with any legal or rule and regulation. The system complies the rule
and regulation of the data processing system. Therefore, since the system does not conflict with
any rule and regulation the system is legally feasible and cannot cause any harm in the
environment.

1.10.4. Economic Feasibility

One of the main influences to the new system is to minimize capitals that will be needed to
generate accurate information. In the new system the employees need to have web-based system
that they directly read the information needed right on their own office. This leads to a more
accurate data that will be reported to the office in charge and that estimation will be more
accurate. It’s free so no need to use any cost.
1.11. Project Time Schedule and Cost Estimation

Time Schedule to complete the project

S.No Activity date

14th -23th 24th - 30th 1th -15th 16th -31th 1th -5th 6th -20th
April
April May May June June
2021 G.C
2021 2021 2021 2021 G.C 2021 G .C
G.C G.C G.C

1 Project
Proposal

2 Requirement
analysis

3 Design

4 Implementat
ion

5 Installation
testing
 6 Project
closure

Start time duration End

Table 2: Time Schedule

Cost estimation

There are two types of cost to develop new system. These are:

a) Tangible Costs

The tangible costs to be acquired in developing the system are: -

 Miscellaneous Cost which includes hardware development cost and other costs.
 Software development cost which is software cost to develop the new system.
B) Miscellaneous Cost

This cost contains the various types of costs in which we spent for the development of the project or the
University covers some of the hardware expenses.

The following table lists the different miscellanies costs that we spent in the process of the development of the
system.

i. Cost breaks down

Type List item Quantity Total cost

Pen 6 30Birr

Hardware required Printing 80 pages and 176 Birr

cover page

Paper 1 packet 120 Birr

Flash 8GB 150 Birr

CD and DVD 4 24 Birr

Computer dells & Toshiba/PC 2 by university and

11000

Software requirement WAMP server 1 Free down load

 Microsoft office 2010 1 Free down load

SQL 2005 server 1 Free down load

Notepad++ 1 Free down load

Total 88 11500 Birr

Table 3: Cost of project

ii. Intangible Costs

Those are costs which are uncountable. The intangible costs to be acquired in developing the system are: -

a, Human Knowledge
To develop the new system, it requires our knowledge that knowledge may not be measurable in terms of
money.

1.12.Team Composition

The technical team of this project consists of 5 Computer Science B.Sc. under graduate students
with experience of doing different mini projects. The ultimate objective of the team members is
to develop web-based information system for Gedeo zone agricultural sector.

Project Web based Agro management system for Gedeo zone

Title

Prepared No. Name ID.NO. Email/mobile Responsibility

By 1 Kushabo Kurawo RCSC- +251989935989 All tasks

1575/17

2 Mulalem RCSC- mulualemwondimg@gmail. All tasks

Wondim 8795/17 com/+251960826534

3 Maereg Hailu RCSC- maereghailu1230@gmail.c All tasks

1575/17 om/+251943757633

4 Hailemariam RCSC- hailemengiste4750@gmail. All tasks

Mengiste 4750/17 com/+251918641174

5 Salega RCSC- asalegeta@gmail.com/ All tasks

Ambachew 1580/17 +251940362902
Date 11/8/2013 E.C

Advisor Girmay Tekele

Table 4: - Team composition

1.13. Document Organization

The project organization involves four chapters. Below we are going to list some of the contents
included in each chapter.

Chapter one is introduction of the project mainly includes:

 Introduction

 Statement of problem and limitations of the system

 Objectives and Methodology

 Scope of the project

The second chapter is analysis the existing system phase that includes:

 Description of Existing system

 Documents used

 Players and functions of the existing system

 Alternative solutions

The third chapter is requirement specifications of the project, which contains

 Functional requirements and non-functional requirements

 Product functions and product perspective

 Actors and constraints of the project

 System models

 Assumptions and dependencies

 UML diagrams: Use case, activity, sequence and class diagrams

The fourth chapter is design of the project, which contains:

 Purpose and goals of design

 System Architecture

 Subsystem decomposition

 Deployment and component diagrams

 Persistent data management

 User interface design

 CHAPTER TWO
1. DESCRIPTION OF THE EXISTING SYSTEM
2.1. Introduction
A detailed study of the process has been made by techniques like interviews and observation.
And we have analyzed the operations of the existing system. The operations of existing system
are done in hierarchy. Which means the work is divided in levels:

 Woreda/District Level
 Zone Level and

In Woreda/District Level: some corrections will be given to the report which came from the
kebele’s. They also aggregate the total sum of the demands of all the kebele’s. In this level there
is a form paper. In this form paper they put the total of the demands of all kebele’s. In addition to
this they also put the production GDP of last year; this is useful for estimating the demand of the
coming year. Once finished they make copies of it and submit to next level, i.e. zone level.

Zone Level: this level is the same as the Woreda/District level. The only difference is the inputs
for the Woreda/District are kebele’s where as the inputs for this level is Woreda/District. What
they do in this level is, they put the sum total of the demands of all Woreda/District and give a
correction if there is any. In giving correction they analyze the production GDP of the previous
year of each Woreda/District. Then they put the production GDP to the zone and submit it to the
regional office. The drawback of this system can be visualized as:
 Time drawback and
 Economical drawback.

Time: In the existing system as discussed above there are different levels that are connected
manually, for this particular reason sharing of information is time consuming.
Economical: The capital invested to collect the data is of a huge amount. The first thing done in
order to collect the data is printing the form paper. This requires a lot of papers, so it requires a
great deal of money. In addition to that the government should have to pay money for the people
involved in the collection of the details from the farmers.
 Economical Drawbacks after Distributing: the drawbacks we see above lead to under
estimation of demands, so that the agro office will not be able to get the amount of materials or
resources they need. This leads to the decrease in the Production GDP of the country. On the
other hand it results in the under success of the goal or the plan
2.2. Main Activates in the Existing System
Input: The office takes the following components as an input to provide the information within
the office.

 Agro office name

 Location
Processes: The agricultural office performs the following operations while proving information
to the farmers.

 Verifying the office name.

 Verify the office location.
 Manage the time for each information
Output: After taking the above inputs and processing them the office provides the following
results or out puts.

 Share full information between the offices.

 Will able to generate reports for the allocation or estimation of farming needs such as
materials like seed, fertilizer and the like.
2.3. Functions of the Existing System
The existing system allows zone to manage Woreda’s/districts since it is the higher
administrative level. The agricultural sector of the zone office distributes information, news and
events, and material like fertilizer, seed or it can be other materials needed by the sector.
 Woreda’s/Districts on the other hand receive the information and materials provided by the upper
level (zone). Additionally Woreda’s/districts in turn request requirements (which can be
resources) needed by the farmer in kebele level.
2.4. Players in the Existing System
In Existing systems there are different actors that use manual operation. The following actors
are listed below:
 Agricultural Data Collection Office Worker (ADCOW): who is working
agricultural data collection office and have limited privilege, which is determined by
the administrator.
 Administrator: is the one who is working on some office as a manager. He/she has the
power to control other staffs in that office.
2.5. Report Generated in the Existing System
In the current system, report is generated by consolidating all the data gathered by the employee
in the form of paper, after which the report will be submitted to the zone level and to be
forwarded to the manager.
2.6. Forms and Other Documents of the Existing Systems
Currently, Zone office uses forms and reports to distribute farming materials and to manipulate
different records associated with different activities.
2.7. Weakness of the Existing System
The present system of Zone and Woreda office are prone to various problems. These problems
can be seen from the following perspectives like performance, information, economic, control,
efficiency and services given by the existing system to the office, by using the PIECES
framework as follows.
 Performance: Since the system is designed to be accessed by different offices’ with different
needs of information, it is capable of handling and processing their information quickly. The
current system’s performance of distributing information is weak. This is due to the following
reasons, first the acceptable throughput rate is relatively high land i.e. the time required from
initiation to completion of a particular task is relatively high. For example when the
Woreda/District office want to get information about crop production, he may go to the Zone
office or may sends letters to Zone for they question and the Zone office will respond to him
according to the available data they have and the time they could spent for every inquiry. The
response time will depend how fast they will respond for every inquiry and the availability of
data they have in their records. Since it is a manual operation, long waiting time is expected.

Information: The main input in the current system are the data gathered by the Woreda/District
office from the farmers, and this data will be the basis for the office to make estimation on the
materials needed by particular farmers.

Economical: The Zone Office performs all of its tasks manually which requires much of the
work to be done by manpower, and requires huge amount of papers for the manual storage of
data on papers, which lead the manual system to spend much money for human resource and for
purchasing papers and other materials.

Controlling: Since all the records associated with the manual system are recorded and stored
manually the security that the system provides for the privacy of this records is not reliable. The
system cannot provide sufficient protection for access and manipulation of the records associated
with the system.

Efficiency: As we mentioned earlier, the Zone Office system encountered many problems such
as: unnecessary information redundancy, consumption of cost and time and needs more labor to
teach the farmers.
2.8. Strength of the Existing System
Even if the existing system has no capacity to fulfill all of its requirements alongside this, the
System has the following strength:
  No internet access requirement.
 Allow communication within any language as needed.
The new system will have the same functionality as the old one but in a better implementation.
That is the new system is faster, efficient, effective, economically better and reliable.
2.9. Alternative Solutions
To overcome the problems occurred in existing system our project group members have put
down alternative solution. We proposed that the new system should be automatic
(computerized). Converting the manual system to be automatic makes the system to function
better than the old one. When converting the system from manual to automatic, we will consider
using database, server and network connections. We are proposing to develop a website
application that runs on a server and uses the database to manipulate data. Network connection is
vital in the new system and nothing will be available without it. We will use the network to
connect the Zone and the Woreda’s/Districts so that the information pass between them is in real
time. We use PHP coding to make the generation of the schedule reliable and simple.
 CHAPTER THREE
2. REQUIREMENT SPECIFICATION AND ANALYSIS
3.1. Introduction
In this project, the team used an object oriented system development methodology which
incorporates two principal phases. These principal phases are Object-Oriented Analysis and
Object-oriented Design. This chapter discusses the first phase of the methodology: object
oriented analysis (OOA).
3.1.1. Purpose
Analyzing the current system and making requirement determination helps to develop a system,
which includes necessary information and sources for different activities. The purpose of the
software requirements specification document is to maintain functions in web based agro
farming management system for Somali Region Fafan zone. During object oriented analysis the
following major activities are performed.

 System Requirement Specifications (SRS),

 Use case modeling and documentation (for each use case identified).
 Development of sequence activity diagrams and class diagrams.

3.1.2. Intended Audience and Reading Suggestions

Since we are developing web based agro farming management system for Fafan zone, more
concern has given for the different woreda offices in Fafan zone. So that we have prepared and
presented the existing system workflow and the optional analysis of our proposed system and we
get the following suggestions from the Agro office workers since they are also part that will be
affected by the system. The proposed system is

 Efficient because the proposed system reduce inaccuracy

 Decrease the wastage of time
 Introduce to the new technology
 We also accept some suggestions from the SoRPARI administrator Mr. Ali Bashe as follows:

 It is easy to manage employees.

Easy to transfer information for Woreda office employees with no delay.

3.1.3. Document Convention

 MySQL: My Structured Query Language.
 Xampp: X (any of four different operating systems. e.g. windows operating system),
Apache, MySQL, PHP and Perl.

 HTML: Hyper Text Markup Language.

 SRFZ: Somali Region Fafan Zone
 WBFMSFZ: web based farm management system for Fafan zone
 PHP: PHP Hypertext Preprocessor.
 MS Office: Microsoft.
3.2. Objectives
The requirement specification is the phase that leads to the designing and implementation, that
the correct and accurate designing has a great role to the system implementation. Based on this
designing, our target providing the automated system to the agro farming management System
attained with the rapidly developing technologies.
3.3. Functional Requirements
The functional requirement is the functionality that the system can be done. The functionality of
WBFMSFZ can be view report, land use management, post news and events, response in
emergency, target annual plan, give information about production and productivity, distribution
seed and fertilizer and view type of crop production for zone office and also the Woreda/District
office can be view solution, view different type of information, see news and events, see
emergency response, send feedback, send report.
 Input Related Requirements
 The system should accept user name and password
 The system shall validate and authenticate the users’ username and password
 The system should validate the data entry.

Output Related Requirements

 The system shall allow Zone Office to update necessary offices’ information to the
system.
 The system allow the Woreda/District office can be view different type information, new
and events, send feedback , view solution, send crop production, see emergency response
and send report.
 The system allows zone office to generate report, emergence response, update
information, view feedback, view crop production, post new and events, response
solution.
 The system allows admin to view the user account.

Storage Related Requirements

 The system will store all the different information of the Zone and Woreda offices.
 The system store all product and user detail information
3.4. Product Perspective
The product of the system indicates the final output of the proposed system that is farm
management system for Fafan zone, which aimed to give different access to the users of the
system; these are woreda office employees, zone office employees and agro office
administrators.
3.5. Product Functions
Our system can help the users to maintain the integrity of the generation of farm management.
The proposed system will expect to have the following functionalities.
  Create account for employees by using employee’s username,

 Search any information from database to update the record.

3.6. Principal Actors
An actor represents anything or anyone that interfaces with your system. This may include
people, external systems, and other organizations. Actors are always external to the system is
being modeled. The actors of our system are:

Administrator: can perform the following activities:

Create, update, delete and view accounts and change password.
Zone Employees:
View feedback, send emergency solution, view report, land use management, update information, generate
report, annual target plan, view major type of productivity

Woreda/District Employees:

 Send feedback, view emergency responses, send report, send major type of productivity,
view information, view news and events and the like.

3.7. User characteristics

User characteristics are about people who are going to use the system. Users of the system are
zone employees and woreda employees. In our case, most of the users are experienced.

 Educational Level: Users should be comfortable with English language.

 Experience: Users should have prior information about the system.

 Skills: Users should have basic knowledge and should be comfortable using general-
purpose applications on computers especially web applications.
3.8. General constraints

 All operations are in English. So, user must have basic knowledge of English.

 The email of the user must be any character followed by @gmail.com, @yahoo.com or
@hotmail.com.

 The user must type the correct user name and password.

 Normally Fafan zone uses manual based activities. Automating this all with short period
seems to be difficult. Therefore, it takes more time to be automating.

 The other risk is the price of materials may arise and fall. Therefore, budget may modify
in negotiation. In addition after implementation, if the software fails to run how to fix is
negotiable.

The main risk during the development of the project, is securing the project from unauthorized
access. To overcome such risks we are going to develop a password protection method that gives
access to authorized persons only. The other is data loss, which has caused by virus infection. To
prevent this problem, virus and worms infection, we will install a current updated antivirus. In
addition to installing the updated antivirus, we will take back up of our documents.

3.9. Assumptions and Dependencies

The users have some minimal knowledge of English language.

 The woreda employees, zone employees and the administrator must have valid user name
and password.

 The administrator has full privilege on the system.

 To use the product, the internet connection needed.

3.10. Non Functional Requirements

A non-functional requirement is a requirement that specifies criteria that can be used to judge the
operation of a system, rather than specific behaviors. It defines how a system is supposed to be.
 Non-functional requirements are often called qualities of a system

Performance: Focus should be kept on monitoring and managing the performance and service
availability of software. The system should be available 90% of the time, because of their power
fluctuations 10% the system may be down. The system can assume to support more than 100
concurrent requests at once.

User Interface: Visual layout of the system that a user might interact with.

 The designed systems’ user interface graphics will reflects the system.

 The user interface will be light weight and easy to use and manage.

 The designed user interfaces will be attractive.

Security and Access Permissions: Security requirement are important factors in this system as
classified data/information will be stored in the database. User validation will be done during
login to ensure that the user is valid and that the user only has access to his/her permitted
information.

Backup and Recovery: The proposed system can be damaged or fail if there is virus attack and
continuous power disconnection from the source station and the data can be lost at that time. It
should be holding a backup of the data by using different storage devices like Hard disk, CD,
DVD Flash. Backup can be performed in a week at middle night 6:00 pm because of no works
perform at this time.

3.11. System models

3.11.1. Use Case Diagram

A use case diagram at its simplest is a representation on users’ interaction with the system and
depicting the specification of a use case. Below is the use case diagram for web based agro
farming management system for Fafan zone.
 Figure 1: Use case Diagram for WBFMSFZ

3.11.2. Use Case Descriptions

Use case documentation includes text descriptions of processes with sections like use case
number, Actors, Precondition, aim and alternative action.
 Use Case Documentation (for each use case identified)

Use case name Login

Actor Admin, Zone office and Woreda/District office
Description: Allow login into the system.
Precondition The user should have an account in the system.
Post-condition: The user is logged in the system and provided with privileges for

actions according to their roles

Normal Follow System response
Step 2: Select Login link.
Actor action Step 4: Enter username
Step 3: Login form displayed
and password.
Step 6: validate data entry
Step 1: opens the web page. Step 5: User clicks on Login
Step7: Appropriate page will
button
be displayed

Alternative If the user did not insert correct user name and password, system

displays incorrect username and password combination message.

Table 3: Login use case description

 Update Information Use Case Description

Use case Name: Update Information

Actor(s) Zone office
Description The use case describes the process upload information.
Pre-condition The Zone office employees must be login-in to the system
Post –condition Updated information has been recorded and system will display
appropriate Message.

Normal Follow Actor Action System Response

Step 1: Clicks update info link. Step 2: Update info page displayed
Step 4: Select link Zone office
want to update, Step 3: Display update form
Step 5: Click on update button.
Step 6: Give appropriate message.
Alternative -

Table 4: Update information use case description

Views Feedback Use Case Description

Use case Name: View feedback

Actor Zone office
Description: Allow the Zone office to view complain.
Pre-condition : Zone office must login in to the system
Post-condition Zone office view Woreda/District office complains.
Normal follow Actor action System response

Step1: Clicks view feedback link. Step2: Feedback page

displayed.
Step3: Zone office view Woreda/District
office Feedback.
Table 5: Views feedback use case description
 Response Solution Use Case Description

Use case Name: Response Solution

Actor Zone office
Description: Allow the Zone office to response Solution.
Pre-condition : The Zone office must login in to the system
Post-condition Solution will submit to the Woreda/District.
normal follow Actor action System response

Step1: Click on response solution Step2: The system display page

that the admin want.

Step3: Insert information in the Step4: The insert information

form. Step5: Generate notification that

the information Is inserted.

Table 6: Response Solution use case description

Send Feedback Use Case Description

Use case Name: Send feedback

Actor(s): Woreda/District office
Description: Allow the Woreda/District office to send complain
Pre-condition : Hit the submit data menu item.
Post-condition Complain send to Zone office
Normal follow Actor response System response

Step1: The Woreda/District office presses Step4: The system

send complain button notifies as the complaint
Step2: The Woreda/District office write is successfully
complain. submitted.
Step3: The Woreda/District office presses
 submit button.

Table 7: Send feedback uses case description

 Major Crop Production Use Case Description

Use case Name: Types of major crop production

Actor(s): Woreda/District office
Description: Allow the Woreda/District office to send types of crop production in

the area
Pre-condition : Hit the submit data menu item.
Post-condition Send the major types of crop production to Zone office
Normal follow Actor response System response
Step2:The system displays
Step1.The Woreda/District office presses
the page.
send types of crop production link
Step5: The system
Step3: The Woreda/District office writes
notifies as the types of
type’s crop production.
crop production is
Step4: The Woreda/District office presses
successfully submitted.
submit button.

Table 8: Major crop production use case description

View Information Use Case Description

Use case Name: View type of information

Actor Woreda/District office
Description Allow the Woreda/District office to view information about
Pre-condition The web is Launched.
Post-Condition The Woreda/District office view the information
Normal follow Actor response System response

Step 1.The Woreda/District office Step2. The system displays the

presses menu option
Step 3.The Woreda/District office
selects what he want to read.
Table 9: View information use case description
 Create Account Use Case from Description

Use case Name: Create Account

Actor Administrator
Description Allow to create Account
Pre-condition -
Post-Condition user Information recorded in database
Normal follow Actor response System response

Step 1: select create account Step2:The system displays the

link form
Step 3: fill the form Step4: If it is valid information

recorded to database.

Table 10: Create Account use case from description

News and Events Use Case Description

Use case Name: Post News and events

Actor(s) Zone office
Description The use case describes the process news and events information.
Pre-condition The Zone office employees must be login-in to the system
Post –condition News and events information has been recorded and system will

display appropriate message.

Normal Follow Actor Action System Response

Step 1: Clicks News and events Step 2: News and events info
info link. page displayed
Step 4: Select link Zone office Step 3: display News and events
want to post News and events form
Step 5: Click post News and Step 6: give appropriate
events button. message.
Alternative -

Table 11: News and events use case from description

 Production and Productivity Use Case Description

Use case Name: Production and productivity

Actor(s) Zone office
Description The use case describes the process of Production and productivity type

information.
Pre-condition The Zone office employees must be login-in to the system

Post –condition Production and productivity types of information have been recorded and

system will display appropriate message.

Normal Follow Actor Action System Response

Step 1: Clicks Production and Step 2: Production and productivity

productivity info link. info page displayed
Step 4:Select link want types of Step 3: Display types of Production
Production and productivity and productivity form
Step 5: Click Production and Step 6: Give appropriate message.
productivity button

Table 12: Production and productivity use case description

Generate Report Use Case Description

Use case Name: Generate Report

Actor(s) Zone Office
Description Allows the Zone office to generate analysis report.
Pre-condition The Zone office employees must be login-in to the system
Post –condition The system generates analysis report.
Normal flow Actor Action System Response

Step 1: Press generate report Step2: The system displays choices

Step 3: The User selects from the choices to generate report

Step 4: System displays the report
Step 5: Click send report to Woreda
office Step 6: Give appropriate message.

Table 13: Generate report use case description

 Land Use Management Use Case Description

Use case Name: Land use management

Actor(s) Zone office
Description Allows the Zone office to inform about land use management
Pre-condition The Zone office employees must be login-in to the system
Post –condition The system gives information about land use management.
Normal Follow Actor Action System Response

Step1: The User press Land use Step2: The system displays the
management link. Land use management form
Step3: The User fill the form Step6: Give appropriate message.
Step5: Click the Landuse
management to Woreda/District
office

Table 14: Land use management use case description

3.11.3 Sequence Diagram

A sequence diagram is an interaction diagram that emphasizes ordering of message. These
diagram is model describing how groups of object collaborate in some behavior over time .It also
capture the behavior of a single use case. Some of major sequence diagrams of web based agro
farming management system for Fafan Zone agriculture sector are illustrated below.
Login Form

Figure 2: Login form

Create Account
Figure 3: Sequence Diagram for Create Account
 Update Information
9

Figure 4: Sequence diagram for update information

News and Events
`

Figure 5: Sequence diagrams for news and events

Annual Target Plan

Figure 6: Sequence diagrams for annual target plan

Generate Report

Figure 7: Sequence diagrams for Generate report

Send Feedback

Figure 8: Sequence diagram for send feedback

View Information

Figure 9: Sequence diagrams for view information

 Send Report

Figure 10: Sequence diagrams for Woreda/District office Send report

 Major Crop Production

Figure 11: Sequence diagrams for send type of major crop production
 Change Password

Figure 12: Sequence diagram for admin change password

 Figure 13: Class diagram for web based farm management system

3.11.4. Class Diagram (Conceptual Modeling)

UML class diagram are the mainstay of object oriented modeling. Class models show the classes
of the system, their inter relationships and the operation and attributes of the class.
 3.11.5. Activity Diagram
Activity diagram is special kind of state chart diagram that shows the flow from activity to
activity within the system.
Login activity diagram

Figure 14: Login activity diagram

 Activity Diagram for Send Feedback

Figure 15: Activity diagram for Woreda/District office send feedback

View Type of Information

Figure 16: Activity diagram for Woreda/District view type of information
Insert Information

Figure 17: Activity diagram for insert information

Generate Report

Figure 18: Activity diagram for generate report

 Post the Zone Office News & Events

Figure 19: Activity diagram for post the zone office news & events
 View Production and Productivity

Figure 20: Activity diagram for view production and productivity

 CHAPTER FOUR

3. SYSTEM DESIGN

4.1. Introduction to System Design

This project is designed in a manner that solves the problems of Fafan Zone Agriculture Office
by minimizing the work load that appears on the employees because of the existing system is
manual. In this project design we try to show how the project is designed. It designed to simplify
function of the manual system and it is capable of doing large amount of works in short period of
time.
The goal of system design according to the proposed project is to manage complexity by dividing
the system into smaller and manageable pieces. It mainly focuses on the different types of class
type architectures, such as user interface layer, process/control layer, business /domain layer,
persistent layer, and system layer and also different types of system modeling techniques that are
used for the implementation types of the system such as class modeling, state chart modeling,
component modeling, deployment modeling, persistence modeling and also some system design
techniques such as user interface designing are also to be covered in this design chapter.

4.2. Goals of System Design

The goal of this project is to develop Web based farm Management System for Fafan zone. This
document will provide interface design models that are consistent user friendly and will provide
straightforward transition through the various system functions.
The design goals can be generally grouped in to

 Performance criteria

 Dependability criteria

 Maintenance criteria
  End user criteria

Performance, dependability, and end user criteria are usually specified in the requirements or
inferred from the application domain. The customer and the supplier (developer) dictate cost and
maintenance criteria.
 4.2.1. Performance Criteria
Performance criteria: - this criterion includes:

 Response time, the speed imposed on the system. The system should responsive
maximum number of tasks with minimum times.
 Number of tasks accomplished in a fixed period of times. Memory space available for
speed optimizations should be used efficiently.
4.2.2 Maintenance Criteria
When we say the system is maintainable, we mean it can be maintained easily when changes
arise from the user and designer/developers. We prepare full maintenance document and attach
with the web content then the end user can maintain the fall of the system easily by using the
maintenance manual or document.
4.2.3. End User Criteria
This is to mean that users of the system after the completion of the system, how the system is
used in friendly manner for both the experienced and inexperienced users using the user
interface.

4.3. System Architecture

The software system architecture is a high-level structure of software system, the discipline of
creating such structures, and the documentation of these structures. There are many recognized
architectural patterns and styles. Among them are:
Client-Server: The Client-Server model of computing is a distributed application architecture
that partitions tasks and workloads between the providers of resources or services, called servers
and service requesters, called clients.
Peer-to-Peer: this architecture is a distributed application architecture that partitions tasks and
workloads between peers. Peers are equally privileged equipotent participants in the application.
Three tier Architecture
Three tiers Architecture is an architecture in which the functional process logic, data access,
computer data storage and user interface are developed and maintained as independent modules
on separate platforms.
User (Presentation) Tier: End-users operate on this tier and they know nothing about any
existence of the database beyond this layer.
Application (Middle) Tier: At this tier reside the application server and the programs that
access the database. For a user, this application tier presents an abstracted view of the database.
End-users are unaware of any existence of the database beyond the application. At the other end,
the database tier is not aware of any other user beyond the application tier. Hence, the application
layer sits in the middle and acts as a mediator between the end-user and the database.
Database (Data) Tier: At this tier, the database resides along with its query processing
languages. We also have the relations that define the data and their constraints at this level.

Figure 21: Class Type Architecture diagram

4.4. Subsystem Decomposition

These are the working areas of the project after the completion of total process. In the sub system
decomposition, we can see different components emanated from system architecture that
collaborate to handle single application at a time.
When the operator runs the intranet application, the user interface appears by preceding login
screen. Next to login screen is the main page that supports other operational directories. The
different subsystems have a coupling to complete entire process.
Manage Account Subsystem: this subsystem enables the administrator to manage user
accounts. The management includes creation of new accounts, removing the existing accounts
and modification of accounts. The management of user account is the responsibility of the
account class. This subsystem also enables the determination of who has access to the official
page of the system at what time. The class that is responsible to establish such a service is called
the access-control class. It is to keep track of the time and date along with the user accessing the
login page, if the user has successfully login in, it also display the recorded information to a user
with the administrator privilege.
Report Management Subsystem: This subsystem enables to generate and view reports.
Production and Productivity Subsystem: This allows information exchange about fertilizer
and seed distribution between woreda and zone offices.
Feedback Subsystem: This subsystem enables the user to send and view feedback.

News and Events Subsystem: In this subsystem the users can post and view news and events.

Land management subsystem

 Figure 22: Subsystem decomposition

4.5. Component Modeling

Component diagrams are different in terms of nature and behavior. Component diagrams are
used to model physical aspects of a system. Physical aspects are the elements like executable,
libraries, files, documents etc that resides in a node. So component diagrams are used to visualize
the organization and relationships among components in a system. These diagrams are also used
to make executable systems.
 Figure 23: Component Modeling for Web based Farm management system

4.6. Deployment Modeling

Deployment modeling used to show the hardware of the system, the software that is installed in
the hardware and also the middleware that is used to connect the disparate machines to one and
other. It also shows how the software and the hardware components work together.
Figure 24: Deployment Modeling Diagram
4.7. Persistence Data Management

This model used to relate and shows the relationship between each and every of the designed
system database. Persistent data management is basically used to represent the design of the
database, usually a relational database. Database design is the process of producing a detailed
data model of a database. This logical data model contains all the needed logical and physical
design choices and physical storage parameters needed to generate a design in a Data Definition
Language, which can then be used to create a database. Database design describes many different
parts of the design of an overall database system. Database designs also include ER (Entity-
relationship model) diagrams. An ER model ER model is an abstract way of describing a
database. Design process of a database includes:
 Determine the purpose of the database.

 Divide the information into tables.

 Turn information items into columns.

 Specify primary keys.

 Set up the table relationships.

4.8. Access Control and Security

Here we concerned with determining the allowed activities of legitimate users, mediating every
attempt by a user to access a resource in the system. The objectives of an access control system
are often described in terms of protecting system resources against inappropriate or undesired
user access. From a business perspective, this objective could just as well be described in terms
of the optimal sharing of information.

In our project the system administrator have a full privilege to operate on the system, i.e. he/she
is allowed to create, view and delete accounts and also can change passwords. On the other hand
Users/Zone and woreda office workers are not allowed to do so. They have restricted privilege or
right such that they can simply access the entire system according to the responsibility that
belongs to them. Woreda/District office workers are allowed to send request (it may be about
fertilizer, seed…), feedback, and emergency report and the like. Zone office workers in turn give
53
response; view feedback, post news and events or about seed and fertilizer distribution as the
system platform allows operate on it.

4.8.1. Boundary condition

The boundary conditions in our project identify what is included what are not included within
project work. Project boundaries represent one of the components of the scope statement.

Generally in our project:

 Account and account relate tasks are given only for the system administrator. The system
does not allow users to do the same.
 The user should be any one who is an employee or anyone who is a part of Zone or
Woreda agro office staff in a certain department.

4.8.2. Exception handling

Exception handling is a method of achieving system robustness, and is also related to fault
tolerance and error recovery.

Human Interface: Since input from a human user is one of most likely places that exceptional
and invalid inputs can be generated in an embedded system, the user interface should be able to
prevent the operator from causing a fault condition. The interface should constrain the user to
only entering valid inputs into the system.

Security: Many security vulnerabilities are caused by not properly containing exceptional
conditions. For example, many security holes are caused by race conditions and not detecting a
memory buffer overflow. These vulnerabilities can be exploited by people to gain access to and
tamper with restricted systems.

4.9. User Interface Design

User interface design or UI design generally refers to the visual layout of the elements that a user
might interact with in a website, or technological product. UI must not only be attractive to
potential users, but must also be functional and created with users in mind. The layout of a user
interface design should also be clearly set out for users so that elements can be found in a logical
position by the user. In our case we will try to make it simple, clear and attractive so that users
can operate on our system as quickly and easily as possible.

Homepage User Interface

Figure 25: Homepage user interface

Login User Interface

Figure 26: Login user interface

Sign Up/Create Account User Interface

Figure 27: Sign up/Create account user interface
 Chapter Five: Implementation and Testing

5.1. Introduction to Implementation and Testing

The implementation phase is the critical phase in which it transform the design and analysis of
the system in to tangible system by writing the code to the system to be developed and make is
operational and applicable by testing debugging the functionalities that are done. This phase
involves the construction of the actual result. During this phase the project become visible to
outsiders, to whom it may appear that the project has just began. This makes the implementation
stage more essential step to develop the required system. So, it is the most Vital and necessary
stage in archiving successful system and in giving the users that the new system will work and be
effective by testing the system that is already implemented. The main objective of this phase is
generally is to deploy and enable operation of the new information system in the production
environment.
During implementation and operation, physical design specification must be turned into working
computer code, and then the code is tested until most of the errors have been detected and
corrected. The user sites are prepared for new system and user must come totally on the new
system rather than the existing. There are some managerial activities in this, coding and testing.

5.2. Final Testing Procedures of the System

It is the final step of testing in which the entire system as a whole with all forms, code, and
modules are tested. In this procedure we have tested all the functionalities of the System. All
errors in the forms, functions, modules have been tested. Finally System testing ensures that the
entire integrated software system meets the desired requirements. It tests a configuration to
ensure known and predictable results. To the test whole system the team follows the following
procedures.
 Unit Testing: Every module of the System is separately tested. I.e. the team tests every
module by applying some selection mechanism. Through this mechanism every modules
gets tested. If an error occurs correction will be taken without affecting another module.
 Integrated Testing: In this testing part, all the modules will be combined together and
tested it for its fitness with each other and with the systems functionality. If error occurs
in combining them, the module with problem will be identified and recombined.
 Black Box Testing: The team has conducted this testing procedure to evaluate only the
outputs generated in response to selected inputs and execution conditions.
 White Box Testing: The team has conducted this testing procedure during writing the
code for each desired components of the system to check if the written code is working
properly or not.
 Functional (Black Box Testing) and System Testing: In this testing, the team performs
over all functional testing by checking whether it meets or not meets the required target.
 Compatibility Testing:

 Hardware Compatibility test- the system is compatible with all the Hardware and
Software listed under the Hardware and Software Acquisitions.
 Software compatibility test – the system is compatible with all the software listed
under the development tools table.
 User Interface Testing: The team has conducted this testing procedure to evaluate the
GUI elements like field forms drop down box, input type length, radio button are work
properly and suitable for the users. As a result all of these components are working
properly.
 Usability Testing: The team has conducted this testing procedure to evaluate the extent
to which a user can learn to operate, prepare inputs for, and interpret outputs of a system
or component and the system’s user friendless.
 Test case specification

Log in

Test Case ID
Testing Class Black Box & White Box Test
Testing Name Unit & Integration Test
Unit to Test = User Login
Assumptions = User Successfully Login

Test Data
 User Name (valid username, invalid username,
empty user name)
 Password (invalid password, valid password,
empty password)
Steps to be
Data Expected Results Actual Results
Executed(Description)
Enter valid user name and valid user name =xxx Display an alert message” go to
Password. password =xxx aproprate page”
Should display an alert Wrong Username
Enter valid username and invalid user name =xxx
message “Wrong Username or or Password click
password. password=xxx
Password here re- Enter
!"
Should display an alert Wrong Username
Enter invalid username and valid username= xxx
message “Wrong Username or or Password click
password. password= xxx
Password ” here re- Enter
Should display an alert Wrong Username
Enter invalid username and username = xxx
message “Wrong Username or or Password click
invalid password. password = xxx
Password here re- Enter
click here to go back”
Should display an alert The following
username=----
Enter empty username and valid message“The following error(s) error(s) occurred:
password=xxx
password. occurred: - username is - username is
required.” required.
Should display an alert The following
Enter valid username and empty username=xxx message“The following error(s) error(s) occurred:
password. password=---- occurred: - password is - password is
required.” required.
Should display an alert The following
message “The following error(s) occurred:
username=---- error(s) occurred: - Incorect - username is
Enter all fields empty
password=--- UserName and Password required.
- Password is
required.

Table 15: Log in Test case specification

Sample Code:

Login code
<?php
include('conn.php');
session_start();
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>login</title>
<meta name="description" content="website description" >
<meta name="keywords" content="website keywords, website keywords">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<link rel="stylesheet" type="text/css" href="css/style.css">
<link rel="stylesheet" href="css/main.css">
<!-- modernizr enables HTML5 elements and feature detects -->
<script type="text/javascript" src="js/modernizr-1.5.min.js"></script>
<style type="text/css">
.style1 {
font-size: medium;
}
.style2 {
margin-top: 0;
}
</style>
<style type="text/css">
ul{
padding: 0;
list-style: none;
background: teal;
}
ul li{
display: inline-block;
position: relative;
line-height: 21px;
text-align: left;
}
ul li a{
display: block;
padding: 8px 25px;
color: black;
text-decoration: none;
}
ul li a:hover{
color: white;
background: cyan;
}
ul li ul.dropdown{
min-width: 100%; /* Set width of the dropdown */
background: aqua;
display: none;
position: absolute;
 z-index: 999;
left: 0;
}
ul li:hover ul.dropdown{
display: block;/* Display the dropdown */
}
ul li ul.dropdown li{
display: block;
}
</style>
<style type="text/css">

div#container
{
width: 600px;
position: relative;
margin-top: 0px;
margin-left: auto;
margin-right: auto;
text-align: left;
}
body
{
background-color: crimson;
background-image:url(images/index_bkgrnd.png);
color: green;
font-family: Arial;
 font-size: 13px;
margin: 0;
text-align: center;
}
</style>

<script type="text/javascript">
function ValidateForm(frm) {
if (frm.user.value == "") {
alert('user name.');
frm.name.focus();
return false;
}
if(frm.pass.value == "") {
alert('Password.');
frm.pass.focus();
return false;
}
return true;
}
</script>
</head>
<body>
<div id="main">
<fieldset>
<header>
<div id="logo">
 <div id="logo_text">
<!-- class="logo_colour", allows you to change the colour of the text -->
<img src="images/aaa.jpg" width="146" height="55" align="middle" >
<img src="images/aab.jpg" width="120" height="55" align="middle" >
<img src="images/aac.jpg" width="120" height="55" align="middle" >
<img src="images/aad.jpg" width="120" height="55" align="middle" >
<img src="images/aae.jpg" width="120" height="55" align="middle" >
<img src="images/aaf.jpg" width="120" height="55" align="middle" >
<img src="images/aag.jpg" width="120" height="55" align="middle" >
<img src="images/aad.jpg" width="120" height="55" align="middle" >
<img src="images/aai.jpg" width="120" height="55" align="middle" >
<img src="images/aab.jpg" width="146" height="55" align="middle" >
</br>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content=
"width=device-width, initial-scale=1.0" />
<title>Double Layered Text</title>
<style>
body {
background: teal;
}
.geeks {
text-align: center;

font-family:Arial Narrow, sans-serif

 }
.geeks span {
font-size: 50px;
font-weight: 700;
color: white;
position: relative;
text-shadow: -1px 0 0 rgba(0, 0, 1, .2);
}
.geeks span::before {
content: attr(data-title);
position: absolute;
top: 0;
left: 0;
transform-origin: right;
color: teal;
transition: .3s cubic-bezier(
0.175, 0.885, 0.32, 1.275);
transform: rotateY(18deg);
}
.geeks span:hover::before {
transform: perspective(1000px) rotate(-67deg);
}
</style>
</head>
<body>
<div class="geeks">
<span data-title="Web">Web</span> &nbsp
 <span data-title="Based">Based</span> &nbsp
<span data-title="Agro">Agro</span>
<span data-title="-Farming">-Farming</span>&nbsp
<span data-title="Management">Management</span> &nbsp
<span data-title="System">System</span> &nbsp
<span data-title="for">for</span> &nbsp
<span data-title="Fafan">Fafan</span> &nbsp
<span data-title="Zone">Zone</span> &nbsp
</div>
</body>
</html>
<nav>
<ul class="sf-menu" id="nav" >
<li class="selected"><a href="index.php" class="style2">Homepage</a></li>
<li><a href="about.php" class="style2">About Us</a></li>
<li><a href="#" class="style2">Services</a>
<ul>
<li><a href="infoworeda.php" class="style2">Woreda Information</a></li>
<li><a href="infozone.php" class="style2">Zone Information</a></li>
<li><a href="galary.php" class="style2">Gallery</a></li>
</ul>

</li>
<li><a href="mission.php" class="style2">Vision and Mision</a></li>
<li><a href="contact.php" class="style2">Contact</a></li>
<li><a href="login.php" class="style2">Login</a></li>
 </ul>
</nav>
</header>
<div id="site_content" style="height: 471px">
<div class="sidebar_containerde" style="width: 478px; height: 143px">
<div class="sidebar" style="width: 410px; height: 203px">
<?php
if (isset($_POST['log'])){
$username=$_POST['user'];
$password= $_POST['pass'];
$passord_md5= md5($password);
$sql ="SELECT * FROM registration WHERE username='$username' AND
password='$passord_md5'";
$result = mysql_query($sql);
// TO check that at least one row was returned
$rowCheck = mysql_num_rows($result);
$row=mysql_fetch_array($result);
if($row['user_type']=='administrator'){
$_SESSION['ID']=$row['id_no'];
$_SESSION['username']=$row['username'];
echo "<script>window.location='admin.php';</script>";
}
else if($row['user_type']=='zone'){
$_SESSION['ID']=$row['id_no'];
$_SESSION['username']=$row['username'];
echo "<script>window.location='zone.php';</script>";
}
 else if($row['user_type']=='woreda'){
$_SESSION['ID']=$row['id_no'];
$_SESSION['username']=$row['username'];
echo "<script>window.location='woreda1.php';</script>";
}

else {
echo'<br>';
echo' <p class="wrong">Wrong User name or Password Please try again!</p>';
echo' <meta content="15;login.php" http-equiv="refresh" />';
}
}
mysql_close($conn);
?>
<!--End of PHP script-->

<html>
<head>
<meta name="viewport"
content="width=device-width, initial-scale=1">
<style>
body {
height: 100%;
font-family: lucida, handwriting;
}
*{
box-sizing: border-box;
}
h1 {
text-align:center;
color:green;
-webkit-text-stroke: 1px black;
}
}
/* Styling the form container */
.container {
position: absolute;
left: 28px;
top: 50px;
margin: 20px;
max-width: 300px;
padding: 16px;
}
{
color:blue;
font-size:24px;
-webkit-text-stroke: 1px gray;
}
/* Full-width input */
input[type=text],
input[type=password] {
width: 100%;
padding: 18px;
margin: 15px 0px;
 border: 2px solid green;
}
</style>
</head>
<table style='border:60px solid green;'class="log_table" align='center' background="images/108.jpg"
style="color:white">

<form action="login.php" method="POST" onsubmit="return ValidateForm(this);"><br>

<tr align="center" ><th colspan="2" class="style1" ><font color="navy"><b><i>Enter User Name and
Password to Login!</th></tr>
<tr>
<td><br>
<label ><span><font color="navy" size="3"><b><i>&nbsp;User Name</font></span></label>
</td>
<td>
<input type="text" name="user" style="height: 24px" ="&#4840;&#4773;&#4653;&#4661;&#4814;
&#4661;&#4637;" required >
</td>
</tr>
<tr>
<td>
<label><span class="style1"><font color="navy"
size="3"><b><i>&nbsp;Password</font></span></label></b></i>
</td><td>
<input type="password" name="pass" id="pw" style="height: 24px" ="&#4840;&#4845;&#4616;
&#4941; &#4675;&#4621;" required >
</td>
</tr>
<tr>
<td>
</td>
<td>
<input type="submit" name="log" value="Login" style="width: 80px;background-color:silver;font-
style:oblique; height: 31px;" >
<input type="reset" value="Cancel" style="width: 80px;background-color:silver;font-style:oblique;
height: 31px;" >
</td>
</tr>
<tr>
<br><br>
</tr>
</form>
</table><br><br>
</div>
</div>
<body>
<div class="bg-img">
<h1></h1>
<form class="container">
</form>
</div>
</body>
</html>
</div>
 </fieldset>
<footer align="ceneter" >
<p style="color: white" ><font size="4"><br>
Web Based Agro Farming Management System For Somali Region Fafan Zone. Prepared by JJU
CoSc GC 2020</p>
</footer>
</div>
<p>&nbsp;</p>
<!-- javascript at the bottom for fast page loading -->
<script type="text/javascript" src="js/jquery.js"></script>
<script type="text/javascript" src="js/jquery.easing-sooper.js"></script>
<script type="text/javascript" src="js/jquery.sooperfish.js"></script>
<script type="text/javascript" src="js/jquery.kwicks-1.5.1.js"></script>
<script type="text/javascript">
$(document).ready(function() {
$('#images').kwicks({
max : 600,
spacing : 2
});
$('ul.sf-menu').sooperfish();
});
</script>
</body>
</html>

5.3. Hardware software acquisitions

5.3.1. Hardware:-
  Computers: for writing code &document, design the system.

 Printer: To printing the documents

 Server: To create connection to the client computer(to host the system

5.3.2. Software:-

 Notepad++

 HTML 5 AND CSS

 PHP XAMPP

 Wamp

 EDraw Max 7

 Microsoft office 2007

 Paint

5.4. User Manual Preparation

The team has prepared a user manual entitled as a help in our system home page navigation bar
that can guide users when they get any confusion during their usage.

In order to access the system, first of all every user must have an account or permission from
system administrator. So, system administrator should have to create an account for every user
like employee of zone and Woreda. Users should enter to the system parts by using their
individual Username and password and also with the role given to them. These Username and
password is created by the system administrator. Finally the Employee of zone and Woreda can
access the system by using their Username and Password.
5.5. Training
During the deployment of the system, the team will give short time training for the system
administrators and Agricultural Expert explaining how the system works and in what way they
can manage their system.

5.6. Installation Process

Since the project is a web based System, there is no need to install it on a particular machine
rather it will be hosted on a web server. Database server will also be configured.

5.7. Start-up strategy

Once the system is hosted, it has two start-up strategies: the first start-up strategy is for the
administrator and users which require the username and password to access the system in both
cases for the administrator and users. The second start-up strategy part is the system home page
which does not require the username and password and it can be viewed by anybody.
 Chapter Six-Conclusion and Recommendation

6.1. Conclusion
In this project, we develop a web-based system that facilitates Agro office information provider
activities. The web-based system enables the user to know activities like view information about
the fertilizer, view information about crop production, view information about seeds, view the
solution, view complains, upload news, response solution and sends complains.

Our model contains analysis model which contains the functional and non- functional
requirements, use case, sequence, state chart, activity diagram, conceptual modeling of classes
and user interface prototypes. And also contains Design Model which consists Class modeling,
Component Modeling, Deployment Modeling, Persistence modeling of classes.

6.2. Recommendation

While doing this system the team has faced different challenges. But by the cooperation of all the
group members, advisor and examiners the team is now able to reach the final result.

We recommend that when the Agro office use this web-based system, it solves the problems in
the current system. Most of the time has been taken for understanding the working of existing
system, how communications are going on in existing system between zone and Woreda office
and what problems are there in the existing system. Finally, we recommend that when the
functional requirements that are not completed by us, are fulfilled by the next generation this
system is very useful to handle the Web based Agro-Farming management system for SNNPRS
Gedeo zone agricultural sector.
 REFERENCES

“Increasing Agricultural Productivity and Enhancing Food Security in Africa: New Challenges
and Opportunities”, Addis Ababa, Ethiopia, November 2011.

C. W. Bachmann (November 1973),"The Programmer as Navigator", CACM (Turing Award

Lecture 1973)"database, n". OED Online. Oxford University Press. June 2013. Retrieved July
12, 2013.

Ken North, "Sets, Data Models and Data Independence", Dr. Dobb's, 10 March 2010
Development of an object-oriented DBMS; Portland, Oregon, United States; Pages: 472 – 482;
1986

"DB-Engines Ranking". January 2013. Retrieved 22 January2013. “Ethiopia launches hotline to

give farmers information”, retrieved from

http://newbusinessethiopia.com/index.php/trade/item/75-ethiopia-launches-hotline-to-give-
farmers-information, December 15, 2015