1. Product Related Information

1.1 Current Status of the Product

Groundhog GDSViewer is a currently parsing GDSII files and drawing VLSI chips to the screen. We have imlemented user preferences that contain color data, alpha values, draw order, layer alias, z-depth, and z-position. These preferences can be saved, and also has a default preference that is loaded upon opening the application. We have also implemented a printing option that will allow the user to specify how large of paper and which printer they would like to print to. We have also provided an intuitive UI that allows the user to play around with the viewing of the VLSI chip that are applied on the fly. UI enhancements such as a solo mode, structure depth traversal, and a visability component for layers and structures.

1.2 Recommended Work

• Optimize drawing
• Add additional preferences
• Add additional UI enhancements
• Add 3d viewing capability
• possible texture support
• Code Optimization

1.3 Advice to Teams Continuing This Project

• The best advice I think we can give is to do more research on performance enhancing algorithms that can be applied to the current project. These include language types, image processing algorithms, and compatability between technologies.
• I would recommend that if any group were to pick up this project and to continue the biggest thing they should really focus on is trying to compress the objects into larger objects, or to find a way to minimize the calls to open gl methods.

2. Project Team Information:

2.1 Management Objectives and Priorities

1. Plan: Our plan is to provide our users a product that renders a VLSI chip in a clean, simple and understandable format. We plan on giving our user an easier method to understanding the chip, how it is stacked, in order to enhance there ability to design VLSI chips.
   • Result: Our team created a very powerful tool that renders a VLSI chip using alpha blending that supersedes the industry standard of using stipling patterns. We then paired that with an intuitive User Interface to give the user a more convenient and simple way of viewing VLSI chips.

2.2 Final Team Structure

1. Who was responsible for which tasks?
   • Tim was the OpenGL graphics guru. He was responsible for taking the GDSII data and rendering it using alpha blending techniques and providing a means for the user interface to allow for soloing layers, and choosing which layers and structures to render.
   • Scott was in charge of researching and implementing a print feature that would allow our users to not just print the chip, but allow the user to print the chip on any size of paper and scaling the chip data to fit those demands.
   • Josh worked on implementing a parser for the GDSII files, implementing a tree structure to view the structures inside of the GDSII object, and helped with miscleneous items on different parts of the product to get them functioning the way we wanted the product to work.
   • Curtis was our User Interface guy. He designed the main interface to allow the user to adjust settings of the GDSII object, provided an area to display the OpenGL graphics. This is the main hub for all of the different parts of our project talk to.
   • Adam worked on the user preferences, drag and drop features and GDSII parsing.
   • All team members worked on documentation.
2. Did you rotate any of the roles?
   • When it was needed each team member stepped in to fill the gaps. There was a good amount of overlap and each team member has worked on multiple parts of the product.
3. What would your team change about the team structure if you were starting all over with your current experience?
   • All team members performed their roles quite well, I don't think any of the roles would need to change.
4. What advice do you have for teams wanting to use the same structure?
   • Just find ways to split up your project without much overlap.

2.3 Schedule and Planning

1. Which aspects of your team's scheduling and planning procedures worked well?
   • Our scheduling and planning was based around the scheduled time for the class. We met two times a week and would report on any difficulties or needs.
2. Which problems did your team have with scheduling and planning?
   • There weren't any notable problems.
3. What tools did your team use to assist you in planning and tracking the project?
   • We used a bug management application called bugzilla, we used subversion for version control and email for communication.
4. How could your team have improved its scheduling and planning?
   • No change.

2.4 Support Functions

1. Discuss the effectiveness of your team's quality assurance.
   • Our QA managed to find quite a few bugs that we were able to quickly fix.
   • We made sure to do bi-monthly meetings with our client to demo the product. Doing so we were able to verify that we were meeting our requirements, determine the most intuitive ways to design our user interface and to verify the integrity of the graphic rendering.
2. What procedures did the team establish for defect tracking? How successful has the team been in faithfully using these procedures?
   • We used a defect tracking application called bugzilla. Bugzilla managed the bugs by severity, product and who was in charge of fixing each bug. All members were responsible for testing all parts of the application, and logging any bugs that they found. We did not use any written test cases, but we would test everytime a new feature was added.
3. What support function lessons did the team learn that would have helped if you had only known them earlier in the semester?
   • I think we could have benefitted from knowing that we would run into performance issues ahead of time and to look for performance hits.

2.5 Work with the Clients

1. How did your team's relationship with the client worked out?
   • The team-client relationship was very helpful. We kept in close contact to make sure that we were creating a product that was going to meet the clients needs.
2. What would you go back and change about this relationship to make it more effective?
   • I think that we managed the relationship very well.

2.6 Other Issues

• N/A

3. Feedback From the Mentors

N/A

4. Advice to Future Teams

1. Plan plenty of meetings with your sponsor
   • By planning meetings with your sponsor you allow feedback to be given while you are designing the product, which will help you from getting to far into implementing a bad design which will cost you time.
2. Play to the strengths of your team members
   • Each member of your group will have strengths that can benefit your product. While knowing your members strengths you can design your application to each of those strengths which is extemely helpful when you have a diverse team.
3. Pace yourself
   • Good code is not written over night. By pacing your code, you will allow for more thorough QA, cleaner and more succinct code.