Project Information

Project Options
Team Roles
Artifact Document Templates
Sprint Information
Final Grading Information
Project Resources

Project Options and Requirements

Your team must choose one of these project options, as voted on by the class and selected by the staff. You have a great deal of agency within these options, but you must stick to the core use cases of the project.

You must meet any common and project specific requirements listed below.

Common Requirements

All projects must do the following, regardless of idea chosen:

  • All projects must incorporate Google user accounts as the primary way that someone logs into the system. You will need to use the Google account API to make this work. There are several libraries that are built for Django to work with Google accounts with tutorials. You should not limit logins to just @virginia.edu accounts! (this will lock out the faculty :-( )
  • Users then must be able to do something in the system that is meaningful based on that login, such as account management, save favorites, make message posts, “liking” things, etc. This will vary by project.
  • All projects must incorporate at least one additional third-party API other than login for something meaningful in the app. Note that if an app description requires use of an API (such as mapping), you must have an additional API. Adding a trivial and meaningless API like “current weather” button to an app that has nothing to do with needing the weather would not count. Some example ideas are posted with each project idea.
  • All projects must be built using the prescribed language (Python 3), framework (Django 3), build environment (GitHub Actions CI), source control management (GitHub), and cloud hosting (Heroku). No exceptions to these will be granted.
  • You must use Postgres as your database engine for production (on Heroku) and continuous integration (on GitHub Actions). If you use SQLite (which is the default option when you create a new Djano project), the database will be deleted every time you upload a new version of your app to Heroku. You are allowed to use SQLite for local testing so you do not have to install Postgres on your own maching, but another option is to change your settings.py file point to the Postgres DB on Heroku at all times. This will allow you to use the same data set online and with every team member without any extra setup.

Project Options

Students in the course will pitch ideas that the class will vote on. The staff will choose the top three (or so) ideas that are viable in the opinion of the instructors. Teams will then be able to choose any of these general project ideas for their semester project.

The theme for Spring 2022 is: “Being social.”

All project ideas must embody the spirit of this theme in some way.

NOTE: The options below list some “must include” features. Building just these features is NOT SUFFICIENT for you to have a successful app. This is just to give some guidelines on what we need to see.

Project Option 1: Word of Mouth

A place to post recipes, but without the pages and pages of backstory that all cooking webpages now have to force you to scroll through ads. Recipes would include a set of ingredients and directions, as well as images, possible videos, etc.

  • Users must be able to add a new recipe, with ingredients (including quantities), step by step directions, and photos.
  • Users must be able to “favorite”/”like”/reviews recipes
  • Users must be able to “fork” recipes - this means take an existing recipe and modify it (such as changing some ingredients and steps). The “forked” recipe must reference the original recipe. For example, if recipe A is forked into a new recipe, recipe B, the page for recipe B must link back to recipe A.
  • Uploading photos counts as your “additional API”, but you must have permanent image storing (meaning something like AWS-S3, Google Drive, etc.) You cannot store the images on Heroku, as Heroku wipes all storage daily.

Project Option 2: Study Buddy

This website would be used to help find study buddies in your classes a one-off “find someone for a specific class on a specific night” (i.e., not consistent study groups).

  • Students must be able to list which UVA courses they are in. These must be real UVA courses (you can find an API for UVA courses here ). Note: this does not count as your “additional API” from the general requirements.
  • Students should be able to toggle which class they are looking for a study buddy for at any given time (i.e., I’m only looking for help with CS 2150 right now, but not any of my other classes)
  • Students must be able to communicate with other students within the website (i.e., just listing email or phone number isn’t enough. You can either implement messaging, embed chat rooms, whatever)
  • Students must be able to schedule study times with 1 or more other students, and be able to see all upcoming “study sessions”
  • Additional API Ideas: Google calendar integration, messaging connections (such as SMS), Mapping for study locations, etc.

Project Option 3: Watch Party

A networking website for TV shows and movies (either in-person or streaming) to form watch parties (either in-person or online). Participants list their favorite shows and/or genres, and can form “watch parties” for episodes/streaming parties, etc. Note that in these directions, I’m using TV shows. However, this could also work for movies, etc.

  • Users must be able to list favorite TV shows
  • Users must be able to find other people who like those shows in some way (this could be handled with groups, listing everyone who liked a given show, etc.)
  • Users must be able to enter new TV shows (after all, new shows come out all the time).
  • Users must be able to create events to watch a given show. They must be able to invite (either directly or through fans of the show being able to see the upcomign watch party) other people who have “liked” that show. These events must be accepted by others to join. The creator should be able to remove people from the watch party if needed.
  • Events can either be in-person or streaming. Your external API usage may be influenced by this (for example, if you are planning online watch parties, it wouldn’t make sense to use a Maps API).
  • Additional API Ideas: Google Calendar for scheduling events, Maps and directions for finding a physical meetup, Zoom setup for online streaming, etc.

Team Roles

Each member of your five person team will take on one of these roles. Each role has different responsibilities, but ALL ROLES require that you be an active contributor to the code of the project. In other words, if you take on Scrum Master, that doesn’t mean you don’t have to contribute as much code as someone else.

Scrum Master - The Scrum Master could also be called the Team Leader, but it’s not really a “leader” position, per se, in that they are not making major decisions about the project itself. The Scrum Master is responsbile for keeping everyone on track, facilitating all team meetings, and monitoring team status / issues. The course staff will come to the Scrum Master first if there are any team issues or questions, and similarly the Scrum Master needs to know what’s going on with the team and can communicate with the staff if someone is falling behind, etc.

  • Reasons to be the Scrum Master: You like keeping schedules; you like keeping things organized; you don’t mind being the point of contact with the staff.
  • Reasons not to be the Scrum Master: You are not the most organized person; you don’t think you can stay on top of what the team is working on; you don’t like talking to the staff.

Major Artifact: Scrum Master Final Report, due at the end of the semester

Requirements Manager - The Requirements Manager is responsible for keeping up with “what” it is you are building. This person will spearhead the requirements elicitation process (which takes place in the first couple weeks of the project) as their major activity. Note that the Requirements Manager doesn’t do the whole process - they just lead the effort. Everyone else has to participate as well! Then throughout the semester they will update the burndown chart, monitoring the state of the project.

  • Reasons to be the Requirements Manager: You are interested in learning how requirements are created; you want to find out what your fellow stduents are excited about with your project; you like updating a spreadsheet; you like knowing “what’s coming next” in the project.
  • Reasons to not be the Requirements Manager: You have no interest in interacting with other people to find out what they want in a system; your first couple weeks of the semester are super hectic and you don’t have the time for the elicitation process.

Major Artifact: Requirements Elicitation Document, due within the first few weeks of the semester

Testing Manager - The Testing Manager is responsible for ensuring that the system is thoroughly tested, for developing the overall testing plan/philosophy of the team, and spearheading the beta testing effort at the end of the semester. The Testing Manager has two documents to create: the Test Plan and Beta Testing Document. The Test Plan is a short, two-page document that outlines what the testing philosophy of the team will be (i.e. every file must have X test cases, every person must write X tests, etc.). The Testing Manager then is responsible for overseeing that philosophy throughout the semester, ensuring unit tests are being written. Note that the Testing Manager does not write every test case in the system - they just keep up with what everyone else is doing and lend support as needed.

  • Reasons to be the Testing Manager: You want to learn more about testing procedures; you love seeing that unit test result bar turn green; you took HCI or something similar and are interested in setting up user testing.
  • Reasons not to be the Testing Manager: You don’t see the value in writing tests; you can’t stand the idea of having to write two documents (even if one is short); you don’t want to work with your fellow students in doing in-person testing.

Major Artifacts: Project Test Plan, due about a month into the semester, and Beta Testing Report, due near the end of the semester

DevOps Manager - The DevOps Manager is the support tech for the team in a sense. They are responsbile for the management and support of all the systems we are using in the class, namely GitHub, GitHub Actions, and Heroku. They should be a person that is relatively comfortable tinkering with computers and settings. The DevOps Manager does not have to have all the answers, but would be the contact person for going to the staff to get help on any particular issues.

  • Reasons to be the DevOps Manager: You are familiar with the tools mentioned already, or you are really interested in learning more about them; you like to tinker with settings to get things working “just right”; you have the patience to help those on your team who might need assistance getting their environments working.
  • Reasons not to be the DevOps Manager: You do not feel comfortable helping others with technical issues; you are very unfamiliar with the tools above and would rather just have a “turnkey” solution for doing your work this semester.

Major Artifacts: DevOps Report, outlining information about your setup and procedures, due near the end of the semester

UX Designer - The UX (user experience) Designer is responsible for the overall look-and-feel of the project. They are responsible coming up with the design of the overall app and managing the styling on all pages (most likely with Bootstrap). This person would hopefully have the most HTML/CSS/JS experience of the team, but that is not necessarily required.

  • Reasons to be the UX Designer: You are familiar with HTML/CSS/JS and/or Bootstrap and you enjoy thinking about how you want people to interact with your application. You are a person who wants to make sure you turn in a “good looking” app.
  • Reasons not to be the UX Designer: You have absolutely no experience with web design and, in fact, you think Geocities pages from the late 90s was the peak of web design. For some fun examples, see https://www.cameronsworld.net/.

Major Artifacts: Usability Assessment, due toward the end of the semester at the same time as the beta test document.

Artifact Document Templates

Team Documents

Project Management Spreadsheet
Sprint Report
Final Submission Pledge

Scrum Master

Scrum Master Final Report

Requirements Manager

Requirements Elicitation Document
Project Management Spreadsheet

Testing Manager

Project Test Plan
Beta Testing Report

DevOps Manager

DevOps Report

UX Designer

Usability Assessment

Sprint Information

For each sprint check, your team must meet the minimum requirements shown below for each sprint to earn full XP. Faculty will not override a TA’s decision except in extreme circumstances.

Each sprint is graded out of 5000 XP. In general, the following grading standard applies:

  • 5000 XP: Excellent progress toward completing the project on time and meeting all requirements.
  • 4000 XP: Good progress toward completing the project, but at least one requirement looks a bit uncertain.
  • 3000 XP: Fair progress toward completing the project, but team will need to step up to finish successfully.
  • 2000 XP: Poor progress toward completing the project and the team definitely needs to refocus. Some measurable work was accomplished, however.
  • 1000 XP: Little progress was made toward completing the project during this sprint.
  • 0 XP: Project is in danger.

Sprint 1: Project Organization

Due: February 6 or 7

Goal: Have your initial meeting as a team and determine who will be doing what on the team. This meeting can be any time between when your team is formed and your first official meeting with your TA on either February 6 or 7. The Scrum Master of each team MUST complete this form with the team as a part of the Sprint: Team Declaration Form.

Requirements: Complete the Team Declaration form above ASAP. Initialize your GitHub repo and have all team members join.

How To Submit: Scrum Masters should fill out a Sprint Report and submit it to Gradescope BEFORE meeting with your TA so they can reference it. Scrum Masters must select their team members in Gradescope when submitting so all members will earn the XP for the sprint. (No, you won’t have much to report this week, but think about what’s coming up and discuss that.)

Spring 1.5: Github setup

Due: February 13 or 14

Goal: Have the github repository setup for your team and everyone having joined your teams repository.

Requirements: Scrum Masters should initialize the team GitHub repo through GitHub Classroom at https://classroom.github.com/a/tIwCESPc. Please use your assigned team number for the identifier when prompted (e.g. A-03). Other team members can then go to that link and accept the assignment, selecting the proper team.

How To Submit: Just simply show your TA at your sprint meeting that the Github repository is setup and that everyone on the team has joined.

Sprint 2: Requirements Elicitation

Due: February 27 or 28

Goal: Spend most of this sprint working as a team to elicit the full requirements for your system. Note that while the final Requirements Document is the responsibility of the Requirements Manager, ALL TEAM MEMBERS are expected to contribute to gathering and refining the final set of requirements. Some coding can be performed if desired, such as some design work or starting on Google Account integration. For the project code itself, create a base Django project, put the code in GitHub, and have it hosted on Heroku. Basically, you’re taking the lessons you learned from the setup of the Django Practice Assessment and putting it to use here to show that you have a working foundation to build off of.

Requirements: The team must have a working basic Django app hosted on Heroku. The team can also show and discuss the results of their requirements elicitation document. The Requirements Manager will receive a separate score for the actual document. Also, teams should be able to discuss ideas for the design of their application.

How To Submit: Scrum Masters should fill out a Sprint Report and submit it to Gradescope BEFORE meeting with your TA so they can reference it. Scrum Masters must select their team members in Gradescope when submitting so all members will earn the XP for the sprint. The master branch of your GitHub repo should be live on Heroku.

Sprint 3: Login Integration

Due: March 6 and 7

Goal: All projects have to do something “interesting” with a user account. Thus, it makes sense to start by making sure folks can login.

Requirements: A user with a Google Account (not just a Netbadge account!) can login to the system and the system shows in some way that that user has indeed logged in. You cannot lock your app to just @virginia.edu accounts (otherwise the professors can’t login…). GitHub Actions CI MUST be operational with at least one test case in order to earn full XP. As you are just getting started with testing, this is more showing us that you have the process setup and that you have some passing tests. You do not have to have login fully tested at this point.

TEAM EVALS: At the end of Sprint 3, Sprint 5, and the project itself, you need to fill out an evaluation for each member of your team! You can find the evaluation form at: Sprint 3 and 5 Evaluation

How To Submit: Scrum Masters should fill out a Sprint Report and submit it to Gradescope BEFORE meeting with your TA so they can reference it. Scrum Masters must select their team members in Gradescope when submitting so all members will earn the XP for the sprint. The master branch of your GitHub repo should be live on Heroku.

Sprint 4: First Major Feature

Due: March 27 or March 28

Goal: Make a big push this sprint to get a major feature of your app working!

Requirements: In the opinion of the TA, significant work was accomplished this week on at least one major feature of the application, such that it is visible and mostly usable in the system. GitHub Actions CI MUST be operational with at multiple test cases in order to earn full XP. You should be moving more toward having a robust test suite at this point.

How To Submit: Scrum Masters should fill out a Sprint Report and submit it to Gradescope BEFORE meeting with your TA so they can reference it. Scrum Masters must select their team members in Gradescope when submitting so all members will earn the XP for the sprint. The master branch of your GitHub repo should be live on Heroku.

Sprint 5: Next Major Feature

Due: April 10 and April 11

Goal: Well… your app needs to do more than just one thing… right?

Requirements: In the opinion of the TA, significant work was accomplished this week on another major feature of the application, such that it is visible and mostly usable in the system. GitHub Actions should still be working.

TEAM EVALS: At the end of Sprint 3, Sprint 5, and the project itself, you need to fill out an evaluation for each member of your team! You can find the evaluation form at: Sprint 3 and 5 Evaluation

How To Submit: Scrum Masters should fill out a Sprint Report and submit it to Gradescope BEFORE meeting with your TA so they can reference it. Scrum Masters must select their team members in Gradescope when submitting so all members will earn the XP for the sprint. The master branch of your GitHub repo should be live on Heroku.

Sprint 6: Beta Version

Due: April 17 or 18

Goal: After Sprint 6 is complete, you are going to have other students test your system. So you need a working system with most all of your functionality ready to go. The app may not be fully polished and still needs a bit of work, but it needs to be usable from beginning to end.

Requirements and Full Beta Version: In the opinion of the TA, you have an app that is ready for other students to test out (e.g. it doesn’t crash, it looks reasonably good, it has most features, etc.). You will earn 5000 XP for the sprint check plus 25000 XP as the first half of your overall project score of 50000 XP (basically, if you have a working app at this point, we know your final project grade will be at least 25000/50000 XP, so we can give you those points now).

How To Submit: Scrum Masters should fill out a Sprint Report and submit it to Gradescope BEFORE meeting with your TA so they can reference it. Scrum Masters must select their team members in Gradescope when submitting so all members will earn the XP for the sprint. The master branch of your GitHub repo should be live on Heroku.

Final Grading Information

The final project is worth 50000 XP. Like the other assessments in this course, grading is overall wholistic - that is, there is no specific point-for-point breakdown for the rubric. One reason for this is that this is simply not how software is delivered in real-life. There are basically only four outcomes:

  • You meet the expectations of the customer within reason and both parties are satisfied with the outcome;
  • You exceed the expectations of the customer, potentially generating more good will, a good reference, or more future business;
  • You do not quite meet the expectations of the customer, leaving some room for improvement;
  • You ship a system that simply does not work to the expectations of the customer.

We will grade your projects in a similar vein, with some flexibility for minor adjustments.

Thus, the grading levels will be:

  • Above and Beyond - Min XP: 50000 / Max XP: 50000
  • Complete - Min XP: 40000 / Max XP: 50000
  • Lacking - Min XP: 30000 / Max XP: 40000
  • Insufficient - Min XP: 0 / Max XP: 30000

Aspects that will determine the exact grade within a range include but are not limited to:

  • UI design
  • Overall flow of application
  • Special features
  • Obvious bugs that should have been corrected
  • Polish

Remember: we will award the first half of the points (25000 XP) when your Beta version is complete after Sprint 6.

TEAM EVALS: NOTE: This is a DIFFERENT eval form than from Sprint 3 and Sprint 5! Link forthcoming

The final version of the project must be in GitHub and Heroku no later than **5:00 PM EST on Tuesday, May 3**!