Sweet 'n' Salty Team Case

• Getting started early is always good. We were pretty good about meeting way before assignments were due to at least get a grasp on what we needed to tackle.
• Dividing work based on our strengths and weaknesses (Ami and Dan were better back end programmers, Matthew and Heather were better suited for UI/web front end)
• Everybody came to meetings and had a valid excuse when they couldn't. We all pulled our weight, albeit in different areas of the project.
• Our group was composed of four people who all four weren't friends at the beginning of the semester. There were no big arguments. :)
• Communication between team members was good. We never had to wait more than 12 hours for a response from anyone on anything.

• We should have been clearer at the beginning about who was strong in what areas. Luckily, we randomly divided tasks up with no big problems, but knowing everyone's strengths would have made it easier.

• Meeting at the CoC is far more productive than meeting at someone's apartment. We learned this after M5 – you get much more done when you're motivated to get out of the CoC. :)
• We should have probably had at least one CS major in our group – CM majors are rockstars (duh), but we think differently than CS majors, and that different perspective could have been useful.

• Structured our classes properly
• Team Sweet 'n' Salty (the most amazing CM team ever):

• Division of classes logically (Person, Project, Bug Report, and System were our major ones)

• We drew our UML on paper instead of using software. This made it harder to change later.

• Security checks on the type of user as opposed to different classes for different users
• SUnit testing

• Handling of developers – we didn't set it up right in relation to projects and we had to scramble at the last minute to fix this
• Some classes/methods were unnecessary; we had five different search methods which could have all been handled in one method.

• started work on M7 while doing M6

• using library chart widgets (BGOK)
• broke the GUI into smaller components as opposed to having everything on one screen

• The Projectes had a direct link to the UI to keep it actively updated when changes were made, which made the saving and loading of these instances not an option.

• Checked when the demo date was! We found ourselves in a crunch because we thought our demo was on Monday and it was really on Friday.
• We should have made a buffer class to take in update information from project and feed it to the UI so that the load/save feature would be fully operational.
• A few of the commands were guilty of feature envy as the UI didn't properly ask the system and just went straight for its data.

• Everyone evaluated the heuristics separately without influence from other group members, which really made it apparent what the problems were in the GUI we were evaluating.

• Waited until the last minute to write the first evaluation, even though we had heuristics done in plenty of time.
• Much of the UI was limited by knoweledge of the language, so things were kept simple.

• Things could have been more thoroughly looked at and explained.
• Further research into the features of UIs in smalltalk and visual works to create a more attractive and efficient UI.

• Created the web front end first and stubbed out all the pages we knew we'd need (this made it really easy to just pop the backend onto it)
• We structured our code really well so it was easy to put the front end on

• More of us should have gone to class the day that web programming was discussed. It took us 3-4 hours just to figure out the small differences between VisualWorks and a web environment.

• We could have had more team envolvement because only have the team implemented it.

Link to this Page

• Case last edited on 29 July 2009 at 11:50 pm by c-76-97-208-233.hsd1.ga.comcast.net