View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Team Asterisk - M3 Case Study

The Assignment
For M3 we had to design the whole thing. The design had to include:
  • Scenarios that touch on every leaf class in the system
  • CRC card analysis for the entire system (for every future milestone)
  • A test plan corresponding to the CRC card analysis, based in indentification of equivalence classes in the input.
  • UML class diagram for the entire system with descriptions for each class.
  • Description of what each team member is going to be responsible for what
  • Internal group timeline with dates and milestones

Our Approach
The first thing we did was to give every team member a couple of days to review all of the milestones in detail before we actually talked about anything. Since there were 4 more milestones and we had 4 group members, it was tempting to let each group member focus on one milestone apiece (while at least being familiar with the rest). After taking a closer look, we saw that milestones 4 and 7 both were GUI-intensive, while milestones 5 and 6 were more algorithmic in nature.

We decided it would be wiser to group 2 people on each type of milestone, so Matt and Derek analyzed 5 and 6 while Neeraj and John took on 4 and 7. Even with the 2 person teams, it still ended up where one person would focus more on one of the 2 milestones assigned to the pair.

The group members focusing on the different milestones were basically to come up with the scenarios, then the CRC cards, then the UML. Of course, the entire process isn't necessarily linear, so modifications were made to any of the design elements as necessary.

The Design
CRCs and Scenarios (PDF file)

UML

What Went Well
It turned out to be a pretty good idea to let individual team members focus more on certain milestones (while still staying informed about the rest of the project). When we would get to the milestone that a particular person had focused on in the design, they were able to take the lead and work out what all the group had to do. This helped to evenly distribute the workload over the course of the semester.

It was generally a good idea to start with scenarios, because from there you could draw up the CRCs, then the UML. The CRCs were semi-helpful, mainly in deterimining what classes and which we could discard. Once we had the list of classes, we basically never looked at the CRCs again.

The UML was probably the most helpful of all the design elements we had to generate. We continually referred to (and heavily modified) the UML diagram as we reached each milestone.

What Went Bad
For the most part developing the design was fairly painless. As we progressed through the semester to each design, it was sometimes regrettable that we didn't go into further detail on some of the design, the GUI in particular. But that is difficult to do when it is the beginning of the semester and you don't know a thing about Squeak GUIs (But a design should be language independent, right? Well, it doesn't always work out like that).

Synopsis
What worked for us when designing our project:
  • Divide up the workload, but make sure everyone is familiar with the material as a whole. This has benefits as the semester progresses and different team members are "experts" at certain aspects of the project. This also keeps the workload over the semester fairly evenly distributed, without having a project almost entirely designed and coded by 1 or 2 group members.
  • Start with the scenarios, go from there.
  • CRCs can actually be useful!
  • Think things through as thoroughly as you are able, you'll be glad you did when you can add each milestone in without breaking your entire project.


Link to this Page