FYP Progress Report
The FYP progress report is due in It is usually about 10 to 39 pages long, single spaced, not including the appendix. (See Table of Contents for the FYP Progress Report.)
Advice from a 2003 CS graduate regarding the FYP - "Don't leave all the writing until the end. Keep notes - especially for the Progress, Design, Implementation, Testing and Evaluation sections. Even if the notes are only in point form, it will be much easier to write the Progress Report."
Progress Report Format
Since your CT will probably make a lot of marks and notes on a hard copy of your report, please submit your proposal in MS Word format, and please use a 12pt font with double spacing or 1.5 lines (click Format, Paragraph, Line Spacing.) Before you submit your progress report to the FYP management system, you can change back to single spacing.
A Possible Plan
Your progress report is the basis for the final report. After your CT copy edits your submitted proposal, you can meet him/her to discuss it. This can be done between October and January. Then, you can go back and edit your proposal document and save it as your progress report. Ideally, you add to it as you as you make progress - do some work and then document it. A lot of groups procrastinate and wait until January to do most of the work, but smart groups do a lot of their coding and experimenting by the end of the Christmas holiday, complete a draft progress report for their CT to copy edit or proof-read in January and then make changes before submitting their progress report in February.
Introduction
Don't rewrite your introduction, perfect it.
- Has your supervisor requested that you radically change your introduction?
- Have you changed the scope and aims of your FYP?
If not, you should not waste time rewriting your introduction. Instead, use the time to make sure your introduction is perfect. Proofread and check your verb tenses.
Progress
In this section, think of the investigative process that you have gone through; the trial and error. Did you think that Giddy's algorithm should work, but, in testing it, it didn't work? Why didn't it work? What did this [the fact that it didn't work] tell you? How did you apply this knowledge to the next algorithm you chose?
This section is important as it shows your team's ability to think analytically and to problem-solve.
Design
- Refine and formalize ideas and methods [For example: optic design, data structure design].
Implementation
- Describe in detail how you will implement your ideas and designs.
Testing
- Provide a test plan
- Must be more detailed than in the Proposal.
- Think of how you will determine if it is efficient - how will you interpret the results? How can you tell whether your implementation is effective and efficient?
Evaluation
- Find a comparable system.
- Find more data sets.
- If it is a multifaceted system, take out one component and compare.
What else have you achieved in the project so far? Focus on the project, not on you.
Example: BAD
We had the opportunity to apply several concepts that we learned from our software engineering course.
Example: GOOD
To ensure that our software would operate across platforms, we drew upon three well-established concepts in software engineering: X, Y, and Z.
The BAD example starts to sound like 'My Summer Holiday' - more of an essay than a research paper. The GOOD example actually gives more information, telling why something was done.
Project Planning
Update the Gantt Chart and the Division of Work including everything that you have done and will do.
References
Update, unless you didn't get it right the first time.
Appendices
More meetings=more minutes
Keep your minutes up-to-date. Do them within a day of the meeting. Don't waste time just before the Progress Report is due trying to remember what you said at a meeting five weeks ago.
Remember when writing up your minutes that they should cover:
- tasks done
- problems/suggestions
- tasks to do, by when, by whom
Meetings are a platform for YOU to ask questions. Don't leave technical questions unanswered - it is your job to bring these questions to your supervisor.
Other things that you can find in an appendix:
- detailed proofs
- results from experiments
- illustrations
- diagrams
- tables
If a table/illustration/diagram is critical for explaining an abstract idea, it may be better to include it in the body of the paper and not in the appendices. Ask your supervisor if you are unsure but the general rule of thumb - if it's big and bulky and of little relevance to most readers, stick it in the back.
Progress ReportResource: Handbook: Progress Reports
Caution!
The sooner you start each phase, the better! Keep in mind that some employers and grad schools might want to look at your FYP to see what kind of work you can produce, so it could affect your future studies or career.
Related Links