View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Team Phoenix Cases

Team Analysis

What Worked

The best aspect of our group was that everybody on the team was focused on trying to build the best project possible. Most of the time we were able to detach ourselves from our ideas and debate the merits of different layouts and models. We focused on building a quality application and thought about what we could do to accommodate future changes that might happen. We also managed to organize the files in our project well; we used the wiki to store scenario documents, candidate classes, UML diagrams, and the like, and used the Visualworks built-in Store to manage the different versions of our project.

What Didn't Work

It was sometimes difficult to get work done because of our strong opinions. At times we were defensive about our ideas, and we argued more than once about how the project should act and look. We eventually put these differences aside, but it cost us valuable time whenever we focused on winning arguments instead of finding the best solution.

What Could Have Been Better

Because everyone was so busy, it was hard to meet as a group. We attempted to set up consistent times for meeting as a group, but we were never able to get everybody together on a regular basis. If we had succeeded in establishing consistent meeting times, we would have had more focus as a group towards the end of the project. Also, defining certain roles in our group (such as leaders, organizers, etc) would have saved us even more time, as such roles would have put more pressure on us to be prepared for our meetings.

Project Analysis

M1

What Worked

As a group, we had a lot of designs that we wanted to use for the project. We keep thinking and improving upon the design, and were always looking for ways to make things better. We also designed the whole application from the start, including complete classes that we would use for extra credit. We planned for everything hoping to accomplish everything, but designed the project so we could remove extra credit functionality if necessary. The part of this milestone we focused on the most was the scenario list, which we did an excellent job creating. We went through four different scenario iterations, each being more defined and user friend. Over time, we resisted the urge to use programming jargon in our scenarios. We started with a detailed and technical way of completing a task and dumbed it down to the layman's level. As we continued to improve our design, we abstracted classes and focused on making all aspects of the application as modular as possible.

What Didn't Work

We didn't have any structure to our ideas and our meetings. It took a long time to discuss our vision on how we wanted to project to be. A group member would often explain his vision of the design of a certain section of the application, but it would be a couple of days before the other group members would finally realize what he was talking about. Also, since we were trying to design a program designed to design other programs, it was always confusing to decide whether someone was talking about physical CRC cards or the CRCCard classes & objects.

What Could Have Been Better

Again, better communication and more planning would have increased the amount of work we got done at meetings. We should have written down our ideas before group meetings, allowing us to focus on debating the merits of our designs instead of trying to understand what a group member was talking about.

M2

What Worked

We continued to go through different designs. We also went back to M1 and continued to change and improve our analysis phrase. We were fortunate to come up with a strong and modular design, so we could take and remove features from the application depending on whether we had time to implement them or not.

What Didn't Work

All of the troubles we experienced in M1 came back in M2. In addition, we started to get into a bad habit of not assigning an even load of work for each group member. We would have group members asking what they need to do because they were done with everything while other group members continued to work on their more extensive portions of the project. Overall, everybody did an even amount of work, but there were long stretches of time where some members had nothing to work on.

What Could Have Been Better

We could have done a better job of giving everybody a consistent amount of work for this milestone instead of simply having members do whatever work was available.

M3

What Worked

Since we had a solid design, we were able to knock out the domain models relatively quick. We also had the capacity to assign the project into individual parts. For example, one member focused on the look and feel of the UI, another on hooking up the UI to the model, and another still focused on building the model. This division of responsibility allowed us to quickly and easily finish this milestone.

What Didn't Work

Although our design allowed us to split up and work on the code, we should have constantly been in communication with each other. There were still some discrepancies in how exactly we planned to implement the domain model, and the ways some methods were implemented could have caused some tests to fail and some exceptions to be handled incorrectly.

What Could Have Been Better

A more descriptive plan on how exactly to implement the domain model and better communication of ideas would have enabled us to do a better job assigning tasks to each of the group members. Also, having a better idea on how long each component would take would have allowed us to prioritize more than we had, as the UI took far longer to complete than the domain model.

M4

What Worked

The experiences we had in this milestone were pretty much the same as the experiences we had in M3. Our strong design allowed us to add and remove features at the last minute without impacting the rest of the program, and we were able to pull everything together even though we weren't always together in the same room.

What Didn't Work

The biggest problem with M4 was getting the GUI to work. We were still able to split the project up to individually, but we also had a problem assigning tasks according to how hard they were. Also, we were getting bogged down with other classes, so we had the least amount of time to work on this milestone.

What Could Have Been Better

As before, splitting up the work more evenly would have helped us tremendously.

M5

What Worked

We were able to come to a conclusion quickly about the format of the report, and group members were able to follow through on getting the evaluations done. Overall, there were very few problems with the evaluations.

What Didn't Work

There was some confusion to what exactly was required for the evaluations, so our cognitive walkthrough may not have met all of the exact requirements of a cognitive walkthrough. Also, most of the work in this stage was done by one person, with others only helping out with menial tasks.

What Could Have Been Better

Dividing up the project into several different pieces would have made this milestone into a trivial affair.

Link to this Page