Project Analysis

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. Include diagrams/pictures as appropriate.

Overview

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. Explain both the broad purpose of the application, as well as on what part(s) you focused on. Include an estimated time spent on project, for you and for your whole team.

Planning

Document your initial thoughts about the [sub]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 page, each class, each method, and ultimately each line of code contributes to the project as a whole. Reference design concepts discussed during the course.

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 [sub]team's ability to collaborate, interaction, and productivity.

How easy or difficult was collaborating as a team? How did that change over time?
Were git and Jira 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 (including yourself), indicate the tasks (e.g., design, implementation, testing, debugging, documentation, 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 your document (as PDF -- definitely not a .docx or .doc or .odt file ) into the assignment in Canvas.

Grading

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