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 16 (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, outlining information about your setup and procedures, along with generally working components throughout 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:
- 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
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 ...