What's an abstract?
An abstract is LIKE A MOVIE TRAILER. It briefly describes some exciting elements of your project. It is usually a brief yet interesting summary of:
- your project
- the extent of your research
- selected (important) results
To help you write the abstract, try to think about the following questions:
- Why would another student or researcher be interested in this project or research?
- What are the most important aspects of the project or research? What should a reader be sure to know after reading your abstract?
- What information will the reader have to have in order to understand the most important aspects?
- What are the main points from each section of your report? Summarize each section in one sentence, if possible.
In addition, we would add:
- Incorporate the key facts and conclusions from the body of the report.
- Write the abstract using mainly present simple verbs.
- Try to keep your abstract to 50-200 words.
The methodology section should serve as an instruction manual with which another FYP or FYT student could completely duplicate your results. It should include facts, procedures, equipment, data, details, tests performed and results (success or failure or what degrees or each.) It should also tell the two professors who give you your grade what was special about your work. Beware of two extremes:
- Not explaining clearly what you did or being specific in how you did it.
- Telling about almost every tiny detail and boring the readers to death. (You don't need to write a user manual!)
Instead, try to show your readers how you are intelligent, clever, skillful and resourceful and how you utilized your software engineering skills or computer science knowledge. For boring details, put them in appendices or just leave them out. Focus on what's important. Imagine what you would write if you were taking your report to a job interview and letting your prospective employer look at it! Why would he want to hire you? Or if you were to apply to grad school, would your report help or hurt your chances?
For Design, think about WHAT you did:
- What does the system look like?
- What are the hardware and software components, and how do they relate to each other?
- What kinds of functions can different kinds of users perform and in what sequence can or should they perform them?
- What does the data look like that is used for input, and do you need to do anything to it before processing it?
- What processes are involved in the system, and how do they relate to each other?
- What algorithms or formulas were needed, and why did you use them?
- What does the output information look (or sound) like? (If you have a lot of screen shots, it might be best to put them in an appendix.)
- What elements of the user interface (UI) make it user-friendly and/or facilitate a good user experience (UX)?
For Implementation, think about HOW you did it and HOW you applied your software engineering skills or other computer science knowledge:
- What data, coding tools, development kits, IDE, libraries and APIs did you use, and where did you get them?
- How did you set up the server (if your system has one)?
- How did you build your database, and how is it updated?
- What important steps did you follow as you built the system, performed experiments or recorded data?
- What cool or creative ideas did you come up with?
- What were the most difficult parts of building the system or solving your problem, why were they difficult and what steps did you take to try to overcome them?
- What assistance did you seek from your advisor or other knowledgeable people?
For Testing, think about this:
- What could possibly go wrong from the user's point of view? (If you have a lot of test cases, you can list them in an appendix.)
- What types of tests helped to locate bugs or logic errors?
- How did you make the testing environment realistic? Did you need to run any simulation?
- What devices or equipment were used in the experiments?
In the Evaluation, think about this:
- Did we accomplish each of our objectives? (Explain one-by-one.)
- What went well, and what didn't?
- What factors might discourage people from actually using the system in real life? (See also Evaluation or FYP final report examples.)
- What statistics, charts, or graphs might help me illustrate how good (or bad) the system or approach is?
Think about this:
- WHY did you succeed or fail or only partly succeed in accomplishing each objective?
- What does your reader need to know before anything else in order to understand and be persuaded to believe your argument?
- What is the most important thing for your reader to understand from your interpretation? Consider placing this first.
For organization, you can either follow the sequence used in your Evaluation, or perhaps you can organize your information starting with what you are most happy or certain about and progressing towards matters that you are less happy or certain about.
For research reports, the sequence might follow this outline:
- Discussion of the data
- Generalization or analysis of the data
- The relationship between the data and the research problem or hypothesis
- What can be inferred from the data
In this section, you summarize the major technical accomplishments of the project and suggest areas for future research and analysis. Focus on:
- the key things you did and learned
- problems not addressed in your paper
- questions that were not answered in your paper
- what techniques or algorithms or tools might be useful for further development
The Conclusions section doesn't need to be long. One page may be enough.
Q&A about the final report
What's the difference between testing, evaluation and discussion?
Implementation and testing are like playing a basketball game. Evaluation is like the game statistics; discussion is like what the players or spectators say about the game afterwards.
In your evaluation you summarize the results from testing and state how well you achieved your objectives. This is very objective (客觀的). In your discussion, you interpret the results based on your opinions, so it is more subjective (主觀的). In the discussion you can also mention what you could have done better. Nobody's perfect. Some of the best lessons of life are learned from our mistakes.
What do we do with the Project Planning and Required HW & SW sections?
You can simply move these to appendices, for example, "Appendix B - Project Planning" and "Appendix C - Required Hardware and Software". You can have several appendices, if necessary. In the past, some FYP groups had 5 or 10 different appendices.
What if we changed our project scope and cancelled some objectives?
You can delete all mention of the cancelled objectives in the final report, because they are no longer relevant, but be sure to mention what parts you cancelled and why you cancelled them in your Discussion.
Can we change the title of our project?
Yes! The title should accurately and concisely describe your project in its final state. Many FYPs start with a title that reflects a concept that is quite different from the final concept. Make your final title describe the final concept. If your CT suggested a new name and that name fits, it is probably best to use that title.
How do we label pictures and graphs?
Most writers center the picture or graph or table and put a description underneath which identifies the figure for easy reference and identification, for example: Figure 3 - System flowchart. To be reader-friendly, figures are also usually best placed directly under the paragraph that first references them, not several paragraphs down or on another page.
What verb tense should we use?
There is no fixed rule, because projects differ, and sections of the report differ. However, in general present tense is usually appropriate for concepts and application features, for example, "The frequency is denoted by ..." or "The system calculates ..." Past tense is usually appropriate for work you did, for example, "We developed a system..."