PROJECT WORK FORMAT AND GUIDELINES

Title of the Project work the fewest possible words that describes the content of the project.

They identify the main issue of the project, they relate directly to the subject, it must be;

accurate, concise, specific, unambiguous, complete, devoid of abbreviations, easy to extract the main content,
attract readers by communicating appeal.

5 main chapters

1. Introduction

2. Literature Review

3. Methodology/ Systems Analysis and design

4. Implementation/ Results and Discussion

5. Conclusions/ Recommendations

CHAPTER I

INTRODUCTION

1. Introduction
- Introduction

An introduction should be sufficiently interesting to motivate a reader to consider reading the rest of the paper.
The introduction thus comprises:

• Sufficient background information to enable a reader understands the context and significance of the issue or
problem that was addressed.

• A statement of the goal of the project: why the study was undertaken, or why the software was developed.

• Proper acknowledgment of any previous work that is being built upon. Sufficient references such that a reader
could follow to get further understanding of the context and significance of the problem.

• A "road map" guiding the reader as to what lies ahead.

Here is the actual problem.

What goes into chapter one that is the INTRODUCTION:

1.1 Background of Project

- general perspective of the project area

- reasons for choosing the topic

-introduce the case study

1.2 Problem Statements

Where the problem of the case study is stated or opportunity thereof.

describe the problem to be solved or the opportunity to take advantage of.

Bullet the problems if possible

1.3 Aim and objectives

state the aim of the project (the aim is always linked to the project topic)
1.3.1 Objectives

State/list the various objectives i.e. problems derived into smaller part or modules

1.4 Significance of Project Work

State the benefits/importance of the project work when it is finished to the case study.

1.5 Scope
State the project areas to cover or areas not covering.

state the areas you will cover and those you will not cover with respect to your case study

1.6 Limitations
State any constraints/hindrances faced as a developer during the project work.

state the constraints or difficulties you met during the project.

- come at last end of the project.

1.7 Organisation of the Project Work.

Write briefly about each chapter and stating what the chapter is about.

CHAPTER II
LITERATURE REVIEW

Here is how I studied/ reviewed the work. Thorough evaluation and analysis and discussions of works related to
your work. Follow trends.

A good literature review provides an overview of the field of inquiry by describing, summarizing, evaluating,
clarifying and integrating the contents of primary or original scholarly material in that field. This is done so as
to:

• Justify the necessity for the current research work or development process

• Identify gaps in the literature pertaining to the particular issue or topic under study

• Avoid repeating work that has already been done

• Identify materials, methods and approaches that could be relevant to one's project

• Identify other people working in the same field etc.

For projects that involve developing software solutions, the literature review might involve looking at related
systems - what specific solutions are out there, how they were developed, how they work, how effective (or
ineffective) they are at addressing the unique problem under consideration etc. All this should serve to justify
the need for developing a particular software, the appropriate materials to use, "best-practice"
approaches to adopt etc.

Introduction

Introduce the chapter here and lay what entails in the rest of the chapter

2.1 Overview of the Project Work Area

Give the general overview of the project work and narrow it down to the study area.

Summarizing, evaluating, clarifying and integrating the contents of primary or original scholarly material in
that field. This is done so as to:

• Justify the necessity for the current research work or development process

• Identify gaps in the literature pertaining to the particular issue or topic under study

• Avoid repeating work that has already been done

• Identify materials, methods and approaches that could be relevant to one's project

• Identify other people working in the same field etc.

2.2 Review of Other Related Systems

Review related works and state how different they are to your project work.

For projects that involve developing software solutions, the literature review might involve looking at related
systems - what specific solutions are out there, how they were developed, how they work, how effective (or
ineffective) they are at addressing the unique problem under consideration etc. All this should serve to justify
the need for developing a particular software, the appropriate materials to use, "best-practice" approaches to
adopt etc.

2.3 Technical Review

Review of technical tools if any.

2.4 Summary
*** you must provide referencing here. In fact most of your references will come from this
chapter. Remember we use the IEEE referencing style.

CHAPTER III

METHODOLOGY/SYSTEM ANALYSIS AND DESIGN

(if you are doing system development then use System ANALYSIS AND DESIGN, but if you are working on
research then use METHODOLOGY)

here is how I did the workable. How did you do it steps you followed.

Methods employed and clarifications of rationale of using a procedure. Provide materials used, data
collection/sources, analytical/statistical techniques used, the study target or area. Include flow chart, maps,
graphs, figures, tables, screenshots, GUI.

This section gives a detailed account of the research or development processes and must be written in a way
that will allow a reader to assess the believability and credibility of the outcomes. It should also be written in a
way that will enable another researcher replicate the research (or key algorithms) and arrive at the same or
similar results. The section therefore involves description of the materials, equipment and technologies used,
data sources, strategies adopted, how, where and when data was gathered and analysed, assumptions made etc.
It is therefore not enough to say for example, interviews were conducted or survey questionnaire were used to
collect data etc. The day, date and time of each interview, who comprised the interviewer(s) and interviewee(s),
how long, what questions etc. must all be clearly spelt out.

For software developers, all issues pertaining to how one arrived at the particular application being developed
must also be addressed here, i.e. problem analysis, systems analysis, prospective user demands and
expectations, hardware and software availability and limitations etc.

Introduction

This chapter describes how the project work is done i.e. methods used

3.1 Initial Data Collection Methods

State the initial data collection methods used and how you collected them and also, the kind of data collected.

3.2 System Development Methodology Used.

State the SDLC method used and why you used that method

State what you did at every stage of the method

3.3 System Analysis

Analyse the project work thoroughly

3.3.1 Analyse/Review of Existing System

Details of the case study describing in details the case study

Describing the existing system as it is now

Analyse the system thoroughly

3.3.2 Analyse the Proposed System

Describe the proposed system

State how the new system tackles the problem of the existing system

State the features of the new system that handle various problems

3.3.3 Feasibility Studies

Analyse the system from Technical, Economic, organizational etc point of view (feasibility studies)

State technical, economical, organisational and feasibility analysis

3.4 System Design

3.4.1 System architecture

Give the system architecture to show a clear pictorial view of the system.

3.4.2 Design diagrams

Give the ERD, DFD, sequence diagram, use case diagram, activity diagram etc.

3.5 Systems Requirement/Tools

State hardware and software requirement of the system.

 CHAPTER IV

IMPLEMENTATION

Here is what I found or what I did

Discussion: say the significant of the results.

State the results and discuss the implications (state and discuss)

The results are actual statements of observations, including statistics, tables, graphs and screenshots of
software interfaces. Sufficient details are presented to enable readers draw their own inferences and construct
their own explanations.

For software development projects, this section must give an account of usability testing results. If the system
was implemented, user impressions, questions and comments should also be presented. The tendency is always
for students to leave out any negative or nonconforming results, but this is not acceptable. All positive and
negative outcomes must be reported.

Results are then interpreted and discussed in a way that will help answer the original research question or
problem and also give indications as to whether the outcomes are significant. The student does not explicitly
state that the results are excellent, significant etc. Whatever is written here should help a reader answer the
question - what are the things we now know or understand (or can now do) that we didn't know or understand
(or could not do) before the present work?

Introduction

Introduce the chapter and state what the rest of the chapter entails.

Where the design is actually implemented

4.1 Testing

Show how you tested the system by showing all the steps in testing a system.

4.2 Implementation

Show screen shoot of the system modules

Give description of the modules shown.

4.3 Cost Analysis (if any)

Give the cost analysis of the project work or the research. How match each component cost and the total cost
involved in the project.

4.4 Summary
 CHAPTER V

CONCLUSION AND RECOMMENDATION

Conclusion: here is what the results mean. A brief summary of the results. Compare your results to a previously
published results.

Recommendations: here is what I propose/suggest. Proposal for future works, any improvement for the project.

This is the final section of the thesis, and in this, the student refers back to problem posed, summarizes the key
steps taken to help address the problem and describes the conclusions that were reached based on the outcomes
of these steps. In so doing, there is an opportunity to suggest to a reader that what the project set out to do had
either been accomplished or not. This must however be based solely on the results and not from general
knowledge or the student's own imagination.

Since the project set out to solve a problem or address an issue, it is good practice to make some
recommendations as to how the NEW knowledge (or software solution) obtained 10 from the research, or
development process can be applied in the particular context or similar situations. Recommendations are
therefore based strictly on the findings and conclusions of the study, and should be written as suggestions and
not as arguments or instructions.

5.1 Summary

Give summary of the project work

5.2 Conclusion

Here answers the question “was the aim achieved?”

What is the meaning/significance of the result?

5.3 Recommendation

Give recommendation on two fronts

 For future developers. Suggestion to help any future expansion or developing a similar system
 For usage. Suggest as how the system could be used optimally

REFERENCES

Referencing Style
All scholarly writings in the Department of Computing must follow the IEEE referencing
style. In this style, citations are numbered, but these numbers are included in the text in
square brackets as [1] and not as superscripts. All bibliographical information is then
included in the list of references at the end of the document, next to the respective citation
number. Below are a few examples of IEEE citation referencing style, but students are
advised to consult the full document at: http://www.ieee.org/documents/ieeecitationref.pdf
For books:
[1] A. Author and B. Author, "Title of book." City of Publisher: Abbrev. of Publisher, year.
[2] A. Author, "Title of chapter in the book," in Title of Published Book, xth ed. City of
Publisher: Abbrev. of Publisher, year, ch. x, sec. x, pp. xxx–xxx.
Example:
[1] J. Doe and P. Brown, "Robot Vision." Cambridge, MA: MIT Press, 1986.
[2] L. Stein, "Random patterns," in Computers and You, J. S. Brake, Ed. New York:
Wiley, 1994, pp. 55-70

For Periodicals
[3] A. Author, "Name of paper," Abbrev. Title of Periodical, vol. x, no. x, pp. xxx-xxx,
Abbrev. Month, year.
Example:
[3] R. E. Kalman, "New results in linear filtering and prediction theory," J. Basic Eng.,
vol. 83, pp. 95-108, Mar. 1961.

For Websites
[4] A. Author. (year, month day). Title (edition) [Type of medium]. Available: http://(URL)
Example:
[4] J. Jones. (1991, May 10). Networks (2nd ed.) [Online]. Available: http://www.atm.com

Number of References:
BSC degree up to 30
Msc degree up to 50.
APPENDICES
-contain information that are not essential but support your analysis or validate your
conclusions.
- there is no limit to what you place here.
Questionnaires are mostly placed under appendices

Add any additional material you think should be part of the work.

************************************************************************

Prefatory Pages

ABSTRACT

must be informative and indicative

abstract has 6 things:

1. they are summary of work that has been done (past tense)

2. should not be more than one page (2/3 of a page)

3. a sentence or two summarizing each of the 5 chapters.

4. no new information, no supporting materials, limited essentials.

5. it condenses the whole paper into miniature form.

6. it is a one paragraph summary of project.

7. should always be written last.

Contains the following:

Introduction/Problem statement,

Aim,

Method and tools used,

Results found,

Conclusions and recommendations.

DEDICATION

There is no dedication in under graduate project work.

ACKNOWLEDGEMENT

Acknowledge the people who help you in doing the project work especially
Your project supervisor, Lecturers ( if they helped you), HoD (if they helped you), Dean (if they helped you),
fellow students (if they helped you), Parents and Guardians who contributed in your up keeps, etc.

Format of the Thesis

Presentation
Thesis must be presented in a permanent and legible form in typescript or print.
Photographic and other illustrations should be permanently mounted on international standard
A4 size paper and bound in with the thesis. In no circumstances should 'sellotape' or similar
materials be used for any purpose.

Print and Paper

Plain white A4 size (30 cm x 21 cm) paper of good quality and of sufficient opacity for
normal reading should be used. Standard photocopy paper is perfectly acceptable. Text
should be printed in black ink, on one side of the page only. This prevents show-through and
helps to ensure that photocopies are clear.

Font Character and Line Spacing

The university accepts a 12 point size Times New Roman type face of letter quality black
printing only, except for footnotes where 10 or 11 point size may be acceptable.
Corrections (with typewriter correction fluid) are not acceptable. Double line spacing should
be used in the main text. However, single spacing should be used for block quotations and
footnotes. All candidates are required to type their own thesis.

Layout & Word Processing

Margins should be 4 centimeters (1½ inches) wide on the left-hand side (i.e. binding edge)
and not less than 2 centimeters (0.75 inches) on the right-hand side of the paper. Top and
bottom margins should be set at 2.5 centimeters (1 inch). Text should be justified.

Pagination
All pages must be numbered in one continuous sequence, i.e. from the first page to the last
page. This sequence must include everything bound in the volume, including maps, diagrams,
blank pages, etc. Any material which cannot be bound in with the text must be placed in a
pocket inside or attached to the back cover.

Indentation
No first line of paragraph indentation throughout the dissertation.

Footnotes
If footnotes are used, they are placed at the bottom of the page and indexed in the text by
superior Arabic numbers raised a half-space above the line. The numbers should begin with 1
and continue sequentially throughout the text. In situations where multiple numbers are used,
there should be no spacing between them, and they follow (not precede) punctuation such as
a period, comma or closing quotation mark.

Word Limits
A bachelors' degree thesis should not exceed 12,500 words (about 50 pages) for the main
text. The word limit does not include appendices, essential footnotes, tables and figures,
introductory parts and references.

Text
The text of the thesis usually has an introductory chapter followed by the report of the study
divided into chapters. Chapter One is the first page, and each chapter begins on a new page.
The number of each chapter is given in capital Roman numerals and its title in capital letters,
for example:

Tables, Figures, Charts and Illustrations

Tables and figures must have at least a 1½-inch left margin. They are numbered
consecutively within each chapter of the thesis and given page numbers. They are listed
numerically by number, title and page number in the appropriate named List in the prefatory
section. In exceptional cases oversize tables or charts may be added provided that the 1½-
inch left margin and proper pagination is maintained. Still larger tables and charts may be
typed full size and then reduced to fit on the page. The candidate may also insert illustrations
of any size, but the 1½-inch left margin must be maintained for binding purposes. All
illustrative pages must be included in the consecutive numbering of pages. If a table or figure
is depicted in landscape format the page remains in portrait format; only the object is
produced in landscape, and pagination continues in the bottom center. A landscape format
table or figure must read outward (i.e., the bottom must be at the right margin).

The Oral Presentation

The oral presentation, which makes up 40% of the final grade, is examined for content,
delivery and responses to questions. The grading criteria will thus involve looking at the
student's:
 Ability to clearly articulate the problem, objectives, significance of the study, and to
place the research in the proper context or perspective
 Ability to explain the research or system design and how it is derived from the
literature or system reviews etc.
 Ability to discuss clearly and in detail how the study or development was executed
 Ability to prove the usefulness of project output or results
 Clarity of deliver y and appropriateness of responses to questions
 General appearance, composure and exhibiting a sense of being in control
 Ability to provide evidence that he/she actually did the work him/herself. Thus
students who conduct surveys must present ALL the responses (if they are paper
based), or for online surveys, show the website with the responses etc. Students who
develop software must show the coding and development processes.
The Written Thesis
The written thesis (60%), is assessed by at least two readers - an internal examiner who is
usually a lecturer in the student's department, and an external examiner who is usually a
lecturer in an affiliated institution. The grading criteria include the following:
 Abstract - how it appropriately summarizes the whole work
 Introduction: background, context, problem etc. - how clearly articulated
 Research questions, objectives, significance - how clearly discussed in relation to the
problem
 Thoroughness of literature or system review
 Methods used - their appropriateness and correct execution
 Correct discussion and interpretation of the findings (or evidence that a software
solution achieves stated objectives)
 Clarity and cohesiveness of content, including grammar, spellings etc.
 Text formatting, pagination etc. adhere to the guidelines outlined in the thesis manual
 Overall relevance of the project