Module name: Software Engineering (CMP020N204S)

Lecturer: Dr Lisa Haskel, Dr Touseef Tahir, Dr Mamoona Humayuan

Coursework 2025

_________________________________________________________________________

Software Engineering Group Project – NOT FINALISED: draft @ 19 Jan

2022
Coursework Specification
PREPARATION
Before you begin this coursework, it is important to plan your activities and to manage the delivery of your
milestones in the context of the submission deadline. Therefore, you are strongly advised to READ THIS
COURSEWORK DOCUMENT CAREFULLY!

ACADEMIC MISCONDUCT
Your submission for this coursework will be scrutinised for plagiarism, collusion, and other forms of academic
misconduct. Please ensure that the work that you submit is your own, and that you have cited and referenced
appropriately, to avoid having to attend an academic misconduct hearing. You can find more information
about academic integrity and how to mitigate plagiarism here:
https://roehampton.libwizard.com/f/academic_integrity

Coursework: Group project

The coursework is worth 70% of the total module mark. Delivery of the coursework is divided
into four Sprints. You will deliver the sprints as a group.

For each sprint, all members of the group will receive the same mark.

You will also be evaluated for your individual contribution to the project via your individual
reflection document, worth 20% of the coursework mark. The marks for the coursework
element are divided as follows:

Title Deadline Marks Code

Review

Sprint 1 tbc 20%

Sprint 2 tbc 20%
Sprint 3 tbc 20%
Sprint 4 tbc 20%
Individual tbc 20%
component
Module name: Software Engineering (CMP020N204S)
Lecturer: Dr Lisa Haskel, Dr Touseef Tahir, Dr Mamoona Humayuan
Coursework 2025

Coursework description
Overview

Each group will produce a ‘full stack’, dynamic web application which can be deployed using
Continuous Integration/Continuous Deployment techniques.

Technologies

The technologies used in the module are as follows:

Frontend:

• HTML
• CSS
• JavaScript
• PUG templating system

Backend:

• Node.js
• Express.js
• MySQL database

DevOps and CI/CD:

• Docker
• Git
• Github actions

Project management:

• Github project

Your application must be built using the tools and techniques taught in the module.

Theme

For 2025, our theme will be “Sharing, exchange and mutual aid”.

To address the theme, students should consider how they can use their skills to promote
community development and help solve real problems, for example: waste, climate change
and cost of living crisis, and/or support their interests and hobbies. They will do this by
creating a dynamic, database driven web application through which users can exchange
goods or services co-operatively, for mutual benefit rather than financial gain.
Module name: Software Engineering (CMP020N204S)
Lecturer: Dr Lisa Haskel, Dr Touseef Tahir, Dr Mamoona Humayuan
Coursework 2025

Each group will choose one of the project ideas presented by the staff team - indicative
examples below. They can suggest their own idea which will need to be validated by a
member of the staff team by the end of week 2.

Indicative project ideas

• Minimising food waste by sharing excess food

• Organising the community fridge (this is a real project)
• Study buddies: peer support for students
• Ride sharing to university
• Book and record swap
• Community languages – teach and learn
• Circular fashion – re-make and mend
• Sharing outfits for job interviews, special occasions etc
• Running and cycling buddies
• Game tips and tricks
• Recipe swap

The groups will be expected to consider usability, security and ethics as they develop their
application. While all groups will start with basic functionality, the projects will allow
increasing creative input and unique ideas as they develop.

Deliverables
You will work on the project using a ‘scrum’ project management methodology. This means
that you will work as a team to deliver your project iteratively.

Your progress will be discussed weekly during ‘stand-up ‘meetings in lab time with your
lecturer, and formally via the code-review assessment points.

The following details the deliverables for each sprint:

Sprint 1: Review point: Lab of Week 3

The aim of this sprint is to check that the project workflow is set-up for the team, you have
clarified your project idea and adopted a code of conduct.

Checklist Submission 1
The following must be in place:

• GitHub repository for coursework set-up and at least one commit from every group
member
• Product Backlog created and kanban board in Github project created
• Scaffolding files added to github and README file customised for your project
Module name: Software Engineering (CMP020N204S)
Lecturer: Dr Lisa Haskel, Dr Touseef Tahir, Dr Mamoona Humayuan
Coursework 2025

• Correct branches for GitFlow workflow created - includes `master`, `develop`, and
`release` branches
• Each member of the team able to run the development environment using Docker
• A single PDF document with:
o Your group members and group name
o Project description refined
o Code of Conduct
o At least two ‘Personas’
o Ethical issues identified
o Meeting records completed

Sprint 2: Lab of Week 5

The aim of this sprint is to assemble the initial requirements and ensure that specifications
are ready for sprint 3.

Checklist Submission 2

The following must be in place:

• A single PDF Document with:

o Features for your application defined as user stories
o Use case diagram
o Sprint 3 specification prepared with at least: user stories, wireframes, activity
diagrams.
o Other artefacts may be included such as sequence diagrams, ERD diagram,
class diagram, designs, colour schemes
• Sprint 3 tickets prepared on your Kanban board
• A screenshot of your Kanban board
• All students up to date with lab work and ready to start development
• Meeting records completed

Sprint 3: Lab of week 8

The aim of this sprint is to begin the application development by creating some simple
features. All members of the team must show that they can build the development
environment and have contributed code. For your sprint review you will be expected to be
able to have your database populated and be able to run your code

Checklist Submission 3

Initial requirements implemented using MySQL, Express and PUG, using Docker containers
for the team development environment and demonstration. To include at minimum (these
pages must use data pulled from your database):
Module name: Software Engineering (CMP020N204S)
Lecturer: Dr Lisa Haskel, Dr Touseef Tahir, Dr Mamoona Humayuan
Coursework 2025

• Users list page

• User profile page
• Listing page
• Detail page
• Tags/categories

A single PDF document with:

• The user stories you implemented in sprint 3
• Database design
• A breakdown of tasks and developers allocated (from Github project)
• Github repository and github project links
• A screenshot of metrics from github showing that all team members are
participating
• A screenshot of your kanban board
• Meeting records

In your sprint 3 review, you will plan your final sprint which will be tailored to each groups
progress

Sprint 4: To be presented in Week 12

The aim of this sprint is to complete your ‘MVP’ to by adding features and refining your design
as much as possible. The scope of your sprint 4 will be tailored to each group and will be
determined in your sprint 3 review meeting.

You will also add some CI/CD workflows using github actions.

Groups will present to the whole class in week 12.

Checklist Submission 4

Web application: Intermediate and/or advanced requirements implemented to include at

least some of:

• User login
• Basic matching algorithm
• User points or ratings
• Advanced ratings or points system
• In-app messaging
• Advanced matching algorithm / recommendations
• Use of external APIs where relevant (eg. Transport, maps, weather)

DevOps and CI/CD

• Application runs in Docker containers

Module name: Software Engineering (CMP020N204S)
Lecturer: Dr Lisa Haskel, Dr Touseef Tahir, Dr Mamoona Humayuan
Coursework 2025

• At least one github action implemented

Presentation
A presentation of your application idea, ethical issues and and MVP during week 12. Ppt file
to be uploaded to Moodle.

Individual Assessment

Individual contributions to the team will be assessed based on attendance at the various
meetings and code reviews, and via the metrics gathered from tools such as GitHub.
Individual contributions can lead to a scaling of the overall coursework grade if the module
team have evidence that illustrates a lack of contribution to the team deliverable.

The coursework must be delivered as part of a team. If anyone is dismissed from their team
this means they cannot deliver the coursework and is at high risk of failure for the whole
module. Dismissal from a team involved the following process:

▪ An individual is evidenced as breaching the code of conduct as set-out by the student

team
▪ Evidence is presented at the next available meeting with a member of the module
delivery team
▪ The individual evidenced will have the opportunity to explain any mitigating
circumstances either to the student team or privately to a member of the module
delivery team
▪ The module delivery team retains the right to the final decision of whether the
dismissal is warranted

Any dismissed team member has a week to appeal the decision to the module team with
suitable evidence provided.

___________________________________________________________________________

Code Review Meetings

Each group will undertake four graded code reviews:

1. Week 4 (20% of CW mark)

2. Week 8 (20% of CW mark)
3. Week (20% of CW mark)
4. Week 12 (20% of CW mark)
Module name: Software Engineering (CMP020N204S)
Lecturer: Dr Lisa Haskel, Dr Touseef Tahir, Dr Mamoona Humayuan
Coursework 2025

The meetings will take place during the lab sessions. Each group will be given 10 minutes
maximum for the code review. Your group will be allocated a time for the code review. The
details of the individual review points are below. These meetings must be attended at the
stated time. Guidelines for grading the group:

▪ Being late for the meeting or not being ready when the meeting starts will result in
the grade for that review being capped at 40%

▪ Not attending the meeting will mean the code review will be marked at 0%

▪ All team members should attend the code review; however commitments and other
considerations will be taken into account. Individuals attendance at reviews will be
monitored to ensure the team is contributing collectively to the project.

▪ Being ready means that you are ready to present the points for the code review. This
means that you have a computer with your application ready to run.
Module name: Software Engineering (CMP020N204S)
Lecturer: Dr Lisa Haskel, Dr Touseef Tahir, Dr Mamoona Humayuan
Coursework 2025

___________________________________________________________________________
Individual component

TBC
Module name: Software Engineering (CMP020N204S)
Lecturer: Dr Lisa Haskel, Dr Touseef Tahir, Dr Mamoona Humayuan
Coursework 2025

Marking Scheme:

Sprint 1
Criteria Excellent Satisfactory Not Satisfactory Not attempted

Tasks may either be lacking a

Task definition the Tasks represent clearly the Tasks lack completeness and
complete set of those expected No tasks provided, or tasks
completeness and main tasks to be completed there are tasks defined that
at this stage, or there might be completely unsuitable and
suitability of the initially and are suitable for the are unsuitable for the
some unsuitability in the tasks incomplete.
defined tasks. application proposed. application proposed.
defined.

Code of Conduct suitably

Code of Conduct the Code of Conduct covers most Code of Conduct only covers
covers the problems that Code of Conduct not
suitability of the Code of issues the team will face and some significant issues and/or
can arise and how the team provided, or unsuitable for
Conduct and its ability to provides suitable guidance of doesn’t provide clear
will resolve issues when managing the team.
support the team’s work. how to resolve these. guidance of how to proceed.
they arise.

Both GitHub repository and GitHub repository and task GitHub repository and task No GitHub repository and
Technical aspects the
task board created and all board created but not all team board created but only one task board created, or
completeness of technical
members have joined and members have joined and person joined, or one of these simply just created with
deliverables.
contributed. contributed. aspects not created. nothing additional done.
Module name: Software Engineering (CMP020N204S)
Lecturer: Dr Lisa Haskel, Dr Touseef Tahir, Dr Mamoona Humayuan
Coursework 2025

Sprint 2
Criteria Excellent Satisfactory Not Satisfactory Not attempted

User stories lack some

User stories the User stories are clearly defined and User stories are generally clear, and
clarity, and/or may not all be
suitability and are appropriate for the application. mostly appropriate for the No user stories provided, or
appropriate for the
completeness of the Set of user stories suitably application. Set of user stories may user stories are inappropriate
application defined.
user stories so far complete for this stage of the not be as complete as expected at or mostly incomplete.
Provided user stories are
identified. project. this stage.
sparse.

User story
Most user stories are on task User stories are not clearly
tracking suitable All user stories are on task board,
board, and generally tracking of tracked in all instances, and User stories are not tracked, or
documentation and with suitable tracking of story
progress is being undertaken but detail is missing in areas, the level of tracking is very
tracking of user stories progress including assignment of
some gaps in areas, for example such as the assignment of limited.
using a suitable task tasks to individuals.
assignment of people. people to stories.
board.

Use case diagrams that clearly map Use case diagrams generally map to
Use case diagrams do not No diagrams provided, or use
to user stories provided and user stories and provide good-
Software design the map well to user stories and case diagrams do not map to
provide high-quality information of quality information of the system
suitability and are lacking in some detail. user stories. Activity diagrams
the system design. Activity design. Activity diagrams are good-
completeness of the Activity diagrams also lack not provided, do not cover
diagrams are of high-quality quality but no not cover the
software design some detail on the overall much or the system flow of
illustrating the flow of control in complete flow of control in the
presented given the flow of control in the control, or are inappropriate.
the application. Suitable class, application. Suitable class, state,
application design system. Class, state and Class, state and sequence
state, and sequence diagrams are and sequence diagrams are also
proposed. sequence diagrams are diagrams not provided or are
also provided based on the idea provided based on the idea
sparse. inappropriate.
specified. specified.
Module name: Software Engineering (CMP020N204S)
Lecturer: Dr Lisa Haskel, Dr Touseef Tahir, Dr Mamoona Humayuan
Coursework 2025

Criteria Excellent Satisfactory Not Satisfactory Not attempted

Wireframing and flow between

Wireframing and flow between Wireframing and flow
UI design the suitability screens is generally completed but
identified screens clearly between screens is No UI elements provided, or UI
and completeness of the lacking some detail or perhaps
illustrated and clearly map to the incomplete as defined from design presented is unsuitable
UI design aspects such as missing some of the actual screens.
complete set of user stories and user stories and other for the application defined.
wireframes and UX flow. Some of the user stories are not
other design aspects defined. design elements.
clearly mapped in the UI design.

Team collaboration the Evidence that the team is generally

Clear evidence that the team is No evidence indicating that the
evidence of the team working collaboratively although Evidence provided doesn’t
working collaboratively on the team is working together, or
functioning and working the task board and GitHub indicate that the team is
project as evidenced in the the level of collaboration is
collaboratively to repository indicate that there are collaborating very effectively
deliverables, the task board and insufficient to support
complete the work some inconsistencies between to deliver the project.
GitHub repository. successful project delivery.
defined. team members work.
Module name: Software Engineering (CMP020N204S)
Lecturer: Dr Lisa Haskel, Dr Touseef Tahir, Dr Mamoona Humayuan
Coursework 2025

Sprint 3
Criteria Excellent Satisfactory Not Satisfactory Not attempted

All user stories are on task Most user stories are on task User stories are not clearly
User story tracking suitable
board, with suitable tracking board, and generally tracking of tracked in all instances, and User stories are not tracked, or
documentation and tracking
of story progress including progress is being undertaken but detail is missing in areas, such the level of tracking is very
of user stories using a
assignment of tasks to some gaps in areas, for example as the assignment of people limited.
suitable task board.
individuals. assignment of people. to stories.

Team has not made

Excellent progress made Team has made satisfactory No progress made, or progress
Technical progress the satisfactory progress towards
towards delivering a final progress towards delivering their is minimal at best.
degree of progress the team delivering their final product
version of the product based final product version based on the
version based on the current
Module name: Software Engineering (CMP020N204S)
Lecturer: Dr Lisa Haskel, Dr Touseef Tahir, Dr Mamoona Humayuan
Coursework 2025

Criteria Excellent Satisfactory Not Satisfactory Not attempted

has made in the delivery of on the current project and current project and capabilities of project and capabilities of the
their technical requirements. capabilities of the team. the team. team.

Database integration the Database has been fully

Database has been fully designed Database is not yet fully Database has not been
completeness of the designed and implemented to
and implemented to support the designed and implemented. designed and implemented, or
database implementation support the project. All
project. Only minimal data added Therefore, only minimal data has very minimal design and
and integration into the necessary data for the project
at this point. is available. implementation.
application. has been entered.

Template development the

Not all templates fully defined
progress of the templates Templates for all features Some templates developed with No templates defined, or very
and implemented. Templates
and understanding of how developed and dynamic data some dynamic data correctly minimal set produced with no
don’t show correct data from
they integrate with the pulling through pulling through connection to the database.
database.
backend

Obvious evidence that the Evidence that the team is Some evidence of the team No or little evidence of the
GitHub repository
team is collaborating well, collaborating, and in general collaborating. Not as clear team collaborating. Team is
practice evidence of team
everyone is committing to everyone is committing to the that the whole team is not using GitHub universally.
collaboration and good
the project, and commits are project. Commits are not always committing to the project. Commit practice is non-
practice in GitHub.
frequent and small. frequent and small. Commit practice needs work. existent or poor.

Evidence that the team is generally

Team collaboration the Clear evidence that the team No evidence indicating that the
working collaboratively although Evidence provided doesn’t
evidence of the team is working collaboratively on team is working together, or
the task board and GitHub indicate that the team is
functioning and working the project as evidenced in the level of collaboration is
repository indicate that there are collaborating very effectively
collaboratively to complete the deliverables, the task insufficient to support
some inconsistencies between to deliver the project.
the work defined. board and GitHub repository. successful project delivery.
team members work.
Module name: Software Engineering (CMP020N204S)
Lecturer: Dr Lisa Haskel, Dr Touseef Tahir, Dr Mamoona Humayuan
Coursework 2025

Sprint 4
Criteria Excellent Satisfactory Not Satisfactory Not attempted

All user stories are on task Most user stories are on task User stories are not clearly
User story tracking suitable
board, with suitable tracking of board, and generally tracking of tracked in all instances, and User stories are not tracked,
documentation and tracking
story progress including progress is being undertaken but detail is missing in areas, such or the level of tracking is very
of user stories using a
assignment of tasks to some gaps in areas, for example as the assignment of people limited.
suitable task board.
individuals. assignment of people. to stories.
Module name: Software Engineering (CMP020N204S)
Lecturer: Dr Lisa Haskel, Dr Touseef Tahir, Dr Mamoona Humayuan
Coursework 2025

Criteria Excellent Satisfactory Not Satisfactory Not attempted

Team has not made

Technical progress the Excellent progress made Team has made satisfactory
satisfactory progress towards
degree of progress the team towards delivering a final progress towards delivering their
delivering their final product No progress made, or
has made in the delivery of version of the product based on final product version based on the
version based on the current progress is minimal at best.
their technical the current project and current project and capabilities of
project and capabilities of the
requirements. capabilities of the team. the team.
team.

Evidence that the team is Some evidence of the team No or little evidence of the
GitHub repository Obvious evidence that the team
collaborating, and in general collaborating. Not as clear team collaborating. Team is
practice evidence of team is collaborating well, everyone is
everyone is committing to the that the whole team is not using GitHub universally.
collaboration and good committing to the project, and
project. Commits are not always committing to the project. Commit practice is non-
practice in GitHub. commits are frequent and small.
frequent and small. Commit practice needs work. existent or poor.

Evidence that the team is

Team collaboration the Clear evidence that the team is No evidence indicating that
generally working collaboratively Evidence provided doesn’t
evidence of the team working collaboratively on the the team is working together,
although the task board and indicate that the team is
functioning and working project as evidenced in the or the level of collaboration is
GitHub repository indicate that collaborating very effectively
collaboratively to complete deliverables, the task board and insufficient to support
there are some inconsistencies to deliver the project.
the work defined. GitHub repository. successful project delivery.
between team members work.

Application quality the Product is of an excellent User interface is poor and

Product is of a good overall Product user interfaces have
overall quality of the quality, with a well built user does not meet the
quality, with generally good user some issues, and the
application, based on its interface and no obvious errors requirements set out for the
interfaces and few obvious errors application has some obvious
robustness and user occurring when running the project. Application often
when running the application. errors that lead to instability.
interfaces. application. fails or lacks stability.
Module name: Software Engineering (CMP020N204S)
Lecturer: Dr Lisa Haskel, Dr Touseef Tahir, Dr Mamoona Humayuan
Coursework 2025

Criteria Excellent Satisfactory Not Satisfactory Not attempted

Program contains appropriate Program contains some

Program contains some
Code quality ability to documentation for all major documentation (at least the
documentation on major Program contains no
format and document code functions, variables, or non- student’s name and
functions, variables, or nontrivial documentation, or grossly
for human consumption trivial algorithms. Formatting, program’s purpose) but has
algorithms. Indentation and other misleading indentation.
(Good Style) indentation, and other white occasionally misleading
formatting is appropriate.
space aids readability. indentation.

Individual Contribution
Module name: Software Engineering (CMP020N204S)
Lecturer: Dr Lisa Haskel, Dr Touseef Tahir, Dr Mamoona Humayuan
Coursework 2025

Criteria Excellent Satisfactory Not Satisfactory Not attempted

Good organisation, points are Organised, although some points Some organisation points Poorly organised. No
Presentation how well organised
logically ordered, report order are somewhat jumpy. General flow jump around. Flow is logical progression.
is the report.
flows together. of report works. unclear. Overall flow is vague.

Good discussion level provided Discussion is good but lacks Discussion is poor and
Discussion overall level of Excellent overall level of
although unclear or inconsistent in clarity and consistency in does not provide clarity
discussion in the report. discussion provided.
a couple of places. places. to the report.

Quality of information ability to Details are somewhat Specific details

Supporting details specific to Some details are non-supporting to
provide details to support the unclear and do not support undefined or difficult to
subject. the subject.
report. the topic. find.

Excellent depth of analysis on the Analysis is brief and doesn’t

Good depth of analysis, but could No reflection or little
Depth of reflection ability to overall process undertaken in the really explore how the
have gone into more detail of the reflection on the overall
provide an in-depth analysis of project including the product developed product
product delivered based on the project process and the
the overall process of the project. delivered based on the original compares to the original
original vision. product delivered.
vision. vision.

Excellent level of self-appraisal, Self-appraisal is brief and

Critical self appraisal ability to Good level of self-appraisal, No self-appraisal or little
highlighting what went well and doesn’t go into any real
critically analyse own including some analysis of what self-appraisal on own
what would have been done analysis of what went well
contribution to the project went well and what could have performance in the
differently in hindsight based on or what could have gone
process based on role. gone better given hindsight. team.
the project delivered. better.

Excellent level of appraisal of the Good level of appraisal of the No team appraisal or
Critical team appraisal ability to Team appraisal is brief and
team’s work and how they have team’s work and how they have little team appraisal and
critically analyse other team doesn’t really analyse the
contributed to the delivery of the contributed to the delivery of the how they have
members’ contribution to the individual roles within the
project, including individual roles project, although might be lacking contributed to project
project process based on role. team.
undertaken in the project. exploration of individual roles. delivery.