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

Project Option 1: Civic Connect

Core Use Case: Users login to a system to generate email/letter templates for contacting their representatives about particular issues.

  • The system shall provide users with a listing of issues that the they can save with their account profile as issues they care about, along with location information, such as address and zipcode.
  • Users shall be able to select from a set of pre-made email, letter, or phone call templates that they can use to contact their specific representatives at the local, state, or federal level.
  • Users shall be able to submit new templates that can be approved by the site administrators (or some other similar process).

Project Option 2: Micro-Donations / Micro-Volunteering

Core Use Case: Users are part of a gamified system in which they can donate small amounts of money that can be divided up among multiple causes or small amounts of time that can be assigned to small tasks that people need help with.

  • The system shall present users with some gamified interface upon logging in.
  • Users can opt to give money (we will use a mock credit card API to simulate this) or to sign up to work on small tasks based upon their expertise.
  • Example: A user could donate $10 to the system, then using a widget like a slider, show how much money goes to each cause. A user could also volunteer 10 hours of time and in a similar fashion, allocate that time between tasks categories like “tech help,” “home repair,” “yard work,” etc. Tasks are then auto assigned to the user based upon tasks that were submitted to the system.

NOTE: It is possible to do just micro-donations or just micro-volunteering, rather than a combined system as described above, but the difficulty level (particularly with micro-donations) needs to be raised in order to be significant enough. Talk to the course staff if you have questions.

Project Option 3: Meet-Up Finder

Core Use Case: Using a map API (like Google Maps) and GPS of the user, the user can find meet-ups of various types of events, gatherings, etc. happening near them. Events are submitted to the system with information about the event, including it’s location for mapping.

  • The system shall allow a user to save a set of event types, causes, etc. with their account.
  • Upon logging in, the system shall show events within a certain GPS radius of the user taking place within a specific time range.
  • Users shall be able to search for events based upon time, type, location, cause, etc.
  • Users shall be able to submit events to the system for posting.

Project Option 4: Virtual Study-Buddy Finder

Core Use Case: Users set up their account with their interests, course schedule, what they need help with, what they can help others with, etc. The system then generates study buddies or study groups dynamically based upon similar learning needs and interests.

  • Users shall be able to save their course schedule with their account.
  • Users shall be able to identify where they need the most help and where they can help others.
  • The system shall automatically generate study buddies or study groups or the system shall allow users to form their own groups.
  • The system shall provide a mechanism for students to meet up virtually (no in person meet ups for this!). Options could include generating Google Meet links, a Discord bot companion app, managing Zoom IDs, etc.

Team Roles

Each member of your four 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

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

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 2 sprints during the semester. After those two chances have been used, a No Pass will remain as 0 XP.

At the end of each sprint, every team member must complete an evaluation of every other member of the team for part of your overall team evaluation score - https://forms.gle/De15cs89D5EvYJBC6.

Sprint 1: Project Skeleton

Due: Week of September 13-19

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/GzgS8yxrXyVKmUvSA. Also, Scrum Masters should initialize the team GitHub repo through GitHub Classroom at https://classroom.github.com/g/inb0EhTj. Please use your assigned team number for the identifier when prompted (e.g. 2-03). Other team members can then go to that link and accept the assignment, selecting the proper team.

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

At the end of each sprint, every team member must complete an evaluation of every other member of the team for part of your overall team evaluation score - https://forms.gle/De15cs89D5EvYJBC6.

Sprint 2: Requirements Elicitation

Due: Week of September 20-26

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]: (UPDATED SATURDAY, SEPT 19) 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.

UPDATE: The Requirements Manager must submit the Requirements Elicitation Document into Gradescope and make both the Requirements Elicitation Document and Project Management Spreadsheet available to the staff in your team Google Drive folder before your meeting with the TA on the week of 9/27-10/3.

Example Requirements Document from Spring 2020

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.

At the end of each sprint, every team member must complete an evaluation of every other member of the team for part of your overall team evaluation score - https://forms.gle/De15cs89D5EvYJBC6.

Sprint 3: Login Integration

Due: Week of October 4-10

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.

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.

At the end of each sprint, every team member must complete an evaluation of every other member of the team for part of your overall team evaluation score - https://forms.gle/De15cs89D5EvYJBC6.

Sprint 4: First Major Feature

Due: Week of October 18-24

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.

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.

At the end of each sprint, every team member must complete an evaluation of every other member of the team for part of your overall team evaluation score - https://forms.gle/oK5GUk7R6Mnfe4Ua7.

Sprint 5: Next Major Feature

Due: Week of November 1-7

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.

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.

At the end of each sprint, every team member must complete an evaluation of every other member of the team for part of your overall team evaluation score - https://forms.gle/De15cs89D5EvYJBC6.

Sprint 6: Beta Version

Due: Week of November 8-14

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.

At the end of each sprint, every team member must complete an evaluation of every other member of the team for part of your overall team evaluation score - https://forms.gle/oK5GUk7R6Mnfe4Ua7.

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.

After Sprint Check 6, the staff will tell the team at which level they believe the project is currently at, with specific suggestions to move to the next level.

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