Final Team Report

CS 4500, Spring 2006

Date due: The date of the team's legacy turn-in meeting.

---

To submit the final report:

• When the final report is complete, send an email message with the URL to teach-cs4500. This message should be sent at least four hours before your team's legacy turn-in meeting to allow an opportunity to read the report before you meet. Use the following subject line on your message:

              CS373tf: <team name> Final Report

where you replace <team name> by your team's name.

• Put the final report in the project web site.
• One hardcopy of the final report will be part of your team's legacy notebook.

Developing the final report: All team members should participate in discussing the answers to the questions in the final report. All members should also review and comment on a draft of the final report. The mentors should be asked to provide comments on the final report as well.

Format: Your final team report will be an inter-office memo directed to the instructor. It should be prepared as an html document.

Naming and location of the final team report: The final team report goes on the team web page  and the name of the file containing the team report should be final_report.html. (See the team reports description.)

There is a page that gives access to the final reports from previous semesters at Texas, which your team can use as examples.

Content of the team report:

1. Product-related information: Some parts of this section may somewhat duplicate information in the final version of your team's README.txt file. Ensure that these documents do not contradict one another.
   • Current status of product:
     • What is the current status of your product?
     • Are there parts of the product that have not been adequately tested?
     • Are there product features that could not be implemented due to time or resource constraints?
   • Recommended work: This list can include topics such as known faults, enhancements of existing features, and suggestions for new features. If the features are described in your SRS or SDS, provide references to the relevant document and section. If the faults are documented in the VVR, provide that information. The goal is to transmit your ideas as clearly as possible.
   • Advice to teams continuing this project: Include information that can help someone starting a new iteration with this project to get it started up again. Include information you feel is important but that is not documented elsewhere in the legacy.
       
2. Project team information:  (Postmortum analysis)
   • Management objectives and prioritories
     • In section 3.1 of the Project Plan, your team defined its management objectives and priorities. Revisit that description and rewrite it in terms of the objectives and priorities that have evolved through the semester.
   • 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:
     • Who was responsible for which tasks?
     • Did you rotate any of the roles?
     • Pretend you are just starting the project armed with your current experience. What would your team change about the team structure (if anything)?
     • What advice do you have for teams wanting to use the same structure?
   • Schedule and planning:
     • Which aspects of your team's scheduling and planning procedures worked well?
     • Which problems did your team have with scheduling and planning?
     • What tools did your team use to assist you in planning and tracking the project?
     • How could your team have improved its scheduling and planning?
   • Support functions:
     • Discuss the effectiveness of your team's Quality Assurance and Configuration Management functions.
     • What procedures did the team establish for defect tracking? How successful has the team been in faithfully using these procedures?
     • What support function lessons did the team learn that would have helped if you had only known them earlier in the semester?
   • Work with the clients:
     • How did your team's relationship with the client worked out?
     • What would you go back and change about this relationship to make it more effective?
     • What could Dr. A have done to make the client-team contact more effective?
   • Work with project mentors.
     • Discuss your team's experiences with the project mentor arrangement.
     • What advice does your team have for how this program can be made more useful from the point of view of the student teams?
     • Which aspects should remain unchanged?
   • Other issues. Bring up any other issues from your team's experiences that should be recorded in this forum. 
        
3. Feedback from the mentors: Ask the mentors for their observations about the team's accomplishments, the mentoring process, or other aspects of this semester's mentoring interactions. One way to stimulate discussion is to provide the mentors with a draft of the other sections of the final report and ask for their comments and suggestions.
   
   In this section the team must summarize, rather than quote, the overall mentor feedback. The report may include the mentor message(s) in an appendix if the mentor gives permission to do so.
     
4. Three general pieces of advice to future S2S teams as they start out. I will add these points to the collection of advice from previous semesters. This will be your advice to future generations of software engineering students.