11 
compare the systems, since numbers are the best and perhaps the only way to 
objectively describe performance.  For example,  the mean time between failures 
(MTBF) or the number of incorrect rejections in a pattern recognition system.  Quite 
often, we use statistical measures as our comparative metric, e.g. the mean and 
standard deviation of some performance measure when the system is subjected to a 
large variety of input parameters and conditions. 
3.8 Documentation 
We noted earlier that writing is an essential part of understanding.  We note it again 
here but in a different sense.  In this case, writing is essential in order for others to 
understand what you have done.  There are two reasons why you want others to 
understand your work: 
1. 
So that you can be given credit for it (your final mark depends on it); 
2. 
So that others can carry on your work and develop or maintain your system. 
It is extremely important that you document your work at every stage of your project.  
We saw already that documentation is essential in the initial reading-in, requirements, 
and specification phases but it is equally important in the design, implementation, 
test, and maintenance phases.    
The best way to organize your writing is to keep a log book of all work in progress.   You 
should go out and buy a nice hard-cover notebook and write everything you do on the 
project into this log book every day.  Every thought and observation you have on your 
project should go into this book, along with notes of meetings with your supervisor, 
results,  theoretical developments, calculations, everything.  This log book will become 
an invaluable source of material when you come to write up your project in the final 
report. 
However, don’t wait until the end of the project to begin the process of formal 
documentation.  At the end of each phase of the project (or at the end of each task)  
you should write up a formal report on that phase.  These reports will, in turn, become 
an excellent basis for your final report. 
Finally, there is one other form of documentation which you will have to create during 
your project.  This is the project presentation.   Since the final report and the project 
presentations are so important, we will devote all of the section 4 to these topics. 
3.9 Good Engineering Practice and Safety Regulations 
Projects requiring the construction of physical models will be allocated dedicated 
bench-space in the laboratory.  If any other special facilities are required, you should 
inform the Superintendent Technician.  In choosing electronics components for 
experiments you should try to make use of standard components.  Orders for 
specialized components may be submitted to the Project Technicians if there is no 
equivalent stock item. However, no responsibility is accepted for the effects of supply 
lead time. 
A record of all components and parts used and their cost will be entered on your 
project record card.  Expenditure above a quoted maximum limit must be referred to 
the Project Coordinator for signature. 
How to convert pdf to powerpoint on - C# Create PDF from PowerPoint Library to convert pptx, ppt to PDF in C#.net, ASP.NET MVC, WinForms, WPF
Online C# Tutorial for Creating PDF from Microsoft PowerPoint Presentation
pdf picture to powerpoint; how to add pdf to powerpoint slide
How to convert pdf to powerpoint on - VB.NET Create PDF from PowerPoint Library to convert pptx, ppt to PDF in vb.net, ASP.NET MVC, WinForms, WPF
VB.NET Tutorial for Export PDF file from Microsoft Office PowerPoint
pdf to ppt converter online; pdf conversion to powerpoint
12 
As we noted above, you must keep a log book during your project in which to keep a 
full dated record of design work, theoretical work, experimental results, and 
conclusions.  Note instrument numbers in case the experiment has to be repeated in 
identical circumstances.  Project supervisors, assessors, and examiners may ask to 
inspect your log book at any time. 
Projects involving the design and construction of equipment should be performed in a 
competent and well-engineered fashion with due regard to all relevant safety 
regulations. If mechanical construction is required, you should apply to the technician 
who will advise on the most suitable materials to use and the methods of construction.  
Thereafter, a clear sketch, drawn approximately to scale, is required, with dimensions 
included in metric units.    
In view of the requirements of the Health & Safety Regulations you are not allowed to 
work in any room alone if your work involves exposed live conductors at dangerous 
voltages or large moving mechanical parts. 
You should familiarize yourself with the contents of the Electrical Safety Handbook, a 
copy of which was issued to you in Year 1, and you should conduct all your work in  
accordance with its recommendations. 
3.10 Back to the Beginning: Managing Your Project 
One of them most important things you will learn when doing your project is the need 
to manage your time.  Final Year Projects require a considerable amount of time.  You 
should expect to spend at least 150 hours working on it, and probably 200 or more. 
Any attempt to try to complete a project in the last couple of months or so of the 
second semester is doomed to failure. They are complex and require careful thought 
and analysis to identify manageable component parts. 
Consequently,  it is essential that you begin your project early, work consistently at it 
throughout the year, and track your progress closely.  Naturally, the best way to do 
this is to plan your project in considerable detail.   We will identify here one of the 
fundamentals of good project management: scheduling. 
A project schedule is an indispensable tool:  building it forces you into thinking about 
all the things you need to do, their inter-relationships, the time each will take, and 
what each one will be used for.  So, draw up a schedule: 
¾ Identify all the major tasks; break these down into sub-tasks. Note well that the 
best input for this task is your system specification: there will be a task for each 
functional block and each data-structure, as well as sub-tasks for analysis, design, 
implementation, test, integration, and documentation.  There will also be tasks for 
system test and evaluation, as well as documentation and report writing. 
¾ For each task and subtask 
ɽ 
estimate how much effort you expect it to take (hours) and over what period you 
will spread that effort (days): this is the task effort & duration 
ɽ 
identify the required inputs – information, software, hardware, and, most 
Online Convert PowerPoint to PDF file. Best free online export
Download Free Trial. Convert a PPTX/PPT File to PDF. Then just wait until the conversion from Powerpoint to PDF is complete and download the file.
changing pdf to powerpoint; how to add pdf to powerpoint presentation
C# PDF Convert to Jpeg SDK: Convert PDF to JPEG images in C#.net
C# PDF - Convert PDF to JPEG in C#.NET. C#.NET PDF to JPEG Converting & Conversion Control. Convert PDF to JPEG Using C#.NET. Add necessary references:
convert pdf to powerpoint; copying image from pdf to powerpoint
13 
important of all, the results of other tasks in your project. 
ɽ 
Identify the expected outputs 
ɽ 
Identify a course of action to take if the task fails for some reason (e.g. the 
software or hardware doesn’t arrive in time) 
¾ Now try to identify the sequence in which you should do each task.  In this, you 
will have to consider the relationships between each task and the use of the output 
of one task as the input to another. 
In drawing up your project schedule, you may find it useful to use a standard project 
management tool (such as Microsoft Project).  These tools make it easy to draw the 
schedule and to track your progress. However, they won’t do the planning for you, i.e. 
they can’t identify tasks, subtasks, effort, duration, etc.  That’s something you have to 
do yourself.  You should be able to make a good attempt at this by the time you’ve 
finished reading this handbook. 
Project management tools usually represent a finished schedule in one of two ways, a 
PERT chart and a GANTT chart 
PERT stands for Program Evaluation Review Technique.  A PERT chart represents each 
task/subtask as a box containing its identity, duration, effort, start date, and end date 
(among other things).  It displays not only project timings but also the relationships 
among tasks (by arrows joining the tasks).  It identifies the tasks to be completed 
before others can begin and it identifies the critical pathi.e. the sequence of tasks with 
the longest completion time.  The critical path is important as it defines the absolute 
minimum time needed to complete the project.  Note that the critical path can change 
as task start-dates and durations are changed.  Figure 1 shows an example of a PERT 
chart for simple project. On the other hand, a GANTT chart represents tasks by 
horizontal bars and lines are used to show the dependencies; see figure 2. 
VB.NET PDF Convert to Jpeg SDK: Convert PDF to JPEG images in vb.
Convert PDF to Image; Convert Word to PDF; Convert Excel to PDF; Convert PowerPoint to PDF; Convert Image to PDF; Convert Jpeg to PDF;
how to convert pdf to powerpoint in; convert pdf into ppt online
VB.NET PDF Convert to HTML SDK: Convert PDF to html files in vb.
Convert PDF to HTML. |. Home ›› XDoc.PDF ›› VB.NET PDF: PDF to HTML. Convert PDF to HTML in VB.NET Demo Code. Add necessary references:
image from pdf to powerpoint; convert pdf to powerpoint online
14 
Figure 1: An Example of a PERT Chart.  The Critical Path is shown in red. 
(Source: Computing Essentials, T. O’Leary & L. O’Leary, McGraw Hill, 1999) 
Figure 2: An Example of a GANTT Chart.  The Critical Path is shown in red. 
(Source: Computing Essentials, T. O’Leary & L. O’Leary, McGraw Hill, 1999). 
C# powerpoint - Convert PowerPoint to PDF in C#.NET
C# PowerPoint - Convert PowerPoint to PDF in C#.NET. C# Demo: Convert PowerPoint to PDF Document. Add references: RasterEdge.Imaging.Basic.dll.
convert pdf file into ppt; and paste pdf into powerpoint
C# PDF Convert to HTML SDK: Convert PDF to html files in C#.net
Convert PDF to HTML. |. C#.NET PDF SDK - Convert PDF to HTML in C#.NET. How to Use C# .NET XDoc.PDF SDK to Convert PDF to HTML Webpage in C# .NET Program.
pdf to powerpoint; how to change pdf to ppt on
15 
4. Documenting Your Project 
During the course of the year, you have to write three reports.  These are the Project 
Specification, the Interim Progress Report, and the Final Report.  These reports are 
important for several reasons.  First, they are formal components of the assessment 
exercise. In other words, they contribute towards the overall mark you will receive for 
your work.  Second, and equally important, these report are valuable milestones for 
you: they help you focus on achieving concrete outcomes as your project progresses.  
The documentation of these outcomes is a difficult and time-consuming process: do 
not underestimate the importance or the magnitude of the task.  
4.1 Project Specification
The first report you have to write is really an extended definition of what the project is 
all about.  Note that this is a ‘project specification’ and not a ‘system specification’.  
That it, it must address not just the system which will be created as a result of the 
project, but also the entire development process by which it will be created.   Of course, 
it will also include a major section on the system specification but it must also address 
other issues such as the requirements elicitation, the development lifecycle, the tasks 
that must be undertaken to a achieve successful conclusion, a description of the 
problem domain, a description of the solution domain (i.e. environment in which the 
system will operate), and the theoretical foundations for the system.    
Since this report must be produced approximately six weeks into your project, it is not 
likely that your system specification will be extremely detailed.  In addition, the 
schedule of project tasks will probably be only good estimates and will have to be 
refined as the project proceeds.  
The ultimate goal of this report is to present a clear and explicit definition of the 
required system, together with the steps that you will take to realize this system. 
The following is an outline of a typical Project Specification Report. 
Title Page 
ɽ 
Specific Title of the Project (e.g. “Automatic Test Pattern Generation for Digital Circuits”)  
ɽ 
General Title (i.e. “Project Specification”) 
ɽ 
Degree (e.g. B.Eng. in Computer Engineering) 
ɽ 
Author (name and student identification number) 
ɽ 
Institution (i.e. Etisalat College of Engineering) 
ɽ 
Supervisor  
ɽ 
Date  
Table of Contents 
Section 1. 
Introduction 
1.1 
Brief summary of the problem being addressed. 
1.2 
Overview of the target domain for the final system (where is it going to be used?) 
1.3 
Overview of the technical area, i.e. background technical and theoretical context. 
1.4 
Summary of the system functionality (what is it going to do?) 
1.5  
Overview of the report: what material will you be covering and how is it arranged? 
VB.NET PDF Convert to Word SDK: Convert PDF to Word library in vb.
VB.NET PDF - Convert PDF to MS Office Word in VB.NET. VB.NET Tutorial for How to Convert PDF to Word (.docx) Document in VB.NET. Best
how to change pdf to powerpoint slides; export pdf into powerpoint
VB.NET PDF Convert to Tiff SDK: Convert PDF to tiff images in vb.
VB.NET PDF - Convert PDF to TIFF Using VB in VB.NET. Free VB.NET Guide to Render and Convert PDF Document to TIFF in Visual Basic Class.
how to convert pdf to ppt online; convert pdf file to powerpoint presentation
16 
Section 2. 
System Requirements 
2.1 
Required system functionality: focus on the functionality that a user  
requires of the system, rather than on how the system will deliver that  
functionality. 
2.2 
List of criteria that define a successful project: expected outcomes, required 
system behaviour, and especially performance metrics. 
Section 3. 
Theoretical Foundations: The Engineering Model 
3.1 
Introduction 
3.2 
Details of theoretical model 
ɽ 
Mathematical/computational model 
ɽ 
Discrete or other approximations 
ɽ 
Limitations and assumptions 
ɽ 
Possible algorithm options 
Section 4. 
System Specification  
4.1 
Functionality provided by the system 
4.2 
System interfaces, inputs, and outputs  
4.3 
System models: 
Functional decomposition 
Entity-Relationships 
Data-Flow Model 
Behavioural Model - State Transition Diagram 
4.4 
Specification of user interface 
4.5 
Failure modes and action on failure 
4.6 
Target architecture 
Section 5. 
Task Analysis and Schedule of Activities 
5.1 
Task decomposition 
5.2 
Project schedule 
5.3 
Task specification: for each task, identify goals, inputs, outputs, estimated effort 
and duration, and task dependencies. 
Section 6. 
Project Management 
6.1 
Meetings with supervisor 
6.2 
Major risks and contingency plans 
6.3 
Principal learning outcomes 
References 
Appendices 
ɽ 
Project description from the project list 
17 
4.2 Interim Progress Report
The Interim Report should focus primarily on presenting the progress that has been 
made in achieving the initial goals.  It takes the project specification report as its 
baseline. Any amendments to the project specification should be highlighted and 
discussed in full.  Similarly, any deviation from the schedule should be identified and 
all amendments to the schedule should be addressed: explaining the need for the 
change, the nature of the change, and any knock-on effects.  The interim report should 
provide a complete summary of all project outcomes to date.  These include project 
management documents, system analysis documents, theoretical development, system 
design, implementation, and early results.    
The following is an outline of a typical Interim Report. 
1. Goals of the Project 
Give a short summary of the main objectives of the project and the expected results. 
2. Synopsis of the System Specification 
Provide an abstract of the first report (i.e. the Initial Specification), setting out the main 
features of the system or project and addressing at least system functionality, interfaces 
(electronic and/or human), and signal/information representations.  This synopsis might be 
listed as a series of bullet points. 
3. Overview of Task Specifications and Project Schedule 
List the primary tasks and sub-tasks required to carry out the project and an overview of the 
project schedule, giving the timings (start date, duration, amount of effort) of each task. 
4. Review of Tasks 
Provide a comprehensive review of the status of each task and sub-task, setting out at least: 
♦ The status (not started, on-going, complete, behind schedule, ahead of schedule …); 
♦ Problems encountered and identified solutions; 
♦ Anticipated problems and possible solutions; 
♦ Impact on the project schedule. 
5.  Summary of Changes to the Specification 
List and discuss the changes which have been made to: 
♦ System functionality; 
♦ Tasks and sub-tasks; 
♦ Project schedule. 
6. Interim Results 
If possible, provide examples of any interim results you have achieved. 
7. Short Term Plans  
Identify the next steps you will take in the project. 
18 
4.1 Final Report
Your final report is a critical part of your project.  It defines what you have done and 
why you have done it.  It is also one of the chief ways that your project is examined and 
assessed and it on the basis of the project that you will receive a large proportion of 
your marks. 
In writing your Final Report, you will need to decide on its content and on its structure.  
We will look at both of these aspects in turn, beginning with the content.  We will 
conclude with a few guidelines on good writing practice. 
4.1.1 Content of the Report 
Clearly, the content of the report is going to vary from project to project and it is 
difficult to make any strict recommendations.  However, we can  make a few general 
observations about the content of your report. We return again to the definition of 
engineering at the beginning and highlight the phrase: 
“Knowledge … is applied with judgement …” 
Your final year project provides you with an opportunity to demonstrate your ability to 
use your judgement.  This means that you must show your skill at 
ɽ 
Assimilating 
ɽ 
Synthesizing 
ɽ 
Critically Appraising 
all material relevant to the engineering project.    
Your main opportunity to display your talents at assimilation and synthesis comes 
when you describe the background material you read, the requirements, specification, 
and design phases of your work.  Needless to say, synthesis means that you must write 
the text yourself, expressing your understanding of the material in your own words.   
Resist the temptation, no matter how strong, to copy sentences or paragraphs (or 
whole sections) from other books or articles.  Copying is not synthesis and it 
demonstrates neither your assimilation of material nor your understanding of it.  If you 
do come across a sentence or paragraph which is so good that is just has to be used, 
then do so and include it as a direct quotation, providing a reference to the original 
source. 
It is extremely important that you also appraise, or assess, your work critically, i.e. 
with objectivity and with a view to seeing how it could be improved.  Such honest 
criticism does not mean you will receive fewer marks; in fact, it is likely that you will 
receive more.  Typically, you exercise your talents of critical appraisal at the end of the 
report in a discussion chapter but you can also exercise it throughout the report 
wherever it seems appropriate.  Note that this exercise of critical appraisal is different 
from the testing processes of verification, validation, and evaluation, which refer to the 
functionality of the system you have designed.  The critique you write applies less to 
the system and more to the overall objectives, methodologies, and findings of the 
project. 
19 
4.1.2 Structure of the Report 
The structure of your report is critical to the impact you make in your writing.  
Remember that you are trying to convey a message to the reader and, since this message 
is likely to be quite complicated, you must assist him or her by making your points 
clearly and in a logical order.  Think of it as telling an exciting story:  you want to tell 
enough early on to attract the reader’s interest but not too much otherwise he will 
become confused. You want to build up to a climax, incrementally revealing more and 
more of your message, but doing so in a way which builds on what you have already said.  
This is what we mean by a logical structure: breaking up the ‘story’ into a sequence of 
messages which follow naturally one from the other and which lead to an interesting 
conclusion (i.e. a conclusion you couldn’t have guessed from reading page 1). 
Because all engineering projects involve (or should involve) the exercise of a fairly 
standard engineering methodology (requirements, specification, modelling, realization, 
testing & evaluation), you can, if you wish,  adopt a fairly standard structure.  Note 
well, however, that this does not mean that you just simply have to fill in the gaps in a 
general report template: this  standard structure simply provides you with a place to 
start as you begin to design the final structure and content of your report.  You will 
still have to do quite a lot of work to make it fit your own project.  A typical outline of a 
final year project report is provided on the next page. 
You should design your own report to the level of detail given in the proposed 
structure, adapting it to your own particular needs.   Note that you should do this 
before you start writing anything.  It’s just like designing a piece of software: the sooner 
you start coding, the longer it will take (and the more likely it is to be wrong).    Try to 
achieve modularity and independence amongst your chapters and sections.  At the 
same time, remember you are trying to convey a convincing message to the reader.  
Again, it’s like telling a good story: you have to keep the reader interested and he has 
to be able to follow the story-line (which means there has to be one: make sure there 
is).  Keep the thread of the story going continuously, from section to section, and from 
chapter to chapter by providing link sentences or paragraphs: at the end of a chapter, 
for example, remind the reader of the important messages, tell him why they are 
important, and then say what you need to look at next, and why, in order to continue 
with the story.  That’s your cue for the next chapter. 
In general, your final report should be between 40 and 80 pages long, not counting 
appendices and front matter.  The report should be printed on A4 paper, single-sided, 
using either in space-and-a-half or double line spacing, and leaving left and right 
margins of approximately 25mm.  You are required to submit three copies (one for the 
Library, one for your supervisor, and one for the Academic Director).  You should also 
make a fourth copy for your own records.  Note that copyright of the projects rests with 
the Etisalat College of Engineering as do all intellectual property rights associated with 
the project.  In essence, this means that the report is confidential to the College and 
may not be copied, published, or otherwise disseminated without the prior written 
permission of the College management. 
20 
Typical Structure of a Final Year Project Report 
Title Page 
ɽ 
Specific Title of the Project (e.g. “Automatic Test Pattern Generation for Digital Circuits”)  
ɽ 
General Title (i.e. “Final Year Project Report”) 
ɽ 
Degree (e.g. B.Eng. in Computer Engineering) 
ɽ 
Author (name and student identification number) 
ɽ 
Institution (i.e. Etisalat College of Engineering) 
ɽ 
Supervisor  
ɽ 
Date  
Abstract 
ɽ 
What is the subject matter of the report: what did you do? 
ɽ 
Motivation: why did you do it? 
ɽ 
Significance: what are your findings and conclusions? 
ɽ 
The abstract should be approximately 200 words long.  It normally takes at least four 
revisions to achieve a good abstract. 
Table of Contents 
ɽ 
Chapters 
ɽ 
Sections 
Acknowledgements 
ɽ 
Help from friends, colleagues, and staff.  
ɽ 
Support from Etisalat 
ɽ 
Support from Parents, etc 
Chapter 1. 
Introduction 
1.1 
Goals & Objectives: what was to be achieved? 
Motivation:  why undertake the project? 
Method: how was it undertaken or carried out? 
1.2 
Overview of the technical area, i.e. background technical context 
1.3 
Overview of the report: what material will you be covering and how is it 
arranged? 
Chapter 2. 
System Overview 
2.1 
Requirements 
2.3 
System Specification 
Chapter 3. 
Theoretical Foundations: The Engineering Model 
3.1 
Introduction 
3.2 
Details of theoretical model 
ɽ 
Mathematical model 
ɽ 
Discrete or other approximations 
ɽ 
Limitations and assumptions 
Documents you may be interested
Documents you may be interested