CA400 - CA Final Year Projects
This page is obsolete
I am not the CA400 coordinator this year.
The CA400 coordinator is now
4th year CA projects co-ordinator:
| Stage 1
|| Presentation of Project Proposal to a panel
|| Week 5 (Mon 17 to Fri 21 Oct 2016)
| Stage 2
|| Gitlab submission of Functional Specification
|| End Week 10 (Fri 25 Nov 2016)
|| Semester 2 lectures end
|| Sat 22 April 2017
|| Semester 2 Examinations end
|| Sat 20 May 2017
| Stage 3
|| Gitlab submission of video walkthrough, project documentation, and code
|| Mon 22 May 2017
| Stage 4
|| Final Year Project Expo
|| Tue 23 May 2017
| Stage 5
|| Project Demonstrations
|| Wed 24 May - Fri 2 June 2017
Picking a project
You need to find a member of staff willing to supervise your project
and sign a Project Proposal form.
Your project might be the staff member's idea, or your own idea, or a combination.
You may need to meet with your potential supervisor a few times before they are happy with your proposal.
For help in picking a project and supervisor:
- Staff project ideas
- Staff Research Areas
- Staff Initials
- Previous years' booklets and videos
- Projects booklets for
Projects are normally individual projects.
In some special cases a joint project may be allowed.
Special hardware / software:
The School of Computing is not in general in a position to supply special hardware / software for projects.
Any special needs should be provided by the student.
Note though that supervisors themselves sometimes have special hardware / software that they want to supervise projects on.
All projects must be demonstrated in a School of Computing lab, either on a lab machine or the student's own machine.
Project Proposal form
Writing the Project Proposal:
- Project Proposal form:
When submitting your project proposal, you should include:
- Project Title
- General area covered by the project
- Description of the proposed project.
- Background - where the ideas came from
- Achievements - what functions it provides, who the users will be
- Justification - why/when/where/how it will be useful
- Programming language(s) - List the proposed language(s) to be used
- Programming tools - List tools (compiler, database, web server, etc.) to be used
- Learning Challenges - List the main new things (technologies, languages, tools, etc) that you will have to learn
- Hardware / software platform - State the hardware and software platform for development.
- Special hardware / software requirements - Describe any special requirements.
IBM Open Source Competition
IBM will be running a competition for best use of Open Source code in Final year projects.
This year the competition will be based on IBM Bluemix
A talk to 4th year students will be given.
Stage 1. Presentation of Project Proposal to a panel
You must present your Project Proposal to a panel in a 5 minute presentation.
There are no marks for this.
But it is compulsory to get project approval.
Timetable will be sent on email.
Bring your Project Proposal form
signed by a supervisor.
The 5 minute presentation will be a verbal explanation of the various sections of your Project Proposal form given above.
You will be asked questions by the panel.
Do not plan to do a PowerPoint presentation.
There is no time for that.
If there is anything quick you want to show the panel to help explain,
bring a printout of it,
or show them quickly on your laptop / tablet / mobile screen.
This year, your code and documents and other
project material will be submitted through
A talk will be given to 4th year about
and how to use gitlab.computing.dcu.ie.
Stage 2. Online submission of Functional Specification
Your Functional Specification is to be
uploaded through GitLab
by the deadline.
It will be marked.
It is important to discuss and agree contents of the functional specification with your supervisor.
- Structure of functional spec:
You are expected to keep a blog of your work on the project across the year.
Your blog should be on GitLab.
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 almost always confirms that they were never consulted (or only at the start).
Contact with your supervisor should be reported regularly in your blog.
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.
You need to show you had regular contact with your supervisor. Get your supervisor to sign the following form at each meeting.
Have these signed sheets available at the project demo.
- Supervision form:
Stage 3. Online submission of video walkthrough, project documentation, and code
The following material is to be
uploaded through GitLab
by the deadline.
- A video walkthrough
of your project.
This is a full capture of you introducing and demo-ing the project.
It should be like a demo. Introduce the project. Show what it looks like running. Change things and show changes on screen.
You should focus on things that are hard to show in the docs.
i.e. Anything dynamic, that we need to see running in action. Don't read out big blocks of text. You can refer to the docs for those.
- An external examiner checks our marking at the end of the year.
The video is something to show to a person (the extern) who did not see the demo.
Previously they had to imagine your project just through the docs, without ever seeing it running. Now they can see it running on the video.
Maximum video length 15 minutes.
But less is often more.
It might be a nicer video to sit through if it is 5-10 minutes.
Only do 15 mins if you really need it.
It does not have to be a real-world video, with you standing there. It can be just a screen video capture.
It does not have to have real audio. That is often good, but sometimes silent screen titles might be better. It's up to you.
Your project documentation.
- This should consist of two documents:
- Technical guide to the project (motivation, research, design, implementation, sample code, problems solved, results, future work)
- User manual (installation, user guide, screenshots)
Put project name / author / supervisor on the front page. First page should have an abstract explaining in one paragraph the big picture of what the project does.
- Format: Please submit in PDF format.
You do not need to submit a hardcopy of your docs.
But you might like to have a hardcopy handy during the demo.
The source code.
You do not have to upload support files and third party libraries.
Only upload the code you wrote yourself.
This is not for the examiners to install your project.
It is for them to inspect the code you wrote.
Stage 4. Final Year Project Expo
You must attend the Expo.
Should a student be absent from the Expo without a medical cert,
their final CA400 mark will be multiplied by 0.95.
Stage 5. Project Demonstrations
You will demonstrate your project during the Project Demonstration Week. You will be assigned a timeslot.
The project is examined and marked by 2 examiners.
Usually the supervisor of the project is also present.
The examiners will have seen the video walkthrough and the docs in advance.
The demo timeslot is for them to see it in reality,
experiment with it themselves,
examine you on what they have seen,
ask new questions,
ask for a step-through of parts of the demo,
look at code, and so on.
You can prepare a short presentation, but the examiners are already familiar with your project,
so your presentation should be no more than 15 minutes.
The examiners will then ask questions.
They are expected to leave after 30 minutes.
Demos can be in any lab chosen by the student. Email supervisor and examiners in advance as to your location.
- Have supervisor meeting forms at the demo to hand up.
- It might be nice to have a hardcopy of your docs handy during the demo.
Marks breakdown this year is as follows:
- Design - 15
- Implementation - 30
- Validation - 15
- Main documentation - 10
- Functional Specification - 10
- Blog - 5
- Presentation at demo - 10
- Video walkthrough - 5
There are no Autumn repeat projects
The module is category II.
We do not offer an Autumn resit for the project.
If you fail, you have to repeat the project next year. If you defer, you have to defer to next year.