4/19/2008

• Team: Diamond Cutters
• Project: Diamond Airport Parking Suite
• Members: Kem Elbrader, Chris Fahim, Spencer Burgoyne, William Trang

1. Product-related information:

Current status of product

Diamond Airport Parking Suite is fully functional and is ready to be installed at Diamond Airport Parking. However we still need to go back and update our database to include Diamond's latest entries, which include claims, customers, and employees.

Recommended work

The suite can be enhanced in the future based on any needs Diamond may require as they expand. Such as adding new fields for any other services they may want to offer or any data reporting. Also there are two menus made in Macromedia Flash which reside in the “\Diamond\diamond-parking-war\src\main\webapp\flash” directory. In order to change any navigation features or add any new features. The flash(.fla) files must be edited since the Flash Action_Script (driver code) is nested within these files.

2. Project team information: (Postmortum analysis)

Management objectives and priorities

The team leader will supervise to make sure all members are doing their work and make sure communication is flowing for quality assurance. Individual team members are responsible for finishing their own said tasks, getting help from leader when needed, updating website/logs, and helping other members. Our goal is to produce a well functioning program that will last at DAP for years to come without any trouble. We aspire to make it modern, sleek, and very easy to use.

Final team structure

• Chris – Team Leader, Database Programming
• Will – Graphics, Primary Code Testing
• Kem- Gui Programming, Server setup
• Spencer – GUI design, Interactivity enhancement

Will was the only one whom had a role change. With the current Hibernate Framework, we found that much of the defensive programming was given to us for free and we found more need to implement better graphics.

If we were to start this project again we would follow the same orientation that we ended up with. Everyones roles worked out very well which led to a successful project.

We advise any team who would like to use this structure elect a leader who strictly enforces these roles and has good management skills to ensure that all tasks are being complete.

Evaluations:

Our team was a little disoriented at first since it was our first time working together and some of us were unfamiliar with the framework. However as we figured out the goals of the project each member was caught up and team meetings helped relay each individuals opinions. All individuals were very on task and completed goals that I assigned for the week and I am very happy with the outcome of the project. All members full-filled their roles, regardless of what their roles whether it was in graphics, gui, or database design all members displayed amazing talents and knowledge.

Scheduling and planning

We took on the project in incremental steps with new goals for each week. Originally we met once a week where each member would present their completed tasks. Later we found it very useful to meet two to three times a week and have code development and integration meetings. This allowed for us to provide feedback to other team members and answer any questions if issues arose.

The only issues we came across was related to time availability. Sometimes individuals would not be able to come to meetings due to time conflicts caused by other classes. However we always just rescheduled the meeting so all members could participate.

One very notable tool which we accredit our success to is the Code.Google tool. This tool not only provided us with a code repository, it came with a wiki which all team members have access to, and also provided us with a means to communicate through email. The repository is based on Tortoise SVN which tracks all checked in code and revisions. Whenever conflicts arose we were able to track them down and fix them by reverting to previous revisions. Furthermore since all members had access to the wiki, individuals had the ability to add/modify documents on-the-fly.

We felt that our overall scheduling and planning scheme worked out rather well and no changes would have benefited us.

Support functions

We had a very good quality assurance plan which allowed for us to discover bugs and track them. For defect tracking, we had a page linked from the main project site that described in detail each defect as it was discovered, and recorded progress made on fixing the defect. We were successful in using this defect tracking tool and to date no bugs exist. All of the support functions we used were the ones we had originally implemented and planned on using. We did not adopt any new support functions.

Work with the clients

The team's relationship with Diamond Airport Parking went rather well. Initially we were provided with some starting parameters which we developed into the DAP suite. However it wasn't until much later when we demonstrated the project to DAP. They were very happy with the results and provided us with some helpful feedback. None the less they pointed out some missing features which are important to their day to day operation. If we would have been able to meet with Diamond more often (starting from the beginning of the project) that would have benefitted us in saving time on implementation and adding new features. Dr. A did a great job in being the liason between our client and team and we feel that no improvements can be made.

Work with project mentors

There was little interaction with our project mentor. Most interaction was done via email, and related to submitted documentation.

We felt the interaction with our mentors via email was more than sufficient. However the only issues we dealt with was figuring out due dates for documents based upon the previous years calendar system.

We feel that the way the course is designed should remain unchanged. It was very rewarding for our group to be given space to develop our project alongside developing documentation. We feel that this arrangement most resembles working in the industry and allows for the practice of team work and organization. Other classes that we have taken never challenged us in this sense.

Other issues

N/A

3. Feedback from the mentors

The only feedback we received from mentors was from the professor. He let us know when we weren't keeping up our logs, and in which documents needed to be revised in order to meet expectations. This feedback none the less helped guide us through the project and understand why documentation and project tracking is important.

4. Three general pieces of advice to future students

• 1. If you are working with a sponsor, ensure you have all necessary requirements documented. Ask to see previous systems if they exist. That way you can get a feel for what they need.
• 2. Elect a good team leader to manage the project. Good management equates to keeping all team members on tasks.
• 3. Spend more time programming in groups or pairs, you can learn a lot from other individuals.