Title of Project Report: Format of Cover Page (Hard Bound For 8 Sem and Spiral Bound For 7 Sem)
Title of Project Report: Format of Cover Page (Hard Bound For 8 Sem and Spiral Bound For 7 Sem)
by
Department of .................................
Name of Institute
Address of Institute
Month, Year
(Example of Title Page)
by
Bachelor of Technology
in
<Discipline>
<Institute's Logo>
<Institute Name>
<Month, Year>
VISION OF THE DEPARTMENT:
To spark the imagination of the Computer Science Engineers with values, skills and creativity
to solve the real world problems.
Mission 1: To inculcate creative thinking and problem solving skills through effective
teaching, learning and research.
Mission 2: To empower professionals with core competency in the field of Computer Science
and Engineering.
Mission 3: To foster independent and life-long learning with ethical and social
responsibilities.
PEO1: To empower students with effective computational and problem solving skills.
PEO2: To enable students with core skills for employment and entrepreneurship.
PEO4: To foster students with research oriented ability which helps them in analyzing and
solving real life problems and motivate them for pursuing higher studies.
PROGRAMME OUTCOMES:
Engineering Graduates will be able to:
PO1. Engineering knowledge: Apply the knowledge of mathematics, science, engineering
fundamentals, and an engineering specialization to the solution of complex
engineering problems.
PO2. Problem analysis: Identify, formulate, review research literature, and analyze
complex engineering problems reaching substantiated conclusions using first
principles of mathematics, natural sciences, and engineering sciences.
PO3. Design/development of solutions: Design solutions for complex engineering
problems and design system components or processes that meet the specified needs
with appropriate consideration for the public health and safety, and the cultural,
societal, and environmental considerations.
PO4. Conduct investigations of complex problems: Use research-based knowledge and
research methods including design of experiments, analysis and interpretation of data,
and synthesis of the information to provide valid conclusions.
PO5. Modern tool usage: Create, select, and apply appropriate techniques, resources, and
modern engineering and IT tools including prediction and modelling to complex
engineering activities with an understanding of the limitations.
PO6. The engineer and society: Apply reasoning informed by the contextual knowledge to
assess societal, health, safety, legal and cultural issues and the consequent
responsibilities relevant to the professional engineering practice.
PO7. Environment and sustainability: Understand the impact of the professional
engineering solutions in societal and environmental contexts, and demonstrate the
knowledge of, and need for sustainable development.
PO8. Ethics: Apply ethical principles and commit to professional ethics and
responsibilities and norms of the engineering practice.
PO9. Individual and team work: Function effectively as an individual, and as a member
or leader in diverse teams, and in multidisciplinary settings.
PO10. Communication: Communicate effectively on complex engineering activities with
the engineering community and with society at large, such as, being able to
comprehend and write effective reports and design documentation, make effective
presentations, and give and receive clear instructions.
PO11. Project management and finance: Demonstrate knowledge and understanding of
the engineering and management principles and apply these to one’s own work, as a
member and leader in a team, to manage projects and in multidisciplinary
environments.
PO12. Life-long learning: Recognize the need for, and have the preparation and ability to
engage in independent and life-long learning in the broadest context of technological
change
COURSE OUTCOMES
C410.1: Identify, formulate, design and analyze a research based/web based problem to
address societal and environmental issues.
C 410.3: Apply appropriate computing, engineering principle and management skills for
obtaining effective solution to the formulated problem within a stipulated time.
CO-PO-PSO MAPPING
COs PO1 PO2 PO3 PO4 PO5 PO6 PO7 PO8 PO9 PO10 PO11 PO12 PSO1 PSO12
C410.1 3 3 3 3 2 3 3 3 3 3 2 3 3 3
C410.2 2 2 2 2 2 2 2 2 2 3 2 3 2 2
C410.3 3 3 3 3 3 3 2 3 3 3 3 3 3 3
C410.4 3 3 3 3 2 3 2 3 3 3 3 3 3 3
(Example of Declaration- makes only one certificate for entire team)
DECLARATION
We hereby declare that this submission is our own work and that, to the best of our
knowledge and belief, it contains no material previously published or written by another
person nor material which to a substantial extent has been accepted for the award of any
other degree or diploma of the university or other institute of higher learning, except where
due acknowledgment has been made in the text.
Signature:
Name :
Roll No.:
Date :
Signature:
Name :
Roll No.:
Date :
Signature:
Name :
Roll No.:
Date :
Signature:
Name :
Roll No.:
Date :
(Example of Certificate-make only one certificate for entire team)
CERTIFICATE
Supervisor
Date
(Example of Acknowledgement)
ACKNOWLEDGEMENT
It gives us a great sense of pleasure to present the report of the B. Tech Project undertaken during B.
Tech. Final Year. We owe special debt of gratitude to Professor Anshuman Singh, Department of
Computer Science & Engineering, College of Engineering, Lucknow for his constant support and
guidance throughout the course of our work. His sincerity, thoroughness and perseverance have been
a constant source of inspiration for us. It is only his cognizant efforts that our endeavors have seen
light of the day.
We also take the opportunity to acknowledge the contribution of Professor M. S. Dhoni, Head,
Department of Computer Science & Engineering, College of Engineering, Lucknow for his full
support and assistance during the development of the project.
We also do not like to miss the opportunity to acknowledge the contribution of all faculty members of
the department for their kind assistance and cooperation during the development of our project. Last
but not the least, we acknowledge our friends for their contribution in the completion of the project.
Signature:
Name :
Roll No.:
Date :
Signature:
Name :
Roll No.:
Date :
ABSTRACT
VISION i
MISSION i
PROGRAMME EDUCATIONAL OBJECTIVES i
PROGRAM OUTCOMES ii
PROGRAM SPECFIC OUTCOMES iii
COURSE OUTCOMES iii
CO-PO-PSO MAPPING iii
DECLARATION ................................................................................................... iv
CERTIFICATE ..................................................................................................... v
ACKNOWLEDGEMENTS .................................................................................. vi
ABSTRACT ........................................................................................................... vii
LIST OF TABLES.................................................................................................. viii
LIST OF FIGURES................................................................................................ ix
LIST OF SYMBOLS .............................................................................................. x
LIST OF ABBREVIATIONS ................................................................................ xi
CHAPTER 1 1
1.1. ................................................................................................................. 5
1.2. ................................................................................................................. 8
CHAPTER 2 ……………………………. ......................................................... 13
2.1. .................................................................................................................. 15
2.2. .................................................................................................................. 17
2.2.1. ......................................................................................................... 19
2.2.2. ......................................................................................................... 20
2.2.2.1. ................................................................................................ 21
2.2.2.2. .......................................................................................... 22
2.3. ................................................................................................................. 23
CHAPTER 3 …………………………….......................................................... 30
3.1. ................................................................................................................ 36
3.2. ................................................................................................................ 39
CHAPTER 4 (CONCLUSIONS) ......................................................................... 40
APPENDIX A ......................................................................................................... 45
APPENDIX B ......................................................................................................... 47
REFERENCES... .................................................................................................... 49
LIST OF TABLES
LIST OF FIGURES
(Example)
LIST OF SYMBOLS
≠ Not Equal
∈ Belongs to
€ Euro- A Currency
_ Optical distance
LIST OF ABBREVIATIONS
INTRODUCTION
It is the first chapter of the Report. The purpose of an introduction in the B. Tech Project
Report is to justify the reasons for writing about the report. The goal in this section is to
introduce the topic to the reader, provide an overview of previous research on the topic, and
identify the own hypothesis. The goals just mentioned could, if abused, lead to write an
introduction that is pages and pages long. It can be noted here that the introduction should not
contain every bit of detail in the report, and it should not include support for the report. An
introduction might, however, include the reasons for supporting the report.
In order for readers to trust the writer, the introduction must be well written with few errors.
In order to keep readers reading, the writer needs to catch the attention of the reader and write
in an interesting way. The unique language enhancement feature may suggest words to
strengthen the writing. Strong writing may hold readers' attention.
In addition to well-written English with strong vocabulary, there are a few other strategies to
hold readers' attention. It should be noted that to excite the readers' interest, one may also
want to sound as though the readers know the topic that are considered in the report. Some of
the following strategies in the bullet-list above may help.
• To pose a specific question that can invite the readers to keep reading for the
answer-- A provocative question works well to engage readers, so long as it
doesn't put them off
• To choose statistics to surprise readers or to go against the common belief about a
topic
• To mention a short, interesting anecdote (or story) related to the topic
It has been observed that the difficulty level to write the Introduction is average and it takes
the variable amount of time. Following sub headings are to be included in this chapter
depending on the project-
1.1.1. Motivation
It briefly includes previous work carried out in this field, researching the problem
studied, summarization of the results obtained etc
Literature Survey
(LITERATURE SURVEY FORMAT FOR NON-WEB BASED PROJECTS)
● A brief description of what is studied in the survey should be given in a paragraph of 6-10
lines (approx.) this paragraph should not contain any title.
● Then you can elaborate on each technique/algorithm/ technology depending on your project
section wise. For example if literature survey is for face recognition then all existing
approaches should be mentioned in a separate section.
● Each section should contain a heading and should be numbered. It can also contain images,
formulae, flow chart and tabular data that are needed for explanation. Each section size
should not exceed 1 to 1.5 pages.
● Use citations from the References section where ever required-
Example- A pun, or paronomasia, is a form of word play that deliberately exploits
[1]
ambiguity between similar-sounding words for humorous or rhetorical effect. (If the
contents are taken from reference 1 of References section).
● Any included image, formula, flow chart or tabular data should be numbered and should be
referred in the respective section. Tables numbering should appear on the top of table and
figure numbering should be below the figure.
● At the end of the literature survey chapter, include a summary section with the heading
SUMMARY. In this section sum up the above studied techniques/algorithms/ technologies
paragraph wise.
CHAPTER 2
(For Web Based Projects)
Software Requirement Specification
Describe the general factors that affect the product and its requirements. This section does not state
specific requirements. Instead, it provides a background for those requirements, which are defined in
section 3, and makes them easier to understand. In a sense, this section tells the requirements in plain
English for the consumption of the customer. Section3 will contain a specification written for the
developers.
Put the product into perspective with other related products. If the product is independent and
totally self-contained, it should be so stated here. If the SRS defines a product that is a component of
a larger system, as frequently occurs, then this subsection relates the requirements of the larger
system to functionality of the software and identifies interfaces between that system and the software.
If you are building a real system, compare its similarity and differences to other systems in the
marketplace. If you are doing a research-oriented project, what related research compares to the
system you are planning to build.
A block diagram showing the major components of the larger system, interconnections, and external
interfaces can be helpful. This is not a design or architecture picture. It is more to provide context,
especially if your system will interact with external actors. The system you are building should be
shown as a black box. Let the design document present the internals.
The following subsections describe how the software operates inside various constraints.
List each system interface and identify the functionality of the software to accomplish the system
requirement and the interface description to match the system. These are external systems that you
have to interact with. For instance, if you are building a business application that interfaces with the
existing employee payroll system, what is the API to that system that designer’s will need to use?
2.1.2 Interfaces
Specify:
(1) The logical characteristics of each interface between the software product and its
users.
(2) All the aspects of optimizing the interface with the person who must use the system
This is a description of how the system will interact with its users. Is there a GUI, a command line or
some other type of interface? Are there special interface requirements? If you are designing for the
general student population for instance, what is the impact of ADA (American with Disabilities Act)
on your interface?
Specify the logical characteristics of each interface between the software product and the hardware
components of the system. This includes configuration characteristics. It also covers such matters as
what devices are to be supported, how they are to be supported and protocols. This is not a
description of hardware requirements in the sense that “This program must run on a Mac with 64M
of RAM”. This section is for detailing the actual hardware devices your application will interact with
and control. For instance, if you are controlling X10 type home devices, what is the interface to those
devices? Designers should be able to look at this and know what hardware they need to worry about
in the design. Many business type applications will have no hardware interfaces. If none, just state
“The system has no hardware interface requirements” If you just delete sections that are not
applicable, then readers do not know if: a. this does not apply or b. you forgot to include the section
in the first place.
Specify the use of other required software products and interfaces with other application systems.
For each required software product, include:
(1) Name
(2) Mnemonic
(3) Specification number
(4) Version number
(5) Source
Here we document the APIs, versions of software that we do not have to write, but that our system has
to use. For instance if your customer uses SQL Server 7 and you are required to use that, then you
need to specify i.e.
2.1.4.1 Microsoft SQL Server 7. The system must use SQL Server as its database component.
Communication with the DB is through ODBC connections. The system must provide SQL data table
definintions to be provided to the company DBA for setup.
A key point to remember is that you do NOT want to specify software here that you think would be
good to use. This is only for customer-specified systems that you have to interact with. Choosing
SQL Server 7 as a DB without a customer requirement is a Design choice, not a requirement. This is
a subtle but important point to writing good requirements and not over-constraining the design.
Specify the various interfaces to communications such as local network protocols, etc. These are
protocols you will need to directly interact with. If you happen to use web services transparently to
your application then do not list it here. If you are using a custom protocol to communicate between
systems, then document that protocol here so designers know what to design. If it is a standard
protocol, you can reference an existing document or RFC.
Specify any applicable characteristics and limits on primary and secondary memory. Don’t just make
up something here. If all the customer’s machines have only 128K of RAM, then your target design
has got to come in under 128K so there is an actual requirement. You could also cite market
research here for shrink-wrap type applications “Focus groups have determined that our target
market has between 256-512M of RAM, therefore the design footprint should not exceed 256M.” If
there are no memory constraints, so state.
2.1.7 Operations
Specify the normal and special operations required by the user such as:
(Note: This is sometimes specified as part of the User Interfaces section.) If you separate this from
the UI stuff earlier, then cover business process type stuff that would impact the design. For instance,
if the company brings all their systems down at midnight for data backup that might impact the
design. These are all the work tasks that impact the design of an application, but which might not be
located in software.
In this section:
(1) Define the requirements for any data or initialization sequences that are specific to a
given site, mission, or operational mode
(2) Specify the site or mission-related features that should be modified to adapt the
software to a particular installation
If any modifications to the customer’s work area would be required by your system, then document
that here. For instance, “A 100Kw backup generator and 10000 BTU air conditioning system must
be installed at the user site prior to software installation”.
This could also be software-specific like, “New data tables created for this system must be installed
on the company’s existing DB server and populated prior to system activation.” Any equipment the
customer would need to buy or any software setup that needs to be done so that your system will
install and operate correctly should be documented here.
Provide a summary of the major functions that the software will perform. Sometimes the function
summary that is necessary for this part can be taken directly from the section of the higher-level
specification (if one exists) that allocates particular functions to the software product.
For clarity:
(1) The functions should be organized in a way that makes the list of functions
understandable to the customer or to anyone else reading the document for the first time.
(2) Textual or graphic methods can be used to show the different functions and their
relationships. Such a diagram is not intended to show a design of a product but simply
shows the logical relationships among variables.
AH, Finally the real meat of section 2. This describes the functionality of the system in the language
of the customer. What specifically does the system that will be designed have to do? Drawings are
good, but remember this is a description of what the system needs to do, not how you are going to
build it. (That comes in the design document).
Describe those general characteristics of the intended users of the product including educational
level, experience, and technical expertise. Do not state specific requirements but rather provide the
reasons why certain specific requirements are later specified in section 3.
What is it about your potential user base that will impact the design? Their experience and comfort
with technology will drive UI design. Other characteristics might actually influence internal design
of the system.
2.4 Constraints
Provide a general description of any other items that will limit the developer's options. These can
include:
This section captures non-functional requirements in the customers language. A more formal
presentation of these will occur in section 3.
List each of the factors that affect the requirements stated in the SRS. These factors are not design
constraints on the software but are, rather, any changes to them that can affect the requirements in
the SRS. For example, an assumption might be that a specific operating system would be available
on the hardware designated for the software product. If, in fact, the operating system were not
available, the SRS would then have to change accordingly.
This section is catch-all for everything else that might influence the design of the system and that did
not fit in any of the categories above.
Identify requirements that may be delayed until future versions of the system. After you look at the
project plan and hours available, you may realize that you just cannot get everything done. This
section divides the requirements into different sections for development and delivery. Remember to
check with the customer – they should prioritize the requirements and decide what does and does not
get done. This can also be useful if you are using an iterative life cycle model to specify which
requirements will map to which interation.
Figure 2.1 Use case model examples
2.7.2 Use Case Diagram (you can use either use case diagram or scenario)
2.7.3 Use Case Scenario (Following details can be provided for a use case scenario)
Use Case
Description
Element
Use Case
ID to represent your use case
Number
Application What system or application does this pertain to
Use Case
The name of your use case, keep it short and sweet
Name
Use Case
Elaborate more on the name, in paragraph form.
Description
Primary Actor Who is the main actor that this use case represents
Precondition What preconditions must be met before this use case can start
Trigger What event triggers this use case
The basic flow should be the events of the use case when everything is perfect; there are no errors, no
Basic Flow exceptions. This is the "happy day scenario". The exceptions will be handled in the "Alternate Flows"
section.
Alternate
The most significant alternatives and exceptions
Flows
3.1.2.DFD, Class Diagram, flow charts, ER Diagrams (which ever applicable depending
on the project)
3.2. Algorithm(s)
(if required, add any other section applicable for the methods and
approaches you have followed)
Chapter 3
System Design
System Design should include the following sections (Refer each figure or table in some text). Figure
number should be provided below the figure and the table numbering should be provided above the
table.
3.5. ER Diagrams
In this section provide the details of any software or hardware requires for the
implementation of the project.
4.4.3. Results
Include the output of your work here. The result can be in tabular and/or graphical
format depending on the project. Comparison with earlier or other work may also be
presented.
CHAPTER 5
Conclusion
This chapter should usually be reasonably short---a few pages perhaps. As with the
introduction, it is a good idea to ask someone who is not a specialist to read this section and
to comment
Appendix
If there is material that should be in the project report but which would break up the flow or
bore the reader unbearably, include it as an appendix. Some things which are typically
included in appendices are: important and original computer programs, data files that are too
large to be represented simply in the results chapters, pictures or diagrams of results which
are not important enough to keep in the main text. Thus in the appendix, one may include
1. Cite all ideas, concepts, text, data that are not own by the project group
2. If author makes a statement, he must back it up with his own data or a reference
2. Maiers, J., and Sherif, Y. S. , "Application of Fuzzy Set Theory," IEEE Transactions on
Systems, Man, and Cybernetics, Vol. SMC15, No.1, pp. 4148, 1985.
3. Doe, N., Control System Principles, New York: John Wiley, 1999.
5. Nayak, T., "Application of Neural Networks to Nuclear Reactors," M.Sc. Report, U.P.
Technical University, 2005.
7. Lokhande, R., Arya, K. V., and Gupta, P., "Identification of Parameters and
Restoration of Motion Blurred Images", Proceedings of the 2006 ACM Symposium on
Applied Computing (SAC 2006), pp. 8995, Dijon, France, April 2- 7, 2006.
9. Das, A. R., Murthy D., and Badrinath J., A Comparison of Different Biometrics Traits,
RSRE Memorandum No. 4157, RSRE Malvern, 2001.
10. Bell Telephone Laboratories Technical Staff, Transmission System for Communications,
Bell Telephone Laboratories, 1995.
11. "Signal integrity and interconnects for high-speed applications," class notes for ECE
497- JS, Department of Electrical and Computer Engineering, University of Illinois at
Urbana- Champaign, Winter 1997.
Each software developed by the Project's Group should be burnt in a CD with proper
documentation. The CD should contain files containing the source code, one or more sample
input and corresponding output separately. Other than these there must be another file named
"READ.ME". In this ASCII text file, the following sections must be appear.
Author's Identity. A file should contain the name of each project group member along with
the Supervisor's name.
Files in the CD. In this section, the names of the files together with their contents must be
listed.
Hardware Requirements. In this section, we should note down the hardware requirements
along with any special type of equipments/ components such as graphics card, numeric
coprocessor, mouse, RAM capacity etc. needed to run the software.
Software Requirements. In this section, the operating system, the compiler, linker, and the
libraries etc. necessary to compile and link the software must be listed. There is a need to
obtain the necessary license from the copyright owner before one incorporates the
copyrighted material file in CD.
TEXT PROCESSING INFORMATION
It is important to note that type format of all reports should be uniform. So there is a need to
follow some guidelines on typesetting and other aspects. Some of such guidelines are given
below.
1. The original copy shall be typed on 75 or 80 gr./m2 white paper. All photocopies shall be
run on the same grade of paper. Size of paper shall be 210 x 297 mm, i.e. A4.
2. Only Near Letter Quality or sharper dot matrix printer or Laser printer and Ink Jet printer
and electrical typewriter outputs are acceptable. In case of dot matrix printers or a
typewriter, black ribbon must be used and replenished as frequently as necessary to
maintain clear and high contrast constant density copy throughout the report.
3. As a character font, one should use Times new roman preferably (Times, Times Roman,
Courier, Geneva, Helvetica or equivalent) which are available in most word
processors. The font size must be 12 point in the text and at least 8 point in the
figures. However, if a typewriter is used, then typing must be done on an electric
typewriter and with an Elite, Pica, or Letter Gothic typeface, and preferably with a carbon
film ribbon to avoid a fading effect.
4. Whenever titles and headings are to be centered the centering shall be such that 112 mm.
from the left edge of the paper or 98 mm. for the right edge of the paper is the center
point of the title or heading.
The above margins shall be observed on charts, graphs, tables, and drawings. Folded papers
will not be accepted unless there is absolutely no other way for the material to be presented.
6. Spacing of the text material shall be 1.5 with the following exceptions:
c. Extensive quotations single spacing and indented eight (8) spaces relative to the
text material.
7. Headings used in the report shall conform to the following rules:
(1) Must begin a new page and be centered using the Font Size 18 with Bold Fold.
Omit period at the end of the heading.
(3) Chapter headings are to be titled names that reflect content of the text that
follows.
(4) It should be centered and Font Size to be used is 18 with Bold Face.
(1) Must be towards left margin and be typed in capital and lower case letters; i.e.,
the first letter of each word except conjunctions, prepositions, and articles
must be a capital letter. Omit period at the end of heading.
(2) The letter designation of the heading shall be followed by a period and two
blank spaces.
(3) Must be three spaces below preceding text and two spaces ahead of succeeding
text.
(5) In case it is found that first line of the succeeding text starts from the next page,
then this heading should start from the next page using page break.
(1) Must be typed on separate lines beginning at the left margin line of the text, but
need not begin a new page.
(2) Must be typed in capital and lower case letters except conjunctions,
prepositions, and articles.
(3) The number designation of the heading shall be followed by a period and two
spaces. Omit period at the end of the heading.
d. Second subheadings 2.2.1.1, 2.2.1.2 etc.. (second subheadings must not be included). In
case required, this must be italic and bold and text should start in the same line. (As shown
below)
8. Figures and Tables: Ideally, every result claimed in the text should be documented with
data, usually data presented in tables or figures. If there are no data provided to
support a given statement of result or observation, one should consider adding more
data, or deleting the unsupported "observation." Examine figure(s) or table(s)
pertaining to the result(s).
The actual figures and tables should be embedded/inserted in the text, generally on the
page following the page where the figure/table is first cited in the text. All figures
should be numbered and cited consecutively in the text as Figure 2.1, Figure 2.2, to
indicate the first and second figures in Chapter 2 respectively. Similarly it is the case
with tables such as Table 3.1, Table 3.2, etc.
A caption for each figure and table is to be given with proper citation about reference,
data sources, etc. and by highlighting the key findings. One should include an index
figure (map) showing and naming all locations discussed in the report.
Author is always encouraged to make his own figures, including cartoons, schematics
or sketches that illustrate the derived processes. He should see all his figures keeping
in mind that:
2. Axes of figures are labeled and the units, if used, are indicated.
4. If the data are fitted by a curve, its goodness of fit should be determined.
12. Whether its caption guides one’s eye to the "take-home lesson" of the figure.
Footnotes shall be sequential for each page and for the entire report.
Footnotes shall be placed at the bottom of the page on which they are indicated. They
shall be indented from the margin line of the text by eight spaces and placed under a
broken line made of 15 dashes.
Avoid to start a sentence in the text with the expression number. This can be avoided
by using changing the voice.
10. Pagination and Paragraphs: Each page in the report or dissertation is expected to
bear a number. Only one side of the paper may be used. The following plan should be
used exclusively:
a. The preliminary section, including the title page; copyright page, if any; foreword,
preface, or acknowledgements; table of contents; etc., should be numbered, using
lower case Roman Numerals, e.g., i, ii, iii, etc. The title page counts as Page i, but the
number does not appear. The sequence of the preliminary section is as follows:
Title Page ........................................................ Page i number does not appear
Declaration...................................................... Page ii
Acknowledgements......................................... Page iv
For the remainder of the report, Arabic numbers are used. Each page must be
numbered. Page numbers are to be placed 2 centimeters from the top and right hand
margins on the pages. All pages for illustrations, tables, appendices, bibliography, etc
are included. Use of suffixes, such as 25a, 25b ... are not allowed. The numbering in
the main body should begin with Page 1 and run consecutively to the last page. No
punctuation, such as dash or a period, should accompany the page number.
b. Paragraphs: A new paragraph must not begin at the bottom of a page if there is
not sufficient space for at least two lines.
11. Size of Thesis: There is no limit on the number of pages to be used in the report. But it
should be complete in all respect. However it is expected that the number of pages in
the report will not exceed 100 pages of typed matter reckoned from the First page of
Chapter 1 to the last page of the Appendix.
12. Binding Specifications: Beside the supervisor's and personal copies, two copies of the
project report should be bound in light Blue color (Matt finish) hard rexin binding
with golden engraved letters. Ensure that the side face of thickness of the thesis
should have the surname of the students, and month of submission at top and bottom
edge respectively.
CITATION STYLE
In a project report there is a need to make references in the text, and relate them to notes, or
to a list of bibliographical references, at the end of the description of the work. A number of
elements must be present for a document to be identifiable with certainty. It is better to give
extra or redundant information than to omit vital features.
1) Citation of Books
● author(s)
● title
● edition (if applicable)
● place of publication
● publisher
● date
Some citation styles omit place of publication, but it is useful, e.g. when filling out inter-
library loan requests, where it can simplify and limit the searching process. Examples (books)
are given below.
To some extent, the details of punctuation are up to the author as long as he is consistent. He
may, for instance, decide to write authors' names in upper case (capitals), or to give their
forenames in full ,if it is available.
The purpose of using italics is not just to give emphasis, but to show which element in the
citation is a separately published unit. It is especially important when one is citing a section
(an article, a paper, or a chapter) in a collection or other composite work, e.g.
Watson, R. 'Racial and Ethnic Relations', in Anderson, R. and Sharrock, W.W., eds.,
Applied Sociological Perspectives. London: Allen & Unwin, 1984. pp.3-65.
If one makes this kind of reference correctly, the reader will immediately know what is the
book to look for (i.e. Anderson and Sharrock) and not waste time searching for a non-existent
(or a different) work with the title, Racial and Ethnic Relations. Inverted commas are often
used to signal a part or contribution in a larger work - they show that it is not separately
published in its own right, and it is not good practice to use them to show a book title.
2) Citation of Periodicals
The same principles that apply to a book apply when he is citing articles from periodicals -
journals, magazines, newspapers, reviews, etc.
● author(s)
● title of the article
● title of the periodical, or its accepted abbreviation.
● date , volume, and part number of the issue in which it appears
● page numbers
Davis, R.D. 'Sludge disposal - keeping it safe'. Water and waste treatment, 1984, 27 (9) 38-42
or
Zlotnik, M. D. 'Chernenko succeeds'. Problems of Communism 33 (2) March-April 1984,
pp.17-31.
The detail of order and punctuation may vary between one writer and another, or with the
same writer on different occasions; the important thing is to decide firmly at the start how the
author is going to proceed, and stick to that style. Publishers of books and journals have their
own 'house-styles', and editorial staff to apply them rigorously; for these purposes, clarity and
consistency are enough -- one should not cite something unless the author is quite sure, he
has enough information for a reader to identify it. It is not necessary to use Roman numerals
for volume numbers, even if the periodical the author is citing uses them itself, or if he has
seen them in a citation elsewhere. Single inverted commas are used again here, to show
which is the article, and which is the periodical title.
It is sometimes needed to cite an issue by date, rather than part number, even if it has one,
e.g.
Wood, Nick. 'Multiracial Study Pioneer in Grenada Coup'. Times Educational Supplement,
28th October 1983, p.1.