University of Malta
 

FYP FAQ
UOM Main Page
 
 
 
Apply - Admissions 2016
Newspoint
Campus Map button
Facebook
Twitter

FYP FAQ

This is a list of frequently asked questions which should help you with your FYP.
DISCLAIMER: This is not an official document and is not meant to be your only guide. Always consult with your supervisor before taking any substantial decisions.

  1. What is an abstract?
  2. What should the introduction include?
  3. What should my aims and objectives include?
  4. What is the difference between Background, Related Work, and Literature Review?
  5. What should I write in the design chapter?
  6. What level of detail should go in the implementation section?
  7. Should I present stuff in a top-down or bottom-up fashion?
  8. Diagrams tell a thousand words, are there any rules when using them?
  9. How should I present mathematical formulae?
  10. Should I mention the different solutions/approaches considered throughout the life-time of the project?
  11. What is the difference between testing and evaluation?
  12. Do I always need to have an evaluation?
  13. My evaluation is case-study-based. How do I choose my case study? How many case studies should I have?
  14. The problem I am trying to solve is too big, what should I do?
  15. For my evaluation I have to run experiments and gather data. Any pitfalls I should be aware of?
  16. Furthermore, when gathering results there are a number of threats to validity. For example, are the experiments repeatable? If yes, do you get the same result over and over again? Are there other variables in play apart from those being considered?
  17. I need to carry out a survey using a questionnaire for my evaluation. How should I choose the subjects? And how many subjects should I choose?
  18. When do I need to apply for an approval from the ethics board?
  19. Do I have to contribute academic knowledge for my FYP?
  20. Is it true that every chapter in my report should have a conclusion?
  21. What might examiners consider?
  22. Are there any general rules for writing up?
  

What is an abstract?

    An abstract should provide a quick summary of the problem solved, how it has been solved, and the results which have been achieved.

 

 

What should the introduction include?

    The introduction should have the following components:
       
  • Motivation for the problem - why is the problem being studied interesting and worth solving?
  • Problem definition (or aims and objectives) - a clear description of the problem/research question being addressed and how would you be able to measure/check whether the problem has been solved.
  • Limitation of current solutions - why the problem is not currently adequately solved
  • The proposed solution - what is the approach taken in this work?
  • Contributions - a summary of the achievements
  • The rest of the document - a quick tour of the rest of the work

 

 

What should my aims and objectives include?

    Most importantly, the aim of a scientific project is not to build something but rather to answer a research question. Examples include:
  • What is the best approach to solving … out of these approaches?
  • Can this approach improve/contribute to/etc … ?
    The implementation part of the project is simply to serve as an experiment to be able to answer this question. Once the aim (question/s) is set, this can be broken down into smaller aims (objectives). Importantly, the objectives should provide the necessary details and rigour which would enable a reviewer to check whether the question has been answered correctly. Thus, objectives should clearly answer: 
       
  • What do I mean by “best approach” in my research question?
  • What do I mean by “improve/contribute to/etc” in my research question?
  • This would then provide a clear connection to the evaluation of the project

  

What is the difference between Background, Related Work, and Literature Review?

    The background section should provide the reader (assuming the reader has an undergraduate degree in ICT) with enough information to be able to understand the rest of the project. The related works section usually is the chapter before the conclusion and its purpose is to related the contribution presented in the document to other similar works in the field. Note that a list of related works in not enough! For each piece of work, one should clearly state how it compares to the presented work. Furthermore, ideally the works are not simply organised in a list but rather organised according to some applicable classification. Literature review is a generic term used to refer to both background and related work concepts.

  

What should I write in the design chapter?

    The design chapter typically starts with presenting the general picture (e.g. a block diagram of the solution) and then take the reader through the choices carried out explaining the reasoning behind them. 

  

What level of detail should go in the implementation section?

    A common problem with FYP reports is that they give too much detail in the implementation section. Unless is crucial to your contribution, typically there is no need to go into class structures and other similar details. Keep the reader interested and simply give glimpses of the main and interesting aspects of your implementation.

 

 

Should I present stuff in a top-down or bottom-up fashion?

    A big problem when trying to read FYPs is that stuff is usually presented in a bottom up fashion, i.e. start with a lot of details and seemingly irrelevant stuff, only for the reader to realise the purpose of the details ten pages later. The problem is that top-down doesn’t always work either: how can you present something if you haven’t provided the background for it? So the answer for this question is: start with the big picture, perhaps using an example or a case study and explain the intuitions without going into the full detail. Then, once the reader has an idea of the full picture, use the bottom up approach. So in summary, use a quick top-down approach followed by a meticulous bottom-up approach.

 

 

Diagrams tell a thousand words, are there any rules when using them?

    It’s true that they say that a picture is worth a thousand words, and you should use diagrams when possible, but you should not assume that they are able to tell the story on their own - make sure that what is in the diagram is referred to and explained in the text. 

  

 

How should I present mathematical formulae?

   As has been said about diagrams, make sure that what is written mathematically is also explained intuitively in text. Other than that make sure to organise your results in definitions/propositions/lemmata/theorema/etc and remember the top-down/bottom-up question above: never present mathematics without first giving the big picture.

 

 

Should I mention the different solutions/approaches considered throughout the life-time of the project?

    In general, no, there is no need to mention all the dead ends you encountered during your project. However, if the discovery of dead ends is interesting to the readers, then yes. For example: When applying approach A to problem P, we discovered that we get a wrong result R for reason N. Thus, we applied approach B instead and in this case we got the correct result S because unlike A, B didn’t suffer from problem P.

  

What is the difference between testing and evaluation?

    Testing is simply the checking that the artefact works as expected. However, recall from above that a scientific project is not about the artefact but about answering a scientific question. For this reason, testing is important but not enough! The evaluation is the actual reasoning about the answer of the scientific question. Make sure that the evaluation includes a mature discussion of your findings including any limitations of the generality of your conclusions, which variables affected your results how, etc.

  

Do I always need to have an evaluation?

    You always need to answer the research question however the evaluation can take various forms: 
       
  • Case study driven: A very common evaluation strategy is through the use of one or more case studies. Typically this is used when the project involves the development of a proof of concept to try out a new approach.
  • Quantitative: Another common evaluation is through the use of numeric measurements of particular aspects of an artefact. This is particularly useful when comparing a number of approaches for example with regards to performance.
  • Qualitative: Sometimes it is difficult to get numeric measurements. For example when evaluating the quality of a domain-specific language which has been designed for the project. In this case, evaluation would typically include argumentation to explain why the artefact does in fact have a particular attribute.
  • By proofs: Project which involve formal definitions typically involve formal proofs to demonstrate the sensibility/correctness of the definitions and any relevant properties about them.
   

 

 

My evaluation is case-study-based. How do I choose my case study? How many case studies should I have?

    When choosing a case study, you have to argue why the case study is representative. If you are solving a problem for Java systems and you choose a C program, then clearly this is not a good case study. Similarly, if I choose a 100-line Java system, it might not be applicable if the problem only appears in the case of large systems.  The more case studies you have the better but at FYP level there is a limit to how much one can do. Thus, usually one significant case study is enough, but as always, the conclusions drawn from evaluating a system on a single/few case studies are limited and this should be stated in the report. 

 

 

The problem I am trying to solve is too big, what should I do?

    It is normal that many FYPs start out with trying to solve a big problem and then narrowing down the scope to make the problem manageable. This is not a problem but make sure to ask for a change of title if this applies.

  

For my evaluation I have to run experiments and gather data. Any pitfalls I should be aware of?

    Before starting taking measurements it is imperative to understand exactly what is the question being asked and decide what metrics will be used and how these will be measured. In addition, it is important to decide on and justify the test procedure. For example: Why was this particular experiment of relevance more than others? Why have I decided on using this particular load to evaluate the performance? It is also ideal to perform a small number of tests early and evaluate whether the test plan is correct, so as to avoid investing time in gathering results which are not useful. This may also be further aided by finding the quickest way of gathering results and automating as much of the process as possible (perhaps using scripts).

       

Furthermore, when gathering results there are a number of threats to validity. For example, are the experiments repeatable? If yes, do you get the same result over and over again? Are there other variables in play apart from those being considered?

    Imagine you are measuring the CPU and memory usage of a Java system. Are you sure no other processes on your machine are interfering with your measurements? Have you made sure that the garbage collector is not skewing your results? etc Usually, it is acceptable to observe small fluctuations in results when working with Java systems. In this case make sure to run the experiment over a number of times and take an average. 

  

I need to carry out a survey using a questionnaire for my evaluation. How should I choose the subjects? And how many subjects should I choose?

    Similar to the case study issue, make sure that the subjects you are choosing are representative and non-biased. If applicable, and when possible, subjects should be chosen randomly from a sample. When the ideal standards are not met, one should state so clearly in the report.

  

When do I need to apply for an approval from the ethics board?

    Usually when experiments involve human subjects, and/or personal data, one should apply for an approval from the ethics board. 

  

Do I have to contribute academic knowledge for my FYP?

    No, at FYP level you are not expected to have novelty. Thus, a survey of an area is a valid FYP project.

   

Is it true that every chapter in my report should have a conclusion?

   Yes, make sure that every chapter in your report is properly concluded and that there is sufficient glue across chapters to provide the reader a flowing read.

  

What might examiners consider?

   
  • Proper specification of your work (including hypothesis/es, aims and objectives and evaluation strategy)
  • Proper execution of the pre-defined evaluation strategy (this should have been designed at the initial stages)
  • Proper use of language and formatting (do not submit until you’ve gone through a number of proofreading iterations – need be, seek professional help)
  • The ability to explain your thesis well! Before writing up, make sure you understand what you’re trying to convey (a story). You should be able to explain your thesis to someone else, without using any jargon, in 30 seconds or less. Ask them to repeat what they understood - it’s a crude reality check!    

Are there any general rules for writing up?

  • Less quantity – more academic rigour (thorough understanding of the material at hand).
  • Focus on the underlying concepts and on the learning experience rather than on producing glossy ‘products’
  • Stick to one referencing style (tools here and here).
  • Planning of frequent milestones is expected (stick to your research plan as much as possible)
  • References and Citations    
             
    • You are encouraged to use RefWorks (for free with your UoM account – here)        
    • Use any one of the following styles (ACM, IEEE or Harvard) – but you must be consistent throughout your document
   

Calendar
Notices
Study-unit Registration Forms 2017/8

Register

For Undergraduate (Day) and Postgraduate students.

 

Academic Advisors 2017/8

AA1

Academic Advisors for ICT 1st year students (Intake 2017/8), NOW available

Faculty of ICT Timetables

Timetables

ICT Timetables are available from Here.

Health and Safety Regulations for Labs Form

The Faculty of ICT Health and Safety Regulations for Laboratories form can be found here

 HealthAndSafety

 
 
Last Updated: 15 July 2014

Log In back to UoM Homepage