Objective: For each student to analyze the project objectively and learn from its successes and failures (or maybe just non-successes).

It is important for each team member to review the project's history, analyzing its positive and negative aspects. Typically such reviews are called post-project reviews or "postmortems". The goal of a postmortem is to draw meaningful conclusions to help you learn from your successes and failures. (Remember: good judgment comes from experience.) Despite its grim-sounding name, a postmortem can be an extremely productive method of improving your development practices.

Each team member will analyze his/her experience. You may meet as a team to refresh your collective memory about the project's timeline and how specific key decisions were made, but the analysis itself should be written individually. This document should not attempt to assign blame.

Your analysis will address three distinct topics:

1. a technical evaluation of the project's code and design
2. an evaluation of the progress and decisions made by your team
3. an attempt to assess your overall effort

This should be an honest, thoughtful reflection that aims to identify specific actions that either helped or hurt later in the process. Additionally, it can demonstrate your knowledge of the design concepts of the course that may not be easily represented in other project documentation.

At least the following sections must be included in your analysis. Questions are provided to get you started thinking about what to consider within each section, you may include anything else you feel is relevant. In other words, do not be limited by these questions but include them at least.

Description

Begin with an overview of your project, including a design overview and estimated time spent on project. Describe the product's purpose, intended user, and other general information. This is intended to refresh your memory about the project when you read this analysis again later in your career (e.g., before a job interview!) as well as let me know what problem you thought you were solving.

Describe the three extensions your team implemented and how I can access/use/see these extensions in your implementation.

Planning

Document your initial thoughts about the project, including the initial design plans and what was implemented first.

• How hard did you think this project would be?
• What parts did you think would be particularly easy or hard?
• What specifications did you think were clear or ambiguous?

Status

Analyze the design and coding details of your project. Look over the entire project and determine how each class, each function, and ultimately each line of code contributes to the project as a whole.

• How did you test your code?
• Could you have designed it so that it was easier to test?
• Are there any parts of the design you do not understand? especially like? dislike? If you dislike a part, explain a better alternative.
• Are there any parts of the code you do not understand? especially like? dislike? If you dislike a part, explain a better alternative.
• Do you feel the code accurately reflects the design?
• How did the design change as it was realized in code?
• Are there any parts of the design that did not work when you tried to code them? or worked out better?

Code Analysis Conclusions

What conclusions can you draw from analyzing your code? List both successes and shortcomings in your design.

• Which parts of the code required the most rework?
• Which parts of the design required the most rework?
• What faults occurred most frequently?
• What faults were most time-consuming?
• What can you do to reduce the occurrence of those defects in your future projects?

Collaboration

Analyze the team's ability to collaborate, interaction, and productivity.

• How easy or difficult was collaborating as a team?
• Was Subversion sufficient for allowing collaboration/coordination? What other tools (as in what functionality) would have been helpful?
• What could you have anticipated/planned for better to make collaboration easier?
• For each team member, indicate the tasks (e.g., design, implementation, testing, debugging, managing the group's efforts, etc.) that each team member performed and the percent of the total project work that you believe each team member performed.
• Were the appropriate people assigned to all project roles?
• Were the appropriate number of people assigned to all project roles?
• Any final comments about the group's interaction/productivity?

Future work

No project is ever completely finished. Discuss at least three parts of your project that still need fixing, that you wish you could understand better, or could be extended or made more flexible.

• If you could improve one part that would have the most impact on the application's usefulness, functionality, or usability, what would it be?

Submission

Copy your document (a text or PDF file--definitely not a .doc or .docx or .odt or .rtf) into your final directory in your turnin directory.

Alternatively, you can copy your file into your final directory in your cs209 directory. Then, run submitAssignment.sh final to submit the assignment.

You can create/save the files using Eclipse remotely and run the submitAssignment.sh script, adapting the directions from assignment 6.

Grading

Clear descriptions, articulation of answers to above questions. Evidence of understanding of code design.