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:
- a technical evaluation of the project's code and design
- an evaluation of the progress and decisions made by your team
- 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.
- Begin with a brief overview of your project, including a design overview. 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. Include an estimated time spent on project.
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?
Analyze the design and coding details of your project. Look over
the entire project and determine how each page, each class,
each method, 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?
- Are there any parts of the code you do not understand? especially like? dislike?
- 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?
- Analyze the team's ability to collaborate, interaction, and
- 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
- If you could improve one part that would have the most impact on the application's usefulness, functionality, or usability, what would it be?
Copy your document (as PDF -- definitely not a .docx or .doc or
.odt file ) named as
final directory in
Clear descriptions, articulation of answers to above questions. Evidence of understanding of code design.