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 (for instance, here’s a recent one).
  • Users then must be able to do something in the system that is meaningful based on that login, such as account management, save favorites, 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. For example, adding a “current weather” button to an app that has nothing to do with needing the weather would not count.
  • All projects must be built using the prescribed language (Python 3), framework (Django 3.1), build environment (Travis 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 Travis). The reason for this is that that is the native DB engine for Heroku and choosing anything else will prove to be quite difficult for new users of the system. What you use for local testing is up to you (could be sqlite), but one option is to just have your settings.py file point to the postgres DB on Heroku at all times.

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 2021 is: “Once COVID is over and we are back on Grounds, every student coming back will definitely need this app!”

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: Exercise Gamification

Users earn points, trophies, achievements, etc. as a reward for self-reporting exercise. Users can compare their achievements with others, with the hope of a community encouraging each other to exercise and be healthy.

Must Include:

Project Option 2: Roommate Finder / Find a Buddy

We combined these two ideas (while removing the “rate local housing”) since, in the end, the general app flow was the same: users create a profile in some way and are dynamically matched with other users based on an algorithm (which may or may not include housing preferences).

Must Include:

  • All common requirements listed above.
  • Pictures of users (submitted by users) has to be supported in some way. Past teams have often used AWS image hosting to manage pictures that are persistant, because if you allow users to upload pictures to your Heroku site, they are all overwritten every time you push a new version!
  • A way to interact with other users.

Project Option 3: What’s Changed?

Users report new/changed/closed locations around the Charlottesville area. This could be directed more at businesses or could be for anything that has changed since COVID.

Must Include:

  • All common requirements listed above.
  • GPS locations and mapping of the user-reported changes must be supported. Your app should be able to show a map of the area that users can use to browse changes.
  • A way to interact with other users.

Project Option 4: Campus Map / Find Your Classes

Users can input their schedule and/or services of interest and get back a map of Grounds that will help them. This could also do things such as shortest path routing from current location to the next or give a “daily route” for someone’s schedule in a day.

Must Include:

  • All common requirements listed above.
  • GPS locations and mapping of the locations on Grounds must be supported. You don’t necessarily have to show ALL locations, but you at least have to show locations requested by the user.
  • A way to interact with other users.

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: Final Team Project 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 at 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, Travis-CI, 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..

Artifact Document Templates

Team Documents

Project Management Spreadsheet
Sprint Report
Final Submission Pledge

Scrum Master

Final Team Project 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 some minimum requirements to earn a “Full Pass” and 5000 XP. These requirements are shown below, but the final say on whether your project meets a Full Pass lies with your TA. Faculty will not override a TA’s decision except in extreme circumstances.

If your team does not earn a Full Pass, you will earn 0 XP until you can show that your code is up to where it should be. If you can fix your system and show it to your TA before the next Sprint Check, you can earn 3000 XP for a Reevaluation Pass. You can do this for only 1 sprint during the semester. After that chance has been used, a No Pass will remain as 0 XP.

Sprint 1: Project Skeleton

Due: February 22 or 23

Goal: 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.

SCRUM MASTER ONLY: The Scrum Master of each team MUST complete this form ASAP after your first meeting: https://forms.gle/Kp7rnDe49jvAwnkm6. Also, Scrum Masters should initialize the team GitHub repo through GitHub Classroom at https://classroom.github.com/g/4xqd-Z-z. 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.

Full Pass Criteria [5000 XP]: Complete the Team Declaration form above ASAP. Can show a basic, working Django site on Heroku and code is in GitHub. No features required.

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 2: Requirements Elicitation

Due: March 1 or 2

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.

Full Pass Criteria [5000 XP]: Show that you have made “good progress” on your requirements elicitation, with surveys, interview questions, etc. But the process does not have to be complete, nor does the document have to be done in order to get a full pass. However, you must have at least moved into the full elicitation activities, not just planning.

The requirements documents themselves are due the following week. See the course schedule and the requirements docs for more information.

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 15 or 16

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

Full Pass Criteria [5000 XP]: 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.

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: https://docs.google.com/forms/d/e/1FAIpQLSc_i6WnUcv2d8_8540UzV5eBjIovum0bQHcpjOpcaxM_aIroQ/viewform?usp=sf_link

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 29 or 30

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

Full Pass Criteria [5000 XP]: 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. ALSO, Travis-CI MUST be fully operational with working test cases in order to earn a full pass!

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 12 or 13

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

Full Pass Criteria [5000 XP]: 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.

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: https://docs.google.com/forms/d/e/1FAIpQLSc_i6WnUcv2d8_8540UzV5eBjIovum0bQHcpjOpcaxM_aIroQ/viewform?usp=sf_link

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 19 or 20

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.

Full Pass Criteria [30000 XP]: 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 poinot, 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: 52000
  • 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: 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: https://docs.google.com/forms/d/e/1FAIpQLSc_i6WnUcv2d8_8540UzV5eBjIovum0bQHcpjOpcaxM_aIroQ/viewform?usp=sf_link

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