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

2021     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 - expected to be virtual)
Stage3 Complete Functional Specification End Week 9 (17:00 Fri 19th November 2021)
  Semester 2 Lectures end refer to DCU Outline Academic Calendar 2021-2022.
  Semester 2 Examinations end refer to DCU Outline Academic Calendar 2021-2022.
Stage4 Final delivery of ALL project materials 17:00 Friday 22nd April 2022
Stage5 Final Year Project Expo Expo. IMPORTANT: CA400 Demos and FEC EXPO are expected to be held in the two week period commencing Wednesday 27th April 2022 - hold this period until advised otherwise. Attendance at both the Demo and the EXPO is mandatory.
Stage6 Project Demonstration Students MUST be available for CA400 demos, failure to present at the demo results in a zero grade by default. No special scheduling requests will be processed unless extenuating circumstances can be demonstrated to the satisfaction of the Registry Office. The exact schedule will 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 to be performed in groups comprised of two students only. Although projects are completed in pairs, students may be awarded individual grades. The marking scheme is outlined below, and each student will be evaluated for their contribution towards each markable component. Accordingly, it is not advisable for one student to focus solely on documentation while the other student focuses entirely on technical implementation.

It is expected that each student will identify a technical component (or components) within the project and take the lead on implementing them, and that together, the students will build up the other markable dimensions. For example, one student may decide to focus their technical implementation on a neural network backend, while the other team member will work through other technical aspects, perhaps the user facing software development. Be aware that marks are awarded for technical difficulty, and that in the example given above, the student implementing the neural net may receive higher technical implementation marks as a result of the higher technical difficulty. But each case will be different and therefore treated independently.

Of course, close collaboration across all aspects is recommended. The best performing teams will have regular and effective communication with each other and progress their work throughout the academic year (i.e. not just rushed work close to each deadline), in an organised and productive fashion. And it is permissible that both both team members could ultimately be awarded the same high mark, though the converse case is also permissible.

VERY IMPORTANT: THE VERY FIRST THING YOU NEED TO DO: FORK YOUR OWN PROJECT FROM THE MASTER PROJECT (REFER TO INSTRUCTIONS BELOW UNDER THE Use of GitLab SECTION). Make sure to use your DCU login credentials when forking and when commiting to your repo.

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, where you should commit your own proposal once it is drafted).

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.

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 pre-2015 Expo booklets at the following links (more recent booklets are available at the link above): 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 students. 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 your own machine. For as long as the COVID-19 pandemic continues to affect us, special arrangements may be put in place to allow for online demonstration.

Back to Top

Stage 2. Present Project Proposal to Approval Panel

You must present your Project Proposal to the Approval Panel. A max. 4-5 minute presentation limit will be strictly policed by the panel (and you can expect to be asked to stop if overrunning). You are advised to prepare/plan to be finished in around 4 mintues. Tips for your presentation:

  • Start by outlining the concept: e.g. "Our project is a client-server based application that will use machine learning to help end users identify music tracks they may like.... and... "
  • Clearly indicate the technologies to be used: e.g. "A python based server side application, using a machine learning algorithm built and trained using .... , data storage will be using ..., the system will be configuarable by doing.... and the front end will be developed for Android using ..., testing will be conducted using ..."
  • Clearly identify which parts of the project each person will contribute towards: e.g. "Jane will implement the machine learning algorithm, Kieran will write the server side code to interact with the machine learning component, Kieran will implement the Android front end... etc."
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).

Your 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 (or by sharing your screen if approval panels are held virtually).

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 students 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 in an effort to address the feedback from the approval panel.
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 will not be recognised as CA400 contributions.

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 / authors / 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. Testing documentation, incl results
    • 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). In general, it is beneficial to demonstrate a knowlege of and ability to utilise testing frameworks, e.g. unit testing using pyunit, for the purpose of unit and integration testing.
      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 testing 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).

  5. ALL deliverables must be FULLY complete and committed to your repo by the Stage 4 deadline. Defects may be worked on up to the Demo, but any defects addressed must be explicitly identified to examiners and associated code committed to your repo in advance of the Demo. New functional content cannot be added following the Stage 4 deadline.

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 team 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 will be marked by 2 examiners (one of which may be your supervisor).

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 should prepare a short presentation, but the examiners are already familiar with your project, so your presentation should be no more than 15 minutes. It is advisable that you submit/deliver a draft presentation to your supervisor prior to the demo and allow sufficient time to make presentation updates following feedback from your supervisor. It is mandatory in all cases that you clearly identify the individual contributions within the team project as part of your demo presentation. The examiners will then ask questions. They are expected to complete after 30 minutes.

  • Towards the end of Semester 2, the Demo schedule will be published.

Back to Top

Use of GitLab

The School of Computing GitLab is the central hub for storing and submitting materials related to your project. All CA400 materials must be stored here and you must fork your own project from the CA400 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 (I.E. BOTH STUDENTS IN A TEAM SHOULD NOT INDEPENDENTLY FORK A PROJECT), PLEASE AGREE THIS STEP WITH YOUR PROJECT PARTNER.

You must ensure that you FOLLOW THE NAMING CONVENTION INSTRUCTIONS IN THE CA400 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.

Continuous Integration (CI) principles should be in evidence through the use of pipelines (or alternative/complementary CI mechanisms as you prefer). Desirable integration routines will vary from project to project, some examples could include: building and testing the code upon a code commit, this could also extend to continuous deployment. GitLab CI/CD information 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).

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 AND both team members should attend Supervisor meetings together.

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 never consulted (or only at the start).

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 - 10%
    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. Continuous Integration and Git Commit practice - 10%
    Have Continuous Integration / Continuous Deployment mechanisms been put in place?
    Are GitLab pipelines (or alternatives) used to orchestrate CI/CD activities?
    Have there been regular commits to your GitLab CA400 project throughout the academic year?
    Do commits have clear comments assosicated with them that clarify the precise reason for and content of each commit?

  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

Please note that ethical considerations are are of critical importance to all work in the School of Computing. Please refer to the School’s Ethics approval guidance (available from the CA400 Dashboard) for further details, noting that since the advent of GDPR, even anonymous surveys (e.g. with Google Forms and Survey Monkey) require prior approval. The project dashboard has a FAQ and information file for students to download which explains the details, as well as the template form which must be completed and uploaded to their repos. In general, where Ethical Approval is required for projects, it is typically a notification that is required rather than full Ethical Approval. 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