CA400 Comp. Applications Year 4 Project 

CA400 - Final Year Computer Applications Project Guidance

Students and Supervisors should use this webpage in conjunction with your:

** CA400 Project Dashboard **

And pay close attention to the:
** Key Dates **

This webpage contains all of the main information relating to the stages involved in the CA400 final year Computer Applications project. It also contains additional useful information that students are advised to carefully read prior to commencing their project.

Main Stages Other Important Information
Stage 1. Identify a Project Proposal & Supervisor Use of GitLab
Stage 2. Present Project Proposal to Approval Panel Recommended Supervisor Interaction
Stage 3. Complete Functional Specification How your Project will be Graded
Stage 4. Final delivery of all project materials No Autumn repeat for Module
Stage 5. Final Year Project Expo IBM Open Source Competition
Stage 6. Project Demonstration School of Computing Policies / Ethical Considerations

Key Dates

2018     Key Dates / Deadlines
Stage1 Identify a Project Proposal & Supervisor Week 1-3
Stage2 Present Project Proposal to Approval Panel Week 5
Week 6 (Dates and schedule to be notified)
Stage3 Complete Functional Specification End Week 10 (17:00 Fri 30 Nov 2018)
  Semester 2 Lectures end Thurs 18 April 2019
  Semester 2 Examinations end Mon 20 May 2019
Stage4 Final delivery of all project materials Sunday 19 May 2019 (23:59 **NOTE: this is midnight on the Sunday and is a hard deadline)
Stage5 Final Year Project Expo Expo
Stage6 Project Demonstration Hold the period 21st-31st May inclusive. Schedule to be announced closer to the time.

Back to Top

Stage 1: Identify a Project Proposal & Supervisor

You may propose your own project idea or select a project suggested by a staff member (links to staff suggested projects are available below). Projects are normally individual projects. In some special cases a joint project may be allowed.


In all cases, it is mandatory to meet in person with a member of staff (i.e. attend their office by appointment) to discuss your project and to produce a Project Proposal, the template for which is automatically available in your GitLab project repo (under the 'docs' directory). Remember to save your final version of your Project Proposal as a PDF file prior to panel presenation (it continues to be stored in the same directory in your project repo).

It is also mandatory to find a member of staff willing to supervise your project and it is the student's responsibility to ensure 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.

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.

For help in choosing a project:

  • Lots of information is available on previous years' Expo booklets, including project videos. This will give you a sense of what is acceptable as a final year project and may also give you some ideas for your own proposal (but you cannot simply copy or reproduce an earlier project).
  • You can access Expo booklets for 2018, 2017, 2016, 2015, 2014, 2013, 2012, 2011, and 2010.
  • Staff project ideas may also be of interest to you - and you should approach the relevant staff member with any related queries.
  • 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.

For help in choosing a Supervisor:

Back to Top

Stage 2. Present Project Proposal to Approval Panel

You must present your Project Proposal to the Approval Panel. A 5 minute presentation limit will be strictly policed by the panel (i.e. once you reach the 5 minutes, you may be asked to stop). No marks are awarded for this stage - but it is compulsory to get project approval. The Approval Panel Timetable will be notified via email.

IMPORTANT: PROPOSALS THAT DO NOT HAVE A SUPERVISOR WILL NOT BE PERMITTED TO PRESENT TO THE APPROVAL PANEL (meaning that your project will not be approved). Remember that students cannot assign a Supervisor to their project, only the Supervisor has ability to select the "click to Supervise" button on the Project Dashboard).

The 5 minute presentation will consist of a verbal explanation of the various sections of your Project Proposal form. 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. It is advisable to bring a hard copy of your proposal with you to the presentation.

It is critical that you contact the module coordinator in good time (i.e. at least one full week in advance of panel presentation) to indicate that - despite your best efforts - you have not been successful in identifying a Supervisor. When contacting the module coordinator, you must include details of project ideas to date and attempts to secure a Supervisor to date. It is not the role of the module coordinator to assign Supervisors to projects, rather it is the responsibility of the student to secure a suitable Supervisor for their project. Only in exceptional circumstances will the module coordinator intervene in this process.

What to do if your proposal is not approved by the Approval Panel?
1. Immediately following your Approval Panel session (or as soon as possible thereafter), you must carefully document the reasons why your proposal has not been approved and inform both your Supervisor and the module coordinator.
2. Following this (and as soon as possible), you should update your proposal document in an effort to address the feedback from the approval panel. Ideally, you should track the changes to your proposal document so that it will be clear (if editing in MW Word, you can activate the Track Changes feature which will automatically highlight any changes).
3. Your proposed modifications should be issued to your Supervisor and the Module Coordinator for review. It is important to CC your original Approval Panel members on this email. It is very important that you get your revised proposal approved as soon as you can, usually within a small number of days following your Approval Panel session. Projects that are not officially approved may not be implemented.

Back to Top

Stage 3. Complete Functional Specification

The template for your Fuctional Specification is available by default in your GitLab repo (under the 'docs' directory). Remember to save your final version of the functional specification as a PDF file in time for the submission deadline, at which point it will be automatically retrieved from your repo.

The functional spec will form a component of your final grade. It is important to discuss and agree contents of the functional spec with your Supervisor.

Back to Top

Stage 4. Final delivery of all project materials

The following material must be available in your GitLab project repo by the advertised deadline. If using GitLab as it is intended, that is for document (incl. source code) version control, you will be continually updating your documents in your GitLab project repo using the standard edit and commit features. This will also allow you to demonstrate to examiners the dates/timeline for project implementation (via the 'activity' and 'graph' features in GitLab).

  1. The source code - located in the 'src' directory in your GitLab project repo.
    • 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.
    • It is vitally important that you recognise any third party code utilised in the project. Refer to the plagiarism policy material below for further details regarding the use of third party materials in your project work. When detected - and they are detected - such infringements are considered to be very serious offences by the university with implications for student progression. It is acceptable to include code from elsewhere, and also to modify such code where modification permission has been granted by the creator/owner - just remember to recognise this third party code in your submission as otherwise you may be the subject of a plagiarism investigation.

  2. A video walkthrough of your project - located in the 'docs/video-walk-through' directory in your GitLab project repo.
    • 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.
    • A maximum video duration of 5 minutes is allowable. If there are special reasons why your video must be longer than 5 minutes, then you need to contact your Supervisor and clearly outline your reasoning. You can assume that examiners will only view the first five minutes of your video unless special permission has been granted for an extended video.
    • 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.

  3. Your project documentation - located in the 'docs/documentation' directory in your GitLab project repo.
    • This should consist of two documents:
      1. Technical guide to the project (motivation, research, design, implementation, sample code, problems solved, results, future work)
      2. 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. Follow any other guidance provided in the file in the docs/documentation directory in your GitLab repo.
    • Format: You may create and edit your documents in whichever document editing software you prefer - however, final versions of all documents must be available as PDF documents. It is your responsibility to ensure that your PDFs are up to date and available; by default, examiners will read the PDFs only.
    • You do not need to submit a hardcopy of your docs. But you might like to have a hardcopy available during the demo.

  4. Guidelines on testing
    • Every project is different and therefore the testing strategy for projects should involve as a primary objective the confirmation that the quality of the software is sufficient. Some further info in relation to this is provided below.
      1. Testing Type. The type of testing that is desirable may depend very much on the application / project. Some heavy server-side projects may require a greater focus on unit and integration tests with perhaps less focus on system level tests (though system tests would still be required to evaluate that the system operates as intended). In contrast, projects with relatively high levels of user interaction via a GUI may require higher levels of GUI testing, perhaps through the use of system tests (though unit and integration testing may also be required in order to evaluate that the individual units and components operate as intended).
      2. Ad Hoc testing. It is normal for developers to conduct ad hoc testing as they build software however, more formal testing should also be conducted, which includes specific test cases which have corresponding expected test results that are examined by the execution of the test cases and comparison of expected and actual results.
      3. Where to document system testing (incl test cases and execution results)? These can be located in the Technical Guide (under the Results) or if preferred by individual students, this can also be achieved by having separate testing documentation (i.e. a System Test document). Having a separate system test document may be more appropriate in cases where there is a heavy dependance on system testing to establish quality and therefore, large numbers of system tests have been established and executed.
      4. Integration Testing. Integration tests may be implemented within the code, but they may also be implemented separately using drivers, stubs and component-to-component testing. Where implemented in code, the tests will have expected results and if they do not pass, the error will be flagged. Where implemented in other ways, integration test details may be expected, i.e. the amount of integration test documentation very much depends on the type of integration testing that has been performed. In some cases, it may be appropriate to bundle integration tests in with system tests.
      5. Testing strategy. The testing strategy should be highlighted to examiners as part of your demo: i.e. I used unit testing in these parts and for the following reasons; I used formal system testinig as well, with a focus on the following aspects of the project... etc. Examiners will seek to establish that testing has been conducted in a robust fashion that produces good quality software (and inevitably evidence that this has been conducted is required).

Back to Top

Stage 5. Final Year Project Expo

You must attend the Expo. It is further recommended - though not mandatory - that you produce a poster that you can use to present your work to Expo attendees, including potential future employers. A poster can be a very powerful way to talk through your project. It is the responsibility of each student to prepare and exhibit their own poster.

Should a student be absent from the Expo without having verifiable extenuating circumstances (e.g. illness as evidenced by a medical cert) recognised by the Registry Office, their final CA400 mark will be multiplied by 0.95. Further information on the procedure for offically registering extenuating circumstances may be found here.

  • You can get further information on the Final Year Project Expo here.

Back to Top

Stage 6. Project Demonstration

You will demonstrate your project during the Project Demonstration phase. You will be assigned a specific timeslot in advance of the date. The project is examined and marked by 2 examiners. Project supervisors may also present (but this depends upon their availability at the time).

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.

  • Towards the end of Semester 2, you will receive an email with your project number (this number will be for Demo purposes only). At this time, the provisional Demo schedule will be posted here: Schedule

    Note that this schedule is subject to change and therefore you should check in regularly for updates and be sure to confirm your demo schedule time the day before your demo.

    How to read this schedule: Example 1: Project Number 1 will be demo'd at 09:00 on Tues 21st May in LG25. Example 2: Project Number 72 will be demo'd at 14:00 on Wed 22nd May in LG26.

    The **provisional** list of examiners by project number is: Demo Examiners. Please note that examiners can change on the day of the demo and that this is the best guidance that can be provided at this time.

Back to Top

Use of GitLab

The School of Computing GitLab is the central hub for storing and submitting materials related to your project. You must fork your own project from the Master CA400 template.

IMPORTANT: If you do not fork your own project, then your repo will not be visible to prospective supervisors and they will not be able to elect to supervise you. YOU MUST DO THIS BEFORE CONTACTING PROSPECTIVE SUPERVISORS.

You must ensure that you do not change the name of the project when forking, it should continue to be 2019-ca400-XXXX (which is case sensitive). Further repo naming conventions are outlined in the Master CA400 template in GitLab and you need to follow these 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 may 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.

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 student 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).

You are required to maintain a blog of your project work over the year. A directory and template for this blog is availble in your project repo by default - in the 'docs/blog' directory. Marks are awarded for blog quality (refer to the The Project Grading Procedure for further information).

Back to Top

IBM Open Source Competition

We expect that IBM will be running a competition for best use of Open Source code in Final year projects. In previous years, the competition was be based on the IBM Bluemix Cloud Offering. At some stage in Semester 1, we expect that IBM will deliver a related talk to 4th year students.

Back to Top

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 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.

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

How your Project will be Graded

Marks breakdown, including key pointers for consideration, are as follows:

  1. Design - 15%
    Has the project been designed to a high standard?
    Does the project clearly demonstrate the use of appropriate design principles?
    Is the design appropriate for the given problem?

  2. Implementation - 30%
    Has the project been implemented to a high standard?
    Has the project been implemented in accordance with the design?
    Does the implementation involve a considerable amount of technical difficulty?

  3. Validation - 15%
    Has the developed system been tested thoroughly?
    What types of testing have been employed? Unit testing? Component testing? System Testing? Testing Tools used? Etc..
    Has the developed system been thoroughly validated with respect to the potential end users?

  4. Main documentation - 10%
    Is the documentation thorough, complete and of a sufficiently high standard?

  5. Functional Specification - 10%
    Was the functional spec of a high standard and an aid to the design and implementation?

  6. Blog - 5%
    Does the blog clearly track the progress of the project and record the software engineering process?

  7. Presentation at demo - 10%
    Was the presentation thorough, professional and of a sufficiently high standard?

  8. Video walkthrough - 5%
    Is the video thorough, complete and of a sufficiently high standard?

Total: 100%

Back to Top

No Autumn repeat for Module

This is a Category 2 module meaning that there is no possibility of 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.

Back to Top

School of Computing Policies / Ethical Considerations

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 potantial Ethical Approval requirements 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. Refer to the Q&A 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