- All repos must be a part of the uva-cs3240-s20 organization. These are added through accepting classroom assignments through GitHub Classroom.
- Staff can delete/reset repos if needed. Contact Prof. Sherriff if needed.
- 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
- It's important to remember that we are using
travis-ci.org. So sometimes you will need to add flags like
--profor things to work correctly.
- You'll need to add a
.travis.ymlfile and (sometimes) a
requirements-travis.txtto your project to get it to hook up to Travis-CI properly.
- See the project at
https://github.com/uva-cs3240-f19/Staff-TextbookExchangefor an example of what the repo setup should look like.
- In the
.travis.ymlfile, you'll need to add your own deployment information. To do this, install both the
travisCLIs. Login to both in your terminal. Then run
travis setup herokuto generate the
deploysection of your
.travis.ymlfile. Note that everything is case-sensitive!
https://docs.travis-ci.com/user/deployment/heroku/for more information on using Travis-CI and connecting to Heroku.
Project Options and Requirments
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.
All projects must do the following, regardless of idea chosen:
- All projects must incorporate user accounts 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 one of the following third-party systems for login: Google, Facebook, or Twitter. Others, such as GitHub, may be accepted if approved by the staff and if the system makes sense in the context of your app.
- All projects must incorporate at least one more 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.0.2), build environment (Travis CI), source control management (GitHub), and cloud hosting (Heroku). No exceptions to these will be granted.
Project Option 1: TBD 1
Project Option 2: TBD 2
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 (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 within the first few weeks of the semester (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 (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 2/3 of the way through the semester (15000 XP)
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 (15000 XP)
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
During a lab toward the end of the semester, 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 ...