CS4500 Final Report

Team 5 - Groundhog

4/30/2009

· Product-related information

• Current status of product:
• All must have features have been delivered and tested
• Printer functionality has been verified on the Epson Plotter
• Optimization of OpenGL interaction is still needed
• Speed of Drawing GDS Objects is still a concern.
• Recommended work
• Figure out how to speed up interaction with OpenGL buffers
• Improve Zoom to Fit method
• Advice to teams continuing this project:
• Determine if SimpleOpenGlControl is the bottleneck
• Consider replacing OpenGlControl with another technology
• Use Java…  

· Project team information:  (Postmortum analysis)

• Management objectives and prioritories
  Plan: Our priority will be to produce a fully functioning viewer and printing utility. We will be focusing on the challenges surrounding the GDS II format in order to take full advantage of our limited time. We will break each functional module into sections and assign these to individual team members.
  
  Result: We accomplished the overall goal of the project.  There were definitely challenges with the GDS format, and making it render correctly.  We were able to break the work down into functional modules.  Some modules required multiple team members.
  
  
• Final team structure. In sections 2.2 and 2.4 of the Project Plan, you described your team's organizational structure and individual responsibilities. You have also revisited this issue in some of your activity reports. Describe the team structure at the end of the semester:
• Did you rotated any of the roles? - The team roles stayed the same
• Tim – OpenGl Guru, Drawing module
• Josh – Team Leader, PJM, UI Dev
• Scott – Print module, OpenGl interaction
• Adam – Webmaster, UI Dev and QA, Release management
• Curtis – UI Dev and QA
• Pretend you are just starting the project armed with your current experience. What would your team change about the team structure (if anything)?
• Nothing, we all worked well together
• What advice do you have for teams wanting to use the same structure?
• Pick one person to be responsible for documentation tasks, leave the coding to the rest of the team.
• Be sure to keep the coding team members communicating throughout the project
• All team members performed very well given the scope and duration of this project.  We all experienced lows and highs, but the team really came together to ensure that our product was completed successfully.
• Schedule and planning:
• Which aspects of your team's scheduling and planning procedures worked well?
• Having 2 team meetings during the week allowed the team to stay in synch and gave us all open weekends to accomplish coding tasks.
• Which problems did your team have with scheduling and planning?
• No problems came up.  The final presentation with our sponsor was cut a bit close, but we got it done.
• What tools did your team use to assist you in planning and tracking the project?
• Google groups and email
• How could your team have improved its scheduling and planning?
• We could have leveraged a more professional tool like Microsoft Project to set milestones and deadlines.  Luckily, the course structure really helped to enforce this for us.
• Support functions:
• Discuss the effectiveness of your team's Quality Assurance and Configuration Management functions.
• QA was pretty straight forward.  All of the UI elements had easily tested functions. 
• Code reviews occurred regularly to assist in keeping bugs out of the final product.
• What procedures did the team establish for defect tracking? How successful has the team been in faithfully using these procedures?
• We set up a Bugzilla database
• Most bugs were detected and then fixed by the person that found them
• What support function lessons did the team learn that would have helped if you had only known them earlier in the semester?
• We needed to start tracking bugs and issues earlier in the project.
• Work with the clients:
• How did your team's relationship with the client worked out?
• Working with Erik was great.  We learned a lot about GDS, and what makes it so interesting to study.  We met biweekly to ensure that we were working on the most important aspects of the application.
• What would you go back and change about this relationship to make it more effective?
• nothing
• What could the instructor have done to make the client-team contact more effective?
• nothing
• Work with project mentors.
• Discuss your team's experiences with the project mentor arrangement.
• We  met with an OpenGl expert, and tried to implement some of the options he provided.
• What advice does your team have for how this program can be made more useful from the point of view of the student teams?
• Start meeting with an expert sooner.  No matter your level of expertise, there is someone that can help.
• Other issues. Bring up any other issues from your team's experiences that should be recorded in this forum. 
• The size and scope of the project was really unknown at the outset.  Having some predefined, previously attempted projects may help some teams accomplish more in the timeframe.
• Professor sponsored projects are highly recommended.  All students should attempt to work with one of the professors on their project.  Even if you haven’t taken any classes taught by the professor, you will learn a great deal from the interaction.  

· Three general pieces of advice to future teams as they start out.

1. Pick a project with a Professor sponsor, or do your own. External sponsors will not likely have nearly as much time to interact with you.

2. Make sure that you know what your team’s strengths and weaknesses are. Be honest, and don’t forget things like how busy you are during the week.

3. Pick the person that is responsible for all team documentation up front.  Have all team members post their logs before that person starts on the WMR.  This will allow the rest of the team to focus on the coding aspects of the project.