0% found this document useful (0 votes)
18 views9 pages

Level 4 Guides. Hardware - ML Based

The document provides guidelines for students at Midlands State University to produce a functional project with comprehensive documentation, including system manuals and help sections. It outlines the required structure for project documentation, including specific formatting styles, page arrangements, and content requirements for each chapter. Additionally, it emphasizes the importance of supervision and the use of proper referencing throughout the project report.

Uploaded by

Frank Njanji
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
18 views9 pages

Level 4 Guides. Hardware - ML Based

The document provides guidelines for students at Midlands State University to produce a functional project with comprehensive documentation, including system manuals and help sections. It outlines the required structure for project documentation, including specific formatting styles, page arrangements, and content requirements for each chapter. Additionally, it emphasizes the importance of supervision and the use of proper referencing throughout the project report.

Uploaded by

Frank Njanji
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 9

MIDLANDS STATE UNIVERSITY

FACULTY OF SCIENCE AND TECHNOLOGY

COMPUTER SCIENCE DEPARTMENT

HCSE438 / HCSCI438 GUIDELINES


HARDWARE/MACHINE LEARNING BASED
REVISED JULY 2024

Preamble
Students are expected to produce a fully functional project that has an accompanying
documentation that clearly outlines the architecture of the product i.e. if software system is
developed, it should have an accompanying system manual, user manual and a comprehensive
help page/section in your documentation.

Documentation Style
There are two ways that you can use to present your headings sub headings
1) Bold ONLY
2) Underline ONLY

(NOT BOTH)

A candidate is supposed to choose ONE way of presenting sub headings. The style must be
consistent throughout the Documentation document. Each Main heading MUST start on a
fresh page and must be BOLD

MAIN Headings should be of font size 14 and Sub headings of font size 12. E.g
Chapter 4: Design Phase (14) Introduction (12). The font style used in the
document must be consistent as recommended.

Each and every table, diagram, graph, chart etc MUST be numbered and Labelled. The
numbering must depend with the Chapter in which the item is in Eg diagram in Chapter 1 can
be numbered as Figure 1.1: Organogram. Note that the First 1 denotes the chapter
in which the diagram falls under and the Last 1 tells us about the count of the diagram in the
chapter, so literally Figure 1.1 means the figure is in Chapter 1 and its diagram number 1.
This means that the next diagram must have a .2 suffix, thus Figure 1.2, and the labelling of
course is the description of the diagram in question. Table captions should be at the top of
the table and Figure captions at the bottom of the figure. This must be consistent throughout
the document.
Note that * Each and every heading, sub heading must be numbered.

The Structure of Page Arrangements for the Project Documentation


The sequel of pages and their hierarchical arrangement play a pivotal role in structuring the
project report properly and interlinking the vital elements of the report in the best possible
format.
Therefore, the best structure and format that has been devised after extensively selecting
studying, analyzing and structuring myriad and versatile project reports include the following
sequel of elements:

1.​ Cover Page


2.​ Declaration
3.​ Approval or Certification
4.​ Acknowledgements
5.​ Dedication
6.​ Abstract
7.​ Table of Contents
8.​ List of Figures
9.​ List of Tables
10.​List of Symbols (optional)
11.​List of Abbreviations / Acronyms
12.​Body of the Project (Chapters)
13.​References
14.​Appendices

In the above structure, the first nine pages are known as preliminary pages, and are usually
numbered with the Roman numerals as i, ii, iii, iv and so on, except the title page as shown in the
next section.

Cover Page
Declaration ​ i
Approval​ ii
Acknowledgements​ iii
Dedication​ iv
Abstract ​ v
Table of contents​ vi
List of Tables vii
List of Figures. viii
List of Abbreviations / Acronyms ix
List of Appendices​ x….etc
NB. Each of the topics above must have a different page and must be paginated using
lowercase Roman Numerals except for the COVER PAGES
All the contents of the project report should be in ‘Times New Romans’ font, and the size
should be 12 throughout. All the text should be left with the ‘justified’ option with line
spacing of 1.5, but for the Captions single spacing should be opted.
Title page
All the first letters of each word on the title page must be capitalized, and the title page should
not contain page numbers. The other aspects of the title page like the title should be like a report,
and should contain the name of the organization to which the project is intended to be submitted.

Next, the course name should be followed by the student’s name, his roll number, guide’s name
and designation, and at the end of the title page, organization’s logo and address should be
written, as shown in the above figure.

Declaration and Approval

The declaration is a statement written by the student who declares that he or she has sincerely
completed his or her project. The declaration statement concludes with the signature of the
student.

The Approval page is also a confirmation from the head of the department, guide, and external
examiner about their acceptance of the project. The approval page is endorsed with the
signatures of the heads confirming their approval of the project.

NB: No alterations should be made to the declaration and approval statements.

Acknowledgements

The acknowledgements page depicts the gratitude, respect and thankfulness of the student
towards the people who helped him in pursuing the project successfully and ensured successful
completion and implementation of the project. In this page, the author expresses his gratitude and
concern by using praising and thanksgiving words.

Dedication
The dedication, as the name suggests, allows you to dedicate your research to someone (or
multiple people). A dedication is basically a personal tribute to someone or a group of people.
Abstract

Abstract represents a summarized report of the complete project in a very concise and
informative format covering main objective and aim of the project, the background information,
processes and methods used, and methodologies implemented, followed with a brief conclusion
of two to three lines talking about the results and scope of the project.
The entire abstract of a project report should be written in about 250 to 350 words, and therefore,
should not exceed any further.

Table of Contents, List of Figures and Tables

Table of contents provides a complete sketch of the title, subtitles, headings, topics and the
project elements that are involved in those headings. In other words, different sections and their
titles are included here.

The whole project report in a nutshell is made known in the table of contents section, and
therefore, it should include the titles of the first, second and third level headers, and must give a
clear picture of the report to the reader.

Similarly, a list of figures and tables helps the reader to locate diagrams, charts and tables in the
document, and therefore, it should be numbered accordingly by chapter and page number. It is
not necessary to indicate page numbers for symbols and abbreviations used in the document.

Supervision
Students must ensure that upon the approval of their proposals they collect and hand them over
to the allocated supervisors. Candidates are encouraged to work with their supervisors and meet
the suggested deadlines. No student is expected to proceed to the next chapter of their
Documentation without the approval of the preceding chapter by the supervisor. After every
chapter the supervisor and the student are required to sign a supervision form, as a way to
authenticate the completion of a chapter. Candidates will only be allowed to defend their projects
after their supervisor has signed the final draft of the research on the Approval page.

The Main Body of the Report

Students are expected to use reported speech/past tense when documenting. The main body of
the project should comprise several chapters with the corresponding titles, and each page within
these chapters must be numbered in numerals as page numbers. The usual way of presenting
these chapters is given below.

Chapter 1: Introduction

This chapter should contain brief background information about the project, the methodology
implemented for problem solving and the outlines of the results and future scope of the project. It
rarely contains drawings and graphical illustrations. Could consist of the following heading but
not limited to these:
1.1​Introduction
●​ This briefly introduces the topic and highlights what is to be covered in the chapter.

1.2​Background of the study


●​ This gives a brief description of researches or systems which have been
implemented before in the area of study including the current system being
investigated.
●​ Must give a preliminary literature review
●​ Identify gaps in previous studies and or shortcomings of previous studies

1.3​Problem definition
●​ Should be one short paragraph that clearly states the problem.
●​ 5-7 lines

1.4​Aim
●​ Overall goal of the research or project undertaking.
●​ Should be a single statement outlining the aim

1.5​Objectives
●​ Note that objectives must be Specific, Measurable, Achievable, Relevant, Time
sensitive (S.M.A.R.T) and seek to address the problems identified
●​ Should be phrased in a way they start with the word “To”
●​ Objectives should be derived from the actual functionality of the system
●​ Minimum number of 3 distinct objectives
●​ Maximum number of 5 distinct objectives
●​ Inputs (eg. data capturing) and outputs (eg. reports) should not be part of the
objectives. Only processes should be put as objectives

1.6​Limitations
●​ Highlight any hindrance in conducting the research project and steps taken to address
them

1.7​Delimitations
●​ Highlight the restrictions, assumptions and or boundaries of your research
undertaking

1.8​Development Instruments
●​ Highlight the hardware and software tools to be used

1.9​Work Plan
●​ Expected timeline and show the Gantt chart

1.10​ Justification / Rationale


●​ Provide reasons or rationale why you are carrying out this research, the business value
and the importance of the results as well as its contribution to the existing body of
knowledge. ​

1.11​ Summary
●​ Summary of the chapter
●​ Also highlight what will be found in the next chapter
Chapter 2: Literature Review

Evaluate the current work with the previous ones. It depicts how the current implementations
overcome the previous problems and limitations of the solution. It must be clear and simple to
understand. Use the funnel approach. Could consist of the following heading but not limited to
these:
2.1​Introduction
This briefly introduces the literature review, gives definition of terms or concepts to be used in
the research and highlights what is to be covered in the chapter.

2.2​ Analysis of Study or Related Work

N.B: This is an example sub topic, it will depend on the author, area of study.
Students are expected to provide an analysis of usage of systems at International, Regional and
local levels.
Critically review literature on existing solutions in the problem domain to help identify any gaps
which one can target with the proposed work. It depicts how the current implementations
overcome the previous problems and limitations of the solutions. It must be clear and simple to
understand. Use the funnel approach.

2.3 Gaps Identified​


●​ Indicate the gaps which have been identified in the analysis of study which the project
wants to address.

2.4 Proposed Work


Briefly explain the proposed work as a possible solution to any of the gaps identified.

2.4.1 Feasibility Analysis


2.4.1.1​Technical Feasibility
2.4.1.2​Economic Feasibility
In brief focusing on proposed financial costs and foreseen financial benefit
2.4.1.3​Social Feasibility
2.4.1.4​Operational Feasibility
2.4.1.5​Overview of Feasibility Study
2.5 Summary
●​ This is a summary of the main points discussed in the analysis of study and researcher
identified gaps.
●​ Highlight what will be found in the next chapter
Chapter 3: Methodology

This chapter explains the hardware components and software tools to be used in depth (i.e. the
basic theoretical information about each and every software or hardware component to be used
needs to be explained). The system architecture, activity diagrams, flow chart diagrams,
algorithm design and circuit design are also included in this section. If the research involves
gathering information from users the tools to be used should also be discussed here. The research
approach to be followed can also be explained however this is optional.

3.1​Introduction
●​ This briefly introduces the section, gives definition of terms or concepts to be used in
the methodology and highlights what is to be covered in the chapter.
3.2​Hardware and Software Requirements
●​ This describes the hardware devices or components to be used and mentions their
specification.
●​ This also describes the software to be used in linking the hardware components or as
subsystems of the full design.
3.3​Proposed System Architecture
●​ This highlights the proposed full hardware and or software interaction in the form of
an architecture.
3.4​Process Analysis / Data Collection and Preprocessing
●​ This explains how activities are going to occur when implementing the proposed
solution in the form of activity diagrams.
●​ In the case of machine learning based, highlight the datasets available which can be
used in creating training and test datasets as well as the data preprocessing
requirements / procedures, if any.
3.5​Algorithm Design
●​ This explains the specific custom-made or standardized method to be applied in the
proposed solution with justification for choice of method. This can include
pseudocode and flowcharts.
3.6​Circuit Design / Model Designing
●​ This explains the overall circuit architecture to be implemented and clearly shows all
relevant hardware components arrangement or full code in an appropriate
programming language showing how the model was built.
3.7​Simulation Results / Model Training and Validation
●​ This shows the simulations done to evaluate hardware system performance with
the simulation results being recorded for further analysis, OR the model training
and validation runs made and the results showing the model’s training and
validation performance in terms of accuracy and loss.
3.8​Summary
●​ Summary of the chapter.
●​ Introducing the next chapter.

Chapter 4: Results and Discussion


This section explains the implementation carried out in terms of coding or simulations or
experiments done. The results obtained need to be explained in depth and illustrations from
actual implementation shown. Also indicate the testing procedure and evaluations made to the
hardware or software components. The results can also be indicated in tables, figures or graphs
etc. The chapter should have a conclusion which summarizes the results obtained. Sub-headings
can include the following but not limited to these:
4.1​Introduction
●​ This briefly introduces the section and highlights what is to be covered in the
chapter.
4.2​Test Procedures / Model Testing
●​ This describes the actual implementation or experiments carried out in testing the
proposed solution to evaluate its performance in the intended tasks. Should also
illustrate actual circuit set up, code snippets or simulation procedures.
●​ In the case of a model, this describes the model testing procedure highlighting the
size of the test dataset (not the dataset used for training and validation). Should also
include the code, in an appropriate programming language, used for conducting the
model test runs.
4.3​Results Presentation
●​ Present results from testing procedure. Results can be in different forms: Images,
graphs, tables, etc.
●​ Also include a comparative analysis of results or system/model performance with
those of existing solutions in the problem domain.
4.4​Discussion of Findings
●​ This focuses on evaluating the findings obtained from implementation and testing. A
comparison with covered related work results and other standardized benchmarks is
a necessity.
4.5​ Summary
●​ Summary of implementation and results obtained.
●​ Introduce the next chapter

Chapter 5: Summary, Conclusion and Recommendations

This section summarizes the whole report by highlighting all the chapters. It mentions the
significance and the importance of the project while highlighting the achievements made in
reference to the objectives set out in chapter (1) one. This chapter also includes the
recommendations which can be made to the applicable audience or future work which the
researcher (or other researchers) seeks to pursue.

5.1.​Summary of Results
●​ Summarizes research results
5.2.​Significance of Project
●​ This describes how the project has or will impact the specific audience and society
at large. It also seeks to answer the questions; What are the research’s contributions
to the existing body of knowledge? Have objectives been met? And what challenges
were encountered during the research?
5.3.​Conclusion
●​ Draw overall conclusions for the entire project while mentioning if it was a success
or failure and justify. Give your personal opinion on this.
5.4.​Recommendations and Future Work
●​ Describe the recommendations for implementation/deployment of the proposed
solution by target users or other researchers, system updates/upgrades, scheduled
maintenance plan(s), user support and system performance feedback, etc.
●​ Also mention what you intend to improve on in future undertakings with regard to
your project.

Referencing

The project report must be considered as a very standard report, and therefore, it should follow
all rules, guidelines and protocols of gathering and presenting information, and implementing
that and drawing conclusions out of it.

All these activities require appropriate and authentic sources of information, and that particular
information must be referenced or cited according to the copyrights and other guidelines using
the IEEE Referencing Style. Therefore, to make the report original, it should be free from
plagiarism and must follow standard citations and guidelines of citations to represent the
reference names.

References should not be more than 10 years.

Wikipedia is not an academic website so don’t include information from that site,

educational sites have an extension .edu, ac , etc eg http://nile.wpi.edu

Appendices

The appendices of a project report should be written in Times New Roman format of font size
12, and it should contain the information which is appropriate and added to the main text like
Embedded C program code, raw data, and so on. Sub-headings can include but not limited to the
following:

Appendix A : User manual (Should be detailed)


Evidence of research
Appendix B: Snippet of Code
Appendix C: etc

Final Stage
●​ Documentation Binding
●​ Oral presentation (40%)
●​ Documentation document (60%)

These are the exceptional and very informative guidelines about drafting a project report along
with a very simple, user-friendly project report format for those students who are earnestly
seeking project report format.

You might also like