25-08-2017, 09:32 PM
1456601827-DavidVernonProjectManual.pdf (Size: 264 KB / Downloads: 19)
The Importance of Final Year Projects
Your final year project is one of the most important aspects of your engineering degree.
To see why, let’s look at a definition of engineering, taken from the IEEE.
“Engineering is that profession in which knowledge of the mathematical,
computational, and natural sciences gained by study, experience, and practice
is applied with judgement to develop economically effective use of matter,
energy, and information to the benefit of humankind.”
Engineering is first and foremost the application of knowledge. However, the
application must be carried out with judgement, to ensure that the resultant system is
effective and efficient, and that it is of benefit (which raises the issue of the ethical
responsibilities of engineers – a topic for another day). The final year project is one of
the primary the mechanisms used by the College to provide you with an opportunity to
gain experience in the practical, effective, efficient, and beneficial application of what
you have been studying for the past several years. Naturally, you will continue to gain
engineering experience after you graduate but the final year project will be your first
exposure to the full rigour of engineering practice. It is essential that you learn from
this exposure and practise all of the engineering methodologies involved. It is
particularly important that you learn not just to apply what you know, but to apply it
with judgement, with the ability to assess what you are doing and to be critical of it.
There is another reason why your final year project is so important: it will inevitably be
used as a discriminator to decide how good an engineering student you are. If you end
up with a result in your degree examinations which is on the borderline between one
grade and another, the examiners will look at how you performed in your project and
then they will make a decision as to which grade you should be assigned.
Finally, your final year project counts for 25% of your 5th Year marks and 17.5% of
your overall degree mark.
So, for the next 8 months, you should devote yourself totally to your final year project.
Think of it as your passport to the engineering profession – your formal studies are
your ticket but without your passport, you can’t travel. Note, however, that you
shouldn’t neglect your other studies in the pursuit of your project: a passport is
useless without a ticket!
Now that we have established the importance of your final year project, let’s look at the
important issues in pursuing it. There are four principal concerns:
1. Choosing a project
2. Planning, executing, and managing your project
3. Documenting your project
4. Assessment of your project
We will look at each of these in the following sections.
Choosing Your Project
Given that you are going to spend a lot of time working on your project, it is essential
that you pick a project which you like and which you are capable of doing. Note that
these are not necessarily the same things: just because you like a particular project
doesn’t mean you are qualified to do it. You may not have taken all of the requisite
courses or it may be a more theoretically-aligned project whereas you might be a more
practically-oriented engineering student (or vice versa). Think long and hard before
making your final choice. At the very least, you should take the following steps in
assessing and choosing an appropriate topic.
1. Find out what are your options.
A list of projects proposed by academic staff will be distributed to you in week 1.
You should:
• Read all the descriptions
• Identify the ones that interest you
• Read them again
2. Make a short-list of three projects.
3. Think about proposing your own project. Using the descriptions you have read as
a guideline, write your own proposal. Note, however, that the feasibility and
suitability of your proposal will have to be assessed before it can be added to your
list. Submit your proposal to the Project Coordinator who will have it reviewed by
an appropriate member of staff.
4. Go and talk to the supervisors (i.e. the member of staff who proposed the project or
the person nominated by the project coordinator in the case of your own proposal).
5. Go away and write down what you think the project is about.
6. Submit a ranked project selection form to the project coordinator by the end of
Week 2.
7. Your selections will now be reviewed by the project coordination panel.
8. A list of allocated projects will be published in Week 3.
9. Now you can begin your project in earnest … you should begin by making a
preliminary plan (see next section).
Planning, Executing, and Managing Your Project
Most students have no idea how to begin their project. This is understandable: it is the
first time they will have had to tackle a large amount of work that is probably poorly
defined (the project descriptions provided by lecturers are rarely complete!) To get
started, it helps to know the key activities that result in a successful project. They are:
1. Problem identification
2. Requirements elicitation
3. Problem modelling
4. System analysis and specification
5. System design
6. Module implementation and system integration
7. System test and evaluation
8. Documentation
9. Project management
3.1 Problem Identification
Problem Identification involves a lot of background work in the general area of the
problem. Normally it calls for the use of prior experience, typically experience you may
not yet have. It requires an ability to look at a domain (e.g. telecommunications or
engine control) and to identify the issue that needs to be addressed and the problem to
be solved (e.g. elimination of noise or cross-talk on a communication channel, or
engine control for temperature-dependent fuel efficiency). It also required an
understanding of the theoretical issues by which we can model the problem. So, the
first thing you need to do in your project is become an expert in the problem at hand: a
problem-domain expert.
At the same time, you also need to know how to handle the tools that will enable you to
solve the problem. These might include the operating system, the programming
language, the application programming interface (API) definitions, class libraries,
toolkits, or any application-specific analysis utilities. That is, you also need to become
a solution-domain expert.
The only way to become an expert in both the problem domain and the solution
domain is to learn as much as possible about the area and to learn it as quickly and
efficiently as possible. Many people come unstuck at this first step and they launch
themselves into a frenzy of unstructured research, reading much but learning little.
Here are some tips to avoid this happening.
Collect any papers, articles, book chapters you can on the area and make a copy
for your own personal archive.
Make sure you keep a full citation index, i.e., you must record exactly where every
article you copy comes from. Typically, you need to record the title of the article,
the authors, the name of the magazine/journal/book, the volume and number of
the journal or magazine, and the page numbers. If it’s a chapter in a book and the
author of the chapter is different from the editor of the book, you need to record
both sets of names.
Not all the articles you collect will be equally relevant or important. Consequently,
it’s not efficient to give each of them the same attention. But it’s not easy to know
how relevant it is until you read it. So how do you proceed? To solve this dilemma,
you should know that there are three levels of reading:
1. Shallow Reading: you just read the article quickly to get an impression of the
general idea. Read it twice. This should take a half-an-hour to an hour.
2. Moderate Reading: Read the article in detail and understand all of the main
concepts; this will probably require you to read it several times and take a
couple of hours to assimilate.
3. Deep Reading: Here you make an in-depth study of the article. This may take
you several hours or even a couple of days. After many careful readings, you
should know as much about the topic as the author.
The way to proceed with your ‘reading in’ is to
♦ Shallow read everything and write a 5-line summary of the article
♦ If you think the article is directly relevant to your project, label it, and put it on
a list of articles to be read at the next level, i.e. Moderate Reading.
♦ Read all the labelled articles and write a 1-page summary.
♦ If the article is going to be used directly in the project, e.g. as a basis for a
hardware design or a software algorithm, then you need to add it to your list of
articles to be read at the next level, i.e. Deep Reading.
♦ Read all the Deep-Read articles and write extensive notes on them.
Note that the ‘reading in’ phase of the project can last quite a long time (there’s a lot of
reading and writing to be done) and it can overlap partially with some of the other early
tasks, such as requirement elicitation, the topic of the next section.
Finally, it is very important that you realize that, in order to fully understand anything
that you read, you must write it up in your own words. If you can’t express or speak
about a given idea, then you haven’t truly understood it in any useful way. This is so
important that it’s worth saying a third time:
Writing is an Essential Part of Understanding
This is why, in all of the above guidelines, you see recommendations to write things
down.
3.2 Requirements Elicitation
Having chosen your project, you will have in your possession a short description of
what is involved in the project. You will realize by now that this is completely
insufficient for you as a basis for doing the project. Consequently, your next task must
be to find out exactly – and completely – what the project entails. This isn’t as easy as
it sounds. You might think that you should just ask your supervisor and he or she
should tell you. It doesn’t work like that. Quite often, a supervisor won’t have an
exact (and complete) model of what is required – supervisors are just like engineering
clients and customers in the business and industrial world. It is your job to help your
7
supervisor identify exactly what he wants. That’s what good engineers do: they help
people understand what they want and then they build it for them. Here’s how you do
it.
1. Talk to your supervisor.
2. Write down everything he or she says (by ‘write down’ I mean take notes of his or
her words).
3. Write up everything he or she says (by ‘write up’ I mean express what your
supervisor said in your own words).
4. Build a document describing what you think is required.
5. Go back to your supervisor and ask for her or his comments.
6. Return to step 1, and keep returning until you are both happy with your
requirements document.
This all translates into one simple rule: find out what you want the final system to do
and how it should behave, write it down, and get everyone involved to agree to it … in
writing. And don’t spare the detail: every single aspect of what’s wanted should be
teased out and agreed: what it does, what it doesn’t do, how the user is to use it or
how it communicates with the user, what messages it displays, how it behaves when
the user asks it to do something it expects, and especially how it behaves when the
user asks it to do something it doesn’t expect.
This process is called requirements generation. It’s also called requirements elicitation
because it reflects better the fact that you have to work actively with the client to find
out what they really want (as opposed to what they initially say they want, which is a
completely different thing). Perhaps it should be called requirements extraction because
it’s sometimes like pulling teeth (but, of course, not in the case of any of the Etisalat
University College supervisors!) Once you have been though the requirements
elicitation process several times and you are happy that you really know where you
want to go, you must write it down and get everyone concerned to agree to it. This
then becomes part of the system specification: it says what you are going to do. But
that’s the subject of the section after next.
3.3 Problem Modelling
Once you know the requirements, and are an expert in the problem domain, you can
abstract the problem from the problem space and model it computationally: this
means we can identify the theoretical tools we need to solve the problem. Examples
include statistical analysis for the elimination of noise on the communication channel,
characterization of the relationship between fuel consumption and engineer cylinder
temperature for the engine control; the extraction of facial features from images, and
the statistical classification techniques used to match these feature with faces in a
database.
This is the foundation of all engineering and science: the creation of a rigorous –
usually mathematical – description of the real physical problem to be addressed, be it
control, communications, electronics, or some computational model. For example, if
your problem concerned with packet routing, you might represent it using a graph and deploy formal graph theoretic tools for its analysis; if your problem is concerned with
signal analysis, you might choose a Fourier representation or an eigen-vector
representation and deploy the appropriate theorems in Fourier analysis or linear
system theory. If your problem is to do with building a database, you will probably
model the system with an entity-relationship diagram and validate the model by
normalization.
The key to all successful engineering is the use of an explicit model: if you don’t have a
model, you are probably not doing engineering. Connecting components (or lines of
code) together is not engineering, irrespective of whether it works or not. Without the
model you won’t be able to analyze the system and, thereby, make firm statements
about its robustness, operating parameters, and limitations.
You may also wish to consider the use of a symbolic mathematics package such as
Maple in the development of your mathematical model.