Beruflich Dokumente
Kultur Dokumente
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
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
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.
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.
10
Risk Analysis
11
Risk Type
Risk
Requirements
Estimation
Probability
Consequence
Serious
Result
Poor
configuration
control,
Rework of design
Serious
Incomplete
inefficient
project
deliverables
Unrealistic
schedule
Financial
High
Serious
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
Staff illness
Defective
Components
Replace any component that may be defective with another with known
reliability.
Requirement
changes
Organizational
Underestimated
Development Time
13
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
Hardware
TT$15000
Software
TT$17000
TT$32000
Total:
15
Work Breakdown
Activities
Planning
Deliverables/Milestones
Introduction
Description
Project Organization
Description
Risk Identification
Risk Analysis
Prioritized Risks
Risk Planning
Requirements
Proposed Budget
Work Breakdown
Project Schedule
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
Interface Specification
Report Design
Report Plan
Process Design
Coding
Coding
Code
Testing
Test Scenarios
Installation
Installation Plan
Conversion Plan
Documentation
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
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
Requirement Analysis
Design Document
Implementation
Task
Anil
Aaron
Mark
Waithe
Cooper
Chickoree
Rennie
Shane
Ramlochan Siloch
Introduction
Project Organisation
Risk Analysis
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
X
X
Report Design
4
Coding
Testing
Installation
X
X
Documentation
Training
X
23
X
X
Support
X
X
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.
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
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
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
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
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
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:
Application bridges
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 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.
MOA
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
o
In f
ic
Art
International
Agricultural
Institutions
Ar
ticl
es
Inf
o
les
Regional Agricultural
Institutions
General Public
32
1.0
Display Info
MOA
,
cts
,e
ns
General Public
o(
Pr
oj e
Re
2.0
oj e
rts
Pr
po
o(
Re
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
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
Profiles
35
System
SMS
Texting
University Staff
From
Website
to
Mobile
Farmers
From
Mobile
to
Website
Questions
/ Queries
Submit/
View
Reply
Receive/
Reply
36
General Site
37
General User
Administrator
General Profile
Admin Profile
Edit Profile
38
User
General
Guest
Administrator
Upload
data
Update
Or Edit
View
View
Reports or
Project Info
40
View
Post to
Discussion
board
USER
Login Interface
Database
41
Admin
WebSite
Database
SMS
Save changes
Update Site
Confirmation Feedback
Email Subscribers
Confirmation Feedback
Email Users
Save to Database
Load File
Confirmation Feedback
Update Site
Query Request
Confirmation Feedback
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
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
Sms Interaction
Database Management
Server (DBMS)
CellPhone
HTTP Interaction
SQL Query
Workstation
Web Server
Workstations
Database Server
Laptop
Laptops
46
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
DELETE SMS
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
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;
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
Input
Expected Output
Actual Output
Login Id
1235
Invalid Id
Password
Wewh2
Invalid Password
Test Field
Input
Expected Output
Actual Output
User Id
12398
User ID
806005303, shane1
Login Successful
Password
1234
Password
Shae1
User Id
806005303
Id already exists
Registering
53
Test Field
Input
Expected Output
Actual Output
Upload (browse
field)
doc type
Invalid file
Upload (browse
field)
Pdf document
Filename uploaded
successfully
File filename.pdf
uploaded successfully
Test Field
Input
Expected Output
Actual Output
Invalid email
ssiloch@gmail.com
Updated successfully
Thanks Shane
Update was successful
Change password
shane1, shane2,
shane2
Change successful
Change password
shane1, shane1,
shane1
Invalid password
The id and or
password combination
is invalid
Change password
shane2, shane1,
shane2
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
check_email_address
Email address
boolean
Send_id
Success message
logout
none
Success message
Error reporting
Username,password,first
name, last name, etc.
Error message
Check_userid
id
Boolean
True if id is found in
database and false
otherwise
compare_email
Userid, email
55