Comp 145 Team Report
Team 12
Submitted to :
Prof. Greg Welch
May 1, 2001
______Mark Foskey (Technical Director)
______Joohi Lee (Quality Assurance)
______Bryan Crumpler (Librarian)
______Derek Hartman (Producer)
Overall Assessment
We believe that we achieved our baseline goal, but little more. We have a complete, functioning user interface that works for the stereo and mono versions of the program, and the tool can cast a shadow on the model (although, in that mode, the frame rate is very slow). One feature that goes beyond our client's original description of the project is that different tools have different appearances. That is, there is a claw for moving the object, a paintbrush for painting it, etc.
By one measure the project was already a success as of March 21, when the system was demonstrated to attendees of the Interactive 3D Graphics workshop. Response was quite positive.
Lessons Learned
We each learned a number of technical skills, including VRML file formats, texture blending, and Maya editing. Hence the technical director allocated tasks based on the personal interests, each of us could enhence the desired skill.
We learned how hard it is to follow a software schedule, although we were really aware from the beginning that it would be hard. Other course works, incorrect time estimation should have been taken into consideration.
Because our project consisted of several independent items, each person in the team were responsible for their own tasks, which did not require much communcation between team members. It allowed us to work efficiently, without spending time on waiting for other jobs to be done. In the other hand, the thought “not on the critical path” made us a bit lazy, which might be one of the reasons that we did not accomplish much more than the fundamental requirements.
Some of us were struck by how much overhead there is in trying to follow prescribed software development procedures.
One particular challenge with our system was that it was a maintenance project. The bulk of the software was already in CVS, and the technical director really wanted to use CVS for version control. However, the user interface work that had already been done, which we were to complete, had not been checked into the repository. Cleaning up the repository, and getting everyone access to it, was quite time consuming.
In addition, the system was already fairly large and complex, and a lot of our time was taken just learning what code to modify. We realized the importance of proper documentation, with which we could have saved plenty of time wasted understanding the program.
Next time…
If we had it to do over again, we would definitely try to decide sooner exactly what we were going to do. Misunderstanding client’s intention, and having a fuzzy image of the goal is fatal to the success of the project. We would have more discussion with the client at the beginning of the project, and make the goal clear.
What worked, what didn’t:
Concurrent work / Version Control – By using CVS as a version control system, our team was able concurrently work on the inTouch code. This allowed us to work much faster and on many different areas of the code then we would have been able to had we been manually partitioning the code work. It became apparent when listening to other projects end-of-term complaints that using a manual partitioning system on ones code tends to create a lot of problems when trying to put it back together. Though CVS required more overhead initially for our Technical Director to get it set up, we believe the benefits of this system far outweigh the penalties.
Client Satisfaction
We think the client is happy about the project in terms of basic requirements are completed. However, she would have been happier if we had finished shadow by I3D demo. We also think that she might be disappointed that we did not go much further than the minimum goal.