JKU/AA/

JOMO KENYATTA UNIVERSITY

OF
AGRICULTURE AND TECHNOLOGY

IT DEPARTMENT
STRUCTURE FOR RESEARCH PROJECT
1.

STRUCTURE OF RESEARCH PROPOSAL

A) Title page to include:
i.

Title
-

ii.

A concise statement of the main topic and should identify the variables.
Should be a reflection of the contents of the document.
Fully explanatory when standing alone.
Should not contain redundancies such as a study of..or an investigation
of
Abbreviations should not appear in the title.
Scientific names should be in italics.
Should contain 12 to 15 words.
A good title should display understanding of the research problem.

Authors name and affiliation

Avoid use of words like By.. from..
Preferred order of names- start with 1st, middle followed by last name.
Full names should be used, initials should be avoided.
Titles like Dr. should not appear in the names.
Affiliation should be well illustrated i.e. A proposal/ research project submitted to
the Department of Information Technology in the School of. in partial
fulfillment of the requirement for the award of the degree of .. Jomo Kenyatta
University of Agriculture and Technology.
The year should follow at the bottom of the caption.
Note:
For proposals and final report (spiral bound) the cover page should include the title,
author and affiliation (all on one page) and centered.

JKU/AA/

B) Declaration Should include both the candidates and the supervisors declaration
and duly signed.
This proposal/research project is my original work and has not been presented for a
degree in any other University
.

Signature
Date
This proposal/research project has been submitted for examination with my approval
as University Supervisor

Signature

.
Date

Note: Paginate using roman numbers starting with the declaration page.
C) Abstract- This is a brief statement of the problem, objectives of the study, target
population, sampling technique and sample size, instruments, data collection, data
processing and analysis, key findings and major recommendations.
-

Should not exceed 1000 words.

D) Table of contents The rubric should be in title case and single spaced.
The chapter titles should be in caps and bold.
The subheadings should follow each chapter title and should be in title case.
Subheading of rows should be Chapters & Pages indicated once at the top of
each column e.g.,
CHAPTER 1
PAGE
1.1 Introduction
1
1.2 Statement of the problem2

Reference
Appendices
E) List of Tables
F) List of Figures
G) Acronyms
H) Definition of terms
-

Define terms in the text that are not common.

JKU/AA/

CHAPTER 1
INTRODUCTION
This chapter should include the following;
1.1 Background Should show understanding and genesis of the problem within your
client operations.
- Talk about the global perspective followed by the local scenario
- A checklist would assist in coining the details
1.2 Introduction- Should introduce the research area
-Talk about the global perspective followed by the local scenario.
- A checklist would assist in coining the details
1.3 Statement of the problem
Must indicate exactly what the problem is.
- Indicate why and how it is a problem. Give information to support this e.g. by use of
statistics or evidence. This should be derived from background information to
illustrate connectivity.
-It should show the magnitude and effects of the problem
-Must indicate exactly what the research problem is.
-This should be tied to your title/research area.
-This should have more than the physical problem
1.4 Proposed Solution
-State what will be developed. This research seeks to not the prototype.
-The research component should be clearly captured within the solution
-The how (e.g. the prototype of the system) should not be mentioned.
-Students need to compare recent models-globally and regionally to come up with the
best solution without giving an old technology/going backwards.
1.5 Objectives
-One general objective which should be in line with the title.
- Specific objectives- have to be in line with the variables the candidates hypothesize
to influence the phenomenon being investigated.
- Should be related to the general objective.
- Should not be questions in the questionnaire.
-These should be the students objectives-not the clients. It should be measurable
within the 8 months of the projects
-They must cover research area, an implementation one and at least one to evaluate if
they have achieved what they set out to do.
-They should be SMART (Specific, Measurable, Achievable, Reliable and Testable)
-They must be research project objectives
-They should be simple statements-not a paragraph
1.6 Research Questions/Hypothesis
- They should be in line with the specific objectives and equal in number.

JKU/AA/

- Have to be numbered (1, 2, 3..) and should be questions and not statements.
- Gives us a breakdown of the areas that would be covered.
-They should be broad areas that will bring value
-They should not have short answers that can be answered in a few words
-Research questions should be limited to research areas-NOT the clients problem or
proposed prototype
1.7 Hypothesis
-If the student is doing a hypothesis driven research, a pre-literature review is
expected where the hypothesis will be stated.
1.8 Justification
- Should illustrate why the researcher is conducting the research and whom it shall
benefit.
- Should indicate why the proposed solution will solve the clients problem.
- What is it contributing to that research area/Problem area
1.9 Proposed Research and System Methodologies
- Briefly describe the proposed System implementation methodology-An
outline of the methodology without discussions
- Justify your choice of method
- Covers the life cycle of the research
- This is only covered in the proposal
1.10
Scope
- This is a kind of a disclaimer. It should cite the focus of the study geographical area
or target group/ population.
- State what you will confine yourself to as far as the focus
Note:
- Paragraphing should be consistent. Either leave space or indent between
paragraphs.
- Spacing and indenting should not be used together.
- One sentence paragraphs are unacceptable.
- A paragraph should have a minimum of five sentences.
Table of contents should be followed by:
- List of figures/ tables- Should be labeled as per the chapters in which they are
found e.g. the first figure in chapter one should be labeled as Figure 1.1

JKU/AA/

CHAPTER 2
LITERATURE REVIEW
This chapter should include;
2.1 Introduction- Tells us what to expect to be covered
2.2 Theoretical review/Conceptual Framework
- Review the empirical and theoretical literature relevant to the problem being
investigated showing clearly the linkage of literature review to the research
questions;
- Indicate what has been done by other researchers including the methodologies
used and identify gaps. Approaches previously covered
- The hypothesized variables should be subheadings of the literature review to form
a framework that would help in analysis.
- Conceptual framework should demonstrate an understanding of what variable
influences what.
- Cite 3-5 references per key section in the text.
- Use the Original Harvard method of citation. Consistency is important in citation.
2.3 Critique of the existing literature relevant to the study. This should be derived
from the students arguments throughout the document-it should not be separate.
2.4 Summary
2.5 Research gaps

REFERENCES
Project research should have references. Minimum of 10 peer review
references. Students are encouraged to adhere to the age of the references not
be more than 5 years except in a few exceptions
APPENDICES: Instruments, Budget, work plan

JKU/AA/

2.

STRUCTURE OF PROJECT REPORT

The Final Report will include the above two chapters plus;
CHAPTER 3
SYSTEM ANALYSIS AND DESIGN
This chapter should indicate;
3.1 Introduction:
Introduction to the chapter detailing what the chapter covers.
3.2 Describe the Systems Development Methodology that is used in the research. This
is just to introduce it before the actual implementation begins.
3.3 Feasibility Study:
A statement on the project feasibility should be presented.
3.4 Requirements elicitation:
Data Collection:
-Describe the data collection tool, its preparation and how it was administered and
attach it as an appendix. Use tools like Interviews, Observation, questionnaires,
etc. This tool should be approved by the Supervisor before it is administered.
-The data collected must be relevant to the problem and based on the objectives of
the research.
-It should be useful in deducing system requirements
3.5 Data and System Analysis:
Analyze the data collected using Statistical tools (Excel, SPSS) and represent the
findings using any analytical tool (pie charts, bar graphs, line graphs, etc)
3.6 System Specification
Outline the systems requirements
3.7 In this section, you need to describe in clear, precise and non-ambiguous terms
what the application will do. Let me remind you that an important objective of
analyzing a problem is to determine two pieces of information: the information
that must be supplied to the application, and the information that the application
should produce to solve the problem. This information is what is referred to as
specifications. Depending on the software process model that you use, problem
analysis and specification document may contains models such as class diagrams,
use cased diagrams, data flow diagrams, e.t.c.
DESIGN
3.8 Specify Logical design and Physical design
-Logical designs we have tools like Rich pictures, Wire frames-Abstruct
representation of data flows, inputs and outputs of the system

JKU/AA/

-Physical design (OOSAD (Use specific standards-UML 2.x) and SSADAM

diagram)-The actual inputs and outputs processes of the system (User Interface,
Data Design, Process Designs).
3.9 System Architecture -should capture include how you have designed the system
the Client, server and middle tier
-Client/Server architecture application should be structured like a web application
with a defined client the browser- and database plus script servers
-N-tier design application should be divided into well-defined tiers like interface,
business logic, data back end
-Other should be explained by student
3.10 The technique should match the requirements analysis technique and will have
direct implications on the kinds of diagrams required:
-Object oriented design
-Process oriented and Data Oriented design
3.11

Note that the end result should be a normalized database

3.12 Suggested minimum requirements

-Explanation of scope of the system context diagram may be displayed and
explained
-Communication of major processes Detailed/Partitioned Data Flow diagram,
should not be a copy of an unpartitioned DFD or a level 0 DFD from requirements
analysis phase
-Data design entity Relationship diagram and explanation of major entities
-Interface design mock ups of forms
-Identification of components, subsystems
3.13 Other diagrams that may be present
-Use cases
-Sequence diagrams
-Class diagrams
-The design must match the functional requirements, stated requirements should
translate to some tables in the data design, interface forms.
-There should be a statement on overall system architecture
3.14 Design phase report contents
-Summary of overall system architecture
-A partitioned DFD showing various flows
-Details of entities identified from the requirements and their attributes
-Data design - Entity relationship diagram
-Interface design mockups of various forms

JKU/AA/

CHAPTER 4
SYSTEM CODE GENERATION AND TESTING,
CONCLUSIONS AND RECOMMENDATIONS
4.1
INTRODUCTION-A brief on the chapter
4.2
SYSTEM CODE GENERATION-Actual coding
4.3
TESTING-Should describe all tests subjected to your system and the results
4.4
CONCLUSIONS- Did you solve your clients problem and to what extent?
4.5
LIMITATION
- Has to be there in the final project report.
- Indicate the challenges encountered in the study that may have limited the study.
- This may include: Skills, Money, tools, etc. time is NOT a limitation
4.6

RECOMMENDATIONS- Should be derived from the conclusions

4.7
OVERVIEW OF THE CHAPTER
-The system being developed must be based on the system specifications defined in
the previous
-Must use state of the art/latest technology
Main phases are Code generation, integration, testing and documentation
-Code Generation: Has to be done according to the tools and requirements stated
earlier
-Software Integration: All components that were developed must be integratedeverything provisioned at the design and requirements specifications
Testing
Objectives of testing
- Build quality in the system developed
- Demonstrate the working capabilities of your system
- Assess progress and suitability of the system
What is testing
Testing entails subjecting the system developed by the students to set of valid inputs
to validate the outputs of the system against pre meditated set of outputs.
-Identify, design then implement the testing.
-Clearly state the Validation (e.g.Usability, Blackbox, Acceptance) and verification
tests (e.g.Smoke testing, Stress test, White box) conducted.
TESTING SCOPES THAT CAN BE ADOPTED
Gui Testing: Attempt to cover all the functionality of the system and fully exercise
the GUI itself. A GUI has many operations that need to be tested. The objective at this
point will be test sequencing of events and relevance in terms of colors and
appearance of the GUI interface

JKU/AA/

Usability testing is a technique used in user-centered interaction design to evaluate a

product by testing it on users. This can be seen as an irreplaceable usability practice,
since it gives direct input on how real users use the system.
The students should be able to test the system with their friends and peers and report
on how he peers felt about the system. A form or documentary evidence should
accompany the report to show this.
Performance testing is in general testing performed to determine how a system
performs in terms of responsiveness and stability under a particular workload. It can
also serve to investigate, measure, validate or verify other quality attributes of the
system, such as scalability, reliability and resource usage.
The system for the students should actually be subjected in stressful conditions such
as multiple entries of data ,quick succession of activities to determine its performance
level. This should then be reported back to the group for assessment by the
supervisors.
White box testing: tests internal structures or workings of a program, as opposed to
the functionality exposed to the end-user. The student should submit the flow charts
so that set of test cases are subjected to the flow and response of the system
determined from the flow chart. This would then help compare the internal
performance against expected general performance of the system.
Load testing: Load testing is a generic term covering Performance Testing and Stress
Testing. A process of testing the behavior of the Software by applying maximum load
in terms of Software accessing and manipulating large input data. It can be done at
both normal and peak load conditions. This type of testing identifies the maximum
capacity of Software and its behavior at peak time.
Regression Testing: Similar in scope to a functional test, a regression test allows a
consistent, repeatable validation of each new release of a product or Web site. Such
testing ensures reported product defects have been corrected for each new release and
that no new quality problems were introduced in the maintenance process. Though
regression testing can be performed manually an automated test suite is often used to
reduce the time and resources needed to perform the required testing.
Whenever a change in a software application is made it is quite possible that other
areas within the application have been affected by this change. To verify that a fixed
bug hasn't resulted in another functionality or business rule violation is Regression
testing. The intent of Regression testing is to ensure that a change, such as a bug fix
did not result in another fault being uncovered in the application.

JKU/AA/

Stress testing: Testing conducted to evaluate a system or component at or beyond the

limits of its specified requirements to determine the load under which it fails and how.
A graceful degradation under load leading to non-catastrophic failure is the desired
result. Often Stress Testing is performed using the same process as Performance
Testing but employing a very high level of simulated load.
This testing type includes the testing of Software behavior under abnormal conditions.
Taking away the resources, applying load beyond the actual load limit is Stress
testing.
Smoke testing: A quick-and-dirty test that the major functions of a piece of software
work without bothering with finer details. Originated in the hardware testing practice
of turning on a new piece of hardware for the first time and considering it a success if
it does not catch on fire.
Unit Testing: Functional and reliability testing in an Engineering environment.
Producing tests for the behavior of components of a product to ensure their correct
behavior prior to system integration.
This type of testing is performed by the developers before the setup is handed over to
the testing team to formally execute the test cases. Unit testing is performed by the
respective developers on the individual units of source code assigned areas. The
developers use test data that is separate from the test data of the quality assurance
team.
Acceptance Testing: Testing to verify a product meets customer specified
requirements. A customer usually does this type of testing on a product that is
developed externally.
This is arguably the most importance type of testing as it is conducted by the Quality
Assurance Team who will gauge whether the application meets the intended
specifications and satisfies the clients requirements. The QA team will have a set of
pre written scenarios and Test Cases that will be used to test the application.
Black Box Testing: Testing without knowledge of the internal workings of the item
being tested. Tests are usually functional.
Functional Testing: Validating an application or Web site conforms to its
specifications and correctly performs all its required functions. This entails a series of
tests which perform a feature by feature validation of behavior, using a wide range of
normal and erroneous input data. This can involve testing of the product's user
interface, APIs, database management, security, installation, networking, etc

10

JKU/AA/

Functional testing can be performed on an automated or manual basis using black box
or white box methodologies.
This is a type of black box testing that is based on the specifications of the software
that is to be tested. The application is tested by providing input and then the results
are examined that need to conform to the functionality it was intended for. Functional
Testing of the software is conducted on a complete, integrated system to evaluate the
system's compliance with its specified requirements.
Integration Testing: The testing of combined parts of an application to determine if
they function correctly together is Integration testing.
Testing in which modules are combined and tested as a group. Modules are typically
code modules, individual applications, client and server applications on a network,
etc. Integration Testing follows unit testing and precedes system testing.
There are two methods of doing Integration Testing Bottom-up Integration testing and
Top down Integration testing.
Bottom-up integration: this testing begins with unit testing, followed by tests
of progressively higher-level combinations of units called modules or builds.
Top-Down integration: in this testing, the highest-level modules are tested first
and progressively lower-level modules are tested after that.
Security Testing: Security testing involves the testing of Software in order to identify
any flaws ad gaps from security and vulnerability point of view.
Portability/Compatibility Testing: Testing to ensure compatibility of an application
or Web site with different browsers, OSs, and hardware platforms. Compatibility
testing can be performed manually or can be driven by an automated functional or
regression test suite.
Portability testing includes the testing of Software with intend that it should be reuseable and can be moved from another Software as well.
Conformance Testing: Verifying implementation conformance to industry standards.
Producing tests for the behavior of an implementation to be sure it provides the
portability, interoperability, and/or compatibility a standard defines.
Identification of Test case generation
A test case is a set of conditions or variables under which the student determines if the
application is working. It includes Test case ID, Condition to be tested, Expected
results and actual results. Include a column that shows if the test passed or failed.
The students should generate a minimum of 20 test cases to enable the examiners
assess the full functionality of the system. The test cases should cover each unit or
module of the system. The assumption in this scenario is that the students will have

11

JKU/AA/

five modules and so 4 test cases will be applied to each module to determine its
suitability.
A table should be generated to indicate the set of inputs and the valid outputs to be
produced from the system. These inputs will help form test cases and outputs as
assessment criteria for suitability of the system.
Software testing tools in the market:
-Selenum
-HP Quick Test Professional
-IBM Rational Functional Tester
-Silk Test
-TestComplete
-Testing Anywhere
-WinRunner
-LoadRunner
-Visual Studio Test Professional
-WATIR
REFERENCES
Research project should include references
APPENDICES
Instruments
Tables
Figures
Letters of introduction
Budget
Work plan

12