Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Group No. 9
Cases Page:
Team Members are:
Introduction:
Our project was broken into five milestones, and our goal was to create a slide show composed of images which you can edit and do sound manipulation with.
Links to the Descriptions of the Five Milestones:
Our Milestones:
- M3: M3GroupNo9.zip
- Group Timeline.doc: A calendar that lists the due dates of classes that are supposed to be completed, the group meetings, and the milestones.
- M3Class Descriptions.doc: A description of all the classes we wrote for M3; includes the description of the class, the attributes, and the methods.
- M3ClassDiagram.gif: Class diagram for M3 classes including GUI classes.
- M3CRCCards.doc: CRC cards that list the responsibilities and their collaborators of all classes except for GUI classes.
- M3Scenarios.doc: A list of scenarios that touch on every class and cover major functionality.
- Team Member Responsibilities.doc: A list of responsibilities of every group member.
- M4: M4GroupNo9.zip
- M4ClassDescriptions.doc: A description of all the classes we wrote for M4; includes the description of the class, the attributes, and the methods.
- M4ClassDiagramPart1.gif and M4ClassDiagramPart2.gif: Class diagrams for M4 classes including GUI classes.
- M4CRCCards.doc: CRC cards that list the responsibilities and their collaborators of all classes except for GUI classes.
- M4Scenarios.doc: A list of scenarios that touch on every class and cover major functionality.
- README.txt: Information on how to use certain functions in the code (how to use the UI).
- .st Files: Files that hold the code for M4.
- M5: M5GroupNo9.zip
- M5ClassDescriptions.doc: A description of all the classes we wrote for M5; includes the description of the class, the attributes, and the methods.
- M5ClassDiagramPart1.gif, M5ClassDiagramPart2.gif and M5ClassDiagramPart3.gif: Class diagrams for M5 classes including GUI classes.
- M5CRCCards.doc: CRC cards that list the responsibilities and their collaborators of all classes except for GUI classes.
- M5FinalSlideShow.st: The code for M5.
- M5Scenarios.doc: A list of scenarios that touch on every class and cover major functionality.
Advice for future Squeakers:
Importance of Design
- The design is very important. If you really work hard to agree on a good design, it will simplify the rest of the class.
- The best way to find a good design is through strong debate. Examine the reason for everything, and if you have an idea, lobby for that idea. Don't personalize the design. Don't feel like "Well, we used 3 of his ideas now we have to use someone else's idea." Use the best regardless of the source.
- With a good design, everything is a lot more simple. Make sure that your design would make your implementation easier and not make it more complicated.
- Don't get upset if your idea isn't used. All input is very valuable in the design. If you don't understand why the group thinks another idea is better, have them explain it until you understand. This will force every aspect of the final design to be examined closely.
- Know when to compromise. If the other group members understand your idea and still don't agree with it, move on. In this situation, arguing is not going to be productive and will increase group tensions for no beneficial reason.
- Do not care a lot about having a perfect design of the UI at the beginning. Make sure you have everything working and meet all the requirements for the project. If there is time left, then you can improve it and make it look better. This is one of the reasons why you should start early.
- A simple design is a very good design to begin with. If the group starts with a simple design, then all members can easily understand the base design. From this, the group will have more ideas coming from the members to improve the design.
- Time organization is very important in a group project. Try not to wait until last minutes to implement or test the design. Most of the time, we cannot think clearly under time pressure, so this will damage the design quality. Try to design the project early so you can fix the error or flaw with a better design (instead of hacking the design just to make it work).
Advice on How to be a Good Team
- Take advantage of the fact that there is more than one person to do the assignment. Having a group to complete the project has many benefits, but it is up to you to realize and use those benefits.
- Meet with your group often. Start meeting as soon as the project is given. This way, you can plan your other meetings and set up a deadline of when things are due. If you wait until the last minute, you will not have the opportunity to set up other meetings and deal with any problems you might have.
- Hope for the best, but expect the worst. Do not distribute out responsibilites to group members, go your own separate ways, and then meet the day before the project is due to put it together. More than likely, you will experience problems intergrating everything. Allow your group to have at least one weekend to fix everything that needs to be fixed after putting it all together in case you experience problems.
- Stay in touch with your group members. Make sure that everyone is doing what they are supposed to do. If you think that one person is not doing the work because he/she likes to wait until the last minute or needs some motivation to start early, set up meetings to code together in the CoC labs or somewhere else. You will feel a lot better when you know that you got started and you have completed some part of the task. You know that you will have to do it sooner or later, so why not do it sooner and leave the rest of time to handle problems or improve your code and design.
- Have someone in the group who is responsible and punctual be a contact person that contacts the TA, emails the group about meeting dates and other due dates, sends out reminders, and turns in the project.
- Even if you don't have to create a group timeline, create one because it can only benefit you. Set up due dates and meeting dates and stick to the schedule. If one person cannot make the meeting (which can happen a lot because with four people in a group, it is hard to come up with times that are good for everyone), do not cancel the meeting. Everyone else can go to the meeting and then inform the other member of what they missed.
General Advice
- Commenting your code in Squeak is very important. Unlike other languages that have APIs, the code comment is the only API that's available. You might think that it is a waste of time, but it will be very helpful when putting the code together.
- Explaining the type of parameter of a function and the way the function flows would be very helpful. Because Squeak is not a typed language, it's very helpful to know what kind of object is passed into a function. This way, we don't have to guess and wait until a runtime error is generated. It could save you a lot of time.
- Save your image often! Saving the individual functions is not the same as saving the image. Make sure you save often, especially before testing.
Link to this Page
- Cases last edited on 30 July 2011 at 2:33 am by r59h132.res.gatech.edu