This is a team assignment. My 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, I reserve the right to give different grades. A peer evaluation survey at the end of the project will help me to determine this. If the survey or my observations indicate the need, I may ask you to explain parts of your project to me.
Your SVN repository for this assignment is:
http://svn.csse.rose-hulman.edu/repos/csse221-201210-simulationXX
where XX is your team number given here. You should check out the
Simulation project from this repository, and all subsequent work should be placed in this project folder and committed back to your repository.
Milestone dates are listed in the table below. The 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.
| Cycle | Due Date |
Deliverables
(due at start of class on the given date unless specified) |
|---|---|---|
| Problem | Mon, Oct. 10 | End of class: Problem Statement, Screen Layouts |
| Cycle 0 | Mon, Oct. 17 | End of class: CRC Cards, UML Class Diagram, Cycle 1 User Stories |
| Cycle 1 | Thurs, Oct. 20 | Cycle 1 Status Report, Cycle 2 User Stories |
| Cycle 2 | Mon, Oct. 24 | Cycle 2 Status Report, Cycle 3 User Stories |
| Cycle 3 | Thurs, Oct. 27 | Cycle 3 Status Report, Cycle 4 User Stories |
| Cycle 4 | Mon, Oct. 31 | Cycle 4 Status Report, Final working software |
| — | Weds, Nov. 2 | Project Presentation |
| — | Thurs, Nov. 3 | Team evaluation survey |
Because you will need some time to prepare capsule presentations, I will let your team skip any one of Cycles 1-3 during the project. Just commit a file named CycleXskip.txt to your Design folder to let me know. In any case, the final project is still due on October 31. I do not plan to assign written homework during this time period, but there is an exam, and there will be about an hour of videos on C programming to watch to prepare for class on Oct. 31.
Reach agreement with your teammates on a two-sentence description of what you want to simulate/animate and what it teaches. Then describe how it meets the other requirements, namely how it will be interactive, how it could use multithreading, and what other data structure it will use. These can change as the program progresses, but we want to make sure that you are off to a good start. Once your instructor approves it, commit it to your repository under Design.
You should first decide as a team what features you'd like your program to have. Create a list of features, add it to your problem statement, and commit your project statement again. Then make some sketches of annotated screen layouts that show what the project looks like to the user and how the user interacts with the project.
You can choose whether to do the screen layouts by hand or electronically, as long as they are neat. Have your instructor check them off, and then refer to them as you do your design.
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.
Use your list of features and screen layout to brainstorm candidate classes
Your CRC cards (index cards are OK, nothing electronic)
Your UML Class Diagram, drawn using UMLet or a similar program. Save it in your Eclipse project, replacing the existing UML.uxf document in the Planning folder, and commit it. You should save also a pdf version of your UML diagram in your Planning folder.
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. Using a drawing program as an 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 start of each development cycle, you will commit a text document to your project repository listing the user stories that you plan to complete during that cycle.
You can use the existing documents in your Eclipse project, in the Planning folder, named “Cycle N User Stories.txt”, where N is the cycle number.
Commit the file to your repository.
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 221.
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 will 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.
We will post a team evaluation survey on ANGEL. You will receive individual points for completing the survey. I 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 me 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.
A team that delivers all of the milestones, well done and on time, and produces a project that meets the requirements in the overview will earn at least 80% on this assignment.