Project 6: Ruby on Rails Project

Ruby on Rails Tutorial

Complete chapters 2, 3, 5, and 6 of the textbook. (If time permits, try the main bits of chapters 7 and 8 too.) See the syllabus for notes on textbook access.

Everyone in the group should complete this part of the project. Collaboration is permitted and encouraged! You do not need to submit anything for this part of the project, but completing it as soon as possible is highly recommended as it will help in completing the second part (i.e. the final project, below).

Final Project: Peer Evaluation Tool

Background

In classes with a team component, such as 3901, peer evaluations are important component of the grading rubric. The feedback from these evaluations is useful to the instructor for assigning a score to an individual student, as well as to the students for receiving constructive criticism from their peers.

A web application would streamline the collection, collation, and analysis of these peer evaluations.

Required Features

A user should be able to submit scores and comments for all of their teammates (and only their teammates). The application should support multiple peer evaluations over the semester (eg, for each project).
An administrative interface should provide the instructor/TA with an easy, intuitive way to populate the class with names and email addresses from a roster and also create the respective teams.
An administrative interface should give a useful view of the scores assigned within a team. This view should support the instructor's need to assign scores to individuals based on these evaluations, as well as quickly detect potential problems that warrant intervention.

Extensions

The following list is not exhaustive. The goal is to create as useful an application as possible, so the following are some challenges that could be addressed to that end. You are encouraged to think of other improvements that would be useful.

Authentication/login. Peer evaluations should be connected to an authenticated user, preventing forging of evaluations.
Admin dashboard to monitor submission of peer evaluations and simplify sending reminders or managing evaluations that are never submitted.
Support for multiple group structures. A student may belong to multiple groups simultaneously (eg a "project group" and a "technology team" as in 3901).
Changing enrollment. Students might add or drop the course and this should be handled cleanly by the tool.
Audience evaluation of presentations. A related, but different, peer evaluation is the feedback an audience provides for a presentation. This kind of evaluation is not quite the same as peer evaluation because it isn't an n-squared evaluation matrix of team-mates evaluating each other. Instead, it is the rest of the class evaluating n presenters. Is it possible to integrate this kind of evaluation seemlessly with the core functionality of peer evaluation described above?

Submission

There are 2 separate submissions for the final project, with different due dates.

Beta version release. By the due date of the final project (as indicated on the class web site), you must push a tag called "v1.0" to your github repo. Over the next several lectures, each group will have about 13 minutes to present their project to the class. In addition to giving a client-view demo (i.e., from the end-user perspective), this presentation should also describe the technical details of the design from an implementer's perspective (database schemas, architecture, etc). Your git repository should include documentation, the slides to be used for the class presentation, as well as the application itself.
Deployment. By 24 hrs after the end of the 3901 final exam, deploy your application to a service such as heroku. This way, the client can evaluate your project from their own machine/browser. You should push a tag called "v2.0" to your github repo corresponding to this second version of the project. Include a file called RELEASE-NOTES.md that indicates the major changes between this version and the earlier beta version.

Note: Your final project github repos will become public after the beta release. Thus, you will be able to borrow aspects of other groups' projects for improving your own (and vice versa of course). Your final project grade will be 70% based on the beta release and 30% on the deployed version.