I Don't Know Cases

Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

I Don't Know Cases

Before you even start:

Plan out goals and have a time line from the first meeting.
Have a schedule meeting time that's good for everybody.
Keep your schedules free for the nights before each milestone is due...just in case.
Work individually even if none of your teammates ask you to.

M1: Design 1

Form your team early and make sure you have 3 other members who won't drop the class at the last minute. If you wait until the last minute, you may end up with only three members.
Brainstorm and set up your project early. Early planning will allow you to have a good structure and will make the other milestones easier.
Work together on the simple tasks so that everybody has an idea of how the program is coming together. When doing CRC Cards and Scenarios, it is a good idea to make them as a team rather than splitting them up among members.
As you work together on the cards, scenarios, assigning stereotypes, responsibilities, and collaborators, you will learn more about each as well as knowing exactly what each class you are planning to code will do.

M2: Design 2

In this milestone we split up the work, someone can take care of architecture and trust boundaries, another could build the UML diagram, and another can make the mock ups.
First however, you would want to discuss the Application and Utility Objects and create the new cards and scenarios together.
As said before, this will allow the whole team to understand how smalltalk and the program works and be able to split up and individually work on the other requirements on this milestone.

M3: Implementation 1

Now, to start coding! We met at the CoC together and started banging out code. For us, there was an initial learning code since this was the first program any of us had coded for smalltalk from scratch. Once we all got a feel for what -we were doing, we split up the work while collaborating on the main project files.
For example, one of us handles Goals, another CRC Cards, and another Scenarios. But at the same time, we all worked on the Project class and how everything would communicate with each other. This is where the planning in M1 and M2 came in handy.
SUnit tests were done at the the end of coding and basically one member started it and another expanded on it. There is great documentation on how to do SUnit that the professor pointed out.

M4: Implementation 2

Thanksgiving was a great obstacle for us. Make sure to distribute out work and try and work on the project before leaving for break. Instead of coming back full and coding in the CoC in the middle of the night, like us. Expanding on the code from M4, we knocked out UML and Roleplay in a night. We wouldn't suggest this. Also, keep UI in mind when designing these critical parts of the program.
We underestimated the difficulty in getting basic things to work in smalltalk. We had to fix some things from M3 that delayed working on M4. And since we didn't work over break, we didn't get to implement some of the things we planned to do from M1 and M2.
In summary, don't forget to include holidays in your time line!

M5: UI Evaluation

As a team, do one of the UI Evaluations while writing up the report. We think it's better to do these at the same time so you can write about the concerns you have with the other team's code while you experience it. This gives for better descriptions and suggestions that the other team can use.
Make sure the whole team knows how to do the evaluation the team choose. This way, everyone can contribute.
As soon as your done, e-mail the other team your report so they can get started on their rebuttal. We didn't get our report until the day before we had to turn in the rebuttal and it was only 3 paragraphs rather than 3 pages!
In the report, counteract every point the other team makes without being defensive. They probably have good points that would really help the UI in your program. And think of it this way, they are the user...so they know what they want and don't understand. You coded it so obviously you know how everything works...they're just like any other user that would use the program and have no idea how it works.

Good Luck,
Team I Don't Know