COMP3900/9900
Project Deliverables and
Assessment
This document describes group formation, assessments, and other project course
deliverables.
! Group Formation: A group will be five (5) students in size, with all members being in
the same lab (unless there is no possibility to have 5 group members because of the
size of the lab, in which case a group of 4 may be accepted with the mentor’s
permission). Please do register your group on the WebCMS3 course website under the
Groups page and specify group members as well as the Scrum Master (as Admin in
WebCMS3 Groups terminology).
! Roles: Each group should have a Scrum Master and four (or three) Developers. Their
responsibilities are discussed in the lecture. Note that these roles are for
accountability. We expect that all members should be involved in coding. Scrum
Master may contribute marginally less coding efforts, e.g., 10% less, if he/she will
administrate GitHub (having a Maintainer role) and Jira accounts for the team.
! GitHub: Each group should use their GitHub classroom repository to store and
maintain the entire code-base used for their project, and ensure they keep commit
history accurate to represent contributions made by each team-member.
2
Work Diary
Each student should maintain a work diary (call it z0001234.txt if your student zID is
z0001234) and check the file into GitHub.
From Week 1 onwards, we expect that you will update this file every week with your new
contributions to the team and the project. Check the file into GitHub at least once a week
(can be more frequent).
The content of the file should be brief but clear. For example, it should be like:
Week 1
Group formed. I created the Jira & GitHub accounts. Together with John
Smith, I wrote the user story & sprints section of the proposal. I also
found and discussed with the team all available software tools and
libraries that we can use for the project.
Week 2
I wrote the first version of hello.c, api.h, api.c and drafted a design for
the Web service API between the client and the server – all by myself.
You should also include in this diary the following information (if applicable) about the
project progress:
- what was planned for the period since the last work diary entry
- what was finished
- what were the main technical and non-technical obstacles and how they were
overcome (or what was tried and did not work) - what was not finished, why this happened, how this affects the overall project
progress and what adjustments (if any) are needed so the success of the project is
not endangered - what is planned for the next period (e.g., next week)
We expect that other members of the team may access this file to know where others
are up to, but you should not modify your peer’s work diary.
3
The Proposal
! Project Proposal (due Monday Week 4 @ 9.00am, 21 June) (10%): Students will
choose a project from a list of possible projects with a given description and project
objectives. They will produce a proposal that describes: the background for their
project, the product backlog to be used for satisfying all project objectives, an initial
sprint backlog, user storyboards, and the system architecture. The requirements and
criteria for the proposal are described below.
! Please make sure you also take a look at the WebCMS Proposal assessment
submission page for submission instructions, and follow those submission
instructions.
! Students may request to undertake a custom project only if 8 distinct project
objectives of similar technical depth & scope to existing projects are clearly defined
with the request. A clear project description should also be included with the
request. Such requests are subject to mentor approval and amendment, and are to
be sought prior to week 2 by filling in and agreeing to the terms on the custom
project form that can be found at https://rebrand.ly/aje7pe4 .
! The proposal should be self-contained, (ie: no content should be outside of the report
and simply linked to), and follow the following formatting requirements:
a) Include a title page containing: project title; a nominated group name; each
member’s name, email, student ID, role; proposal submission date.
b) Be at least 5 pages long (at most 12pt font with reasonable margins & spacing),
not including the title page and references page, and be in PDF format that is
readable with Acrobat.
c) Include a table of contents, and page numbers.
d) Include references and use either APA (https://student.unsw.edu.au/apa) or
Harvard (https://student.unsw.edu.au/harvard-referencing) referencing style.
! The proposal should include:
a) Background (10%)
” Clearly identifies the problem(s) being solved.
” Identifies existing work or systems in the same problem domain, and their
drawbacks.
4
b) User stories & Sprints (50%):
” Product backlog of correctly structured user stories, describing the functionality to
be delivered, with screenshots showing all these user stories defined in Jira. The
entire text of each user story should be readable inside the report.
” Defines the start and end dates for all sprints envisaged during term.
? Note: ensure that the sprints you define allow you to undertake a demo in each of
weeks 5 and 8; as well as a retrospective before each of the labs in weeks 7 and 9.
” Identifies user stories in scope for the first sprint with screenshots showing all user
stories allocated to the first sprint in Jira. The entire text of each user story should
be readable inside the report.
” Clearly communicates how all project objectives are satisfied by user stories that
are defined.
” Describes how some of the defined user stories provide novel functionality
compared to existing systems.
c) Technical depth, scale, report formatting (40%)
” Report conforms to the formatting requirements specified above; and is easy to
read.
” Interface and flow diagrams (Storyboards for user stories)
Storyboards should be developed to illustrate the system functionality, and how
users interact with the system. One storyboard can cover multiple user stories.
All user stories should be covered by these storyboards.
” System Architecture
A clear description showing the presentation, business and data layers in the
system, and what each layer contains.
A clear description of the external actors (eg: user types) and how they interact
with the system.
A clear description of the technologies/languages planned for use (eg: mysql,
sql server, msmq, .NET, java, etc), including all third party functionality planned
to be used (eg: clouds/services/APIs/libraries/code).
5
! Proposal is marked out of 10, contributes 10% towards the final mark for the project,
and is marked according to the marking criteria below.
Project Proposal Marking Criteria
Category Max Mark
Team
Mark Comments
Background (10%)
Problem domain, existing work/systems, and their
drawbacks
Clearly identifies problem(s) being solved 0.5 Marks considered separately for this category
Clear evidence of research as to existing work or
systems in the same problem domain and what their
drawbacks are.
0.5
Marks considered
separately for this category
User stories and sprints (50%) 5
Product backlog of correctly structured user stories,
describing the functionality to be delivered, with
screenshots showing all these user stories defined in Jira
1.5
Marks considered
separately for this category
Defines the start and end dates for all sprints envisaged
during the length of term 0.5
Marks considered
separately for this category
Identifies user stories in scope for the first sprint with
screenshots showing all user stories allocated to the first
sprint in Jira
1
Marks considered
separately for this category
Clearly communicates how all project objectives are
satisfied by user stories that are defined 1
Marks considered
separately for this category
Describes how some of the defined user stories to be
implemented provide novel functionality compared to
existing systems
1
Marks considered
separately for this category
Technical depth, scale, report formatting / readability
(40%) 4
Report conforms to the formatting requirements specified
for the Proposal in this Project Deliverables and
Assessment document; and is easy to read
0.5
Marks considered
separately for this category
Includes clearly a detailed software architecture diagram 1.5 Marks considered separately for this category
Interface and flow diagrams 2 Marks considered separately for this category
Total Mark (out of 10) 10
6
The Progressive Demos
! Progressive Demo A (Week 5 Lab Time) (2.5%)
and Progressive Demo B (Week 8 Lab Time) (2.5%):
Progressive demonstrations provide an opportunity to showcase user stories that have
not yet been demonstrated, and how well you have developed functionality to support
these.
! Marking criteria:
a) Completed stories to be demonstrated are shown in Jira and described, with
these stories having the correct status in Jira (Done) (1%)
b) Demonstrates the functionality used to support each completed story (1%)
c) Keeps to 12 minutes or less (0.5%)
! Group members absent for a progressive demo receive 0 marks for that entire demo.
7
The Retrospectives
! Retrospective A (Week 7 Lab Time) (2.5%)
and Retrospective B (Week 9 Lab Time) (2.5%):
A retrospective is a reflective activity, where the team meets to think about their team
work process over the past sprint, and discuss: what went well, what didn’t go so well,
and what the team should try to over the next sprint to improve their work process.
Additional aspects are also described in the marking criteria below. This meeting should
follow soon after the sprint demo (usually in the same day). The deliverable for each
retrospective should be emailed by the team scrum-master to your mentor and also
submitted through WebCMS (make sure the document submitted on WebCMS is the
same one sent over email).
! Marking criteria:
WX：codehelp