DATE:  April 22, 2005
TO:  Tom Henderson
Brandt Erickson
FROM:  Moki Team
SUBJECT:  Final Team Report

Content of the Team Report
  1. Product-related information

    • Current status of product

      Our product is finished and is up and running on our website. The final product includes the following features:

      • Login to Access Site
      • Create/Manage Customers
      • Create/Scheudle/Manage Trips
      • Create/Manage Reservations
      • Create/Manage Invoices
      • Create/Mangae Employees
      • Business Summary Report
      • Trip Roster Report


    • Recommended Work

      • Create Additional Reports
      • Add ability to charge credit cards
      • Change Style/Layout of tables/pages

    • Advice to teams continuing this project

      • Before adding a new feature, first consult with the company you are developing the product for to see which features they would like to have in the product.
      • If you want to change the style or layout of the pages you should just be able to modify the CSS file used on all of the pages for this site.
      • Each jsp page has a java class assoiciated with it which provides the functions necessary to generate the page and tables.

  2. Project team management

    • Management objectives and priorities

      Each team member was responsible for making his own contribution to the team. With most of the work assigned by a volunteer system, each team member could volunteer for assignments according to his individual abilities.

      As a team, our major goal was to meet the client's specifications, as well as the general class specifications, to the best of our abilities. We also tried to keep up with the expected schedule while not sacrificing quality.

      These objectives remained the same throughout the semester.

    • Final team structure

      Gib was our client liaison. John and Gib were in charge of the database and java classes, while Shawn and Kyungseog were in charge of the jsp pages. Responsibility for documents, presentations, implementation, and other assignments was divided up among team members, largely on a volunteer basis.

      If we were to start the project over again, we would probably try to define roles more clearly and have checks in place to make sure that the workload is spread evenly among team members, without any one team member being overwhelmed.

      If a team wishes to use a similar structure, they should divide team work wisely so that no team member becomes overwhelmed with duties and no team member has significantly fewer duties than the others. If either situation arises, reanalyze the division; have team members learn new skills if necessary.

    • Schedule and planning

      Our team basically followed the assignments schedule to decide coordinate scheduling. Our team held weekly management meetings which helped us to coordinate our efforts and finish our assignments on time.

      Sometimes the weekly management meetings were insufficient and we had to make some last minute planning decisions through email.

      We did not use any tools for scheduling and planning.

      We should have met with the client to discuss design earlier, which would have given us a better idea of what features the product needed.

    • Support Functions

      Our quality assurance and configuration management procedures were effective. Each person was responsible for his own section of the product, with team members encouraged to review each other's work to make sure no mistakes were present. Also, the client was given a chance to review all work on the product and request changes if necessary.

      We had no formal procedure defined for defect tracking. If a defect was noticed, we would send a message to the mailing list describing the defect, and the person responsible for that portion of the product was then responsible for fixing it and sending a message to the list that the defect had been fixed.

      We do not think there are any support function lessons we learned during the semester that would have helped if we had learned them earlier.

    • Work with clients

      We were able to meet with our client and discuss the features to be implemented in our product. Gib also presented our first release to the company which gave us important feedback for the remaining releases.

      It would have been better if we had arranged more meetings with our client so that we could have better understood their specific needs for this product.

    • Work with mentors

      Our mentor was very helpful in editing the documentation for the project. He made many suggestions which we feel improved our documentation.

      Our mentor relationship was very effective. There are no aspects that we would like to change.

    • Other issues

      There are no other issues at this time.

  3. Feedback from the mentors

      N/A

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

    • These projects require a lot of work. The earlier you start the better, that way you will have more time to work on any unforeseen difficulties.
    • You have four people on your team. If you distribute work well, no member should be overwhelmed with work. If one member is overwhelmed with work, redistribute. If work was distributed well and members are still overwhelmed, that is probably a sign that you are trying to do too much.
    • Meet frequently with team members. This will help resolve issues quickly, and will also encourage frequent integration, which will reduce the number of changes you will have to make.