Group Members:
Brad Timmers
Jeff McLamb
Kwan Skinner
Chris Arrington
Kirk Boyd

	Overall, our team project went very well.  Our client, Dr. Snoeyink, was 
pretty agreeable, and also very helpful in telling us exactly what he wanted in
the product.  Our team had excellent relations, and no one really argued about
anything.

	Our team does agree that scheduling was a difficulty.  It was hard to
estimate how long various parts of the project would take.  Also, meeting together
as a group caused some problems - our schedules sometimes conflicted during our
planned meeting times.  Distribution of work was probably our biggest problem, though.
There were times when one or two of the group members might seem to be doing all of
the work, and then there were other times when the other group members seemed to do
all of the work.  Basically, it was rare to find all of the group members busy and
sharing an equal amount of work.

	Class topics also did not seem to relate to the material we were doing on
our project at times, which caused some disappointment among group members.  One topic
we particularly wanted to see covered was version control, and that was not addressed.
Although our process of building worked for us, we probably would have done things
slightly differently given more information about version control.  We all worked on
the code in separate directories, and developed our own builds.  While this didn't
cause problems in terms of stepping on each other's code, it was tedious to have to
integrate the changes that everyone made into one build.  This also resulted in two
final versions, of which we have to choose which one will be our final product.  It 
would have been much nicer if we could have stored the code everyone was working on
in one place, and so then we would always have the most recent changes that everyone
had made.

	At the beginning of the semester, we faced several obstacles.  First, group
organization took longer than expected.  Also, decision on user interface tools and
learning of FLTK and OpenGL took extra time.  Added to the snow days, we had very
little work to do at the beginning of the semester, prior to spring break.  Basically,
all we did up until spring break was organize our team, meet with our client, and start
with the design process.  This caused some frustration because there just wasn't
anything to do.  Additionally, after spring break, we realized that we were probably
a bit behind schedule, and so did the majority of our work in the month following
spring break, which was very busy.  It was a little frustrating that the work was not
done in a steady process, with the majority done in a period of just a couple of weeks.
But, we think that this was just part of the learning experience because that is probably
how things will work in real-world team projects.

	Our team did agree that there were a few things that did not go as desired.
First, Dr. Snoeyink was sort of vague about coloring the map in the beginning.  It was not
until very late in the semester when he told us how the water on the map was supposed to be
colored, and Kwan had to rush to incorporate this new information at the last minute.
Testing presented a problem as well.  There was really no systematic way for testing our
product, as desired by our boss.  Our tool was basically just a map with user interface, and
user ability to select a region.  We couldn't really write a test program to thoroughly test
GISMO.  Coupled with the fact that we didn't really know what the map should look like for a
while, it felt like we didn't really know if what we were developing was supposed to be
correct.  Also, creativity was limited, as GISMO consisted of just a map and a very simple
user interface.

	Team GISMO had a good experience overall.  Our team had great communication, and did
not argue about anything.  Our client was helpful in laying out the specifications - he even
gave us primary and secondary objectives, as well as one tertiary objective.  Dr. Snoeyink
also helped us by telling us if we were on the right track in terms of drawing the map. 
Besides learning more about FLTK and OpenGL, we also learned how difficult scheduling a project
can be.  We were a little disappointed that our code would not work on another platform other
than SGI, as other platforms did not have the necessary GLX extensions to run OpenGL.  Also,
we learned how much documentation goes into a software product, as we probably wrote as much,
if not more, documentation than actual code.  As a result, we were disappointed that so much
time had to go into the manuals, leaving less time to improve our product and maybe fulfill
other secondary objectives.

	Our team experience was very satisfying.  Besides a few disappointments mentioned earlier,
team morale was very good.  We completed all of our primary objectives and also one secondary
objective of using GISMO for any map, and not just for Vancouver.  In addition to getting along
with our client well, team GISMO had no complaints or power struggles, and we were glad to have
worked on this project, and to have accomplished all that we had planned on doing.