Group Members:

Shane Siloch - 806005303

Aaron Cooper - 807003844
Mark Chickoree - 807002487
Rennie Ramlochan - 02745022

Anil Waithe - 807002402

1

Natural Sciences Agricultural

Extension Portal

Table of Contents
Introduction ..................................................................................................................................... 4
Problem Statement ...................................................................................................................... 4
Project Objectives ....................................................................................................................... 4
Project Description...................................................................................................................... 5
Benefits ....................................................................................................................................... 6
Project Deliverables .................................................................................................................... 8
Estimated Project Duration ......................................................................................................... 8
Constraints .................................................................................................................................. 8
Project Organization ....................................................................................................................... 9
Risk Analysis ................................................................................................................................ 10
Hardware and Software Requirements ......................................................................................... 13
Servers Hardware ...................................................................................................................... 13
Servers Software ....................................................................................................................... 13
Upgrade Machines Hardware ................................................................................................... 13
Upgrade Machines Software ..................................................................................................... 14
Estimated Overall Project Cost ................................................................................................. 14
Work Breakdown .......................................................................................................................... 15
Project Schedule............................................................................................................................ 21
Deadlines................................................................................................................................... 21
Team Members Allocation ....................................................................................................... 21
Monitoring and Reporting Mechanisms ....................................................................................... 23
Development Team Communication ........................................................................................ 23
Collaboration with clients ......................................................................................................... 23
Reporting Mechanisms ............................................................................................................. 23
Requirements ............................................................................................................................ 25
General Requirements ............................................................................................................... 25
Functional Requirements .......................................................................................................... 26
Non-Functional Requirements .................................................................................................. 28
Proposed Solution for Natural Sciences Agricultural Extension Portal ....................................... 29
Feasibility Study ........................................................................................................................... 31
Context Diagram ....................................................................................................................... 32
Data Flow Diagrams ................................................................................................................. 33
Entity Relationship Diagrams ................................................................................................... 34
Use Cases .................................................................................................................................. 35
Activity Diagrams ..................................................................................................................... 38
Sequence Diagrams ................................................................................................................... 41
3

Architecture Design .................................................................................................................. 43

Architecture Design Representing Natural Sciences Agricultural Extension Portal ................ 46
Psuedo code .............................................................................................................................. 48

Introduction
Project Name: Natural Sciences Agricultural Extension Portal
Client: Agricultural Economics and Extension Department
Project Team: Group F
Problem Statement
Currently no convenient and reliable communication link exists which would allow the
University to share information and expertise with their affiliates (Farmers, Ministry of
Agriculture, Caribbean agricultural organisations and International Agricultural Institutions).
As a result, relationships and linkages between the University and the rest of the Agricultural
region have been compromised.
Project Objectives
This project would design, build and set up a web application which would allow the University
to disseminate valuable information in a simple and orderly manner which is easily accessible to
users via the internet.
Currently there exists no forum where the University, agricultural organisations, institutions
and farmers can easily exchange information with each other on a regular basis. Our project
seeks to provide such a platform.
In addition this web application will provide a communication link or virtual environment
(network) where people from the fields such as farmers can meet and communicate with
experts from the University.
Our system would be designed with the objective of sparking interest among various groups in
the agricultural sector by providing a useful and interactive web application that would enhance
their day to day lives and assist with the execution of their jobs.
With the implementation of this web application, we plan to expand the Universitys client base
and help in its extension efforts by attracting and encouraging new farmers and other agricultural
organizations and institutions to use the application.

Clients of the University and potential users of this application especially farmers work in
unique environments. They may not always have access to computers, laptops or even hand-held
internet ready mobile devices. In the past this has hindered participation among farmers in most
technology oriented projects. This application plans to break through this barrier by
implementing an SMS texting feature. This feature would permit users to interact with the
system via the use of the common cellular phone which would not require an internet
connection. It would therefore provide a simple, convenient and affordable way for the users of
the system to access technical expertise within their fields.
Additionally the web application aims to gain the trust of its users and entice them into using
technology in order to make their jobs less difficult. This objective is especially aimed
towards farmers.

Project Description
This project involves the design and implementation of a web application that would allow the
University to disseminate valuable information through the use of newsletters, bulletin boards,
interactive calendars, sharing of articles and projects currently being pursued.
The web application also seeks to encourage user participation and develop a client base for the
University. This would be done by allowing users to freely browse the application. Users will
then be encouraged to register personalized accounts with the University so that their specific
needs can be catered to. Upon registering an account the application would store data on the
preferences and interests of the user with the aim of developing detailed user profiles. These
profiles will assist in the dissemination of information that will be relevant and useful to the
user. On the Universitys side, profiles on each University staff member will be created.
With the creation of these profiles when a question or query is sent to the application, the users
profile and key words within the question or query will be cross referenced with the profiles of
all the Universitys staff members to ensure that the most appropriate staff is chosen to respond.
A comprehensive database of clients and University experts will assist in this feature.
The web application would possess an SMS feature that would allow the University and its
clients to communicate via SMS text messages. SMS text messaging is a feature which
everyone who owns a phone is familiar with. The mobile companies provide this service to
allow users to send text based messages from one mobile phone to another using mobile
numbers. In order for the web application to be able to send and receive SMS texts the
application must request the services of a third party SMS application( in our case Motorola).
The third party SMS application will provide the application with a link to a cell phone
connected to the server computer. All messages sent to this mobile number will be stored on a
server. As long as the application is up and running, messages sent this mobile number would
6

then be forwarded to the web application.

If for some reason the application is not functioning the SMS application will store all messages
on its server and forward them when the application is once again functional. On the other end,
administrators of the web application will be able to send SMS messages to groups or
individuals with accounts registered with the application via the applications interface, using
the mobile phone connected to the server as the source. A wireless internet connection on the
client's side will not be mandatory in order for this feature to work.
An interactive calendar will also be included in the web application. This calendar will allow
administrators to add events that will be displayed on the application. The calendar will include
reminders, and allow administrators to update in real-time.
Other features provided by the web application will include bulletin board, News Letter, Fact
Sheets, Article submission, links and a forum that will allow University staff to communicate
with groups of users at a time.
Benefits
This project provides numerous benefits to the different interest groups namely the farmers,
agricultural organizations (both regional and international) and the University.
UNIVERSITY
1. A platform that can be regularly used and is very accessible to all parties involved would
be set up.
2. Provides a forum where the University and all its affiliates can share information with
each other.
3. The University will be able to save on different costs such as travelling and labour with
the implementation of the web application.
4. Extension services would be greatly improved since the web application would have a
much larger reach than any existing communication link.
5. The web application would improve efficiency and the amount of queries handled per
day. This would improve the clienteles trust and increase their reliability on the system.

6. The web application will provide other universities with reliable and invaluable
information such as farmers crop output, ongoing workshops and conferences and
other information.

FARMERS
1. Farmers would be able to relay important information to different interest groups on
any problems they may experience, solutions to problems, unique approaches and
observations while on the field. This information will be shared in real-time.
2. Farmers would be able to access experts within their fields without having to wait long
periods of time or having to set up appointments. They would be able to receive quick
and reliable responses to any questions or queries they may have.
3. Farmers would also be drawn to the use of technology in their everyday work life; this
would lead to greater efficiency and increasing profits.
4. In the case of natural disasters and other emergencies, farmers can be quickly alerted
via SMS text messages and this would give them sufficient time to put preventative or
corrective measures in place to reduce or minimize any loss or damage to their crop.
5. There is no other more convenient, less expensive way to interact with the farmers than
SMS texting. This feature will give this web application its competitive edge and set it
apart from others. It will fill the missing gap in communication between the University
and farmers.
AGRICULTURAL ORGANIZATONS ( e.g ADB, Namdevco, FAO,etc)
1. Agriculture organizations, other universities and the Ministry of Agriculture would find
this web application very useful since they can easily log on to the site and find out
whats going on in the Agricultural department of the University. By viewing the
University newsletter these organizations can be kept up to date with whats going on
within the University. They can also be kept up to date with the concerns of farmers and
other clients using the site by viewing the bulletin boards and questions and queries
posted.
2.

Institutions would be able to readily access important documents such as Agricultural

reports without having to go through any long procedures. Documents would simply be
a click away.

3. Details on all research and projects being carried out by the university will be readily
available.
8

Project deliverables
Deliverable 1: Project Plan
Deliverable 2: Software Requirements Document
Deliverable 3: Design Document
Estimated Project Duration
The Extension System is estimated to take approximately three months to build.
Constraints
Every system development project has constraints which they must work under. The
Agricultural Extension Portal is no different. Some constraints of this system include:
Limited Budget - The system must be built with minimal cost to the University.
Limited Time - A prototype of the Extension System must be up and running in three
months. This may prove to be a challenge. The project team aims to achieve this by
setting early deadlines and investing extra time in requirements gathering.
Inexperienced developers - developers lack experience and will be learning during the
course of the development process.
Size of project team - the team is limited to 5 persons.
Gaining the SMS system - Discussions need to be held with the company Telios to set up
the SMS server.
Integration of the SMS system with website - Designing the application to integrate the
website with the SMS system.

Project Organisation
The project team consists of five members. The following is a list of each team member and
their responsibilities:
Project Manager/Analyst- Shane Siloch
Mr.Siloch will be responsible for directing the project team to the timely and successful
completion of the system development process. As the project manager, his responsibilities will
include the allocation of team members to particular tasks and scheduling the completion of
deliverables. Mr.Siloch will also be required to arbitrate any conflicts that may arise during the
project in addition to qualitative analysis of deliverables and the system.

Anil Waithe / Mark Chickoree Analysts / Prototype Developers

Mr.Waithe and Mr.Chickoree will be required to use the data obtained from the client and
develop formal requirements for the system. In addition they will be working on developing the
prototype. Mr.Waithe will be designing, the database and the relevant scripts required to provide
the functionality required. Mr.Chickoree will be working on the user interface, ensuring that the
web application is color coded and user friendly and adhere to the 9 heuristics.
Rennie Ramlochan / Aaron Cooper Designers
The Designers will design appropriate process and architectural design. Mr. Cooper will work
on the process design by making models and pseudo code of processes for the proposed system.
Mr. Ramlochan will work on the architectural design of the project by identifying subsystems
and creating appropriate client-server architecture.

10

Risk Analysis

Risks occur by failure:

To know who the project is intended for.
To classify the objectives of the project.
To estimate costs accurately.
To specify very precisely the end users' requirements.
To appoint a fully qualified and supported project manager.
To secure commitments from people who are needed to assist
with the project.
The possible risks that may affect the project include:

Team members unable to perform functions.

Ambiguous requirements due to key people in organization

leaving.

Poor cost and time estimation.

Failure to acquire the resources and services needed to

implement the SMS feature.

11

Risk Type

Risk

Requirements

Changes to the Moderate

requirements
require major
redesign and
rework. Customers
dont understand
the impact of
changes
Time to develop High
underestimated

Estimation

Probability

Consequence
Serious

Result
Poor
configuration
control,
Rework of design

Serious

Incomplete
inefficient
project
deliverables

Unrealistic
schedule

Financial

High

Serious

Size of software High

Tolerable

Cost overrun

Low

Catastrophic

Reduction in
project budget

Cost
High
underestimated
Low skilled staff
or
Low
if main personnel
are unavailable at
critical times due
to illness or death.

Catastrophic

Legal problems

Serious

Poorly designed
prototype

Restructure of
High
management and
staff with
intimate
knowledge of
current system and
processes leaving
the organization
Hardware and
Moderate
Software Defects

Serious

Different
Management

Problems

People

Organizational

Technology

12

overseeing project.

Serious

Poor functionality
of the system

Risk

Strategy

Organizational
Problems

Prepare documentation for the client that illustrates the benefits to the
organization that will come from the development and completion of the
project. For example show them how the system will help their extension
efforts and increase their client base.

Recruitment
Problems

Try as much as possible to outsource components and modules for

the system. This will decrease the work load and amount of personnel
needed.

Staff illness

Reorganizing team members to distribute the work load as well as ensure

that there is communication between the team about each members
specific job.

Defective
Components

Replace any component that may be defective with another with known
reliability.

Requirement
changes

Derive the impact of changed requirement. Since we using throwaway

prototyping any changes will be done at an early stages and will not create
a critical impact on the project.

Organizational

Prepare a document that shows how the project is critical in restructuring

contributing to the overall goals of the organization.

Underestimated
Development Time

Investigate purchasing of software components to reduce time in code

development. When preparing the initial work break down cater for
delays. In addition deadlines for deliverables should be set earlier than
required.

13

Hardware and Software Requirements

The following list contains the proposed hardware and software needed to upgrade the
current system.
The following is the required software to achieve the system:
PHP -this software is free and is the building block of the system. It provides server side
processing.
MySQL - this is used to construct the database which is needed to store the client data.

Php was chosen over asp and flash because php is free and open source. This in turn reduced
start up cost as well as php has a wider technical support and troubleshooting
recommendations. Php is also less resource intensive.
Mysql works hand in hand with php, as well as it is free unlike access and oracle. Mysql is
also less resource intensive.
There is also an existing internet info structure that can facilitate the system. Therefore, there
is no need for any additional resources to set up the internet access.
Dell PowerEdge T300 (Web Server)
Quad Core Intel Xeon X3363, 2.83GHz, 2x6M Cache, 1333MHz FSB
4GB DDR2, 667MHz, 2x2GB Dual Ranked DIMMs
(2) 250GB 7.2k RPM Serial ATA 3Gbps 3.5-in Cabled Hard Drive
16x DVD+/-RW, Internal SATA
Intel PRO 1000PT 1GbE Dual Port NIC, PCIe-4
3Yr Basic Hardware Warranty Repair: 5x10 HW-Only, 5x10 NBD Onsite
Servers - Application Software
Windows Server 2008
MySQL
Upgrade Machines Hardware
AMD Turion Dual Core processor 2.0 GHz or higher
3 GB of DDR2 RAM
120GB Hard Disk space or more.
15.4 LCD display or larger.
1 gigabit Ethernet
14

Upgrade Machine Software

Operating System- Microsoft Windows 7 Business
Microsoft Office Suite

Estimated Overall Project Cost

Hardware

TT$15000

Software

TT$17000
TT$32000

Total:

15

Work Breakdown
Activities

Planning

Deliverables/Milestones

Introduction

Description

Project Organization

Description

Risk Identification

List of Potential Risks

Risk Analysis

Prioritized Risks

Risk Planning

List of Proposed Solutions

Hardware and Software

Hardware and Software

Specification

Requirements

Proposed Budget

Work Breakdown
Project Schedule

Monitoring and Reporting

Activities Report
Gantt Chart

Management Reports

Mechanisms

Software Requirements

Feasibility Study

Feasibility Report

Requirements Analysis

Requirements Definition

Prototype Development

Evaluation Report

Requirement Specification

System Requirements

16

Activities

Design

Implementation

Deliverables/Milestones

Architectural Design

System Architecture

User Interface Design

Interface Specification

Report Design

Report Plan

Process Design

Coding

Coding

Code

Testing

Test Scenarios

Installation

Installation Plan
Conversion Plan

Documentation

System and User Manuals

Training

Training Sessions
Training Manuals

Support

Online Help

17

The work breakdown is where we breakdown the activities involved in the project and determine
deliverables associated with each activity. The project has 4 deliverables:
Deliverable 1: Project Plan: The document contains the following:
Introduction: This briefly describes the objectives of the project and constraints that will affect
the project management.
Project Organization: This describes the organization of the development team, the people
18

involved and their roles in the team.

Risk Analysis: This will identify possible project risks and proposed risk reduction strategies.
Hardware and Software Requirements: this specifies the hardware and software required to
carry out the development. Estimation of the prices and delivery schedule of hardware may be
included.
Work Breakdown: This sets the breakdown of the project into activities and identifies the
deliverables associated with each project.
Project Schedule: This shows the dependencies between activities, the estimated time to reach
each deliverable and allocation of team members to activities.
Monitoring and Reporting Mechanisms: This defines the management report produced, when
these should be produced and the project monitoring mechanisms used
Deliverable 2: Software Requirements Document: The consultants submit a document of the
following:
Introduction: This will define the purpose and layout of this document. Also, it will
contain acronyms, abbreviations and definitions.
User Requirements Description: This will define the general, functional and nonfunctional requirements of the new system.
Analysis Tools: This contains graphical representation of all business processes into functions
and operations that interact with the system.
Deliverable 3: Design Document: The consultants submit a document of the following:
Architectural Design: This in the process of identifying sub-systems and establishing
framework for subsystem control and communication.
Process Design: This contains graphical models and pseudo codes of the processes for the
proposed system.

19

User Interface Design: This defines the design of the software applications with the focus on
users experience and interaction of the proposed system.
Report Design: This shows how the reports are formatted and designed on the proposed system
Database Design: This shows the detailed relationship of files of the proposed system.
Deliverable 4:
Implementation: The Implementation phase involves the software design being realized and unit testing
to ensure each unit meets it specification. Ultimately each unit is integrated and tested as a complete
system to ensure that the requirements of the organization are met.
The consultants submit a document of the following:
Test Plan: Once the code is generated, the software program testing begins. Different testing
methodologies are available to unravel the bugs that were committed during the previous
phases. This task is essential for user requirements verification, which ensures product
acceptability and is also used to uncover errors, as well as the ability to demonstrate that
software functions are working the way they are supposed to by using Test plans and test cases.
The Installation and Conversion Plan: Provides instructions for performing installation and
conversion procedures at all installation sites. This plan is developed in a preliminary state in the
Build phase of the lifecycle and finalized with additional detail in the Evaluate stage.
Installation Plan: Provides a plan for installing software at user sites, including preparations,
user training, and conversion from existing systems. Identifies what is to be installed and
includes steps required for configuring or making operational: Hardware, Operating system,
Storage, Databases, Application services and other components.
Conversion Plan: Its a comprehensive document that provides first step to ensure an accurate and
successful conversion of data from the current system to the new system. The approach document
should outlining the data conversion criteria, provide an explanation and timeline for each step in
the conversion process, and include resource needs assessments. Detailed tasks within each step of
the conversion process should be provided in the conversion work plan, including verifying several
test or "mock" conversions prior to performing the actual production conversion.
User Training: The initial training classes for users are held, and training materials are delivered at
20

the classes. Training is done on the user acceptance test system, accessing the test database or a
special training database.
System Manual and Distributed User Documentation: User documentation that was finalized in
User Acceptance Testing is now distributed and in the users' possession.
Finalized System Documentation: System documentation corrected with all updates from the
testing phases is handed over to production support.
Post-Implementation Review Summary - This report is produced after the post-implementation
review meeting, and contains a summary of the project success criteria that were met, success
criteria that were not met and reasons for the problem, what we can learn from the project to
improve practices for the next project. In particular, the report should identify any techniques or
practices used in this project that worked extremely well, and which the project team feels would
benefit current and future projects.
Methodology Compliance Form: This form is initialized by the project team, and completed
by a methodology representative who has reviewed the project documentation and found it
acceptable.

21

Project Schedule
Deadlines
Deliverable

Description

Deadlines

Project Plan

22nd February, 2010

Requirement Analysis

28th February, 2010

Design Document

29th April 2010

Implementation

13th May 2010

Team Members Allocation

Deliverable

Task

Anil

Aaron

Mark

Waithe

Cooper

Chickoree

Rennie

Shane

Ramlochan Siloch
Introduction

Project Organisation

Risk Analysis

Hardware and Software

X
X

Requirements
X
Monitoring and Reporting

22

Mechanism

X
X

Work Breakdown

Project Schedule

Introduction
2

User Requirements

Description

Analysis Tools

Architectural Design

Process Design

3
Database Design

User Interface Design

X
X

Report Design
4

Coding

Testing

Installation

X
X

Documentation

Training
X

23

X
X

Support

X
X

Monitoring and Reporting Mechanisms

In order for a successful completion of this project communication amongst team members
and the client is needed.

Team Communication
Team members meet regularly during the week to discuss matters relating to the project. Also
communication using online methods such as Instant Messaging chat, sharing of Google
documents and emails would be used to supply information to the whole team as well as discuss
project matters.

Collaboration with Clients

The team would meet with the client at least once a week in order to clarify the requirements to
ensure everything is going according to plan. These meetings can also help in making sure that
the prototype being developed is to the clients liking in terms of the design.

Reporting Mechanisms
Entity Relationship diagrams, Flow Charts and Data Flow diagrams would be the reporting
methods used. These will be done using Microsoft Visio and Microsoft Access. Reports will
be given in both oral and written forms at the scheduled meetings. They would allow for a
visual representation of how the website should work.

24

Requirements
General Requirements- these serve as a basis for functional requirements specification. The
general requirements must first be identified, before the functional requirements are specified.
General requirements describe the different attributes of the system rather than the functional
features.
Functional Requirements- these outline the services that the system must provide and exactly
how it should perform in particular situations.
Non-functional Requirements- These outline the constraints that must be taken into
consideration when building the system. These requirements may specify that the system must
be reliable and efficient or that the system must be built with a certain programming language in
order to inter-operate with another system.

General Requirements
1. Provide a medium to disseminate information from the FSA to regional
collaborators, educators, farmers and other groups who share common interests.
2. Provide a communication link among FSA, regional collaborators, educators,
farmers and other groups who share common interests.
3. Make the system appealing to its target audience, especially farmers.

25

Functional Requirements
1.1.0

Bulletin Board

1.1.1

The web application must provide a board that is easily noticeable upon entering the site.

1.1.2

Only users with administrative privileges should be able to edit the bulletin board.

1.1.3

The Bulletin Board must be easily edited or updated by users with the required
privileges.

1.2.0

Newsletter

1.2.1

Previews of the newsletter should be depicted that are not demanding on resources

1.2.2

If the user chooses to see more details on a specific article they should be able to click
on a link that would lead them to it.

1.2.3

There should be an option to subscribe to the newsletter.

1.3.0

Fact Sheets

1.3.1

Fact sheets should be organized according to topic and then according to author.

1.3.2

Only users with administrative privileges should be able to enter and edit fact sheets.

1.4.0

Article Submission

1.4.1

Only articles that are approved should actually be posted on the site.

1.5.0

Question and Answer Section

1.5.1

Users should be able to post questions freely and the appropriate personnel within the
University should be forwarded the question and be able to post a reply.

1.6.0

Pictures/Videos

1.6.1

Previews or icons of pictures and videos should be provided, with the option to view the
full image or video.
26

1.7.0

Links

1.7.1

Links to other relevant sites should be provided.

1.8.0

Database

1.8.1

The database should contain all user information e.g. ID, password, field/fields of
interest, size of farm, associated organisation, contact info, e.t.c.

1.8.2

The database should also store information on all the FSA staff associated with the
website e.g. ID, password, fields of expertise, e.t.c.

1.8.3

Provisions should be made within the database for the storage and organisation of data
of different formats that may be needed upon request from the website. E.g. all articles
related to the production of sweet corn.

1.9.0

Calendar

1.9.1

The system should post reminders of important dates for farmers (Calender). Example;
when are the appropriate times to plant certain crops e.t.c.

1.9.2

The calendar should be easily updated daily.

1.10.0 Secure Login

1.10.1 The system must provide secure login for users and administrators along with their
respective privileges.

27

Non-Functional Requirements

2.2.0

The system should have sufficient memory space of approximately four gigabytes of
RAM to process all information simultaneously.

2.3.0

The users must be able to access the system anytime of day.

2.4.0

The system must have a lag time that does not exceed 7 seconds

2.5.0

The web application must be very intuitive to allow easy navigation by people with little
Information Technology proficiency.

2.6.0

Each page must be clear and easy to read and access without too much clutter.

2.7.0

The colour scheme for the web system and its pages should be consistent and not too
intense.

2.8.0

Information and feedback should be given to the user whenever there may be uncertainty
for the user while navigating the system.

28

Proposed Solution
There are various off the shelf document web content management systems. Joomla is one such
offering. Joomla is an award-winning Content Management System (CMS), which enables you
to build Web sites and powerful online applications. Many aspects, including its ease-of-use and
extensibility, have made Joomla the most popular Web site software available. Best of all,
Joomla is an open source solution that is freely available to everyone.
Joomlas content management system allows us to keep track of every piece of content on our
Web site; much like your local public library keeps track of books and stores them. Content can
be simple text, photos, music, video, documents, or just about any other type of digital media
you can think of. A major advantage of using a CMS is that it requires almost no technical skill
or knowledge to manage, since the CMS manages all your content for you.
Joomla's powerful application framework makes it easy for developers to create sophisticated
add-ons that extend the power of Joomla into virtually unlimited directions.
The core Joomla framework enables developers to quickly and easily build:

Data reporting tools

Application bridges

Custom product catalogues

Reservation systems

Communication tools

Since Joomla is based on PHP and MySQL, you're building powerful applications on an
open platform that anyone can use, share, and support. Joomla provides tools that help
users update and modify website content easily and with minimum technical effort.

It is designed to work perfectly in basic shared hosting environments, a package that is

least expensive and most common. Installer is simple and just like any other common
desktop software.

It is supported by several extensions, add-ons, and plug ins. They are written in PHP,
which is the most widely used, general purpose scripting language and best suited for
web development.

Available in many languages: Joomla is one of the few CMS which is multi-linguistic.
You can design your website with different languages using Joomla.

Maintenance: It can be a bit of a task when it comes to managing a website. Even tech
savvy professionals find it difficult to maintain a website. Let alone a lay-man. But
websites designed by Joomla are not at all difficult to maintain as it is quite user
friendly.
29

Updating: Joomla is a self-updating application. You do not have to be on a look out for
individuals or software to keep updating Joomla. A person with good knowledge of
Joomla can look into updating the application on their own.

The benefits of mobile and SMS applications include instant availability and access using cell
phones, compatibility and integration with existent information systems, real time integration
with dedicated automated devices (machine to machine, or M2M), GPS systems, SMS gateways
integration, connectivity with the web application, ease of use, friendly user interface, support
of pictures, sounds, video, and many other.
Mobile applications can be used for text messaging, communication and networking, votes,
ratings, registration systems, mobile marketing and statistics purposes, emergency systems,
checking and monitoring systems, chats and video.
The third party SMS application would provide the functionality of the SMS feature which
would be used for the relaying of messages to and from the web application to the clients
mobile device.
Unfortunately early in our development process the development team experienced numerous
difficulties when trying to integrate the web application and the SMS feature. Hence after team
deliberations, it was decided that the team would not use the Content Management System
Joomla. Instead they opted to create a tailor made Content Management System for the
application.

30

Feasibility study

Costs:
The proposed system incurs no development cost as the University already has the infrastructure
(server, bandwidth software etc.) needed for the system. However, cost in terms of time is
incurred since it would take 2-3 months to complete.
With respect to operating cost, only a small amount of bandwidth is needed as the data is in text
form. Down time in terms of system crashes is also another cost.
Benefits:
The new system would allow the distribution of information simultaneously to many individuals
via a web application. The system can serve over 50 users at once. Data can be retrieved
between 1 to 5 seconds. The feedback mechanism allows an individual to get answers to
questions they may have.
Technical:
The building blocks of the system are SQL and PHP. The team constructing the system has the
technical skills in the key areas (PHP and SQL). Therefore, creating the system would not pose
much of a problem. Again the University already possesses the required technology to drive the
system in terms of hardware, software and individuals with the skills to control the system out
of the box.
Legal:
Concerning legal issues, Trinidad in which the University is situated has no laws governing how
electronic data should be distributed. In addition, the proposed system contains data for
educational purpose. Hence there are no legal issues with the proposed system.
Schedule:
The proposed system would take 2-3 months to be completed. This estimated time is desirable
not demandable. The method of recycling code will be used to stick within the desirable time
frame.
Operational
With the proposed system the University can achieve its intended purpose to share information
with the farmers as well as the rest of the population.
31

The system accommodates those without access to a computer as they can communicate with
the system via SMS text messages (using their cellular phones) to receive important
notifications from the system when necessary. The feedback forum offered by the system would
allow the public to post questions which would be answered by the appropriate University staff.
This can contribute to educating the public about agriculture thereby increasing efficiency and
productivity in the agriculture sector and assisting with the Universitys extension efforts.
From the above findings, the proposed system proves to be feasible.

Context Diagram of Proposed Web Application System

MOA

Media (pics, videos, etc)

SMS texts

Ques/ queries

Articles

Info / profile

Questions/ Queries
Info
University Staff

SMS texts
Ans to ques/ queries

0
Web Application

SMS texts
Info
SMS texts

Farmers

Media (pics, videos, etc)

User info/ profile

Updates( calendar etc)

o
In f
ic
Art

International
Agricultural
Institutions

Ar
ticl
es
Inf
o

les

Regional Agricultural
Institutions
General Public

32

Level 1 Data Flow Diagram: Proposed Web Application System

Info (Projects, Bulletins e.t.c.)

Reports

Info (Projects, Bulletins, e.t.c.)

1.0
Display Info

MOA

,
cts

,e
ns

General Public
o(

Pr
oj e
Re

2.0

oj e
rts
Pr
po
o(
Re

Submit Articles and

media

artic

cts
,B
po ulleti
rts
ns
,

.c .
)

f
In

cl
es

D3

Regional Agricultural
Institutions

3.0

Ar
ti
S ta

Articles file

International
Agricultural
Institutions

e .t

les

In
fo

In f

ti
lle
Bu

In f

.)
.t.c

ff i

nfo

Register Users
and Staff

D1

info

User

Users file

info.

4.0
Questions/ Queries

University Staff

Questions/ Queries

Forward Questions
and Queries
Answ

Up

da

qu
ers to

te s

(to

Ques
ti

ca
le

ons/
Que
rie

D2
nd
ar

Update Discussions
.)

Queries file

Disc
ussio
ns

Discussions

SMS texts

SMS

33

upda
tes

D5

SMS texts
SMS texts

Database

SMS texts

s s
xt xt
te te

D4

6.0

SMS texts

e.t
.c

7.0
SMS texts

eri
e

5.0

Update Other
Features

D6

Farmers

Entity Relationship Diagram For Proposed Web Application System

Users
PK

send

FirstName
LastName
CropInterest
LivestockInterest
MobileNumber
SizeOfFarm
AdditionalInterests
Address
Email
Date
Password

send
FactSheets

Messages
PK

PK

MessageID

FactID
Name
Size
Type
Path

UserID
StaffID
MobileNumber
Message
Date

Subscribe
to

Respond
to

Subscribers
PK

Staff
PK

StaffID
FirstName
LastName
Certification
FieldsOfInterest
Projects
Email
MobileNumber
Password
KeyWord

UserID

SendMail
PK

MailID
UserId
TopicId
Active

34

SubscriberID
DateSubscribed
Name
Email
Date

Use Cases For Proposed Web Application System

Profiles

35

System

SMS
Texting

University Staff

From
Website
to
Mobile

Farmers

From
Mobile
to
Website

Questions
/ Queries

Submit/
View
Reply

Receive/
Reply

Messaging Questions and Answers

36

General Site

37

Activity Diagrams For Proposed Web Application System

Create user profile

General User

Administrator

General Profile

Admin Profile

Edit Profile

Activity Diagram For Profiles

38

Messaging Questions and Answers

39

User

General

Guest

Administrator

Upload
data

Update
Or Edit

View

View
Reports or
Project Info

Activity Diagram For

General Site

40

View

Post to
Discussion
board

Sequence Diagram For Proposed Web Application System

USER

Login Interface

Database

Input User Name and Password

Query Logon info with
Database

Return Result of Query

Success = continue
Else ERROR message

Sequence Diagram For Users Login

41

Admin

WebSite

Send request to Change

Database

SMS

Save changes
Update Site

Confirmation Feedback

Email Subscribers

Send Email Request

Confirmation Feedback

Send request to Upload File

Send request to Delete File

Email Users

Save to Database
Load File

Confirmation Feedback

Get All users

Update Site

Query Request

Confirmation Feedback

Delete File if exists and

Update Site

Sequence Diagram For Administrator Control Panel

42

Architectural Design

The architectural design that best represent the system, being developed for the Natural Sciences
Agricultural Extension Portal, is a Three Tier Client-Server Architecture.

Three-Tier Architecture
A Three-Tier Architecture provides greater application scalability, lower maintenance, and
increased reuse of components. Three-tier architecture offers a neutral method of building
Client/Server applications with vendors who employ standard interfaces which provide services
for each logical tier. Apart from the well defined interface of modular software, the three-tier
architecture allows any of the three tiers to be upgraded or replaced independently because of
technology change.
A Three-Tier Architecture is a client-server architecture in which the user interfaces functional
process logic (business rules), data storage and data access are developed and maintained as
independent modules, most often on separate platforms. The three-tier model is considered to be
software architecture and a software design pattern.
The 3-Tier architecture has the following 3-tiers:
Presentation Tier
Application Tier/Logic Tier/Business Logic Tier
Data Tier

Three-tier Client/Server Architecture Diagram

43

First Tier / User Interface Tier: First-tier components are responsible for presentation and user
interaction. These client components enable the user to interact with the second-tier processes in a secure

and intuitive manner. Application Server supports several client types. Clients do not access the
third-tier services directly.
This tier manages the input/output data and their display. With the intention of offering greater
convenience to the user, the system is prototyped on the Internet. The users are allowed to
access the system by using any existing web browser software. The user interface tier contains
HTML components needed to collect incoming information and to display information received
from the application logic tiers. The web visitors communicate with the web server via
application protocols, such as HTTP and SSL, sending requests and receiving replies. In our
system, the major web-scripting language exploited in designing the presentation layer is
HTML, Cascading Style Sheets PHP, Java, JavaScript and Java Server Pages (JSP).
Second Tier / Application Logic Tier: The second-tier commonly referred to as the application logic
layer, manages the business logic of the application and has access to the third-tier services. The
application logic layer is where most of the processing work occurs. Multiple client components can
access the second-tier processes simultaneously, so this application logic layer must manage its own
transactions.
The application logic tier is the middle tier, which bridges the gap between the user interfaces and the
underlying database, hiding technical details from the users. An SQL Application Server is deployed. Its
OC4J container embeds a web server, which responds to events, such as data receiving, translating,
dispatching and feed-backing jobs. Components in this tier receive requests coming from the interface
tier and interpret the requests into propose actions controlled by the defined work flow in accordance
with certain pre-defined rules.
Third Tier: Here information is stored and retrieved from a database or file system. The information is
then passed back to the application tier for processing, and then eventually back to the user. The thirdtier services are protected from direct access by the client components residing within a secure network.
Interaction must occur through the second-tier processes.
The database tier is responsible for modeling and storing information needed for the system and for
optimizing the data access. Data needed by the application logic layer are retrieved from the database,
and then the computation results produced by the application logic layer are stored back in the database.
Since data are one of the most complex aspects of many existing information systems, it is essential in
structuring the system. Both the facts and rules captured during data modeling and processing are
important to ensure the data integrity. An SQL database is deployed in our system, and the Object
Relational Model is applied to facilitate data reuse and standard adherence.
44

An Example

As an example of how this works, we created a web page that allows the user to enter
information which you wish to then enter into the database.
1. First Tier / User Interface Tier:

This layer will mainly consist of the user interface of the website i.e. the visible part of
the website. You create a web form, which allows the user to input the data into the web
form which is coded with JavaScript and HTML. So when users are entering their
information in the form, the JavaScript should make sure each field is entered properly
before sending the data to the database.
2.Second Tier / Application Logic Tier:

In the code behind web form, you handle the submit button click event, and send the
data from the form to your class, which sends the information to the database using the
table adapter that allows the data to be inserted into the table, either by a query or stored
procedure. This is basically the PHP logic part of the website. It gets the data from the
1st tier, does the logic and calls the data it needs from the 3rd tier. This layer will have
the business logic implementations and it transfers the data between the two layers.
3. Third Tier:

This is your Data Access Layer. This is the part of application that has direct access to
the database. It has functions that access the My SQL database correctly. You then
create a class, which retrieves the information from the form, checks for field validations
and then uses the table adapter to send the data to the database which then manages and
provides access to the data.

45

Three-tier Client/Server Architecture Design Representing

Natural Sciences Agricultural Extension Portal

Sms Interaction

Database Management
Server (DBMS)

CellPhone

HTTP Interaction
SQL Query
Workstation

Web Server
Workstations

Database Server

Natural Sciences Agricultural

Natural Sciences Agricultural

Extension Portal Website

Client And Staff Database

Laptop

Laptops

The Client tier:

The Client tier which is usually a web browser processes and displays HTML
resources, issues HTML requests and processes the responses. These web browsers are
HTTP clients that interact with the Web servers using standard protocols. The client is
often referred to as a thin client as very little application logic resides in the client tier. It
does have built in features to do more than just display html pages, but they too are
confined only to displaying data of various kinds. Some application logic in the form of
JavaScript is executed by browsers, but its applications are limited in scope and nature.
The advantage of this 3 tier model means that the thin client does not have to be
configured and it does not have to depend on any operating platform or additional
software. While there are subtle differences between the capabilities of different
browsers, more or less they perform similarly.

46

The Middle Tier:

The Middle Tier consists most of the application logic. It brings together the other
layers of the 3 tier. It processes the inputs it receives from the clients and interacts with
the database. This consists of the web server, web scripting language and the scripting
language engine. While the Web server will process the HTTP requests and formulate
responses, the calculation is done by the scripting language which runs on the scripting
engine. The Web Server or the HTTP server listens for the HTTP requests on a network
and return the responses that contain the requested resources. In cases where the request
requires the output after running the program and interacting with the databases, the web
server invokes the scripting engine to perform those tasks. The scripts that are executed
by the scripting engine can be embedded into static HTML pages making client-tier
integration easy. It allows for serving dynamic content and has built in libraries for fast
access to the database tier.
The Database tier:
The Database tier consists of the DBMS or the database management system and the
database. The complex application layer consists of the application logic and exchanges
data between the different layers. The top layer is usually a thin client or a browser.
The Bottom layer:
The Bottom layer or the database layer consists of the Database Management System or
the DBMS and the database itself. This database management layer manages the storage,
retrieval of data as well as allows simultaneous access, provides security, data integrity
and support applications. While a database is a collection of related data, a DBMS is a
set of components for defining, constructing and manipulating the database.
The DBMS consists of several components:a) Applications Interface or the libraries to communicate with the DBMS.
b) SQL Interpreter which is a parser to check the syntax of incoming statements and
translates them into the internal format.
c) Query Evaluator that generates different plans for evaluating a query by considering
database statistics and properties, selects one of these plans and translates it into low
level actions that are then executed.
d) Data Access: These are the modules that manage access to the data stored on disk,
including a transactions manager, a recovery manager, the main memory buffer
manager, data security manager and the file and access method manager.
A DBMS is required in this scenario, which involves multiple people accessing the data
at the same time. While it may not be required where there isn't relational data or the
data to be collected is atomic, it becomes a convenience when there are large amounts of
data that require frequent updating.
47

Psuedo code for SMS function

SENDING SMS
BEGIN IF
IF phone number AND format valid AND message entered
SEND message to cell phone to forward to recipient
ELSE
RETURN error
END IF
BEGIN IF
IF message sent received from phone
PRINT message sent successfully
ELSE
OUTPUT message delivery failed
END IF

RECEIVING SMS
//SMS is sent to the phone from a client phone transfers SMS to php function
WHILE NOT END OF message DO
EXTRACT message
EXTRACT sender mobile number
EXTRACT date received
STORE message, sender mobile number, date received
in database table smsinbox

READ SMS
48

READ database table smsinbox

IF smsinbox NOT empty
READ unread messages
FOR EACH unread message
DISPLAY message
SET message status to read
READ messages
FOR EACH read message
DISPLAY message
ELSE
OUTPUT no sms messages

DELETE SMS

DELETE FROM database- smsinbox

WHERE messageid EQUALS messageid

49

SUBCSCRIBE
READ email entered
IF email valid
IF email address already exists
OUTPUT address already exist in subscription list
ELSE
WRITE email address to subscription list
SEND email to user confirming subscription
ELSE
OUTPUT invalid email address

UNSUBSCRIBE
READ email entered.
IF email valid
SEARCH database for the email address
IF the email address exist
DELETE FROM subscribers
ELSE OUTPUT email address not registered

EMAIL SUBSCRIBERS
READ message, subject
IF message AND subject NOT empty
READ subscribers table
IF subscribers table empty
OUTPUT no subscribers
EXIT
50

FOR EACH subscriber

SEND message to email address
IF message sending failed
OUTPUT sending to email address failed

CONTACT STAFF
User chooses an area of expertise.
Search Staff table
IF the field of interest Equals the field of interest in Staff table
Displays the specific staff
Show information about the staff(name,email address, keyword, and
field of interest)
Show option to email the staff. Enter a message.
If message is Empty
Display error
Else
Validate Email address
Send message to the staff email address
Else if message sending fails
Display error
Else
Display error

51

Software Testing
Software testing is the process of validating and verifying that a software program/application
or product:

Meets the business and technical requirements that guided its design and
development;

Works as expected and can be implemented with the same characteristics.

Validation and Verification encompasses many of the activities of Software Quality Assurance.
Verification is asking the question: Are we building the product right?".While Validation is
asking the question: Are we building the right product? Validation is the process of evaluating
software to determine compliance with requirements.
The objectives of the validation and verification process are to have a system that has the
following characteristics:
Correctness product without errors.
Consistency consistent with itself and other products.
Necessity extent to which everything in the product is necessary .
Sufficiency product that is complete.
Performance product satisfies its performance requirements.
Black Box Testing.
Black-box testing is your primary weapon in the war against errors. The results of sound
black-box testing are robust and reliable modules. With this approach, you do not need internal
knowledge of the technology. All you need to know is how to activate the system and what are
the expected outcomes. We want to test the function of the module. Thus, we are only
concerned with the functional performance as it converts input into output. The philosophy is
that, for the module to work error-free, we enter all the test case inputs which produce correct
outputs, and we don't care how it is done.
Our process looks something like this:
We determine all possible classes of data values.
We select representative data from each class.
We select data at the boundaries of these classes
The objectives of module testing are to:
Design test cases to expose faults and weaknesses of the code.
Select test cases that have a high probability of finding faults due to errors of omission
and commission.
Cover the full spectrum of module inputs and module environments under combinations
that tend to uncover hidden faults.
Use stress tests and overload the module in ways that will force failure.
52

Blackbox Testing Results

Login
Test Field

Input

Expected Output

Actual Output

Login Id

1235

Invalid Id

The login credentials

entered is invalid

Password

Wewh2

Invalid Password

The login credentials

entered is invalid

Test Field

Input

Expected Output

Actual Output

User Id

12398

Invalid User Id (user Id User id must be six to

must be 6-20
twenty characters
characters)

User ID

806005303, shane1

Login Successful

Hello Shane! login

was successful!

Password

1234

Password must be 6-20

characters and consist
of both numbers and
letters

You have a weak

password!
please ensure that your
password is a mixture
of numbers and letters

Password

Shae1

Password must be 6-20

characters and consist
of both numbers and
letters

Password must be 620 letters and numbers

User Id

806005303

Id already exists

Enter mobile number

in the form country
code followed by
number

Registering

53

Enter mobile in the

form wxxxyyyzzzz

Enter mobile number

in the form country
code followed by
number

Test Field

Input

Expected Output

Actual Output

Upload (browse
field)

doc type

Only pdf accepted

Invalid file

Upload (browse
field)

Pdf document

Filename uploaded
successfully

File filename.pdf
uploaded successfully

Test Field

Input

Expected Output

Actual Output

Email

Invalid email

E-mail address doesn't

seam to be valid

Email

ssiloch@gmail.com

Updated successfully

Thanks Shane
Update was successful

Change password

shane1, shane2,
shane2

Change successful

Success password has

been changed

Change password

shane1, shane1,
shane1

Invalid password

The id and or
password combination
is invalid

Change password

shane2, shane1,
shane2

Passwords dont match

Both new password

and confirm new
password must match

Mobile Number

Uploading

Edit Account

54

White-Box Testing
This testing approach is concerned with the internal mechanism of the component. It is done by
examining the programming code to devise sample data which should exercise all parts of the
program being tested. For example, when a program has an if-statement, we want to create data
which will follow both branches, and when a program has a loop, create data which does the
loop 0, 1 and more times. Our testing is especially concerned with branch testing, path testing,
and statement testing.
Whitebox Testing
Function

Input

Output

Supposed to do

db_connect

none

Connect to database

working

check_email

Email address

boolean

True if email is in use,

false if email is new

check_email_address

Email address

boolean

True if email is valid,

false if it isnt

Send_id

Id, password, name

Success message

Sends email with user

account details to user

logout

none

Success message

Destroy session and

logs out user

Error reporting

Username,password,first
name, last name, etc.

Error message

If input does not meet

requirements display an
error message

Check_userid

id

Boolean

True if id is found in
database and false
otherwise

compare_email

email

Userid, email

True if email is correct

and false otherwise

55