CSCI 265 Project 2026
As part of CSCI 265, all students are required to fully participate
in a semester-long team project. The project will involve a wide
range of activities and deliverables, with a mix of both individual
and team activities and requirements.
The project will involve a variety of activities and presentations held in the
course labs (Fridays 10-11, 11-12 in building 315, room 115):
- Week 1 (Sept 11): meet and greet in lab, preliminary team formation
- Week 2 (Sept 18): finalization of team composition
- Week 3 (Sept 25): mandatory team meetings, progress updates
- Week 4 (Oct 2): phase 1 due (presentations in lab, deliverables by end of day)
(individual contributions assessments due on Oct. 5)
- Week 5 (Oct 9): mandatory team meetings, progress updates
- Week 6 (Oct 16): mandatory team meetings, progress updates
- Week 7 (Oct 23): phase 2 due (presentations in lab, deliverables by end of day)
(individual contributions assessments due on Oct. 26)
- Week 8 (Oct 30): mandatory team meetings, progress updates
- Week 9 (Nov 6): mandatory team meetings, progress updates
- study week Nov 9-13: no lectures/labs
- Week 10 (Nov 20): phase 3 due (presentations in lab, deliverables by end of day)
(individual contributions assessments due on Nov. 23)
- Week 11 (Nov 27): mandatory team meetings, progress updates
- Week 12 (Dec 4): mandatory team meetings, progress updates
- Week 13 (Dec 11): final project demos, closeout presentations, and deliverables
(individual contributions assessments due on Dec. 13)
Team composition:
Each lab section will be divided into three teams,
with each team typically consisting of 5 or 6 members.
Since some team members may withdraw from the course during a term
it may become necessary to restructure some teams, and/or to change the
scope/scale of some projects. If this becomes necessary it will be done
in consultation with the instructor and the impacted team members.
Attendance:
With the exception of the study week (Nov. 9-13), students are required to attend their registered lab section each
week unless arranged otherwise with the course instructor in advance
or due to illness or personal emergencies with supporting documentation.
Every member of every team is required to attend all the presentations
for their own team and for the other teams in their lab section.
Participating in your own team's presentations and providing effective feedback
to the other teams is part of the process of building the professional skills you'll need for effective
software development.
Assessment:
The project as a whole is worth 40% of your total course grade,
with each of project presentations and deliverables contributing to that 40%.
The weighting below shows how much each individual component is worth.
The teams will likely adopt different approaches to completing the various deliverables
across the project phases (e.g. some may take a waterfall-like approach, some may take a
more scrum-like approach), but must give formal planning and progress updates at fixed
deadlines as the term progresses (as per the schedule shown at the top of this page).
The course instructor will provide feedback on both the plans and the progress
made each phase, but the official mark for each deliverable will be based on its final state
at the end of term.
Relatively few teams get equal contributions from each team member (overall
or from phase-to-phase). Because of this, each project phase will be given a team mark
reflecting how well that component meets the course expectations, but each individual on the team will
get a mark scaled from that based on their contributions to the component.
The process for assessing contributions is discussed in some detail on the
contributions page.
Project deliverables/values
Each project is marked out of 100, with the various component weights detailed below.
(Links to more detailed descriptions of each component will be provided shortly.)
Phase presentations, on-time content delivery [15]
- phase 1 [3] (presentation, on-time delivery of proposal and charter)
- phase 2 [3] (presentation, on-time repo setup and on-time delivery of standards and procedures and updates)
- phase 3 [3] (presentation, on-time updates of current state of all deliverables)
- phase 4 [6] (final demo, on-time delivery of final versions of all deliverables)
On-time content delivery means all the required deliverables for the phase
have been fully and correctly submitted prior to midnight on the due date.
While documents can be revised and resubmitted at later dates to improve
the marks for them, this does not affect the original on-time delivery aspect.
Each team is responsible for checking they have correctly submitted everything
by the time it is due: there are no second chances for these marks.
|
Documentation [55]
(documentation marks are based on the final state of each document,
and can be improved by resubmitting updated versions for everything
except the initial proposal)
- initial proposal [5] (see details in phase 1)
- team charter [5] (see details in phase 1)
- standards and procedures [5] (see details in phase 2)
- requirements/specifications [15] (ongoing through phases 2-4)
- design [12] (ongoing through phases 2-4)
- peer and self assessments and contribution summaries [8] (2 per phase,
see details in the contributions page)
Other deliverables [30] (repos/infrastructure, code, files, etc)
(note: the weighting of marks in this section
will vary from team to team, based on the nature of the project)
- repos/infrastructure
- client and server-side code
- data and support files
Example documentation:
I've posted sample versions of the various documents,
based on a fictitious game project.
These documents actually follow a 6-phase waterfall approach that included
a testing component, so
won't match exactly with this year's plan, but should give a good feel for the
expected depth and organization of the different kinds of document and deliverable. |
Getting feedback on the project phases
I'll post feedback for each person individually, using a git repo
named feedback.
The server-side repos have already been created (forked), you'll just clone
your feedback repo once, then in the future go into it and run a git pull
to grab any updates I've posted for you.
Getting the repo the first time:
git clone csci:csci265/$USER/feedback
then cd into the directory and have a look at file 'phase1'
Getting updates in the future:
cd into your feedback directory and run
git pull
and have a look at any files/file updates it pulled.
When inviting me to your gitlab/github project:
on gitlab.csci.viu.ca I'm @wesselsd (David Wessels), adding as a 'reporter' is fine
on github I'm DaveWesselsVIU
both use my David.Wessels at viu email address
|
Past project ideas
A wide variety of projects have been tried over the last several years,
here are a few examples:
- tools, web apps, and sites (often with a server-side component and sometimes a database)
- a system of parking sensors and web app to track open parking spaces on campus
(using leaflet for the mapping and their own hardware for the sensors)
- a daily task/route-planning system, showing your planned activities on a live map
with route recommendations (also using leaflet)
- a tracker and predictor for menstrual cycles along with health resources site/guide
- a social image sharing site that allows hidden messages (and even other images)
to be encrypted within the shared images
- a tool for taking and sharing course notes between students
- a light-weight code editor with embedded AI interface
- a VIU-specific social media site
- games (text based adventure, platformers, arcade, puzzles, card/casino, etc)
implemented using a wide variety of tools/languages:
- C/C++ on the csci machines, some purely ascii, some using ncurses, some using gtk
- engines/environments including unity, unreal, godot, roblox
Misc. Resources
If you're looking for information on the tools/processes we're using,
try the resources page.