Project 5 grading

README.md → project-5/README.md

@@ -24,6 +24,8 @@ of Least Astonishment, since a List is typically understood to contain more than
 
 In both of these cases, we decided that the usefulness of the Playable class in its current form outweighed these concerns.
 
+_In discussion with team members, I agreed these were reasonable choices._
+
 #### Include an estimate of your velocity. How many story points did you estimate you would complete during this assignment? How many did you actually complete, how many person-hours did the team spend, and what is the ratio of points/person-hour? I want you to monitor your velocity to help you plan better ovehttps://classroom.github.com/g/3Hlr8BQmfr the final iterations. There are no "good" or "bad" numbers for velocity.
 
 We did not compute an initial estimate of story points, but we did exceed our expectations by completing the assignment
@@ -36,3 +38,5 @@ We paired-programmed each time our group met, swapping partners during each sess
 Each team member was a developer and designer. On this project, we were easily able to schedule times to meet as we went, but on future projects we may want to block off a regular coding session each week so that we have to coordinate less. 
 Overall, paired-programming worked incredibly well to write quality code quickly. We also all realized the value in spending a signficant amount of time designing before coding--we knew better where we were going from the beginning. Nevertheless, there were some times when the two pair-programming teams did not commuicate effecitvely and ended up with small conflicts that we had to resolve after the fact. We will hold more frequent chek-ins between pairs about each pair's responsibilities,
 in particular after a pair commits their code.
+
+_This is a common problem in agile software development! You might consider instituting a regular [Stand up meeting](https://en.wikipedia.org/wiki/Stand-up_meeting)._

project-5/rubric.md

@@ -0,0 +1,63 @@
+# GRADE: 63/64 
+
+_Well done!_
+
+## Functional and implementation requirements: 34/36 points total
+
+Earned|Possible|Requirement | Comments
+------|--------|------------|----------
+1|1| Add two new menu items to the Edit menu called Group and Ungroup.
+4|4| When the Group menu item is chosen, all selected note bars are grouped into one gesture. A gesture behaves as if it is just one note bar with a complex sound to it.  If nothing is selected when the Group menu item is chosen, nothing happens.
+2|2| Selecting any note in a gesture causes the same thing to happen to all the others in the gesture.
+2|2| Unselecting any note in a gesture with control-click causes the same thing to happen to all the others in the gesture.
+2|2| Drag-selecting over a gesture consistently selects or unselects all the notes in the gesture.
+2|4| Dragging note bars in a gesture moves or stretches all notes in the gesture. |_I'm unable to stretch notes within a gesture, but I gave you points for the "stretch goal" below._
+3|3| Gestures are indicated visually by a thin black dotted line around the group of note bars. 
+1|1| A selected gesture is indicated using a style similar to that of a selected note bar.
+4|4| Gestures can include note bars or other gestures (that is, gestures can be nested).
+4|4| When the Ungroup menu item is chosen, the selected gesture is ungrouped. Note that nested inner gestures are not ungrouped; you have to ungroup the nested gestures separately after ungrouping the outer gesture.  If no groups are selected when Ungroup is chosen, nothing happens.
+1|1| After selecting the Group menu item, the new gesture becomes the only selected item. 
+2|2| After choosing Ungroup, all the inner notebars and gestures of the ungrouped gesture are selected.
+
+### "Stretch goal" - 2 points
+
+Earned|Possible|Requirement | Comments
+------|--------|------------|----------
+2|0| When the right edge of a gesture is grabbed and stretched left or right, the duration and offset of everything in the gesture should stretch proportionally. 
+
+### No regressions - 1.5/2 points
+
+Earned|Possible|Requirement | Comments
+------|--------|------------|----------
+3.5|4| All prior requirements are met, unless they have been superseded by new requirements. | _Platform independent keyboard shortcuts_
+
+### Release tag - 2/2 points
+
+Earned|Possible|Requirement | Comments
+------|--------|------------|----------
+2|2| The release is tagged as project-5-release.
+
+## Reflection - 11.5/12 points
+
+For project 5 and beyond, I will expect your discussion of design and elegance to refer explicitly to design principles we have discussed in class.
+
+Earned|Possible|Requirement | Comments
+------|--------|------------|----------
+3|3| UML 
+2|2| Design overview
+2|2| What is elegant?
+2|2| What is not elegant?
+0.5|1| Velocity |_Not computed but you reflect on it
+1|1| Collaboration statement
+1|1| Team retrospective
+
+## Elegance - 12/12 points
+
+I looked at your UML diagram to assess the elegance of your class design.  You will get a grade for class design starting with Project 6.
+I spot-checked a new class (Gesture) and a modified class (TuneComposer) to assess method-level design and self-explanatory code.
+
+Earned|Possible|Requirement | Comments
+------|--------|------------|----------
+0|0| Class design | _Reconsider the contents of the Playable interface with an eye towards the SOLID principles. It's also surprising that an interface named Playable has no method play()!_ _See also GitHub Issues._
+8|8| Method design | _Looks good. Most of my concerns were at the class design level, not the method design level._
+4|4| Self-explanatory code | _I asked for Javadoc on the ```Playable``` interface, but that is not one of the two classes I listed above._