Project Information

Infrastructure Information

GitHub

  • All repos must be a part of the uva-cs3240-f19 organization. These are added through accepting classroom assignments through GitHub Classroom.
  • Staff can delete/reset repos if needed. Contact Prof. Sherriff if needed.

Heroku

  • You only need to use free accounts for Heroku for this semester.
  • You should not need to provide a credit card.
  • Choose one person to host the project for the team. That person should go into Heroku and create the project.
  • Under Deploy, connect this Heroku app to the appropriate repo on GitHub.
  • Then turn on automatic deploys and check the box "Wait for CI to pass before deploy." This will start the process of connecting with Travis-CI.com

Travis-CI.com

  • It's important to remember that we are using travis-ci.com, not travis-ci.org. So sometimes you will need to add flags like --pro for things to work correctly.
  • You'll need to add a .travis.yml file and (sometimes) a requirements-travis.txt to your project to get it to hook up to Travis-CI properly.
  • See the project at https://github.com/uva-cs3240-f19/Staff-TextbookExchange for an example of what the repo setup should look like.
  • In the .travis.yml file, you'll need to add your own deployment information. To do this, install both the heroku and travis CLIs. Login to both in your terminal. Then run travis setup heroku to generate the deploy section of your .travis.yml file. Note that everything is case-sensitive!
  • See https://docs.travis-ci.com/user/tutorial/ and https://docs.travis-ci.com/user/deployment/heroku/ for more information on using Travis-CI and connecting to Heroku.

Project Ideas

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

Common Requirements - LOGIN AND ENVIRONMENT

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

  • 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, such as account management, save favorites, etc.
  • All projects must use some form of third-party system for login. In other words, you cannot use the Django-included default user management system. The best option is to use Google login, as that can be used with UVA student accounts, but other systems may be more appropriate depending on your design.
  • All projects must be built using the prescribed language (Python 3), framework (Django 2.2.5), build environment (Travis CI), source control management (GitHub), and cloud hosting (Heroku). No exceptions to these will be granted.

UVA Craigslist

It's Craigslist, but made for UVA students. Basically, there should be some functionality for buying and selling things. We would expect that posting pictures of items would be a part of this. Also some sort of messaging system. Some functionality akin to using the Google Map API to show where items need to be picked up would also be good. Something beyond the "usual Craigslist" interface is absolutely required. Your have to put your own take on this concept.

Ride Share

You want to go to a place. Other people do to. One of you has a car. You don't necessarily know each other. The system should allow for people to set up trips and for students to sign up to join. Mapping functionality is pretty important here. Do not incorporate actual payment in the system, but mock payments are welcome.

Shopper Share

One person volunteers to be the "master shopper," or whatever you want to call it. Folks then all add their items to a single grocery list. The master shopper goes to the store, buys everying, and then can break the master list into smaller lists for distribution. Indicate how payment would be done (including "tipping" the master shopper), but you don't have to hook up to actual payment systems.

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 + team management evaluation (15000 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, September 23 (15000 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 October 3 (5000 XP) and Beta Testing Document, due at the end of the semester (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: Architecture Document (which includes architecture diagrams of various aspects of the system), due November 4 (15000 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 (due November 18), outlining information about your setup and procedures, along with generally working components throughout the semester (15000 XP)

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.

more ...