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. For example, adding a “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 (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). 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 Fall 2021 is: “As a UVA student, my life would be so much better if I just had ____.”

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: Assignment and Note Organizer

  • Users login to the system using Google login. They then can in some way record their schedule in the system.
  • Users can join classes with other students in the system, seeing who all is in each class.
  • Users can upload PDFs of notes that are then associated with the class.
  • Major tricky feature: Uploading and downloading PDF files
  • Possible APIs you should consider: Google Calendar, other scheduling APIs, file sharing services

Project Option 2: Off-Grounds Housing

  • Users login to the system using Google login. They then can in some way add information about themselves in the system.
  • Housing options are in the system. You do not have to allow for users to add new housing options, but you can if you want. Housing options need to have picture, location, and some form of information about the housing.
  • Users can rate / review housing in some way.
  • Housing can be found in some way by mapping / GPS.
  • Major tricky feature: Using GPS / mapping software
  • Possible APIs you should consider (beyond map / GPS as that is already included): image hosting service, Google Calendar for scheduling visits, directions API

Project Option 3: UVA Guide

  • Users login to the system using Google login. They then can in some way add information about themselves in the system.
  • Users can enter some information regarding “points of interest” around Grounds. This could be their class schedule with building locations, student services, or amenities.
  • This project can take on a few different angles depending on the type of “point of interest” you want to use.
  • Users can generate a custom map of some kind to help them navigate where they are going next.
  • Major tricky feature: Using mapping / directions software
  • Possible APIs you should consider (beyond mapping as that is already included): image hosting service, Google Calendar for scheduling your day

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, 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 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: September 12 or 13

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 September 12 or 13. The Scrum Master of each team MUST complete this form with the team as a part of the Sprint: Team Declaration Form. Also, Scrum Masters should initialize the team GitHub repo through GitHub Classroom at https://classroom.github.com/g/fYEuj00T. 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.

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.)

Sprint 2: Requirements Elicitation

Due: September 26 or 27

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: October 17 and 18

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…).

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: TBD

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: October 31 or November 1

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. 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: November 7 or November 8

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.

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: TBD

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: November 14 or 15

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.

Requirments 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 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: TBD

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