In theory the module descriptor, i.e. the official university document which describes the module, indicative content and the grading breakdown should be available here. However as we all know theory is n't everything it is cracked up to be, and if that link does not bring you joy I summarise the basic elements of the CA4021 final year project below. I would like to thank Paul Clarke for his very well organised web page describing the CA400 final year computing project. The information below follows Paul's model as closely as possible.

Students and Supervisors should use this webpage in conjunction with the:
-->CA4021 Project Dashboard<--

Key Elements and Timing

Activity Identifier Description Timing Marks weighting
Activity 1 Discuss potential project ideas with a range of supervisors. I can provide initial guidance and provisional feedback on the suitability of the project proposal and a likely-to-be-interested supervisor. Contact me by email for such feedback Weeks 1-3 0%
Activity 2 5 minute oral presentation of a proposed project topic with a "Go"/"Try Again" outcome Due November 2020 0%
Activity 3 Submission of a detailed formal project proposal for grading which includes literature review Due 18th December 2020 (Time 17:00) 10%
Activity 4 Contact with supervisor at least weekly with meeting minutes recorded in the project dashboard Ongoing from the time supervisor has indicated project acceptance on project dashboard 10%
Activity 5 Submision of project documentation and live demonstration of same including presentation 7th May 2021 (Time 17:00) 80%

Activity 1: Selecting a Project Supervisor and Project Topic

You may propose your own project idea or select a project suggested by a staff member. Many staff member suggested projects can be found at this link. In all cases, it is mandatory to meet with a member of staff (e.g. zoom meeting by appointment) to discuss your project and to produce a Project Proposal, the template for which I will provide you with soon. It is also mandatory to find a member of staff willing to supervise your project and students are responsible for ensuring that their supervisor is officially secured in time for the Approval Panel presentation. Be aware that you may need to meet with your potential supervisor a few times before they are happy with your proposal. You may also discover that you will need to meet with several propsective supervisors. Therefore, DO NOT DELAY IN IDENTIFYING A PROJECT AND SECURING A SUPERVISOR. IT IS CRITICAL TO ENSURE THAT THE SUPERVISOR AGREES TO SUPERVISE YOUR PROJECT - and this is best achieved during the meeting(s) to discuss your proposal. To do so, the supervisor clicks the "click to Supervise" button in the Project Dashboard. Projects will not be allowed to progress without having a supervisor assigned in the Project Dashboard. Once you have secured a supervisor, you may continue to consult with other members of staff for advice and guidance in relation to your project - however, you must notify both your supervisor and other affected members of staff in advance of such engagements if they should arise. In all cases, it will be your supervisor who will take primary ownership for guidance.

Back to Top

Activity 2: Project topic confirmation process

While this step does not attract a grade it is a critical part of the process. You will be given an opportunity to discuss your final topic target, which must include identification and confirmation of support from a supervisor with a project topic panel. This panel will give you a final go/no-go decision on your selected topic and allows you to progress with the development of the first, graded deliverable. The outcome will not always be a "Go" decision and it is expected that some project proposal will be considered inadequate in some way and require further refinement or replacement which must then be approved by the CA40121 project coorodinator who will have been briefed on the panel-reported shortcomings. Before you rock up to this project topic approval process have a think about any ethics/GDPR issues. You can learn more of this process here.

Back to Top

Activity 3: Submission of first graded deliverable

This activity is concerned with the more formal development of a data science project proposal which will include a literature review and context development. The precise expected structure can be found here . This is an important deliverables as it attracts 10% of the overall grade.

How this component will be graded

The project proposal will adhere to the template at this link. The current grading rubric is available here .

Back to Top

Activity 4: Regular engagement with supervisor

Activity 4 overlaps with all other activities as it reflects your engagement on your project as viewed from your supervsiors perspective.This will largely be based on your regular interaction with the supervisor in the form of meetings, the minutes of which are recorded in the project dashboard. It is up to you, not the supervisor, to ensure there are regular update meetings and that minutes are recorded. The grading rubric used will be made available to you to ensure transparency.

How this component will be graded

The supervisors assessment will be graded according to the following rubric here.

Back to Top

Activity 5: Submission of final deliverables

This final activity culminates in your submission of a deliverable compirsing a final report and a presentation. This attracts the bulk of the grade awarded. As we hope you might publish your work the final deliverable is a conference style paper which should be of 6 to 12 pages in length. This should use the Springer Lecture Notes in Computer Science (LNCS) style. The Springer LNCS Latex template can be found here. You could use the Word template but why would you do that? The presentation is approximately a 30 minute interview with two examiners who will use your paper and original proposal document as the basis for the conversation. This interview will commence with a 5 minute introduction to the project by the student (slides optional).

How this component will be graded

These components will be graded according to the following rubric here.

Back to Top

General tips and tricks for a successful project experience

We will use slack for discussion of issues as they emerge and for sharing of tools and ideas. The best ideas which survive the test of a project year will make it on to this webpage. As this is the first year of this module we will likely make lots of mistakes and learn from them.

Reference Management

In any project which involves an element of research it is important to keep track of good quality citable sources of information. In your final report and even during your initial proposal submission you will include references to important papers or online resources. Efficiently and effectively managing such sources is an important task and thankfully there are many excellent reference management applications available. Currently I use Zotero and I have tried many previously trying to find something that covered all my needs. It is the best I have used to date. It is free and open source.

Recommended Supervisor Interaction

You are expected to have regular meetings with your supervisor to discuss and monitor progress. It is up to you to organise such meetings. Keep in touch with your supervisor as we have found this is one of the main methods of ensuring a successful project. When a project fails, the supervisor often confirms that they were rarely consulted. The other reason for regular contact is that some people have no idea of what is involved in a 4th year project and produce something well below standard, thinking it will pass. Keeping your supervisor informed and in the loop will avoid this. As evidence of regular contact with your supervisor, ensure that your supervisor completes the "meeting form" on the Dashboard each time you have a meeting - this will demonstrate an active engagement with your supervisor and will also serve to clarify important issues.

Back to Top

Important elements of the final year project process

The School of Computing has many decades of experience in the development of processes and procedures to ensure a good final year project learning experience. We will leverage many of these here including the life-saving project dashboard developed by our own Stephen Blott. In the sections below we detail many sensible and valuable ideas born out of experience from the CA4021 program.

Use of GitLab

The School of Computing GitLab is the central hub for storing and submitting materials related to your project. All CA4021 materials must be stored here and you must fork your own project from the CA4021 Master Repo. IMPORTANT: If you do not fork your own project, then your repo will not be visible to prospective supervisors and your project will not be approved. YOU MUST FORK YOUR REPO BEFORE CONTACTING PROSPECTIVE SUPERVISORS. ONLY ONE FORK IS REQUIRED PER PROJECT

You must ensure that you FOLLOW THE NAMING CONVENTION INSTRUCTIONS IN THE CA4021 TEMPLATE REPO CAREFULLY. It is expected that all students are familiar with using GitLab - if you are not familiar, you should contact the module coordinator as soon as possible. More on Gitlab here: Main GitLab Site, and also here: Wikipedia

It is important that GitLab is used throughout your project in the same manner that would be expected in routine commercial/industrial software development. This means that you should be regularly commiting and modifying artefacts in your project repo. In evaluating your efforts and commitment to the project, examiners will look to the GitLab record of your interaction with the project over time as evidence of sustained and committed work. You should note that Supervisors will have visibility of repos throughout the project duration. Advice on good commit practice for source code and other project artefacts is available here.

Following project approval (i.e. only if the approval panel has sanctioned your project), you may set your GitLab repo to be private as opposed to the default internal setting. If you choose to modify your repo to private, it is incumbent on you to also explicitly grant your Supervisor access to your private repo at the time of modifying the setting. You should separately notify your Supervisor by email that you have modified your repo setting and that they will continue to have access. It is the responsibility of each team to ensure that the Supervisor has access to their repo at all times. Note that prior to project examination, all repos will automatically be set to internal (this is necessary in order to enable examiners to access project deliverables).

No Autumn repeat for Module

This is a Category 2 module meaning that there is no possibility of an Autumn resit for the project.

School of Computing Policies / Ethical Considerations & GDPR Requirements

In addition to the standard DCU practices and procedures, some of the School of Computing Policies of relevance may be found here:

An explanatory page on potential Ethical Approval requirements including GDPR related issues for your project can be found here:

In general, where Ethical Approval is required for projects, it is typically a notification that is required rather than full Ethical Approval. Please be aware that even anonymous surveys will likely need some form of review. Refer to the help sheet provided at the link and if in any doubt, please consult with your supervisor in the first instance. Note that all projects must be explicitly considered in view of ethical considerations and that the ethics status should be in "green" on the project Dashboard. Please consult with your supervisor if you are in any doubt regarding this.

Back to Top