MASENO UNIVERSITY

COMPUTER SCIENCE DEPARTMENT

YEAR IV PROJECT REPORT

STRUCTURE AND FORMAT

A) Title page/Cover page. The title page should have:-

i. Project Title
- 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.

ii. Author’s 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 project submitted to the Department of

Computer Science in the School of computing and information technology…………. in
partial fulfillment of the requirements for the award of the degree of …….. Maseno
university

The year should follow at the bottom of the caption.

Note
The title, author and affiliation should all appear on one page (page 1) and centered.
B) Declaration – Should include both the candidate’s and the supervisor’s declaration and
duly signed.

This project is my original work and has not been presented for a degree in any other
University
…………………. …………………
Signature Date
Names Reg number
This project has been submitted for examination with my approval as University
Supervisor

……………… ……………….
Signature Date
Names
Maseno,Kenya

C) Acknowledgements – appreciate those that directly contributed to the success of your

project, e.g. project sponsor (if you had any), your lecturers, supervisors, technicians,
fellow students, e.t.c.

D) 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. It is a summary of the
project as a whole

- Should not exceed 400 words.

E) 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 problem…………………….. 2

References
Appendices

F) List of Tables

G) List of Figures
H) Acronyms and Abbreviations

I) Definition of terms

- Define terms in the text that are not common.

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
o Paginate using roman numbers starting with the declaration page.
 o CHAPTER 1

INTRODUCTION

This chapter should include the following;

1.1 Statement of the problem (What is problem that your project is addressing?)
Must indicate exactly the problem the project is attempting to solve.
- 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.2 Proposed Solution (what is your proposed solution?)

-State your proposed solution. This research sought 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.3 Objectives/Aims (what are aims and objectives of your project?)

-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 student’s objectives-not the client’s. 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.4 Research Questions (what are the research questions?)

- They should be in line with the specific objectives and equal in number.
- 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 client’s problem or
proposed prototype
 1.5 Justification (justify the need to undertake the proposed project)
- Should illustrate why the researcher is conducting the research and whom it shall
benefit.
- Should indicate why the proposed solution will solve the client’s problem.
- What is it contributing to that research area/Problem area

Note: you need also to summarize the structure of the rest of the report contents
`Change the objectives to evaluations`
 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

Note:
You should consult 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
 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
 -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
 CHAPTER 4

SYSTEM CODE GENERATION AND TESTING,

4.1 SYSTEM CODE GENERATION-Actual coding

4.2 TESTING-Should describe all tests subjected to your system and the results
4.3 CONCLUSIONS- Did you solve your client’s problem and to what extent?
4.4 RECOMMENDATIONS- Should be derived from the conclusions

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 integrated-
everything 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
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.

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 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 re-useable
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 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

CHAPTER 5 CONCLUSIONS AND RECOMMENDATIONS

REFERENCES
- List all the materials e.g. books, journals, conference papers, internet materials cited
in the report.
- Use either Harvard referencing style or APA referencing style
- Consult a minimum of 10 peer reviewed references, i.e. journals. Students are
encouraged to adhere to the age of the references not be more than 5 years except in a
few exceptions

APPENDICES
Should contain materials that are peripheral to the body of the report, e,g.
- Test cases and test data
- Users’ manual
- Instruments e.g. a sample questionnaire
- Budget
- Work plan
- Source Code (Not all source code as they can consume many pages. Save part of the
source in a CD). Submit that CD together with the project report.