• Home
• Documents
• Logs
• Development
• Deliverables

---

• Email Team
• Email Tony
• Email Brandon
• Email Travis

Team BLT
CS 4500
April 24, 2008
version: 1.0

Final Report

1.0 Product-Related Information

• 1.1 Current Status of Product
• Product is fully functional - Our improvements were done to an existing product.
• Product has been thoroughly tested - although we anticipate the existence of bugs from original code base.
• Product still has list of remaining improvements that we were not able to get to because of time restraints. With more time to investigate the product, we suspect we would find more places to improve the program user interface.



• 1.2 Recommended Work
• Our work foucused primarily on the first layer of the user interfrace, there is more work to be done in the deeper layers of the program.



• 1.3 Advice to Teams Continuing This Project
• We focused on the first layer of the interface. It would be a good idea to look further improvements deeper down. The functionality of the tools that manipulate the scene need to be overhauled. They should be changed so that they work like every other application in production. Right now they have a very strange implementation of tools such as resize, rotate, etc. Reorganizing the location of the icons for the tools would be more intuitive. Instead of focusing on adding new tools and features you should focus on improving and modifying the existing functionality.

2.0 Project Team Information

• 2.1 Management Objectives and Priorities
We began this project with management as one of our major objectives. As the project evolved and we ran into certain hang-ups with our would-be sponsor it was our tight schedule and weekly checkups that kept the project from derailing. The project was clearly divided and assigned to each of the team members and we were able to keep our priorities together as the project progressed.


• 2.2 Final Team Structure
Our team structure remained throughout the semester as planned in the beginning. Each of our members were assigned and fulfilled the duties as outlined. Looking back its easy to see that the roles picked in the beginning of the task were the roles best suited to the individual members of our team. Our only advice for any other teams using the same structure is to make sure that everyone knows what roles they are getting into when they begin the project.


• 2.3 Schedule and Planning
• At the beginning of the semester (when we still had a sponsor) we had a rigorous schedule to meet with the sponsor and work on the project onsite. This was difficult to do with other classes and work, but it ensured that we met together often. After that we were on a much looser schedule. Weekends worked out best for us to get together because the week nights were pretty tied up with other things. We utilized GoogleDocs to help us all keep track of the project status. It is a very simple tool, but it worked great for us. We were able to keep track of bugs and priorities. You did not ever have to wonder what to do next because it was all spelled out in a spreadsheet. It also helped us ensure that two people were not working on the same task because we could assign them to a team member. We could have improved out scheduling by meeting together a bit more often (although we do not think our work was hindered by too infrequent of get togethers). Scheduling the weekends to get together proved to be the most successful to us though.



• 2.4 Support Functions
• Our quality assurance was a very simple process which helped us to keep us with it. We utilized GoogleDocs for bug tracking as well as other stuff. That was helpful because then everyone knew when someone had finished a task and it was ready to be tested. Anyone on the team (other than the one who fixed/implemented it) could test it and verify that all was well or log bugs on issues encountered. The bugs would immediately to visible to everyone. It seemed to provide pretty quick feedback to the developer. It got everyone involved in the QA process too. It worked well for us.
• We did a pretty good job of keeping the bug tracking up to date. Other team members were pretty good about testing the changes made by one another so that if bugs were overlooked you would receive quick feedback and be able to fix it while it was fresh in your mind.



• 2.5 Work with the Clients
• 1. Client Relationship:
  Our client relationship started off really well, but turned out bad when they decided to cancel our project officially. However they cooperated in letting us continue to work with their source code and make our own changes.
• 2. If we could do it all over:
  While the people we worked with were very nice, I think we would opt to do a project that was not sponsored by a company. They made a business decision to cancel the project, and it really altered our overall experience.



• 2.6 Work with Project Mentors
• We did not have any project mentors.

3.0 Feedback From the Mentors

• We did not have any project mentors.

4.0 Three General Pieces fo Advice to Future Teams as They Start Out

• 1. Pick a project that interests you – Spending and entire semester planning and carrying out a project is much more enjoyable and easier if its something you care about and would be interested in continuing in the future
  2. Do something useful – Web apps are great, and can be quickly put together, but you’re not going to impress anyone with your php/mysql implementation. Work in current industry languages, nothing looks better on a job application then actually having a working piece of code in the language that the company is working in.
  3. Plan Plan Plan – Having a good project schedule will save you much more time than it takes you to make.

Date	Version	Description
April 24, 2008	1.0	Create Final Report