CI401 Coursework

At a glance

Module leader: Shine Shan, j.shan@brighton.ac.uk (the brief spells it “brignton”, which looks like a typo).

What you must hand in

The brief says you build a software project, then hand in two things.

1. A project ZIP file

It must contain all your source files and the generated Javadoc documentation (made by running javadoc).

/**
 * Adds two whole numbers together.
 * @param a the first number
 * @param b the second number
 * @return the sum of a and b
 */
public int add(int a, int b)

2. A technical report

• A PDF or Word document.
• It describes the design, development and testing of your project.
• About 1500 words. This is guidance, not a strict limit.

The two options

You choose one:

For Option B the brief says the project must:

• provide a JavaFX graphical user interface (GUI); and
• follow the Model–View–Controller (MVC) architecture.

When things happen

No submission point yet. As of 17 Oct 2026 there is no submission point on Student Central. It will appear in the Assessment Submission Points folder. A submission point is the upload page where you hand in your files.

Suggested report structure

The brief gives this structure. The page lengths are guides, not strict limits. You do not have to follow it exactly. You may split or adjust sections, as long as all the required parts are there.

Marking rubric

Your work is marked in four areas. A rubric is the table markers use to decide your grade.

The brief’s note: your final mark is an overall total. Getting less than 40% in one area does not automatically mean you fail, but it will lower your overall result.

The full rubric, as written in the brief

On a small screen, scroll the table sideways. The codebase is the whole set of code in the project.

What separates the grade bands

This is the rubric wording above, put into plain words. It tells you what the markers look for. It does not tell you what to build.

Development (60%)

• Fail (0–39%) to D (40–49%): from no, tiny or wrong additions, to additions that exist but are “trivial” (very small and simple).
• C (50–59%): a few additions, and some are “non-trivial” (they take real thought and effort).
• B (60–69%): the additions are finished all the way through and are good quality. There is some sign you understand “more sophisticated” (more advanced) ways of building code.
• A (70–79%): a range of additions, all well thought through, with advanced work shown throughout.
• A+ (80–100%): exceptional skill that goes beyond what the codebase needs.

Testing (10%)

• Fail → D: from no testing, to a little testing that does not fully prove the code is correct.
• C: some testing, and basic errors found.
• B: good testing, with evidence of debugging and of confirming the code is correct.
• A: “comprehensive” (covers everything) testing with a good range of test cases; errors found and fixed.
• A+: “systematic” (done in an organised, planned way) and thorough testing, showing excellent debugging.

Documentation (10%)

• Fail → D: from no comments, to a few comments that are unclear or incomplete.
• C: some comments, but they do not explain the code very clearly.
• B: enough documentation; the code is mostly clear, with Javadoc or inline comments (comments on the same lines as the code).
• A: clear, consistent comments and technical descriptions.
• A+: excellent Javadoc and comments; “highly professional”.

Report (20%)

• Fail → D: from weak in every section (or nothing handed in), to badly organised with vague language and a weak handling of the technical content.
• C: well organised with very few typos, covers most sections, a sound handling of the technical content.
• B: clearly organised and well written, covers all sections reasonably, shows good depth and breadth of knowledge.
• A: everything in B, plus precise technical words, concise writing, many links to other sources, and clear understanding of the technical details.
• A+: everything in A, plus deep understanding of the problem and solution, alternative solutions discussed, “sophisticated critical reflection” (thinking honestly and deeply about what worked and what did not), and a professional-looking report.

Submission checklist

• Hand in on time: by 14:00 on Fri 22 Jan 2027. Do not leave it to the last minute.
• Check the file types: the project is a .zip with all source files and the generated Javadoc; the report is a PDF or Word file.
• Check afterwards that you can see your work in the submission point.
• Keep the receipt you get when you submit.
• Reference your sources, including any third-party tutorials, assets or code, with source and licence. See Avoiding plagiarism. Plagiarism means passing off someone else’s work as your own.
• Declare AI use where asked. Remember the RED rule: spelling and grammar checks only.
• Know the extension and Additional Consideration rules before you need them. An extension is extra time to hand in. Additional Consideration is the process for when something serious affects your work. See Course issues and extensions.
• Learning Support Plan: if you have one, paste your Learning Support Plan statement at the top of your work. See Learning Support Plans.
• Know how to upload: read How e-submission works.

The submission point is not there yet (as of 17 Oct 2026). It will appear in the Assessment Submission Points folder on the CI401 Student Central course.

If something goes wrong with IT

IT Service Desk: servicedesk@brighton.ac.uk · 01273 644444 · servicedesk.brighton.ac.uk
Skills Hub (study skills): skillshub@brighton.ac.uk

How the weekly labs help

Each rubric area is tested on skills taught in the weekly lectures and labs. This list links each area to the roadmap weeks that teach the related topics. Doing every week’s lab is the best way to build these skills yourself.

LO3 (finding and fixing errors in logic and syntax) comes up in every lab, whenever your code does not compile or gives the wrong answer.