CS360 - projects

Project Part 1

2025-08-28T00:00:00+05:00

Dr. Suleman Shahid and Dr. Abdul Ali Bangash, Department of Computing Science, LUMS (2026). Dr. Hazel Campbell, Department of Computing Science, University of Alberta (2019, 2023, 2024). Dr. Abram Hindle, Department of Computing Science, University of Alberta (2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022, 2023). Alexander Wong, 2019. status: published summary: Project Part 1

Learning Objectives
Exercise
Submission Procedure
Hints

Due date: Check the schedule.

Learning Objectives

Set up and use collaborative tools for team-based project development.
Collaborate in a team.

Exercise

Your team is expected to use GitHub for a git repository and wiki to share, manage, and store your project artifacts.

See the Project Teams sheet for your assigned team name, Example: indigo.
Add CS360S26 to it. Example CS360S26indigo
Create a new GitHub Organization using the following naming format: CS360S26teamname e.g.CS360S26indigo
This must be the exact name of your team’s GitHub organization. Use the free GitHub plan.
Inside your newly created organization, create one public repository. The repository name must be a professional, respectful project name related to your team name. Example: indigo-events
Make sure your repository is accessible at all times to team members, the TAs, and the instructor via GitHub. Record the repo URL.
Create a doc/ directory in your repository, create a team.txt file within doc/, and have each of your team members make a distinct, versioned edit to that file. For each member, that edit must be a line with their GitHub username.

(Later in the course, project documentation will be done using the GitHub wiki.)

Submission Procedure

One team member uses the Google form to submit project part 1.

Hints

This exercise can be completed with your team in the labs that cover git and GitHub.

Project Problem Description

2025-08-26T00:00:00+05:00

Dr Abdul Ali Bangash
Dr Suleman Shahid status: published summary: Project Problem Description

Project Problem Description

Select any one topic out of the following:

Project 1: Campus Event Discovery and Management Platform

A centralized platform where students can discover, browse, and RSVP to campus events while event organizers can create and manage their events efficiently.

Core Features

Event browsing and discovery (talks, sports, clubs, performances)
RSVP and attendance tracking
Calendar integration for personal scheduling
Event creation and management dashboard for organizers
Ticket management or capacity tracking
Real-time event updates and notifications
Event categorization and search filters

Primary Users

Students
Student club leaders
LUMS Staff

Key Challenges

Calendar API integration
Real-time notifications
Capacity management
Event discovery algorithms

Project 2: Peer Tutoring Marketplace

A platform that connects students seeking academic help with peer tutors, enabling scheduling, session management, and quality feedback.

Core Features

Tutor and student profile creation with subjects/courses
Tutoring session request and offer system
Session scheduling and booking
Rating and review system for tutors
Session history and progress tracking
Subject-based tutor matching
Simple payment integration or credit system (extra)

Primary Users

Students seeking help
Peer tutors
Academic advisors

Key Challenges

User matching algorithms
Scheduling optimization
Review system integrity
Payment handling (if applicable)

Project 3: Campus Sustainability Tracker

A gamified platform that encourages sustainable behavior by allowing students to log daily activities, track environmental impact, and participate in green challenges.

Core Features

Daily activity logging (transport mode, energy use, waste)
Personal impact dashboards with visualizations
Collective campus-wide impact tracking
Green challenges and competitions
Leaderboards and achievement badges
Sustainability tips and educational content
Team-based challenges for clubs or departments

Primary Users

Students
Campus sustainability office
Environmental clubs

Key Challenges

Data visualization
Gamification mechanics
User engagement strategies
Impact calculation accuracy

Project 4: Campus Gate Access System

A security management system that streamlines visitor entry, credential verification, and entry/exit logging for campus gates.

Core Features

Guard dashboard for visitor credential checking
Visitor request submission portal for faculty and staff
Approved entry time verification
Entry and exit logging system
Ad-hoc visitor approval workflow
Guest pass system for students
Security audit logs and reporting
Visitor lookup and search functionality

Primary Users

Security guards
Faculty
Staff
Students
Security administrators

Key Challenges

Real-time credential verification
Approval workflows
Audit trail integrity
Mobile accessibility for guards

Scope Note:
Focus on core functionality—guard dashboard, visitor lookup, and entry logging. Advanced features like SMS notifications or facial recognition can be considered for future iterations.

Project 5: Counseling Appointment System

An appointment management platform that connects students with counseling services, enabling easy booking, scheduling, and session management.

Core Features

Counselor discovery and availability viewing
Time slot booking system
Appointment reminders and notifications
Rescheduling and cancellation functionality
Counselor availability management dashboard
No-show tracking and analytics
Pre-session intake forms
Post-session feedback mechanism
Appointment history for students and counselors

Primary Users

Students
Counselors
Counseling office administrators

Key Challenges

Privacy and confidentiality
Scheduling conflict management
Reliable notification system
No-show prevention

Scope Note:
Focus on appointment booking flow, availability management, and basic notifications. Intake forms and feedback can be added progressively.

Project Demo Schedule

2024-08-28T00:00:00+05:00

Project Demo Schedule

Project Part 0

2024-08-26T00:00:00+05:00

Team Members
What to submit
Submission Procedure
Marking

Due date: Check the schedule.

Team Members

Project teams consist of 5 members and each member must be registered in the same lab section.

The intent is that all members are available together for a good block of time during the week, to regularly meet their assigned TA, and to attend their project demos in their registered lab, without potentially overloading the lab section.

For an initial teamwork exercise you will be asked to pick a team name according to the exact specifications below.

If you have fewer than 5 members, you may be split up and assigned to other teams.

What to submit

Every team member will need to submit the following:

The lab section (Wednesday/Thursday)
Each team member's ROLLNUM
Each team member's name
Each team member's GitHub username
A proposed team name
- Good examples: kakuna, helium, orchid, magnet, indigo
- Exactly six (6) ASCII lowercase letters
- A single English word
- Must be professional
  - Sexism/Racism/etc. or any other harassment will be brought to the Dean of Students for sanctions
  - Must not contain any insults or negativity. Examples: suckers, copium, haters, betray, regret, losers...
- Must not contain anyone's name as a substring
- Should be unique
  - Words like heroes, awesome, are overused: they'll be accepted but might conflict with another team, if they conflict, the second team to submit will be assigned a different name.

Submission Procedure

All members of the team must submit the Google Form: Form

Marking

If you do not form a team before the due date, you will receive a mark of zero.
If you do not submit on time, you will receive a mark of zero. No late submissions are allowed. No extensions will be granted.
Every team member must submit. If you don't submit you will receive a mark of zero even if your other team members submitted.
You will be deducted one mark for each violation of the required submission format!
- This also includes violating the team name format

Project Part 2

2024-08-26T00:00:00+05:00

Project Part 2 -- Preparation

Due date: Check the schedule.

Learning Objectives

Refine requirements
Apply object-oriented analysis and design
Prototype a user interface.

Overview

The project description outlines the problem and a set of needs. The entire project has several deliverables. Subsequent deliverables may be further refinements of earlier ones, and should address any TA feedback or concerns. This project part focuses on some initial preparations.

Deliverables

The following components are required for this project part.

1. Product Backlog:

Form the initial partial user stories into a backlog of the product's requirements. For each user story, estimate its size in story points, and denote its risk level (i.e., low, medium, or high). These requirements will likely evolve and should be maintained up-to-date throughout the project. Make sure they are numbered for easy reference. Note which stories will be released for the half-way checkpoint.

2. User Interface Mockups and Storyboard Sequences:

Diagram the layout of your main user interface and major dialogs, with comments describing the important elements. Also, diagram storyboard sequences of using your application, with transitions between different states of the user interface, caused by the user manipulating the controls or providing input. Within the diagrams, reference the relevant requirements. Convincingly show all the requirements are covered.

3. Object-Oriented Analysis:

Document your initial object-oriented analysis using CRC cards, focusing on the most important anticipated classes, their responsibilities, and collaborators.

4. Tool use:

Regular and consistent use of GitHub by all team members to share files for the project deliverables, to effectively track issues, and to manage tasks.

Hints

Ask questions about the requirements. Your interpretation of a need or task may be more complex or sophisticated than what is actually desired. Involve the TA for your team to gain feedback on your deliverables.

For neatness and readability, diagrams must be drawn well using a computer tool at a suitably legible scale for insertion into your document(s). Submitted diagram(s) must be embedded as image(s) in your team wiki, not linked externally.

You should look ahead to the future project parts and their deliverables to know what is coming. Do not wait until this part's deliverables are due before working on the next part.

Very likely, the requirements and user interface design will need to evolve during the project. You should keep this information up-to-date so that your team members are properly coordinated.

Submission Procedure

Use GitHub. Your team repo must be self-contained, i.e., not link to external content that might change.

Individual Task and Peer Review Form

After the due date, each member must complete an assessment form to describe his or her individual contribution to the project for this stage, and to review the performance of the other members: https://forms.gle/oJj2AAmdiXL7tybu9 Deadline to complete the form and submit it is 11:59 PM Tuesday 10 March

Marking

Each component of your deliverable will be evaluated individually based on the following rubric:

No part marks, no extra marks. No half marks.

Failure (0) :
- Incomplete. Missing important components.
- Or no submission
Unsatisfactory (2)
- A project submission that is missing components. Inconsistency is key. Missing important test cases. Lack of planning or adherence. Lack of attendance etc. Must demonstrate clear understanding of purpose and rationale behind deliverables.
- Or A project that effort has been put into and doesn't meet the requirements described. Most deliverable points have been met.
Satisfactory (3)
- A project submission that is missing minor components and contains some rough elements, but is NOT missing anything major.
Good (4)
- A not-quite excellent submission that meets the majority of all the requirements without problem.
Excellent (5)
- A excellent submission that meets the all the requirements without problem.
- A flawless project that meets the requirements described.

Project Part 3

2024-08-26T00:00:00+05:00

Project Part 3 -- Half-Way Checkpoint

Due date: Check the schedule.

Learning Objectives

Develop a usable, interactive, mobile application.
Refine object-oriented design.
Produce tests.
Follow scrum practices.

Overview

This project part focuses on a working prototype with about half of the requirements. You must have some server connectivity working by this part.

Deliverables

1. Addressing Feedback: Address any TA feedback on the previous project part.

2. Code Base of Prototype: Your source code will be inspected. The code should conform to some consistent coding convention. Your prototype should provide something tangible to the user, supporting about half the requirements. Maintain the source code in your source repository.

3. Code Documentation: For each source code file, you should have a brief introductory comment describing its purpose or role within the application or a design pattern, as well as any currently outstanding issues. Provide Javadoc interface documentation for your model classes and their public methods (at least).

4. Test Cases: Write runnable tests for your model and control classes. Provide intent tests for the requirements you have done. Deliver the test code to your source repository. If you have test data files, also include those. Test data should be realistic.

5. Object-Oriented Design: Document your object-oriented design using a UML class diagram (or diagrams), including details on key attributes and methods. Add notes as appropriate to clarify. The diagram(s) will likely evolve.

6. Product Backlog: Update the requirements as appropriate. Note which user stories are done at this checkpoint.

7. User Interface Mockups and Storyboard Sequences: Update these diagrams as appropriate.

8. Sprint Planning and Reviews: Maintain a record of what user stories are planned for each weekly sprint at its start, including who is to work on them. For each intermediate week, in the lab, have a sprint review with your TA mentor and all team members present to review the completed user stories.

9. Demonstration: During your team's assigned lab section after the due date (or possibly at a mutually arranged time), you must demo your working prototype to your TA mentor. All team members have to attend the demo.

10. Tool use: Regular and consistent use of GitHub by all team members to share files for the project deliverables, to effectively track issues, and to manage tasks.

There must be consistency across the deliverables at this checkpoint.

The evaluation of this project part will also include a component called "relative quality". This is used to differentiate projects that meet the minimum from projects that go "the extra mile".

Restrictions

Use Java, with Android, and Firestore.

Hints

Integrate early and often, even if some parts may have to be stubbed out to return canned data. Think about issues like server connectivity early in the design, rather than trying to retrofit them later.

Submission Procedure

Use GitHub. Your team repo must be self-contained, i.e., not link to external content that might change.

Please make sure your repository has the right version of code by the deadline. The TA will try to build your program from the submitted code. The TA may contact you if there are build issues.

If you reuse software, give proper credit to the original developers. Obtain approval for the use of third-party libraries as appropriate.

Individual Task and Peer Review Form

After the due date, each member must complete an assessment form to describe his or her individual contribution to the project for this stage, and to review the performance of the other members.

Marking

No part marks, no extra marks. No half marks.

Failure (0) :
- Incomplete. Missing important components.
- Or no submission
Unsatisfactory (5)
- A project submission that is missing components. Inconsistency is key. Missing important test cases. Lack of planning or adherence. Lack of attendance etc. Must demonstrate clear understanding of purpose and rationale behind deliverables.
- Or A project that effort has been put into and doesn't meet the requirements described. Most deliverable points have been met.
Satisfactory (7)
- A project submission that is missing minor components and contains some rough elements, but is NOT missing anything major.
Good (8)
- A not-quite excellent submission that meets the majority of all the requirements without problem.
Excellent (10)
- A excellent submission that meets the all the requirements without problem.

Project Part 4

2024-08-26T00:00:00+05:00

Project Part 4 -- Final Checkpoint

Due date: Check the schedule.

Learning Objectives

Develop a usable, interactive, mobile application.
Produce a product demonstration.
Follow scrum practices.

Overview

Your product is ready to be released!

Most deliverables are final, consistent updates of what was initiated for the previous project part.

Deliverables

Addressing feedback: Address any TA feedback on the previous project part.
Code Base of Prototype: Your source code will be inspected. The code should conform to some consistent coding convention. Maintain the source code in your source repository.
Code Documentation: For each source file, you should have a brief introductory comment describing its purpose or role within the application or a design pattern, as well as any currently outstanding issues. Provide Javadoc interface documentation for your model classes and their public methods (at least).
Test Cases: Write runnable tests for your model and control classes. Provide intent tests for the requirements you have done. Deliver the test code to your source repository. If you have test data files, also include those. Test data should be realistic.
Object-Oriented Design: Update your object-oriented design using a UML class diagram (or diagrams), including details on key attributes and methods. Add notes as appropriate to clarify. Include notes on the use of design patterns among the classes.
Product Backlog: Update the requirements as appropriate. Note which user stories are done at this checkpoint.
User Interface Mockups and Storyboards: Update these diagrams as appropriate.
Sprint Planning and Reviews: Maintain a record of what user stories are planned for each weekly sprint at its start, including who is to work on them. For each intermediate week, in the lab, have a sprint review with your TA mentor and all team members present to review the completed user stories.
Demonstration: Present an engaging demo. The final demo of your final prototype should show the usability of its user interface and the degree to which its functionality fulfills the user's needs. All team members must contribute to the demo. During the last week of labs you and your team will present this demo in less than 3 minutes to the entire lab. It will be your app live, with your team members. No videos, audio, or powerpoint. Just your live app. Make backup videos of the functionality in case your demo fails. Practice your demo in the lab room ahead of time. Make sure you can present your app by testing the projector and your devices the week before. All teams should participate and be present. Aim for live presentation in 3 minutes. Do not leave early.
Tool Use: Regular and consistent use of GitHub by all team members to share files for the project deliverables, to effectively track issues, and to manage tasks. There must be consistency across the deliverables at this checkpoint.

The evaluation of this project part will also include a component called "relative quality". This is used to differentiate projects that meet the minimum from projects that go "the extra mile".

Restrictions

Use Java, with Android, and Firestore.

Submission Procedure

Use GitHub. Your team repo must be self-contained, i.e., not link to external content that might change.

Please make sure your repository has the right version of code by the deadline. The TA will try to build your program from the submitted code. The TA may contact you if there are build issues.

If you reuse software, give proper credit to the original developers. Obtain approval for the use of third-party libraries as appropriate.

This demo should have a logical flow in what is presented (following a story about what a user would naturally do, not just enumerating assorted features).

Individual Task and Peer Review Form

After the due date, each member must complete an assessment form to describe his or her individual contribution to the project for this stage, and to review the performance of the other members.

Marking

No part marks, no extra marks. No half marks.

Failure (0) :
- Incomplete. Missing important components.
- Or no submission
Unsatisfactory (8)
- A project submission that is missing components. Inconsistency is key. Missing important test cases. Lack of planning or adherence. Lack of attendance etc. Must demonstrate clear understanding of purpose and rationale behind deliverables.
- A project that effort has been put into and doesn't meet the requirements described. Most deliverable points have been met.
Satisfactory (11)
- A project submission that is missing minor components and contains some rough elements, but is NOT missing anything major.
Good (14)
- A not-quite excellent submission that meets the majority of all the requirements without problem.
Excellent (16)
- A excellent submission that meets the all the requirements without problem.
- A flawless project that meets the requirements described.

Project Teams

2024-08-26T00:00:00+05:00