Project Information

Project Grading

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:

  • Exceeds staff expectations - Min XP: 50000 / Max XP: 55000
  • Meets staff expectations - Min XP: 40000 / Max XP: 50000
  • Lacking w.r.t. expectations - Min XP: 30000 / Max XP: 40000
  • Customer rejects software - 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

During Lab 10 or 11, 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. Teams can have one pre-evaluation during lab before the final submission of the project (we simply do not have the bandwidth to continuously check your projects).

After final projects have been submitted, no changes can be made to the GitHub repo or pushed to Heroku. Any changes that are found after delivery will result in a minimum 10000 XP deduction.

Login Feature

All projects must incorporate login as a part of the system. Users then must be able to do something in the system that is meaningful based on that login.

For the purposes of these projects, as they both relate to UVA students, we are requiring that you build in UVA email address login through Google Signin. To do this, you should use the python-social-auth library found at . This library was used by several teams last semester with good success, so we know that it is a viable, reasonable option.

Available Projects

Student Skill Matching

Ever wanted a way to find classmates who have a particular skill and are willing to help out folks in need? For this project, you will build a web app that students can create an account, post information about themselves, including what skills/expertise they have. Other students can then search on "tags" that will match up studnets with people that may be able to help.

This project was proposed as LinkedIn for Students in the 11:00 lecture and Tinder in the 3:00 lecture and were combined into this. The project can evolve in several different ways, but the core ideas here are:

  1. Students create accounts and post relevant information
  2. There is a search ability of some kind to find other students regarding whatever other students posted

Off-Grounds Housing Yelp

Finding the right place to live off-Grounds, not to mention who to room with, can be a tricky problem. This project will allow for the posting and rating of various off-Grounds housing options and possibly with a roommate matching algorithm.

This project was proposed in both labs with basically the same core ideas:

  1. Pictures, info, and rating of various off-Grounds housing locations
  2. Students create accounts to login to view, rate, and comment on these locations

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 as the Software Architect.

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 Sherriff or the TAs.

Major Artifact: Team Report, due at the end of the semester (10000 XP)
Evaluation Component: Average scores of other team members AND staff evaluation (20000 XP)

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 Document, due Monday, Feb 11 (20000 XP)
Evaluation Component: Average scores of other team members (10000 XP)

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: Test Plan, due late February or early March (5000 XP) and Beta Testing Document, due at the end of the semester (15000 XP)
Evaluation Component: Average scores of other team members (10000 XP)

Software Architect - The Software Architect is responsible for refining and documenting the overall design of the system. The team together should discuss how the system should be built (i.e. what should be a model? what page goes where? etc.) while the Software Architect drives this discussion. The Software Architect will create the Architecture Document, which consists of several architecture diagrams describing your system. Note that the Software Architect is not the "chief coder" and should not be saddled with the bulk of the coding. However, it is likely that the Software Architect is one of the stronger coders on your team, perhaps with some Django or web experience.

  • Reasons to be the Software Architect: You have used Django before and/or you are really interested in learning its ins and outs; you'd prefer to draw pictures rather than write a document; you are interested in the different components of a web-based software system.
  • Reasons not to be the Software Architect: You are uncomfortable with Python or web development; you are a "new coder" and don't have a good grasp yet on how systems are put together.

Major Artifacts: Requirements Document (which includes architecture diagrams of various aspects of the system), due in the middle of the semester (20000 XP)
Evaluation Component: Average scores of other team members (10000 XP)

Configuration Manager - The Configuration 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 Configuration 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 Configuration 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 Configuration 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: Configuration Document, outlining information about your setup and procedures, along with generally working components throughout the semester (15000 XP)
Evaluation Component: Average scores of other team members (15000 XP)

Team Assignments

See the Team Listings Excel document in Collab->Resources.

more ...