FYP timeline

You need motivation.


False. You need a deadline.

In the meantime, I'll provide a timeline for handling your FYP.


Note that activities herein are not written in stone, ie, it will certainly change as you go.

Tentative timeline

• Late September to Mid-October
• Mid-October to End-October
• November
• December
• January
• February
• March
• April

Overview of tasks/milestones

Sep Oct Nov Dec Jan Feb Mar Apr
  #1 thinking #2 planning
tools?
planning
coding?
#3 coding
testing
coding
testing
writing
prepping
#4 #5
• #1 Kickstart meeting
• #2 Submit Project Definition Form in Blackboard
• #3 Submit Partial Report (Term Report)
• #4 Submit Final Report
• #5 Present Demo
   Check Ethics submission deadlines (it varies each year)
→ Are you generating (primary) or using (secondary) a dataset that contain any human subject data? (if 'yes', you will need Ethics approval)
→ Are you planning to do Usability Testing with actual users? (if 'yes', you will need Ethics approval)


Late September to Mid-October: Your problem is having a problem.

You have perhaps a project assigned by your supervisor. Does it REALLY motivate you? Remember: you are the one working on this for the next six months!

Propose changes, new directions, new features, and so on.

Have clarity on your tool's objectives and draft (high-level) a list of desired features.

Think as if you are the user of your tool: what are the things (features) the system exposes you to?

→ Proceed writing the Project Definition Form using my pre-filled MS-Word document (it's not assessed, however, it is highly recommended that you produce one, to help you clear your ideas).

top


Mid-October to End-October: Broad survey on tools, datasets, techniques, methods, algorithms, and related work. Start 'formalising' your ideas

Go wild on Internet in search of what other people are doing. Find the tools they used in their approaches, datasets, etc, everything you think it's interesting for shaping your own approach.

Make notes of the interesting things you find - they will be a part of your Partial Report.

Think about your objective (limit to one objective with 1-3 sub-objectives).

  Question:
→ What will be your deliverable?

 Strive (ie, make great effort) finding good resources that you will be able to reference later, ie, stable tools and datasets with 'good' licenses (Creative Commons, Apache, MIT, and so on), papers out of IEEExplore↗, Portal ACM↗, Science Direct↗, or Google Scholar↗ making a note of its Digital Object Identifier ↗(DOI) and for tools/datasets, its URL.

 Related tools give you insights for coming up with your original ideas on how to explore additional features or features that are absent from that tool.

 Remember that for the FYP you will be assessed on the Software Development Life-Cycle (SDLC)↗ that you produced for your tool.

  Observation:
→ We are aware of the use of Large Language Models (LLM)↗ tools (eg, OpenAI's ChatGPT, Google's Gemini, Anthropic's Claude, and so on) so we recommend you to use it consciously in assisting you clear your ideas and providing you with insights.
 However, you must come up with your own ideas and do your own writing. Remember, you will have to present a demo and answer questions about it, so you might as well know what you are doing.
 You will sign a disclaimer stating that your Report is free of LLM auto-generated texts, and not adhering to this might invalidate the module (fail).


Next, choose a Software Development Methodology to follow. You have as options:
(i) Waterfall Lifecycle, that follows a linear sequential approach;
(ii) Unified Process (UP), ie, creating diagrams written in the Unified Modelling Language↗ (UML), eg, Use Case Diagrams, Class Diagrams, Activity Diagrams, and so on; or
(iii) Agile approaches, eg, pure Agile, Scrum based, Kanban, eXtreme Programming (XP), or a combination.

The main difference between (i) and (ii) is that waterfall is sequential and linear approach, whereas UP is iterative and incremental.

→ Agile is not a process per se, it's about using as guidelines the Agile manifesto↗. It is useful when you have changing requirements, offering a flexible approach to tackle emerging issues arising from those changes.

🧐 For Agile, you will need to come up with a set of User Stories AND matched Acceptance Criteria that comprises your tool's features. For more information read "user stories and acceptance criteria"↗ and "writing good user stories"↗.

→ Unified Process↗ is an extensible framework centred on structure and documentation, suitable for when you know all your requirements beforehand. It's iterative and incremental.

🧐 For UP, you will need to come up with the appropriate documentation regarding the methodology in the form of (useful) diagrams, ie, Use Case Diagrams, and so on. Access more information about the Unified Process with examples.


 Note that you can combine everything: employ Agile approach, generate a Backlog (which is a Scrum practice), clarify your tool's features with a detailed Use Case Diagram and a Class Diagram to explain your system's internals. You just need to explain everything in the report.

🧐 Tip: Git-based versioning systems such as GitHub↗, GitLab↗, and BitBucket↗ have internal tools to help you write User Stories (and Acceptance Criteria) - check it out and use it at your discretion.

 By the end of October you are expected to have a "stable" list of [Use Cases AND drafts for complementary diagrams] (if you picked Unified Process) or [User Stories AND Acceptance Criteria] (if you chose Agile) comprising your features (it is suggested to have a list of 5 to 10 features).

  Question:
→ At this point, since you are effectivelly building a tool you need to decide whether or not you will do usability tests with actual users. For this, you will need to apply for Ethics considerations. Be conscious of the deadline for applying (check BlackBoard).

top


November: Refine your ideas, tool design and drafting FYP Partial Report

→ First things first: review and get acquainted with your written requirements (note: I'll use onwards "requirements" to state the use of User Stories/Acceptance Criteria or Unified Process' Diagrams, whatever you chose).

→ Start working on your methodology, ie, the list of steps that you will follow to come up with your tool at the end. This will enter the Partial Report to submit next month.

  Tip: from now on adopt a systematic stance, ie, be methodical, following the methodology you work on earlier.
Apply rigour to your investigations, be consistent.
Write it down your approach and apply to all your research items/tools/datasets/algorithms/etc.

→ Come up with some mock screens (hand drawn or using a graphics tool like draw.io↗ (it integrates with Google Drive).

→ Understand the flow of your tool, ie, how you will expose the features to users.

→ Choose programming languages and scripting tools that your tool will be created with.

→ If you are working with a dataset, code a script or use a tool to interact with the data, observing types and what you will extract/process altogether.

→ Compare similar tools' features, positioning and contrasting with your proposition. Differentiate your approach.



→ Start working on the Partial FYP Report, adding everything you have done so far. It will have the objective (and sub-objectives), the tool's features (written as requirements), a draft of related tools and related work (papers and white papers), as well as a timeline until delivery in April.
   • Download the "Term Report or Report" file.

→ Learn how to cite other researchers' work (see this question at my FYP-faq page on where to find "good" references). Consult BlackBoard for further materials.

→ Extend (or revise) the ideas you put on the Project Definition Form.

→ Exercise clarity when writing your document, and precision/accuracy on stating exactly what you need to convey.

  Tip: Make notes on the discussions made with your supervisor, date them, and put them under an Appendix in the Partial Report (by the very end, after "References").

🧐 Develop your own notion of quality: ask yourself, "is this good enough?" and "can I improve this even further?"

 You are expected by this point to have a clear understanding of the tasks ahead (before the next SDLC step, which is implementation/testing).

top


December: Filling out blanks and refining Partial Report

→ At this point, you are refining your ideas, until you submit the Partial Report (or Term Report) on the system.

 You are expected to submit the Partial Report by Mid-December (check actual deadlines on BlackBoard).

→ When submitted, take a few days off, as you accomplished your milestone.



→ Whenever you feel like it, you can start prototyping your tool, choose auxiliary tools and Integrated Development Environment (IDE), install software and libraries, and get acquainted with your surroundings.

🧐

Programming tips:

  • Adopt an incremental approach to developing code.
    • Use a versioning system (Git is highly recommended, in GitHub↗, GitLab↗, or BitBucket↗), commmit and push frequently.
  • Test often, either using Unit Testing↗ or other technique you deem useful.
    • REALLY test it, try to break it! Fix all issues you observe. Learn about Fuzzy Testing↗.
  • Start coding your proposed core features first, then supplemental features.
    • Idea here is to code your functional requirements (features) first, then move on coding your non-functional (ie, quality related) requirements, like performance, security, usability, scalability, and so on).
  • Make notes on algorithms and decisions you took (in either the source code or in the Final Report).
    • Comment your code using Doxygen↗ - so later on you can automatically generate an iterative documentation.

top


January: Start working on your project - implementation

→ For about the next 1-3 months you will be implementing and testing a lot of your own tool.

→ Follow the plan you outlined, your timeline - what are you supposed to be doing?

→ As early as you start the better, so you can account for bumps in the road, ie, unexpected things that might happen, diversions, things you should change direction, find other tools/datasets, and so on.

→ Don't forget: the idea is that you must have a working (and useful) deliverable to demonstrate to a panel.

top


February: Keep going over the SDLC

→ Follow the plan you outlined. At this point, it's expected that you are doing a lot of testing, making sure your tool's behaviour is appropriate and that you meet the requirements you put forth.

→ Remember, you can only do Usability Testing after you have a stable version.

→ When you do and you are cleared by the Ethics Committee to pursue this task, run it with actual users, documenting all interaction from users in your tool. Write everything down the Final Report in a section/sub-section you created for this.

top


March: Focus writing your outcomes on the FYP Report

→ Follow the same principles outlined before, about being systematic, precise, and concise.

→ REFRAIN from capturing screens with texts or source code. Create an Appendix and put those, as text, in the Report.

→ Use a syntax highlighter tool↗ if you wish to put code snippets in the Report.

top


April: Last tool refinements and preparing for the demonstration

→ Fix issues that arised (if any) before presentation.

→ Make sure your demonstration takes 20 minutes, no more, no less.

top