This is a team assignment. Our intention is not that you “divide and conquer” as much as that you have people to talk with as you write and test this program.
Everything that you submit for this project should be understood by all team members. It is your responsibility to (a) not submit anything without first discussing it with your teammates, and (b) not let something your teammates write go “over your head” without making a strong effort to understand it (including having a teammate explain it to you, of course).
Usually all team members will receive the same score for this assignment. But if there is ample evidence that one person did not fully participate in the learning and the doing, we reserve the right to give different grades. A peer evaluation survey at the end of the project will help us to determine this. If the survey or our observations indicate the need, we may ask you to explain parts of your project to us.
Milestone dates are listed in the table below. This rest of this section describes the artifacts due at each milestone. Follow the instructions carefully. Your team may want to print a copy of this document, highlight the key things to do, and check them off as you do them.
You must use the object-oriented design technique discussed in the book and in class to generate CRC Cards and a UML Class Diagram for your project. Name your class with the main() method Main.
Before brainstorming candidate classes, you will probably find it helpful to do two things. First, decide as a team which features sound most interesting to do and which you'll want to do first (cycle 1). Second, make some sketches of potential screen layouts for your project. See the Overview section above and the Features section below for additional information on the responsibilities of your program.
Complete your initial UML Class Diagram based on your CRC cards for your project. Name your class with the main() method Main.
You must draw your UML Class Diagram using UMLet.
Short development cycles are a key feature of Extreme Programming. This is especially useful for projects where the development team—that’s you—is unfamiliar with the problem to be solved. At the start of each development cycle, the team negotiates with the customer on the work to be accomplished during that cycle.
The customer suggests user stories to be completed. These are short, often one sentence, descriptions of what the user would be able to do with the software. For example,
User launches program and sees a blank drawing area and some buttons representing actions that could be taken.
This story doesn’t say anything about the buttons actually working, so that is not part of this user story. A user story for a button working might be something like,
User clicks the Rectangle button and can then draw a rectangle in the drawing area by clicking and dragging the mouse.
User stories are powerful in two important ways. First, they make it very clear how to test whether the story has been completed. Second, they keep the development team focused on the importance of meeting the needs of the user.
After the customer has suggested some user stories for the cycle, the development team will decide whether it is reasonable to complete them all in the time available. If not, the customer will withdraw some of the proposed stories until an achievable set of stories is agreed upon.
For this assignment you’ll play both the customer role and that of the development team. As a customer, the number of features completed will help determine your grade (and how much fun you have with the project). As a development team, you’ll have to do the work to implement the user stories.
Each user story should have an estimate in ideal development time (likely between 30 mins and 4 hours). Calculate the total estimated time for this cycle and include it at the end of the list.
At the end of each development cycle, you will commit a text document to your project repository that lists the user stories and estimated times, then add the actual time you spent on each. Indicate either that you completed all of the user stories for the cycle or else list any user stories the team planned to complete but was not able to. Briefly state any complications that prevented you from completing the stories, for example, “We underestimated how hard it would be to implement mouse dragging.”
You can just modify the document named “Cycle N Status Report.txt”, where N is the cycle number just completed, in the Planning folder. Commit the file to your repository.
You should be using good process as you go. Thus, for each cycle, your code must run, have good style and complete documentation. It should also have no other warnings, but sometimes these are inevitable (like if you have declared a variable you will use in the next cycle).
You must also complete the brief evaluation in ANGEL identifying areas of improvement for your team.
We’ll grade the version of your software committed to your repository at the final-working-software deadline. Your code should be well-commented and should use appropriate class, method, field, and variable names. No Eclipse warnings should remain for your final code according to our standard Eclipse preferences for CSSE 220.
Commit your code often. And don’t forget to update your code before working and before committing. The chances of SVN conflicts grow exponentially with the number of team members, but they decrease with the number of lines of code in the project. The net result is that you’ll have more trouble at the beginning of a project. For this reason it makes a lot of sense to program as a group or to carefully work on completely different classes in the beginning.
Your team will give a 10 minute presentation on your project, which may be open to the Rose-Hulman community. Your goals for this presentation are:
Every team member should play a significant role in the delivery of your presentation.
Keep in mind that all of us have implemented the same basic project, so you won’t have to spend much time describing the basics of the project.
We will post a team evaluation survey on ANGEL. You will receive individual points for completing the survey. We will also use the survey results to help decide whether to give different assignment scores to different team members. Perhaps most importantly, the survey results will help us identify where you are doing well as a teammate and where you can improve. Along with this is an individual reflection. It helps you introspect on what went well in the project and how you can do even better on your next project. You will be graded on the thoughtfulness of your answers.
The specification lists the features that your program is required to have and several potential additional features. An “A” project would include all of the required and additional features. A team that delivers all of the milestones, well done and on time, and produces a project that correctly implements all the required features will earn at least 70% on this assignment.