Final Project: Reflection

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

Overview

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 their 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.

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. This document should not attempt to assign blame. Additionally, it can demonstrate your knowledge of the design concepts of the course that may not be easily represented in other project documentation.

In addition, past students report that this document is helpful when preparing for job/internship interviews, where you'll be asked about significant development experiences, technical successes/challenges, and team successes/challenges.

The document should be a PDF, txt, or Markdown (md) file.

Analysis Content

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 (both individually and as a team). 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 or four extensions your team implemented. The documentation for using the extensions should be in the README.md.

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 code/design you do not understand? especially like? dislike? If you dislike a part, explain a better alternative.
• 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 and which 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?
• Did every member of your team feel valued? How did you help make your team feel valued?
• Was Git sufficient for allowing collaboration/coordination? What other tools (as in what functionality) would have been helpful?
• What could you have anticipated/planned for 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

Submit via Canvas.

Grading

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